Well, thanks for having me here. I think it's great to have this forum to talk about copyright

and licensing. It's very much needed from my point of view and very much a welcome opportunity.

And as someone said before, I'm not a lawyer. And I've been passionate about 3D open source

software development throughout my career. I must say and admit that in the last 20 years

or so, my thinking about it has evolved dramatically. But I thought I'd just pay tribute to those

who I believe have shaped my thinking around this topic the most, which are these two gentlemen,

Lawrence Lessig and Richard Stahlman. And yeah, highly recommended readings for everyone

who hasn't. But I'm a software engineer. And I will try and give you an overview of the

SKA processes around licensing and copyright. But maybe with a slightly different perspective

from Igor and Yuta, who have been great. And I think this might result complimentary in

some sense. And just a very super quick introduction about the SKA. I believe most of you have

already assisted to the presentation from my colleague, Juan de Santander-Vela last Friday

about the SKA software development process. So I won't duplicate any of that. Just to

say that the SKA software development effort is intended to build a radio observatory,

two telescopes in three countries in three different continents, one of which is an island

in the Brexit time. And this might complicate things or not. And so we are truly globally

distributed effort. And we expect to manage our contribution of more or less 200 people

during construction just in the software development area. And that's more or less the side of

the thing. In order to manage this development process, we've chosen to adopt agile approaches

and management practices. As Juan has already explained in his presentation last week. And

we're using a well-known framework called SAFE for that. Now, why am I saying all of

this? Because there are some particularities which might be shared with other similar projects

which are relevant to the way we license and we treat copyright. So looking at previous

experiences and other projects, it's very clear how many of the biggest issues in these

scientific collaborations are related to communication, to dealing with sharing of information, collaboration.

So we try to put a big emphasis on how we collaborate. So we are involving different

research institutes, universities, private companies from different countries, all with

their own regulations. We might have a high turnover of developers who join and live the

collaboration during the development phase and during the mentoring phase of the process.

We are developing firmware and software with the same practices and regulations. I don't

know if that's the same for everyone, but that's what we are doing. And it has implication

because very often, firmware tends to be more protective. And we're managing both in kind

and cash contribution, as Igor was saying before. And we are not contracting finished

products. Based on our IZEIL approaches, we are contracting effort from our partners.

So we need to control the development process quite closely. And maybe most importantly,

we expect to operate the telescope for 50 years. And this means software will be maintained,

rewritten, thrown away, updated continuously throughout the lifetime of the process. And

so when we started thinking about how we manage the software development with SKA, I believe

my engineer mind naturally goes to bespoke software. So software we have to write from

scratch for the SKA project. Now, the big question is, how do we make our developers

life easy and happy? So we acknowledge from the start that we need to enable a global

collaboration. And that has some cultural aspects and some technical aspects. And very

often we've seen how barriers between work packages, institutes, or getting in the way

of the engineering and actually represent a risk to the project. So we need to efficiently

share information. We need to lower the barrier to contribution. We need that contributing

to the SKA software is easy, as easy as possible, as streamlined as possible. We need everyone

to have access to relevant documentation and processes and everyone to be able to jump

on board and contribute effectively in the lowest amount of time possible. We need visibility

and transparency over the code because we are contracting effort. We need to constantly

verify what is produced in progress. So with regular cadence, we would love as developers,