Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment


Michael Dolan
 

I'm just catching up late on a Friday night and noticed this. I have to say I'm surprised this suddenly went to last call for comments. I guess I missed the prior discussion on the list about this and apologize for showing up late.

I honestly do not understand the rationale for doing this. When someone receives a SPDX file, how would you actually use one of these exception? 

The primary issue I had the first time I heard this suggestion was raised is that the Kernel Enforcement Statement (KES) was always a commitment from an individual author for their contributions. It was never drafted to be a project license or a modifier of a project license. It solely modifies an individual's contribution with additional permissions. So what would you have? The one thing I've always thought SPDX was focused on was laying a factual groundwork for the resultant license determination. And for that determination to survive without having to comb through who made every contribution since the last version. A unilateral additional permission cannot change the license for a project or even a file. I don't see how this would work and will explain my rationale below. 

SPDX-License-Identifier: GPL-2.0-only WITH KernelEnforcementStatement-1.0

I've looked at the details of contributions to a lot of files in the kernel as have others on this list. My assumption is there are likely very few files in the kernel that the statement above could be applied to. If you look at cregit, you can visually see how complicated this would be. I personally would never put that statement into a SPDX file or short identifier of a binary or file from the Linux kernel. 

IMO, and I think many of you would agree, one would have to have ALL authors and copyright owners agree to make the Kernel Enforcement Statement individually before this would be possible. Or ALL the authors would have to relicense the project under a new license with a similar exception added to the new project license. No one has ever made the KES a condition of contributing to the kernel. What reliance could someone take away if they saw that applied? And how many people would incorrectly apply it? That's a real issue IMO.

Further you would have to required contributions to be made with that statement going forward in the future. Who will remove the KES exception when the next person who hasn't made a KES pledge sends in a contribution? How would you know? It takes a TON of compute power and resources for us to track this in cregit for just the Linux kernel - imagine all the dependencies that might be included. The moment someone new contributes, you can no longer rely on any analysis that was previously done for any file or binary associated with KES in a SPDX file. So now you have to redo the entire SPDX analysis - or someone downstream who receives an SPDX file will have to know this nuance and never be able to rely on it for the next version of the kernel they receive?

There are MANY political and other hurdles we had to work through in creating the Kernel Enforcement Statement (KES) with developers in the Linux kernel community and many of the top contributing companies. Karen, Greg and I were deeply involved in that process and it was not easy. I realize I had to miss yesterday's call and haven't had time to catch up with whoever was on, but this is something I would honestly raise my hand and at least say I'm completely opposed to. Maybe I'm alone on this, but it makes no sense to me to do this - it undermines key principles behind the drafting and what it took to get support from nearly 100 maintainers in the kernel community and critical corporate copyright owners of code in the kernel.

I will also point out there have been many unilateral grants of additional permissions. There are patent non-assertions from IBM, Google, and others. Some may relate to a project, some may relate to all OSS projects and some may have nothing to do with OSS but could be applied to OSS in certain uses (e.g. Tesla's). Most have nothing to do with any particular project. Those likewise do not modify the project license. They are not a part of a license or grant from any future contributors to a project either. It's no different than the KES.

The Common Cure Rights Commitment (CCRC) which was based on the KES also applies to an indefinite pool of projects. If one or a few of the companies own all the copyright, my recommendation would be to just relicense the project with an appropriate additional permission as a license modifier and require all new contributors to give the same license. Instead it could apply to N number of projects, many of which we do not know about and for each one it only applies to contributions from that company and it doesn't change the project license. Even if the company wrote all the code in a file today, what happens when NewContributor makes a contribution - now you have to notify everyone to remove the "WITH CCRC-1.0" in the next SPDX review? Unless someone is running cregit and reviewing each of those files they would never know. 

To be clear, I'm a huge proponent of using these cure provisions to surgically reduce some of the issues we've seen. BUT I would never have thought that what we drafted would be used as a project license identifier. We always communicate we were not changing the project license and some of those involved in the discussion in the minutes were very adamant about that themselves. If I may point out Bradley's post (https://sfconservancy.org/blog/2017/oct/20/additional-permissions/) in which he stated, "This begs the question: what's the effective license of Linux? Well, more than likely, it's simply GPLv2-only." I do not understand how this interpretation has changed.

I think if communities want to do this, we should be guiding them to revisit using a CLA or some other means to capture commitments from prior contributors and change the project license itself to include these exceptions in any future contributions. If there was a version drafted to do that, I'd be much more receptive. Imagine GPLv2+CureProvision being the project license in the LICENSE file and what everyone put into the headers - I'm far more comfortable if that were the approach in the projects. There is NO project doing that today and I don't believe the KES or the CCRC were drafted with that intended use.

So I'll return back to my original question - why and how would someone ever insert this into a SPDX statement? What reliance should someone take from seeing that in a SPDX file or SPDX short identifier? Does anyone have an example of a community using it in such a manner?

And now I'll add another - has anyone talked to the contributors to communities who would use this SPDX identifier?  Kate Stewart went through a monumentally difficult task of adding SPDX identifiers into the kernel. Who if anyone has discussed this with the kernel contributors and what was their feedback?

Sorry for the long email, but I thought this topic had been laid to rest and wanted to make sure my view was clear. I'm more than happy to join a future SPDX legal call to discuss but unfortunately had a conflict yesterday. 

-- Mike

---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250   Cell: +1.440.552.5322  Skype: michaelkdolan
mdolan@...
---



On Thu, Nov 29, 2018 at 1:34 PM J Lovejoy <opensource@...> wrote:
Hi all,

Thanks for a productive call today. I’ve posted a summary of the discussion in the meeting minutes here: https://wiki.spdx.org/view/Legal_Team/Minutes/2018-11-29

Please note: there was general approval to adding the Kernel enforcement statement and the GPL Cooperation Commitment to the SPDX License List.  Theses are slated to be added to 3.4 version of SPDX License List, which is scheduled for end of the year. 

If there are any fundamental objections to adding these, that should be raised on the mailing list in the next week.

Any details regarding implementation (markup, naming, etc.) should be discussed on the relevant issues in Github:
or the relevant PR, when created.


thanks,
Jilayne

On Nov 28, 2018, at 10:59 PM, J Lovejoy <opensource@...> wrote:

just realized this only went to Richard.  See corrected meeting time/zones below!

Begin forwarded message:

From: J Lovejoy <opensource@...>
Subject: Re: meeting tomorrow/Thursday
Date: November 28, 2018 at 9:55:47 PM MST
To: Richard Fontana <rfontana@...>

here’s the source of truth: https://wiki.spdx.org/view/Legal_Team

which I usually try not to “quote”!  I know it’s 10am Mountain Time, but I’m the only one in MT, so tried to “translate” to more common time zones (unsuccessfully, its appears in this case!)

so, let me re-phase: the meeting is at 10am MT (9am PT, noon ET, - which should also be 5pm UK time, and 6pm central European time)

Thanks for the catch!

Jilayne



On Nov 28, 2018, at 9:52 PM, Richard Fontana <rfontana@...> wrote:

Should that be 12 noon Eastern time? (or 8am Pacific?)


From: "J Lovejoy" <opensource@...>
To: "SPDX-legal" <spdx-legal@...>
Sent: Wednesday, November 28, 2018 11:20:10 PM
Subject: meeting tomorrow/Thursday

Hi all,


We’ll be back on our regularly scheduled call tomorrow/Thursday at 9am Pacific time / 11am Eastern time / 5pm Central European time. 
Optional dial in number: 415-881-1586
  No PIN needed

We scheduled for this meeting to discuss the way to refer to license exception or “additional permissions” in a broader way. I have drafted some proposed changes to the way we describe this part of the SPDX License List in a Google doc, using tracked changes as compared to the current text. You can see that here: https://docs.google.com/document/d/1vWlwlIN1IKNn-lJMx1iqZ7A2Xb-b3lTZ9WjhRQov-DE/edit?usp=sharing

If you are unable to view that link, the basic premise is to replace “exception” with “license modifier” to use a more neutral and inclusive term. (attempts to download in .pdf or .odt did not include the tracked changes… grrr)

We will also discuss specific requests for:
the Linux kernel enforcement statement - https://github.com/spdx/license-list-XML/issues/655 

the GPL Cooperation Commitment - https://github.com/spdx/license-list-XML/issues/714

as well as the variants for the Google patent grant - https://github.com/spdx/license-list-XML/issues/646 


I’m sorry I didn’t send this sooner to enable some pre-meeting email discussion, but would greatly appreciate if people could have a look at these items prior to the call so we can hit the ground running.


Thanks,
Jilayne




Join Spdx-legal@lists.spdx.org to automatically receive all group messages.