Licensing TN: finalize contents

[jouvin]

Before making the Licensing TN final, a few improvements to the contents are needed:

• Add a reference to LLVM discussion in the difficulty to change licenses and the specific constraints of collaboration with commercial contributors
• Add non CERN examples
• Put a reference to NSF and DOE policy (see Liz's email from Oct. 13)

[hegner]

And

• adding a figure / discussion about compatibilites up- and downstream
• maybe add reference to http://choosealicense.com/

[sextonkennedy]

I talked to the IP expert at FNAL, who is part of the FNAL legal team, after sending him a copy of the draft. He was complimentary (saying he found it rare in the scientific community to find scientist who understood these concepts). He suggested we add a reference to:
https://en.wikipedia.org/wiki/GPL_linking_exception
and I agree with him that this clause has some relevance for our case since many of us use a framework where dynamic loading of libraries is a core strategy in forming our large applications.

[jouvin]

@sextonkennedy I had a look at the (very good) link you mentioned. I am a little bit reluctant to add it. Reading again the current version of the note, I see that we didn't say much about the lincense compatibility. This would probably deserve a whole paragraph and this will be clearly one reference to attach to it. My preference would be to stick on what we said at our last meeting: publish what we have as a v1 and collect feedback to write a v2 this year if needed... What do you think?

[jouvin]

BTW, in a future version, it may be good to address remarks in #5 (comment).

[sextonkennedy]

Hi Michel,

Yes, that is fine.

Cheers, Liz

On Feb 11, 2016, at 10:00 AM, Michel Jouvin notifications@github.com wrote:

@sextonkennedy https://github.com/sextonkennedy I had a look at the (very good) link you mentioned. I am a little bit reluctant to add it. Reading again the current version of the note, I see that we didn't say much about the lincense compatibility. This would probably deserve a whole paragraph and this will be clearly one reference to attach to it. My preference would be to stick on what we said at our last meeting: publish what we have as a v1 and collect feedback to write a v2 this year if needed... What do you think?

—
Reply to this email directly or view it on GitHub #4 (comment).

[valassi]

Hi Michel,

first of all, well done and thanks to you and the other authors, and sorry for the delay in sending my own comments. As I mentioned at some meetings, my main suggestion for improvement is to explain better the issues of license compatibilities and clarify their implications and constraints on our recommendations. (Benedikt had also suggested discussing compatibility in an earlier comment.)

I would for instance add a section 4.1 (moving the current 4.1 to 4.2) as follows (stealing large parts of the CERN Task Force text [1], as well as comments I received from colleagues who were members of that Task Force). This is just a proposal and I very much welcome feedback and suggestions, as there may be something I did not phrase or understand correctly:

<< 4.1 License compatibility

The software stacks used in HEP experiments are generally composed of large numbers of software packages, with complex inter-dependencies on one another. The term license compatibility refers to the problem of combining software programmes (such as the software packages in typical HEP stacks) when they are subject to different licenses that may contain contradictory requirements. This issue and the related terminology are well described in the Annexes to the final report of the CERN Task Force on OSS Licenses [1]. As compatibility is not necessarily reciprocal, compatibility is generally described as a directional property between two licenses. One refers to upstream or downstream compatibility to specify the direction of the license compatibility; when the compatibility direction is not specified, this is usually understood as equivalent to the upstream compatibility. For example, as mentioned above, the Apache v2.0 license is (upstream-)compatible with GPL v3, and GPL v3 is downstream-compatible with Apache v2.0: it is possible for programmes licensed under GPL v3 to incorporate programmes licensed under Apache v2.0, with the resulting work still licensed under GPL v3, but the opposite is not true.

License compatibility is an important factor that the owners of a specific package should keep in mind when choosing the license for their software. Downstream-compatibility, with the licenses of any other programs upon which a given package depends, may effectively restrict the choice of the license that can be adopted for that package, as some licenses might be prohibited by compatibility issues. Amongst the licenses allowed by downstream-compatibility, the most appropriate license for a given package should be chosen taking into account its potential upstream-compatibility with the licenses chosen by the prospective customers of that package: the choice of a particular license for a package may in fact be an encouragement or a deterrent for other people to use that package within their software. These considerations are reflected in the HSF recommendations described in section 5 below. >>

I would also suggest that we should include a section with specific practical recommandations about licensing and copyright not for new software projects, but rather for existing HEP software projects that have not yet clarified their license and copyright. This is a relatively frequent and potentially more complex case to address (as hinted in the section about "Changing the License"). But I have no suggestions myself about what we should write and I would welcome suggestions from others.

Finally, I also have a few specific comments on the text too

• page 1, 3rd line: setup -> set up
• page 2, 4th line: "A software license..." should start a new paragraph/bullet (it is a different key term from "public domain software")
• page 2, 2nd and 3rd bullet, I would make two improvements: first, make it clear that "free software licenses" and "restrictive license" are two terms for the same thing (are they?); second, have a separate bullet for these restrictive licenses, or maybe better merge them in the last bullet. For instance, start new paragraph after "copyright holder", as follows:
  << Open source licenses broadly divide into free software licenses (also known as restrictive software licenses) and permissive software licenses. Restrictive software licenses [in italic] include "copyleft" provisions, which require all future versions to also be distributed with these freedoms. Permissive software licenses [in italic] do not impose... >>
• page 3: reference [5] is mentioned after reference [6], I would swap them
• page 5 section 4.3: the "and so" before "commercial exploitation" should probably be removed?
• general comment, the terms "licence" and "license" are used in the text: both are valid, but I would suggest choosing one and sticking to it

In any case, you proposed to publish v1 as it is and include further comments only in a future v2, and I agree with that, especially for the larger chunks of comments I sent. Or maybe you could just incorporate the specific formatting suggestions if you agree, and delay significant content additions to a later time, as you prefer.

Thanks,
Andrea

[hegner]

@valassi - the easiest would be if you would implement the concrete formatting suggestions and create a pull request for them. IMHO that should be the standard procedure anyhow for "trivial" changes.

[valassi]

I have created pull requests #7 for the trivial changes and #8 for the addition of the Licence Compatibility section. (I realise now I have also included the pdf changes which was maybe not optimal, please rebuild the pdf from tex if/after accepting the pull requests).

[jouvin]

Time to close this issue now that the TN has been published. See #9 for follow-up work.