Re: meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment
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.
On Thu, Nov 29, 2018 at 1:34 PM J Lovejoy <opensource@...> wrote: