Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Licensing TN: finalize contents #4

Closed
jouvin opened this issue Nov 9, 2015 · 9 comments
Closed

Licensing TN: finalize contents #4

jouvin opened this issue Nov 9, 2015 · 9 comments

Comments

@jouvin
Copy link
Contributor

jouvin commented Nov 9, 2015

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
Copy link
Member

hegner commented Nov 9, 2015

And

@sextonkennedy
Copy link
Member

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
Copy link
Contributor Author

jouvin commented Feb 11, 2016

@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
Copy link
Contributor Author

jouvin commented Feb 11, 2016

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

@sextonkennedy
Copy link
Member

Hi Michel,

Yes, that is fine.

Cheers, Liz

On Feb 11, 2016, at 10:00 AM, Michel Jouvin [email protected] 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
Copy link
Member

valassi commented Feb 11, 2016

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
Copy link
Member

hegner commented Feb 11, 2016

@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 pushed a commit to valassi/HSF-documents that referenced this issue Feb 11, 2016
valassi pushed a commit to valassi/HSF-documents that referenced this issue Feb 11, 2016
valassi added a commit to valassi/HSF-documents that referenced this issue Feb 12, 2016
valassi added a commit to valassi/HSF-documents that referenced this issue Feb 12, 2016
@valassi
Copy link
Member

valassi commented Feb 12, 2016

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).

valassi added a commit to valassi/HSF-documents that referenced this issue Feb 12, 2016
Trivial formatting changes as discussed in issue HSF#4
@jouvin
Copy link
Contributor Author

jouvin commented Feb 28, 2016

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

@jouvin jouvin closed this as completed Feb 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants