Licensing AT

[lfarv]

During the AT workshop, we raised the question of the adequate license for AT. The question reappeared in #747.

Does any of you have proposals ? I remember that @lnadolski had ideas based on Soleil experience.

[oscarxblanco]

Dear all,
I've been contributor of a few lines of code that I would prefer to be open source, for example a GNU licence.

[lfarv]

From what I could read (I'm not at all a legal expert), GNU licenses are rather restrictive. Seems that any use of AT would need to be submitted to the same license.

I found a sorted list here. About "permissive" licenses I also found "Collective Commons 0" (CC0) and "BSD zero clause" (0BSD).

[oscarxblanco]

Dear @lfarv ,
thank you for the link. From experience I would suggest a license that forces disclosure of the source code.

This is important to have when using the code on a new project that requires novelties or modifications to the original, or when development is inactive for many years and it needs to be brought back to live. In that sense, and considering other than GNU, from the link you sent it seems Mozilla Public License 2.0 could be adequate. New contributions will have the freedom to publish their new code with any other licence they prefer.

Otherwise, if I may point to other options, there is EUPLv1.2 which is compatible with the EU regulation on software, and from what I remember about five years ago LNF/INFN (at Frascaty, Italy) was promoting its usage. I leave here a link to the licence and to an european comparison tool :
https://joinup.ec.europa.eu/collection/eupl/news/eupl-or-gplv3-comparison-t
https://joinup.ec.europa.eu/collection/eupl/solution/joinup-licensing-assistant/jla-find-and-compare-software-licenses

[lfarv]

@oscarxblanco : the European comparison tool is very useful!

From what I could see:

I am not in favour of licenses qualified as copyleft / reciprocal / contaminating. The ones which would force any use of AT to be submitted to the same or compatible license.

Among the rest, it looks like there are 2 categories:

• the so-called "permissive" licenses: "MIT", "Apache 2", "BSD 2", "BSD 3", "CeCILL-B"… Users have a large freedom on the use of the software, this is my favourite class, just ensuring that the origin of the software is mentioned,
• The "public domain" licences: "The Unlicensed", "Creative Commons 0", "BSD Zero Clause". Even no copyright is kept

I see a potential problem with licenses maintaining a copyright (most of them): you need first to identify the owners of the rights on the software ("The Authors"), and get the consent of all of them. What about us? Can we use a collective term like "AT contributors"?

Another related problem: in some cases (at least according to French law), for someone contributing to AT on his working time, as for many of us, the contributor is the employer ! Which means that the license should be accepted by all the labs… It would be interesting to have examples of how the various labs deal with other open-source software.

The "Open Source Initiative" (OSI) maintains a list of OSI-approved licenses, compliant with their open-source definition. This could also be a criteria in the choice.

[oscarxblanco]

I see, in that case my employer was SOLEIL (France) and now ALBA (Spain).
For SOLEIL I will wait for @lnadolski 's word on the topic, and for ALBA I will ask or maybe @ZeusMarti already knows what could apply.

[MJGaughran]

Diamond has a preference for Apache 2, although we also have no issues with MIT or BSD.

I should note that these are also included here, although as I am not French I don't really know what that implies!

[oscarxblanco]

ALBA has no preference for the moment.

[lfarv]

Here is a list a compiled from:

• SPDX which gives the detail and text of each license
• and this. (thanks @oscarxblanco, the comparison tool is nice)

You may also look at this GNU article

I tried to sort the licenses according to permissivity, together with what I understand from it.
I also kept only widely used ones, so others may be considered, of course.
Some license texts are very long (GPL), some are only a few lines, so comparison is difficult.

I also mention if the license is:

• approved by OSI as compliant with their Open Source definition
• considered as free software by the Free Software Foundation
• GPL compatible (can be used in a GPL-licensed derivative)

"Copyleft", also known as "reciprocal" or "contaminating"

From my understanding, any derivative work using and redistributing AT (as it is or modified) must use the same license (or a compatible one). This is quite restrictive, may be too much in my opinion.

	OSI	FSF	GPL compatible
CeCILL-2.1	X	X	X
EUPL-1.2	X	X
GPL-3.0	X	X	X

"Lesser copyleft"

Slightly more permissive: using and redistributing AT unchanged allows the derived work to be covered by any license (while AT keeps its own). But redistributing a modified AT needs disclosing the modifications and keeping the original license for the whole package. This looks fine for me.

	OSI	FSF	GPL compatible
CeCILL-C		X
LGPL-3.0	X	X	X

"Permissive"

Authorises merging AT (modified or not) under any license. Copyright and license text must be kept. Only Apache 2 specifies that any modification to the software must be disclosed and documented. It's therefore my favourite in this category.

	OSI	FSF	GPL compatible
Apache-2.0	X	X	X
BSD-2-Clause	X	X
BSD-3-Clause	X	X	X
CeCILL-B		X
MIT	X	X	?

Public domain

No restriction, no copyright, the code is then in the public domain. Only the liability clause: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, and so on".

	OSI	FSF	GPL compatible
BSD 0 Clause	X
Unlicensed	X	X	X
CC0		X

In the end, my preference goes to:

• LPGL-3.0 in the more restrictive category,
• Apache-2.0 in the more permissive, recommended by GNU "for small programs" !

Still to to be answered: who is the copyright holder? May we use a general term like:
"Copyright (C) 2024, The AT Collaboration"

[MJGaughran]

I agree with using Apache-2.0, as it is permissive and widely adopted.

For copyright, as far as I can find it is held by all co-authors / contributors, while the AT Collaboration is a separate (but overlapping) group of people.

Perhaps something like:
"Copyright (C) 2024, The Accelerator Toolbox authors"?

You can create a separate file to list these people, but we could also consider VCS to be the sole source of information here.

[swhite2401]

Hello, I also think the more permissive Apache-2.0 is better suited for our needs.

Concerning the copyright, this is a bit more delicate in my opinion, there has been many contributors over time, some are now inactive, and it may be difficult to list them and get their approval.

The proposal by @lfarv "The AT Collaboration" seems fine to me.

Shall we implement this? How do we proceed? I would be good to sort this out rapidly.

[lnadolski]

For SOLEIL, recommended licenses compatible with EUPL are:

• CeCILL
• GNU GPLv3.0
• EUROPEAN UNION PUBLIC LICENCE EUPL

This may be not compatible with our needs.
if the copyleft is too strong, LGPL could also be a good option.

Do you know this site?
https://choosealicense.com/

[lfarv]

@lnadolski: the licenses recommended for Soleil are all in the "strong copyleft" category. LGPL v3.0 is in my preference list, though I still find it rather restrictive.

Shall we implement this? How do we proceed? I would be good to sort this out rapidly.

I think we should first get an agreement within the so-called "AT development board".

• on the license itself: I don't think we can get a formal agreement of all the labs where people contribute on their working time. Can we skip this?
• on the copyright: as Simon, I think that listing all the contributors, and getting their formal approval, is impossible, so we should find a "global" term. it's true that "The AT collaboration", as defined on GitHub, is a well-defined list of people which does not include all authors (A. Terebilo !). But more generally I like the term.

Then we can add the license text to the repository and make a new release (minor or major).

The distribution on PyPI does care too much about licenses. On the other hand, Matlab Central asks for a license but puts a default one in case we don't provide it, as it is the case now. And conda-forge insist on having a license, so we should make a decision.

[MJGaughran]

The copyright notice does not affect who holds copyright.

This is the problem with using a term such as 'The AT collaboration'; it does not actually hold copyright and cannot claim copyright. That is why I recommend a term such as 'The Accelerator Toolbox authors'.

[swhite2401]

I think we should first get an agreement within the so-called "AT development board".

I have setup the meeting for the 2nd of April

[lfarv]

'The AT collaboration'; it does not actually hold copyright and cannot claim copyright.

Why? I thought it would… Can you explain?

Anyway, I looked around, and found for instance on the numpy license:

Copyright (c) 2005-2024, NumPy Developers.
All rights reserved.

That looks perfect, Accelerator Toolbox Developers is fine for me

[MJGaughran]

Copyright is held by the individual contributors (often the employer). The AT collaboration is a separate group of people; it does not hold copyright.

I am happy with Developers etc.

[lfarv]

Another information concerning license texts: among the "permissive" ones;

• the MIT license is 16 lines long,
• the BSD 3-clause is 23 lines long,
• the Apache 2 is 201 lines long

I imagine nobody can read the Apache license… However I confirm that it's the only one which specifies that changes to the licensed software must be documented.

[MJGaughran]

We also currently have no right to apply a license to these files.

I understand the difficulty in communicating with previous contributors, but it is difficult to talk about the legal implications of various license files when we have that elephant in the room with us...

[MJGaughran]

A lot of this is probably simplified by the fact that the copyright owner is typically the employer.

[lfarv]

For those who have an employer :-)

[MJGaughran]

I'm hoping that we have your permission for this!