Date
1 - 5 of 5
New Exception Request: GPL Cooperation Commitment 1.0
|
Richard Fontana
Heya, This is a request for addition of the GPL Cooperation Commitment version version 1.0 to the SPDX list of License Exceptions ( https://spdx.org/licenses/exceptions-index.html ) 1. Proposed Full Name: GPL Cooperation Commitment 1.0 2. Proposed Short Identifier: GPLCC-1.0 3. URL reference: https://github.com/gplcc/gplcc/blob/eee52346dd48bdf985657f082bb847f12f40c464/Project/COMMITMENT 4. Text of exception is attached 5. This exception has not been approved by the OSI nor has it been submitted to the OSI for approval 6. Short explanation: Last year Red Hat started an initiative, which we now call the GPL Cooperation Commitment, to encourage companies, individual developers, and open source projects, to extend the cure and repose period commitments in GPL-3.0 section 8 to code under GPL-2.0-only, GPL-2.0-or-later, LGPL-2.0-only, LGPL-2.0-or-later, LGPL-2.1-only, and LGPL-2.1-or-later. As part of this effort, we created a "project" variant of the commitment language, and we announced that henceforth new Red Hat-initiated projects opting to use GPL-2.0-or-later or LGPL-2.1-or-later [1] would be expected to supplement the license with the commitment language, with the official text of the project variant of the commitment, titled GPL Cooperation Commitment Version 1.0, published at https://github.com/gplcc/gplcc/blob/master/Project/COMMITMENT A few existing Red Hat-maintained projects also recently began using the commitment, but this was done using an earlier title, the "Common Cure Rights Commitment". We're in the process of updating these projects so that they will use the commitment language under the new title (GPL Cooperation Commitment). Note that the text of the commitment language has not changed apart from the title. Here are a few examples of projects currently using the commitment language: https://github.com/wildfly/wildfly/blob/master/COMMITMENT https://github.com/wildfly/wildfly-core/blob/master/COMMITMENT https://github.com/pulp/pulp/blob/master/COMMITMENT (currently uses old title) I discussed the new expectation of use of the GPL Cooperation Commitment by Red Hat-initiated projects in a blog post: https://www.redhat.com/en/blog/gpl-cooperation-commitment-and-red-hat-projects?source=author&term=26851 (Note that this refers to the commitment file as "an additional permission extended to users".) While project adoption of the GPL Cooperation Commitment is in its very earliest stages, we anticipate that over time a significant number of projects may adopt it, and that it will appear also as a license document in or accompanying a number of commercial software products. To be candid, Red Hat is primarily interested in having GPLCC-1.0 be added to the SPDX exception list because we think this will lend prestige and legitimacy to the commitment and ultimately encourage its adoption by projects, developers and organizations. But we think from the SPDX perspective adding GPLCC-1.0 is justified because its use by projects and appearance in downstream products and distributions is likely to grow, even if slowly. Note that there is a pending exception list addition proposal, https://github.com/spdx/license-list-XML/issues/655, for the Linux Kernel Enforcement Statement, which similarly extends the GPL-3.0 cure language. However this is, as Bradley Kuhn says in a comment to that issue, "drafted somewhat differently and therefore presumably should be analyzed differently so as not to conflate apples and oranges ". It is also not designed as a project-wide commitment but rather is signed on to by particular named individual developers, while GPLCC-1.0 is by design adopted by a project and applicable to contributions to the project following the date of adoption (note definition of "We".) Finally, the Linux Kernel Enforcement Statement is specific to one project, the Linux kernel (and one license, GPL-2.0-only), while GPLCC-1.0 is designed to be usable by any project that uses GPL-2.0-only, GPL-2.0-or-later, LGPL-2.0-only, LGPL-2.0-or-later, LGPL-2.1-only, or LGPL-2.1-or-later. Richard [1] Nowadays, for Red Hat-initiated projects, we don't normally approve the use of LGPL-2.0-only / LGPL-2.0-or-later, and we don't normally approve the use of GPL-2.0-only. |
|
|
|
On četrtek, 18. oktober 2018 13:08:59 CEST Richard Fontana wrote:
But we think from the SPDX perspective adding GPLCC-1.0 isI think this is a very likely situation. And to be honest, if I see some source code under e.g. GPL-2.0-only and the author¹ signed the GPLCC-1.0, I would much prefer having that expressed in a simple and uniform (SPDX) statement instead of having to check a website every time for every project and every author. +1 from me cheers, Matija Šuklje — 1 Disclosure: I signed it in my personal capacity. And my employer, Liferay, did as well. So that is an additional incentive for me to be able to mark code with it. -- gsm: +386 41 849 552 www: http://matija.suklje.name xmpp: matija.suklje@... sip: matija_suklje@... |
|
|
|
Richard Fontana
I previously wrote, referring to
https://github.com/spdx/license-list-XML/issues/655 as Bradley Kuhn says in a comment to that issue, "drafted somewhatOn further thought, there are actually more underlying similarities than differences between these two exceptions. I believe it would be productive for them to be considered and discussed at the same time. Re-reading the GitHub issue, I remembered that this list had an earlier thread about whether an SPDX identifier would be appropriate for the commitment texts published by Red Hat and other companies at the launch of what we now call the GPL Cooperation Commitment initiative. Since that time, the GPL Cooperation Commitment has been slightly expanded to include a form suitable for inclusion in source trees, much as the Linux Kernel Enforcement Statement is included in the kernel source tree. Bradley, given that, what are your feelings on this at this point? Would you be comfortable at this point considering them together? Richard |
|
|
|
J Lovejoy
Hi Richard, all,
toggle quoted message
Show quoted text
I have not had a chance to post the minutes from today’s call, but this conversation is something we touched upon in terms of planning for post-3.3 release. I agree that it would be productive to discuss these at the same time, as well as the larger issue of potentially revising the description (and possibly name) of the “exceptions”. I’d like to “schedule” that discussion for a particular call to ensure we have all the key relevant parties, which I consider to include you, Bradley and/or Karen, as well as someone from Google (we also need to deal with the Google patent grant), and the usual SPDX legal folks, of course. Our next call is Nov 1st, but it doesn’t sound like that will work for Bradley and is quite soon. I may need to cancel the Nov 15th call due to me being unavailable Thus, can we all aim for the Nov 29th call? Of course, happy to carry on the discussion on the mailing list in the meantime. Thanks, Jilayne On Oct 18, 2018, at 2:03 PM, Richard Fontana <rfontana@...> wrote: |
|
|
|
Bradley M. Kuhn <bkuhn@...>
J Lovejoy wrote just now:
I agree that it would be productive to discuss these at the same time,I was on the call today as well, and as I mentioned there, I was the person who initially asked they be considered separately, but as Fontana says.... Fontana wrote: ...the GithHub issue was filed and discussed was *before* the GPL CooperationRe-reading the GitHub issue, I remembered that this list had an earlier Commitment was written down as an additional permission designed for licensing. Now that the Cooperation Commitment and Kernel Enforcement Statement are both written up this way, we should certainly talk about them together. Thus, can we all aim for the Nov 29th call? Of course, happy to carry onYeah, Nov 29th is fine for me, thanks for accommodating my and Karen's schedule. I'm glad to discuss it on the mailing list in meantime if folks want that too! -- Bradley M. Kuhn Pls. support the charity where I work, Software Freedom Conservancy: https://sfconservancy.org/supporter/ |
|
|