GPL Cooperation Commitment
Towards the end of 2018, Richard Fontana submitted the GPL Cooperation Commitment for review to be added to the SPDX License List. We had some discussion about how that might work, but due to some other issues that took up more time and it being close to the December release, it got tabled for this release.
David Levine, Richard and I chatted the other day to review what Red Hat’s intentions are for the 3 variants of the GPL Cooperation Commitment and how that maps (if at all) with the SPDX License List and use of the SPDX identifiers.
There are 3 variants of the GPL Cooperation Commitment, as follows:
1) Company commitment: made by company for all its specific copyright in any L/GPL-2.x code. In this case the commitment text is implemented by posting it on the company website, and a centralized list of companies is maintained here: https://github.com/gplcc/gplcc/blob/master/Company/Company-List.md
2) Individual commitment: similar to corporate commitment, but applies at individual copyright holder level; a list of individuals is maintained here: https://gplcc.github.io/gplcc/Individual/README-INDIVIDUAL.html
3) Project commitment: to be applied at the project level, effective for all contributors after the date the commitment was implemented. The commitment text file is intended to be placed in the directory along with a copy of the L/GPL-2.x license it applies to. https://github.com/gplcc/gplcc/blob/master/Project/COMMITMENT
The analysis that David, Richard, and I came up with is that the Company and Individual commitments are not appropriate for SPDX License List or use of the short identifiers, as they are applied as a commitment by a specific copyright holder, not tied to specific code or project, and implemented in a separate manner from the relevant code. (This is somewhat similar to the Linux kernel enforcement statement, but we already discussed that for the last release, so I’d highly appreciate if this thread is limited to discussion on the GPL-CC)
Because the Project commitment is intended to be applied directly to the code of a project as of a certain date, this is more well-suited to the SPDX License List and use of the short identifiers, as follows:
(3a) The Project commitment could be applied to an existing project, in which case the commitment would apply to all contributors to the project after that date. In this case, the use of SPDX identifiers for file-level information (be it in a SPDX document, bill of materials, or in individual source files) would have to be carefully limited to only files with copyright on contributors more recent than the date the cooperation commitment was implemented. This could make use of SPDX identifiers a challenge from a practical perspective, but there is also the potential that over time, the project evolves into a state where the cooperation commitment subsumes all contributors for specific files or for the whole project even.
(3b) The Project commitment could also be applied to a new project that that decides it wants to use L/GPL-2.0-only or L/GPL-2.0-or-later along with the cooperation commitment. In this case, it would be easy to use the SPDX identifiers as usual for file-level information (be it in a SPDX document, bill of materials, or in individual source files) with the license expression (for example):
GPL-2.0-only WITH GPL-CC-1.0
A couple people have recently asked about this kind of thing, appropriately, so it seems there is some potential demand for its use already.
Given the intent of the Project commitment to be applied as a modifier to the existing license for a project (as of a certain date) and the ability and applicability to use the SPDX identifier for accurate license identification, especially for a use-case that exists today (3b particularly), we reasoned that adding the Project commitment makes sense, but as stated above, the Company or Individual commitment variants do not fall under the same category.
We also recognized that given the nature of the Project commitment applying as of a specific date and that could be confusing for existing projects; as such Red Hat will look into augmenting their existing webpage with some FAQs to help clarify any likely questions around that.
We have a release coming up soon and I believe we already have a PR that is mostly ready, so if there are any objections or questions about this approach, please respond here.