New Exception Request: GPL Cooperation Commitment 1.0

2018-10-18 Thread 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. 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2410): https://lists.spdx.org/g/Spdx-legal/message/2410
Mute This Topic: https://lists.spdx.org/mt/27401456/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



COMMITMENT
Description: Binary data


Re: New Exception Request: GPL Cooperation Commitment 1.0

2018-10-18 Thread Matija ?uklje
On četrtek, 18. oktober 2018 13:08:59 CEST Richard Fontana wrote:
> 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.

I 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.suk...@gabbler.org
sip:matija_suk...@ippi.fr




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2411): https://lists.spdx.org/g/Spdx-legal/message/2411
Mute This Topic: https://lists.spdx.org/mt/27401456/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: New Exception Request: GPL Cooperation Commitment 1.0

2018-10-18 Thread 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 somewhat
> differently and therefore presumably should be analyzed differently
> so as not to conflate apples and oranges".

On 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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2413): https://lists.spdx.org/g/Spdx-legal/message/2413
Mute This Topic: https://lists.spdx.org/mt/27401456/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: New Exception Request: GPL Cooperation Commitment 1.0

2018-10-18 Thread J Lovejoy
Hi Richard, all,

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  wrote:
> 
> 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 somewhat
>> differently and therefore presumably should be analyzed differently
>> so as not to conflate apples and oranges".
> 
> On 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
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2414): https://lists.spdx.org/g/Spdx-legal/message/2414
Mute This Topic: https://lists.spdx.org/mt/27401456/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: New Exception Request: GPL Cooperation Commitment 1.0

2018-10-18 Thread Bradley M. Kuhn
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:
> > 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.

...the GithHub issue was filed and discussed was *before* the GPL Cooperation
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 on
> the discussion on the mailing list in the meantime.

Yeah, 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/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#2415): https://lists.spdx.org/g/Spdx-legal/message/2415
Mute This Topic: https://lists.spdx.org/mt/27401456/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-