Linux kernel enforcement statement discussion


J Lovejoy
 

Hi all,

I was hoping that others long-standing members of the SPDX legal community would jump in on this thread, but a few days have gone by now and no further discussion, so let me summarize some pertinent background, where I think we are, and any remaining questions or issues that need to be resolved. Please read the whole thing and respond accordingly to the specific questions included at the end of this email. 

A few keys things about the Linux kernel enforcement statement:

1) The Linux kernel enforcement statement (KES) was adopted Oct 2017 and includes a list of individuals copyright holders and company copyright holders (by way of employee contributors) who have agreed to the terms of the KES. 

2) The understanding then, as well as now, is that the KES only applies to those persons or entities whose name appears on the list in the kernel tree here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/kernel-enforcement-statement.rst

3) Additional kernel copyright holders are welcome to add their name to the list at any time. 

4) As it stands today, not every copyright holder in the kernel has signed on to the KES. Therefore, the KES applies only to those copyright holders listed. For the KES to apply to a specific entire file in the kernel, all of the copyright holders of that file would have had to agreed to the KES.

5) Contributions to the Linux kernel are made under the Developer’s Certificate of Origin which states that the contribution is submitted "under the open source license indicated in the file

6) Additional note: The overall drafting and adoption of the KES was a project that involved many, many people in various organizations and, most notably, kernel maintainers and copyright holders, who, as per how the kernel is governed, held the ultimate decision to adopt the KES. Such wide and varied support was critical to it being adopted at every level - and this is something all of the people involved in this effort in any way can be proud of.  Comments as to who worked the hardest or who thinks they deserve credit for this effort are completely irrelevant and unhelpful here (same statement goes for emails outside this list) and will be ignored (at least by me).  


A few key reminders about the SPDX License List: 

7) The purpose of the SPDX License List is to enable easy and efficient identification of free and open source licenses and exceptions in an SPDX document, in source files or elsewhere.

8) To be added to the list, the review includes looking at use “in the wild”, is it free and open?, is it not already on the list when accounting for matching guidelines. The review and decision as to what is added to the SPDX License List is the domain of the SPDX legal community.  To my knowledge, we have not had much controversy over such decisions and have always been able to come to a decision based on broad consensus. 

9) The “exceptions” part of the list includes things that grant an exception to a license condition or additional permission or some other such modification to the underlying license. These are not stand alone licenses. This part of the list started with capturing many of the well-known GPL exceptions (e.g., GCC, Autoconf, Bison, etc.) but is not limited to those kinds of things specifically. 

Important note: Based on the discussion on the call and on the email list. I don’t think any of the items stated above are in dispute.


Regarding adding the KES to the SPDX License List:

A) There was some discussion (perhaps not on this list, but between Mike Dolan and I as part of other conversations) about whether the KES would need an SPDX identifier and how that might be applied. Given the intent for copyright holders to sign up on an individual basis (not adoption at the project or file level) that did not seem needed or tenable at that point.  Later (in June 2018), Karen Sandler submitted an issue in the Github repo to add the KES to the SPDX License List. We finally got around to discussing on a call, with some prior discussion on email list and announcement as to date of call on Nov 29th - essentially one year after the KES was initially adopted. 

B) As to the general requirements for a license or exception to be added to the SPDX License List, there is no dispute that it is a free and open source exception and that it is used in the wild (in terms of existing). 

C) The issue comes down to how the short identifier would be effectively used due to the KES's slightly different implementation as described above in 1-6. 

C-i)  James has provided two examples for the Linux kernel specifically and also explained general process for accepting a short identifier on a file in the kernel. Those two examples can be described as: 1) a patch to change an existing file’s SPDX tag to include the KES identifier, would require all authors and contributors to that file to have agreed or agree to the KES. If that were not the case, the patch would be rejected; and 2) a wholly new file is contributed with an SPDX tag including the KES identifier, which would likely be accepted and would mean that any contributions to that file going forward would also be under the KES. 

C-ii) Another possible use that I thought of is as follows: An individual or company that has already signed on to the KES may release some Linux-related code elsewhere either because it doesn’t make sense to upstream it or before it has been accepted upstream. In effort to be consistent with Linux licensing and their own KES commitment, they might want to signify that their Linux-related code is provided under the KES commitment up front. To do this, they’d have to reproduce the statement from the kernel, but probably modify some of the preamble or something along those lines and would not have an easy way to refer to this at the file level. While I do not know of such an example, based on experience, I don’t think this is far-fetched. 

C-iii) There is also the possibility that people might incorrectly use the KES in the kernel where it shouldn’t be and consequently make it appear that some contributors had agreed to the KES who had not explicitly done so via adding their name to the list and this would then mean the license identifier was not completely correct. 


D) The other implementation question relates to what part of the KES text that appears at the above link is the matchable, pertinent text for purposes of the SPDX License List?  My initial thinking is it would only be the 3 indented paragraphs, as the first two paragraphs seem more like a preamble and everything from “Our intent…” onward is stating intent and other more aspirational text than defining an exception or modification to the underlying terms of the kernel license (GPL-2.0-only). 


Can I please hear some additional thoughts as to the risk and potential outcomes of C, particularly C-iii from anyone who has this concern, as well as some of the long-standing members of the SPDX Legal team?  

Additionally, some thoughts as to D would be helpful.


Thanks,
Jilayne
SPDX Legal co-lead



Dennis Clark
 

I think that a KES Exception on the SPDX list should consist only of the three indented paragraphs in the text at
basically lines 18-36. 

I also think that anyone shold be able to use this exception, and all names of the individual participants are irrelevant. 

The various statements of intention and explanation are just that -- not part of the exception itself.

The usage sould simply be something like "GPL-2.0-only WITh KES-Exception". 

Concerns about anyone using it incorrectly are also irrelevant to putting the exception on the SPDX list.

Regards,
Dennis Clark
nexB Inc.


On Mon, Dec 10, 2018 at 2:58 PM J Lovejoy <opensource@...> wrote:
Hi all,

I was hoping that others long-standing members of the SPDX legal community would jump in on this thread, but a few days have gone by now and no further discussion, so let me summarize some pertinent background, where I think we are, and any remaining questions or issues that need to be resolved. Please read the whole thing and respond accordingly to the specific questions included at the end of this email. 

A few keys things about the Linux kernel enforcement statement:

1) The Linux kernel enforcement statement (KES) was adopted Oct 2017 and includes a list of individuals copyright holders and company copyright holders (by way of employee contributors) who have agreed to the terms of the KES. 

2) The understanding then, as well as now, is that the KES only applies to those persons or entities whose name appears on the list in the kernel tree here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/kernel-enforcement-statement.rst

3) Additional kernel copyright holders are welcome to add their name to the list at any time. 

4) As it stands today, not every copyright holder in the kernel has signed on to the KES. Therefore, the KES applies only to those copyright holders listed. For the KES to apply to a specific entire file in the kernel, all of the copyright holders of that file would have had to agreed to the KES.

5) Contributions to the Linux kernel are made under the Developer’s Certificate of Origin which states that the contribution is submitted "under the open source license indicated in the file

6) Additional note: The overall drafting and adoption of the KES was a project that involved many, many people in various organizations and, most notably, kernel maintainers and copyright holders, who, as per how the kernel is governed, held the ultimate decision to adopt the KES. Such wide and varied support was critical to it being adopted at every level - and this is something all of the people involved in this effort in any way can be proud of.  Comments as to who worked the hardest or who thinks they deserve credit for this effort are completely irrelevant and unhelpful here (same statement goes for emails outside this list) and will be ignored (at least by me).  


A few key reminders about the SPDX License List: 

7) The purpose of the SPDX License List is to enable easy and efficient identification of free and open source licenses and exceptions in an SPDX document, in source files or elsewhere.

8) To be added to the list, the review includes looking at use “in the wild”, is it free and open?, is it not already on the list when accounting for matching guidelines. The review and decision as to what is added to the SPDX License List is the domain of the SPDX legal community.  To my knowledge, we have not had much controversy over such decisions and have always been able to come to a decision based on broad consensus. 

9) The “exceptions” part of the list includes things that grant an exception to a license condition or additional permission or some other such modification to the underlying license. These are not stand alone licenses. This part of the list started with capturing many of the well-known GPL exceptions (e.g., GCC, Autoconf, Bison, etc.) but is not limited to those kinds of things specifically. 

Important note: Based on the discussion on the call and on the email list. I don’t think any of the items stated above are in dispute.


Regarding adding the KES to the SPDX License List:

A) There was some discussion (perhaps not on this list, but between Mike Dolan and I as part of other conversations) about whether the KES would need an SPDX identifier and how that might be applied. Given the intent for copyright holders to sign up on an individual basis (not adoption at the project or file level) that did not seem needed or tenable at that point.  Later (in June 2018), Karen Sandler submitted an issue in the Github repo to add the KES to the SPDX License List. We finally got around to discussing on a call, with some prior discussion on email list and announcement as to date of call on Nov 29th - essentially one year after the KES was initially adopted. 

B) As to the general requirements for a license or exception to be added to the SPDX License List, there is no dispute that it is a free and open source exception and that it is used in the wild (in terms of existing). 

C) The issue comes down to how the short identifier would be effectively used due to the KES's slightly different implementation as described above in 1-6. 

C-i)  James has provided two examples for the Linux kernel specifically and also explained general process for accepting a short identifier on a file in the kernel. Those two examples can be described as: 1) a patch to change an existing file’s SPDX tag to include the KES identifier, would require all authors and contributors to that file to have agreed or agree to the KES. If that were not the case, the patch would be rejected; and 2) a wholly new file is contributed with an SPDX tag including the KES identifier, which would likely be accepted and would mean that any contributions to that file going forward would also be under the KES. 

C-ii) Another possible use that I thought of is as follows: An individual or company that has already signed on to the KES may release some Linux-related code elsewhere either because it doesn’t make sense to upstream it or before it has been accepted upstream. In effort to be consistent with Linux licensing and their own KES commitment, they might want to signify that their Linux-related code is provided under the KES commitment up front. To do this, they’d have to reproduce the statement from the kernel, but probably modify some of the preamble or something along those lines and would not have an easy way to refer to this at the file level. While I do not know of such an example, based on experience, I don’t think this is far-fetched. 

C-iii) There is also the possibility that people might incorrectly use the KES in the kernel where it shouldn’t be and consequently make it appear that some contributors had agreed to the KES who had not explicitly done so via adding their name to the list and this would then mean the license identifier was not completely correct. 


D) The other implementation question relates to what part of the KES text that appears at the above link is the matchable, pertinent text for purposes of the SPDX License List?  My initial thinking is it would only be the 3 indented paragraphs, as the first two paragraphs seem more like a preamble and everything from “Our intent…” onward is stating intent and other more aspirational text than defining an exception or modification to the underlying terms of the kernel license (GPL-2.0-only). 


Can I please hear some additional thoughts as to the risk and potential outcomes of C, particularly C-iii from anyone who has this concern, as well as some of the long-standing members of the SPDX Legal team?  

Additionally, some thoughts as to D would be helpful.


Thanks,
Jilayne
SPDX Legal co-lead



James Bottomley
 

On Mon, 2018-12-10 at 15:58 -0700, J Lovejoy wrote:
[...]
C) The issue comes down to how the short identifier would be
effectively used due to the KES's slightly different implementation
as described above in 1-6.
[...]
C-iii) There is also the possibility that people might incorrectly
use the KES in the kernel where it shouldn’t be and consequently make
it appear that some contributors had agreed to the KES who had not
explicitly done so via adding their name to the list and this would
then mean the license identifier was not completely correct.
[...]
Can I please hear some additional thoughts as to the risk and
potential outcomes of C, particularly C-iii from anyone who has this
concern, as well as some of the long-standing members of the SPDX
Legal team?
I haven't quoted C in its entirety, but it misses what I think was
Mike's primary concern, which has also become mine as I've discussed
with the lawyers our current use of the KES.

The design of KES is to be a strong community statement about
principles of enforcement that can be used to rebut someone claiming to
act on behalf of the kernel (i.e. McHardy) when they take actions
contravening the KES like claiming to terminate the licence of the
kernel. The great thing about the current KES is that the document can
be entered into evidence and easily explained to the court. If we have
a process based on SPDX tags, it's going to be a nightmare to explain
to the court at the preliminary injunction phase and worse still, if we
only have a few SDPX tags, it allows the malicious enforcer to claim
that the KES is weaker than it would otherwise appear because there are
so few SPDX tags containing it within the kernel.

So I think, realistically, the kernel wouldn't ever use this. Now that
means don't do it, but I think it's legitimate to wonder how many other
projects would have similar problems.

James


Michael Dolan
 

On Mon, Dec 10, 2018 at 7:47 PM James Bottomley <James.Bottomley@...> wrote:

So I think, realistically, the kernel wouldn't ever use this.  Now that
means don't do it, but I think it's legitimate to wonder how many other
projects would have similar problems.

Which leads back to my earlier point that the KES language specifically scopes the additional permission to the Linux kernel, so no one could use it "as-is" for another project. If the kernel community won't use the SPDX identifier, who will use it? If someone does modify their license with an additional permission at the project/file level, I would be more open to discussing adding a reference to the specific language used to enable it. Let's make a reference to the exception they use.

It's also important to read Grant's email which I see split off into the other thread where Jilayne and Phillipe did a great job analyzing the variants of the KES and GPLCC.


J Lovejoy
 

Thanks Dennis for weighing in here. 

While I generally agree that incorrect use is not a bar to something (if it was, we would have never gotten very far in this project), it does concern me and always have. Since I raised the hypothetical in c-iii below of using the KES on other projects, I was thinking about that a bit more.

Looking at the 3 paragraphs we’ve agree would make up the actual KES - I can see it would be a bit odd in the wording to apply elsewhere and thus, it’d be tempting to tweak it a bit. If I was releasing a project under GPL-2.0-only or GPL-2.0-or-later and wanted to be sure that it was clear that my intentions related to any potential enforcement would follow the terms in GPL-3.0, then it’d be cleaner and easier to apply the GPL-CC, project version: https://github.com/gplcc/gplcc/blob/master/Project/COMMITMENT as that was written for exactly that intention. Now that there is a project version of the GPL-CC, it’s be almost silly to use the text of the KES in this hypothetical situation. I’m not sure if that is swaying in either direction as to the question of adding the KES (and may be more in favor of adding the GPL-CC), but it is a practical reality of the options available today.

As for the actual threshold question of adding the KES or not: I must say that I’m somewhat surprised at the level of responses here in both directions. I also want to clarify the timing, as I think there was some mention of giving people a week to respond and it’s not quite a hard deadline:

- Overall, as a project, we are aiming to not let old issues, well, become old - that’s not good project management. 
- This issue, as mentioned below, was raised back in June, so it seemed prudent to try and resolve it one way or another for the next release - a goal we have set with other issues as well. (hint hint)
- That being said, I don’t understand the seeming urgency of this particular request - that is, it seems like everyone agrees there is no current pressing need or real-world example for using an SPDX identifier for the KES. This may change in the future, but if that is the case now and there’s this much debate, would be worth tagging this for re-review at a future release? (that way, we are not letting it fall on the floor, but putting it in a future release cycle - maybe 6 mos or a year, which is 2-4 releases roughly.)  Someone raised a comparison to the addition of the Linux-syscall-note, which made me recall that the addition of that was specifically related to the Linux kernel’s adoption of SPDX identifiers at the file level, so that was a different situation than here based on various comments on this thread.  

Am I missing something here on the urgency aspect or did I sort of create the urgency by tagging it for the 3.4 release? 


Thanks,
Jilayne



On Dec 10, 2018, at 5:04 PM, Dennis Clark <dmclark@...> wrote:

I think that a KES Exception on the SPDX list should consist only of the three indented paragraphs in the text at
basically lines 18-36. 

I also think that anyone shold be able to use this exception, and all names of the individual participants are irrelevant. 

The various statements of intention and explanation are just that -- not part of the exception itself.

The usage sould simply be something like "GPL-2.0-only WITh KES-Exception". 

Concerns about anyone using it incorrectly are also irrelevant to putting the exception on the SPDX list.

Regards,
Dennis Clark
nexB Inc.


On Mon, Dec 10, 2018 at 2:58 PM J Lovejoy <opensource@...> wrote:
Hi all,

I was hoping that others long-standing members of the SPDX legal community would jump in on this thread, but a few days have gone by now and no further discussion, so let me summarize some pertinent background, where I think we are, and any remaining questions or issues that need to be resolved. Please read the whole thing and respond accordingly to the specific questions included at the end of this email. 

A few keys things about the Linux kernel enforcement statement:

1) The Linux kernel enforcement statement (KES) was adopted Oct 2017 and includes a list of individuals copyright holders and company copyright holders (by way of employee contributors) who have agreed to the terms of the KES. 

2) The understanding then, as well as now, is that the KES only applies to those persons or entities whose name appears on the list in the kernel tree here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/kernel-enforcement-statement.rst

3) Additional kernel copyright holders are welcome to add their name to the list at any time. 

4) As it stands today, not every copyright holder in the kernel has signed on to the KES. Therefore, the KES applies only to those copyright holders listed. For the KES to apply to a specific entire file in the kernel, all of the copyright holders of that file would have had to agreed to the KES.

5) Contributions to the Linux kernel are made under the Developer’s Certificate of Origin which states that the contribution is submitted "under the open source license indicated in the file

6) Additional note: The overall drafting and adoption of the KES was a project that involved many, many people in various organizations and, most notably, kernel maintainers and copyright holders, who, as per how the kernel is governed, held the ultimate decision to adopt the KES. Such wide and varied support was critical to it being adopted at every level - and this is something all of the people involved in this effort in any way can be proud of.  Comments as to who worked the hardest or who thinks they deserve credit for this effort are completely irrelevant and unhelpful here (same statement goes for emails outside this list) and will be ignored (at least by me).  


A few key reminders about the SPDX License List: 

7) The purpose of the SPDX License List is to enable easy and efficient identification of free and open source licenses and exceptions in an SPDX document, in source files or elsewhere.

8) To be added to the list, the review includes looking at use “in the wild”, is it free and open?, is it not already on the list when accounting for matching guidelines. The review and decision as to what is added to the SPDX License List is the domain of the SPDX legal community.  To my knowledge, we have not had much controversy over such decisions and have always been able to come to a decision based on broad consensus. 

9) The “exceptions” part of the list includes things that grant an exception to a license condition or additional permission or some other such modification to the underlying license. These are not stand alone licenses. This part of the list started with capturing many of the well-known GPL exceptions (e.g., GCC, Autoconf, Bison, etc.) but is not limited to those kinds of things specifically. 

Important note: Based on the discussion on the call and on the email list. I don’t think any of the items stated above are in dispute.


Regarding adding the KES to the SPDX License List:

A) There was some discussion (perhaps not on this list, but between Mike Dolan and I as part of other conversations) about whether the KES would need an SPDX identifier and how that might be applied. Given the intent for copyright holders to sign up on an individual basis (not adoption at the project or file level) that did not seem needed or tenable at that point.  Later (in June 2018), Karen Sandler submitted an issue in the Github repo to add the KES to the SPDX License List. We finally got around to discussing on a call, with some prior discussion on email list and announcement as to date of call on Nov 29th - essentially one year after the KES was initially adopted. 

B) As to the general requirements for a license or exception to be added to the SPDX License List, there is no dispute that it is a free and open source exception and that it is used in the wild (in terms of existing). 

C) The issue comes down to how the short identifier would be effectively used due to the KES's slightly different implementation as described above in 1-6. 

C-i)  James has provided two examples for the Linux kernel specifically and also explained general process for accepting a short identifier on a file in the kernel. Those two examples can be described as: 1) a patch to change an existing file’s SPDX tag to include the KES identifier, would require all authors and contributors to that file to have agreed or agree to the KES. If that were not the case, the patch would be rejected; and 2) a wholly new file is contributed with an SPDX tag including the KES identifier, which would likely be accepted and would mean that any contributions to that file going forward would also be under the KES. 

C-ii) Another possible use that I thought of is as follows: An individual or company that has already signed on to the KES may release some Linux-related code elsewhere either because it doesn’t make sense to upstream it or before it has been accepted upstream. In effort to be consistent with Linux licensing and their own KES commitment, they might want to signify that their Linux-related code is provided under the KES commitment up front. To do this, they’d have to reproduce the statement from the kernel, but probably modify some of the preamble or something along those lines and would not have an easy way to refer to this at the file level. While I do not know of such an example, based on experience, I don’t think this is far-fetched. 

C-iii) There is also the possibility that people might incorrectly use the KES in the kernel where it shouldn’t be and consequently make it appear that some contributors had agreed to the KES who had not explicitly done so via adding their name to the list and this would then mean the license identifier was not completely correct. 


D) The other implementation question relates to what part of the KES text that appears at the above link is the matchable, pertinent text for purposes of the SPDX License List?  My initial thinking is it would only be the 3 indented paragraphs, as the first two paragraphs seem more like a preamble and everything from “Our intent…” onward is stating intent and other more aspirational text than defining an exception or modification to the underlying terms of the kernel license (GPL-2.0-only). 


Can I please hear some additional thoughts as to the risk and potential outcomes of C, particularly C-iii from anyone who has this concern, as well as some of the long-standing members of the SPDX Legal team?  

Additionally, some thoughts as to D would be helpful.


Thanks,
Jilayne
SPDX Legal co-lead






Bradley M. Kuhn <bkuhn@...>
 

Michael Dolan wrote at 19:16 (PST) on Monday:
Which leads back to my earlier point that the KES language specifically
scopes the additional permission to the Linux kernel, so no one could use
it "as-is" for another project. If the kernel community won't use the SPDX
identifier, who will use it?
Note that nearly all SPDX exception identifiers currently listed are: (a)
specific to one project and (b) not used by that (or any upstream) project.

SPDX users almost always seek to do more with identifying licensing info
than upstream projects really want/can do. So, it's completely reasonable to
have SPDX identifiers that upstream probably won't use themselves. In fact,
that's the more common occurrence. Upstreams rarely have the time,
inclination, or know-how to properly use SPDX identifiers in files. But
others with that expertise do write SPDX data for those projects later, and
they need the tools for that job. SPDX shouldn't deny them those tools.

In other words, I strongly doubt that Bison, nor any other project, will
every write "GPL-3.0-or-later WITH Bison-exception-2.2" anywhere, but
everyone here nevertheless needs Bison-exception-2.2 listed in the SPDX
Exceptions list to write their own SPDX data for Bison.

Thus, we all need KES-Exception to write correct SPDX data for Linux.
--

Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/


Michael Dolan
 

On Tue, Dec 11, 2018 at 5:35 PM Bradley M. Kuhn <bkuhn@...> wrote:

Thus, we all need KES-Exception to write correct SPDX data for Linux.

Where would you insert this to create correct SPDX data for Linux"? What is the current "SPDX data for Linux" that is incorrect?



Bradley M. Kuhn <bkuhn@...>
 

Michael Dolan wrote earlier today:
Where would you insert this to create correct SPDX data for Linux"? What
is the current "SPDX data for Linux" that is incorrect?
How do you describe the license of someone's copyrighted material who has
granted the KES additional permission using SPDX syntax without
"KES-Exception"?

Just a quick click-around tour of cregit (which you linked to earlier, Mike):

* Assuming cregit's accurate -- I found lots of code that I could lift
from there and label as "GPL-2.0-only WITH KES-Exception".

Adding some 15 minute shell scripting against Linux's Git tree showed:

* Many files that currently say: "SPDX-License-Identifier: GPL-2.0" at the
top, where both `git blame` and cregit report that most contributors
have actually licensed "WITH KES-Exception", not just GPL-2.0.

Does SPDX have a "threshold" of how much copyright must be licensed under a
specific exception before listing it? I've not heard of such a litmus test
before, but if one exists, please do share it.
--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/


Karen Sandler
 

On 2018-12-11 12:19, J Lovejoy wrote:

Am I missing something here on the urgency aspect or did I sort of
create the urgency by tagging it for the 3.4 release?
I proposed this because there was a strong consensus to add the KES to the exceptions list during an open discussion by the full attendance to the LLW meeting in April in Barcelona. I took the action item publicly there on the spot, noting that you were sorely missed from that event. That meeting was held under CHR and was invitation only, so it was absolutely necessary to have had the opportunity to discuss on this list and on the call and the strong consensus at LLW is just one additional data point.

Before all that, Philippe Ombredanne had already proposed KES for the list in November 2017, so it's well over a year in consideration. I think the urgency is just frustration that the discussion has been going on for so long over such an important exception. It looked to me after this year of discussion, that nearly everyone agreed it was right to add the KES to the list.

It seems to me SPDX should be responsive to changes in licensing in the wild. This phenomenon of "backporting parts of GPLv3 to GPLv2 as additional permission" can easily be called a serious industry trend. I (and many others) would like to be able to point to SPDX's license list and its exception list as a definitive way to express licenses that are operative in the real world. There are real copyrights and real files in Linux that are under "GPL-2.0-only WITH KES-Exception", so we need to list the KES to be able to describe the license of those works using SPDX.

karen


J Lovejoy
 



On Dec 10, 2018, at 5:47 PM, James Bottomley <James.Bottomley@...> wrote:

On Mon, 2018-12-10 at 15:58 -0700, J Lovejoy wrote:
[...]
C) The issue comes down to how the short identifier would be
effectively used due to the KES's slightly different implementation
as described above in 1-6.
[...]
C-iii) There is also the possibility that people might incorrectly
use the KES in the kernel where it shouldn’t be and consequently make
it appear that some contributors had agreed to the KES who had not
explicitly done so via adding their name to the list and this would
then mean the license identifier was not completely correct.
[...]
Can I please hear some additional thoughts as to the risk and
potential outcomes of C, particularly C-iii from anyone who has this
concern, as well as some of the long-standing members of the SPDX
Legal team?  

I haven't quoted C in its entirety, but it misses what I think was
Mike's primary concern, which has also become mine as I've discussed
with the lawyers our current use of the KES.

The design of KES is to be a strong community statement about
principles of enforcement that can be used to rebut someone claiming to
act on behalf of the kernel (i.e. McHardy) when they take actions
contravening the KES like claiming to terminate the licence of the
kernel.  The great thing about the current KES is that the document can
be entered into evidence and easily explained to the court.  If we have
a process based on SPDX tags, it's going to be a nightmare to explain
to the court at the preliminary injunction phase and worse still, if we
only have a few SDPX tags, it allows the malicious enforcer to claim
that the KES is weaker than it would otherwise appear because there are
so few SPDX tags containing it within the kernel.

So I think, realistically, the kernel wouldn't ever use this.  Now that
means don't do it, but I think it's legitimate to wonder how many other
projects would have similar problems.

James


Somewhat breaking my own rule here, as I don’t really think the details of admissibility or ease of explaining external evidence to a court is really on-topic for the SPDX License List… but since you’ve brought it up and this is a public mailing list, I think I ought to provide a complete picture of what we are talking about, as not everyone has necessarily been following all of what you have eluded to above.

First of all, for anyone not familiar with the reference to McHardy - this article should get you caught up: https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering

In light of some of practices in the suits brought by McHardy (which are hard to come by), some specifics of how the German court system works, and concern over this activity “inspiring” copycats, various members of the broader open source (legal) community asked the important question as to what could be done to help establish some community norms around GPL enforcement. And thus, the following initiatives came to be:

  • The Software Freedom Conservancy (SFC), in coordination with the Free Software Foundation published "The Principles of Community-Oriented GPL Enforcement” [1], which were endorsed by the Open Source Initiative (OSI)[2] and the netfilter community[3] (notably, because McHardy was a member of this community).  I believe gpl-vioations also endorsed or adopted the Principles. These 7 principles include a broad statement covering various aspects to be adhered to in GPL enforcement. One of these includes an explicit statement to extend the benefit of GPL-3.0 termination clauses for GPL-2.0-only works. 
  • Grant Likely, chair of the Linux Technical Advisory Board (TAB), proposed the initial draft of the Linux kernel enforcement statement, which formally adopts the principle related to extending the benefit of the GPL-3.0 termination clause to the Linux kernel. This ultimately resulted in the publishing of a version of his original intent, with input from kernel maintainers, Linux Foundation lawyers, and many others which creates an enforceable commitment made by anyone who signs up to it.  Individual copyright holders and corporate copyright holders submit their commitment to the Linux kernel enforcement statement via signing off on the statement commit here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/kernel-enforcement-statement.rst . The list of current signatories is comprised of approximately 103 separate individuals or entities, which includes such companies as Arm, Amazon, Collabra, Google, Linaro, Oracle, Samsung, SUSE, VMware.
  • Red Hat begins an initiative in which corporate entities can pledge a commitment to enforce any of their copyrighted code released under LGPL-2.0-or-later or GPL-2.0-only or GPL-or-later by following the termination and cure provision in GPL-3.0. Thanks to the tireless work of David Levine (Asst General Counsel) and his legal team, 41 companies to-date have signed the GPL Cooperation Commitment, ranging across the globe and across industries.[4] 
  • In follow-up to the corporate GPL Cooperation Commitment, Red Hat later publishes a version of the same promise tailored for individual copyright holders to use and for projects to use as of a certain release date and going forward. Approximately 230 individual copyright holders have signed up to these terms[5]. It is unclear how many open source projects have adopted the project commitment, but that is certainly more than 1. 

By my count, that means that 4 non-profit organizations with influential voices in this space (SFC, FSF, OSI, LF); 44 companies, including some of the most globally recognized and influential names in technology; at least 2 major open source projects (but probably more); and somewhere around 300 individuals have all agreed that automatic termination of GPL-2.0 is too harsh and that the more reasonable termination and cure provisions as drafted in GPL-3.0 provide a more fair and amicable platform for enabling conversations around enforcement and non-compliance. 

That, my friends, is an amazing accomplishment of collaboration and a community coming together. And if that’s not a strong community statement, then I don’t know what is. Most importantly, let this be a solid message, that in spite of whatever difference or competitiveness or politics that any of these organizations, companies, individuals may otherwise sometimes engage in - we can, and, most importantly, we will COME TOGETHER. 

Whether, when, or how the SPDX License List incorporates these somewhat unique commitments is an aside to the amazing effort as summarized above. And that’s coming from someone who unabashedly believes in the importance of SPDX and the SPDX License List. 

So, can we please all just take a moment to feel the appreciation that this accomplishment deserves. And, in kind, appreciate that the above effort probably reflects the collective effort and momentum of upwards of one thousand people or more.



Jilayne 
SPDX legal co-lead (and believer in what we can achieve when we all work together)






James Bottomley
 

On Tue, 2018-12-11 at 19:09 -0800, Bradley M. Kuhn wrote:
Michael Dolan wrote earlier today:
Where would you insert this to create correct SPDX data for
Linux"? What is the current "SPDX data for Linux" that is
incorrect?
How do you describe the license of someone's copyrighted material who
has granted the KES additional permission using SPDX syntax without
"KES-Exception"?
It's still legally and accurately describable as the actual licence
absent the WITH, surely ... that's the point of additional permissions:
they're strippable.

Just a quick click-around tour of cregit (which you linked to
earlier, Mike):

* Assuming cregit's accurate -- I found lots of code that I could
lift from there and label as "GPL-2.0-only WITH KES-Exception".

Adding some 15 minute shell scripting against Linux's Git tree
showed:

* Many files that currently say: "SPDX-License-Identifier: GPL-
2.0" at the top, where both `git blame` and cregit report that
most contributors have actually licensed "WITH KES-Exception",
not just GPL-2.0.
I really don't think we should ever advocate that people do the above
because it's really not safe and thus the licence tags you've derived
aren't reliable.

Cregit, being token based, is certainly one of our best tools, but it's
not definitive: Thomas Gleixner used it as one of the tools to help
derive licences in the kernel in the recent several month long SPDX
addition exercise. The reason it took so long is because there's a lot
of painstaking research involved in licence determination because no
one tool does it all. There's even more research involved in author
determination.

Git blame should never be relied on for copyright attribution because
it works at the line level not the token level, so, for example, the
original author of a line gets replaced by a person who does a later
whitespace or other cosmetic change, which produces a completely
incorrect idea of the authorship of a file.

James


J Lovejoy
 



On Dec 10, 2018, at 8:16 PM, Michael Dolan <mdolan@...> wrote:

On Mon, Dec 10, 2018 at 7:47 PM James Bottomley <James.Bottomley@...> wrote:

So I think, realistically, the kernel wouldn't ever use this.  Now that
means don't do it, but I think it's legitimate to wonder how many other
projects would have similar problems.

Which leads back to my earlier point that the KES language specifically scopes the additional permission to the Linux kernel, so no one could use it "as-is" for another project. If the kernel community won't use the SPDX identifier, who will use it? If someone does modify their license with an additional permission at the project/file level, I would be more open to discussing adding a reference to the specific language used to enable it. Let's make a reference to the exception they use.

actually, on that note, if a project did want to adopt GPL-3.0 termination clause for L/GPL-2.0 licensed code (whether a new project or existing project), wouldn’t it make more sense to use the GPL-CC for projects, since that has the same intent but was specifically written to be applied in this way?

Jilayne


J Lovejoy
 

On Dec 11, 2018, at 9:13 PM, Karen Sandler <karen@...> wrote:

On 2018-12-11 12:19, J Lovejoy wrote:

Am I missing something here on the urgency aspect or did I sort of
create the urgency by tagging it for the 3.4 release?
I proposed this because there was a strong consensus to add the KES to the exceptions list during an open discussion by the full attendance to the LLW meeting in April in Barcelona. I took the action item publicly there on the spot, noting that you were sorely missed from that event. That meeting was held under CHR and was invitation only, so it was absolutely necessary to have had the opportunity to discuss on this list and on the call and the strong consensus at LLW is just one additional data point.

Before all that, Philippe Ombredanne had already proposed KES for the list in November 2017, so it's well over a year in consideration. I think the urgency is just frustration that the discussion has been going on for so long over such an important exception. It looked to me after this year of discussion, that nearly everyone agreed it was right to add the KES to the list.
To be fair to the SPDX community, this hasn’t been discussed here until recently, so I don’t think it’s fair to say the discussion has been going on for so long or that it’s been a year in consideration. I already took some responsibility for the backlog of this (and many other issues), I don’t think I need to keep apologizing for that. It is what it is and this is not the only thing that’s on the agenda for the SPDX License List.


Karen Sandler
 

On 2018-12-12 18:49, J Lovejoy wrote:

I don’t think I need to keep apologizing for that. It
is what it is and this is not the only thing that’s on the agenda for
the SPDX License List.
I don't think you need to apologize at all! My point was to answer your question about timing to give folks the full context to my original post and that it's not a new issue for anyone commenting.

And in response to your email from earlier, cheering on everyone for working together to add: great job, Jilayne! We all really appreciate everything you do as a volunteer for SPDX!!!

karen


Jim Wright
 

Apologies for my late and perhaps ill informed entry here, but just so I understand what is being proposed, is the idea to create a new SPDX identifier for the kernel license plus KES notwithstanding that such a thing would never actually be applied to any part of the kernel source in tree (because the KES is not actually a part of the kernel license but rather only something in the vein of an additional permission from particular parties who have agreed to it in respect of their kernel contributions)?

When would such an identifier ever sensibly be used then? Perhaps I’m missing something but it appears to me at first glance that you really wouldn’t want to use it out of tree either because even if it applied to all contributions to a particular kernel file at a fixed point in time, it might not apply in respect of new contributions to that file going forward, so placing it in there to begin with would introduce the risk of error in later versions. If that’s indeed the case, how is this useful as a license tag versus just confusing and error prone?

Best,
Jim


Karen Sandler
 

I think it's great that so many of us who are not typically involved in spdx discussions are now participating! Since I've been following things, I've noticed that we've had repetitive posts as people reiterate points already made earlier. I think this is true of both the arguments and counter-arguments.

I think this is a sign that we maybe have fully explored the key issues on this. There is disagreement,
but it looks to me like the disagreement is pretty minor. I think it would be helpful to have a summary of most of the key points I've taken from this discussion (both on the mailing list and offline). I'm hoping it helps Jilayne, since re-reviewing a long thread is always painful, and also help anyone joining the discussion fresh. And also will help me figure out if I've missed something.

* There are real, identifiable, and verifiable copyrights licensed under "GPL-2.0-SOMETHING WITH KES-Exception". This copyrighted material could straightforwardly be gathered into files by downstream who wanted to reuse code only with the exception. Opinions vary on the wisdom of doing this, but all agree that with enough proper research, it could be done.

* There are likely entire files available that are licensed as "GPL-2.0-SOMETHING WITH KES-Exception", too. We all agree that some work remains to identify those files, but there is full consensus that such files either already exist now or will exist in the near future as KES advocacy continues by the wide coalition of parties who favor it (which is great!)

* Notwithstanding the last point, SPDX has never required exceptions to either vet and exhibit specific files fully under an exception or convince upstream that they want to use the SPDX identifier in their files before listing that exception. Most upstreams do not use SPDX identifiers. While "SPDX-identifier-use advocacy to upstream" has become a part of this project, it is not the primary use of SPDX identifiers in the wild; rather, people mostly use them to write SPDX files and annotate/discuss licensing info downstream.

* A few Linux developers have expressed an opinion that they would not use this identifier to mark upstream code at this point, mostly because they have not done the work mentioned above. James in particular has agreed that it operates like any other additional permission/exception, but has expressed that upstream Linux use of SPDX identifiers in files has a much higher burden of proof than is typically used by others downstream and outside of Linux.

* Using SPDX for file-by-file annotation -- while the only use of SPDX of apparent interest to Linux upstream -- is not the only use of SPDX notation. Tools to assist in more fine-grained copyright annotation are currently nascent, but no one has disputed that SPDX hopes to provide proper SPDX identifiers for more accurate and fine-grained annotation of licensing on copyrighted material in the future.

* The consensus on the phone call was to give a chance for a legal argument here to support the statement that "the KES-Exception fails to grant additional permissions under copyright", as Steve was wondering on the call if such an argument existed because he'd heard it said that the KES-Exception isn't an additional permission. I can't find any argument like that presented here. It looks like people disagreeing on what I think are more minor points do seem to agree that the KES is in fact an additional permission / exception, and operates like others on the list. I have to admit that surprised me a bit, because when we started this thread, that was what I thought the disagreement was. We reached consensus on it, but the discussion about "how many and which files" was posited as the issue after we resolved what I thought was the remaining issue. Bradley tells me he confirmed with Jilayne that a "how many and which files" analysis was not done for other exceptions, including the Linux-syscall-note when it was added.

* Bradley has pointed out in the thread how all of the arguments opposing listing KES-Exception are equally valid for various other exceptions already listed.

* I hesitate to write this, but it looks that this process may be being politicized because of meta-issues generally unrelated to SPDX that I may not fully understand.

* There is now discussion, similar to that about the KES last year that we delay it again for the next release. I think that's ok, but unlike last year, we now have similar exceptions from Red Hat that will also get delayed if we delay this one, so delay here means delaying a whole line of listing requests.

I think that's it. I really hope that's helpful!
karen


Richard Fontana
 

On Thu, Dec 13, 2018 at 08:51:10AM -0500, Karen Sandler wrote:
* A few Linux developers have expressed an opinion that they would not use
this identifier to mark upstream code at this point, mostly because they
have not done the work mentioned above. James in particular has agreed that
it operates like any other additional permission/exception, but has
expressed that upstream Linux use of SPDX identifiers in files has a much
higher burden of proof than is typically used by others downstream and
outside of Linux.
I believe it was also pointed out that Linux's DCO policy, and the
current wording of the DCO, could have the effect of seeming to force
contributors to an existing file with "SPDX-License-Identifier:
GPL-2.0 WITH KES-Exception" to make the commitment, presumably
something the kernel would not wish to adopt as a policy (whereas the
Project flavor of GPLCC deliberately implements such a policy). That
could be addressed by revising the wording of the DCO but presumably
no one wants to do that.

* The consensus on the phone call was to give a chance for a legal argument
here to support the statement that "the KES-Exception fails to grant
additional permissions under copyright", as Steve was wondering on the call
if such an argument existed because he'd heard it said that the
KES-Exception isn't an additional permission. I can't find any argument like
that presented here. It looks like people disagreeing on what I think are
more minor points do seem to agree that the KES is in fact an additional
permission / exception, and operates like others on the list. I have to
admit that surprised me a bit, because when we started this thread, that was
what I thought the disagreement was.
I myself have assumed that the KES is a GPLv3-style additional
permission (that is, a "GPL exception" in the traditional sense),
since that's how it's described in the KES itself ("additional
permissions under our license"). FWIW Red Hat's view is that GPLCC is
an additional permission in the same sense, as we've said publicly
numerous times.

I don't see inclusion in the SPDX exception list as conferring
validation that something is, in fact, a GPL-style additional
permission, especially since there seems to have been some interest in
broadening the definition of what an "exception" is for SPDX purposes,
if I understand correctly. I am not sure why the "exceptions" list
couldn't also be broadened to include standardized "additional
restrictions" (to use another GPLv3 concept), obviously with the
"exception" terminology replaced with something less confusing, unless
the exception list is designed to be quasi-political in nature (to
reinforce orthodox GPL interpretive concepts or whatever). I think
that issue may have been discussed before though.

There is something about KES and GPLCC that is different from typical
GPL exceptions, in that they seem to go to enforcement procedure
rather than substantive formal details of license compliance or scope
of copyleft. But I don't see why that difference should create any
doubt that they qualify as additional permissions in the GPL
sense. However IMO that is orthogonal to whether they should be
included in the SPDX exception list, because the SPDX exception list
is not intended to be an authoritative designator of GPL-style
additional permissions. I am not sure the difference goes to
"strippability", to use James's term. A fork of a project using the
similar GPLCC could, I have to assume, strip out GPLCC, but the
additional permission would continue to burden copyrights covered by
GPLCC prior to that fork. This is true of all GPL additional
permissions, though.

* There is now discussion, similar to that about the KES last year that we
delay it again for the next release. I think that's ok, but unlike last
year, we now have similar exceptions from Red Hat that will also get delayed
if we delay this one, so delay here means delaying a whole line of listing
requests.
I am obviously completely biased here but I would prefer that
consideration of GPLCC not be delayed. And since the fates of GPLCC
and KES-Exception are, for better or worse, intertwined, I would also
hope consideration of KES-Exception would not be delayed. FWIW I see
no reason why we shouldn't add KES-Exception as well as GPLCC to the
exception list. It's clear that the Linux project won't be
using KES-Exception as an identifier in source files, so the various
potential problems associated with doing so won't actually occur.

Richard


James Bottomley
 

On Thu, 2018-12-13 at 08:51 -0500, Karen Sandler wrote:
I think this is a sign that we maybe have fully explored the key
issues on this. There is disagreement, but it looks to me like the
disagreement is pretty minor. I think it would be helpful to have a
summary of most of the key points I've taken from this discussion
(both on the mailing list and offline). I'm hoping it helps Jilayne,
since re-reviewing a long thread is always painful, and also help
anyone joining the discussion fresh. And also will help me figure out
if I've missed something.
Actually, you've missed the most important one raised by several people
that KES isn't an exception at all. This is partly why there's all the
noise on the SPDX list because if it really isn't an exception and is
used in a different context then trying to codify it as one undermines
the current use case. In our current use case, KES mostly reads like
and is used like the SFC principles of enforcement, which I think we'd
all agree isn't an exception and shouldn't be codified as one. KES
contains five paragraphs, four of which are clearly community norm
statements not additional permissions, so it's really only down to the
one paragraph that can be interpreted as a cure commitment.

The reason for our unhappiness is that we can use enforcement norms to
effectively bind the entire community, even those (like McHardy) who
haven't signed up to them and being flexible around termination is part
of this. If KES becomes an additional permission not a norm, it's not
binding on anyone who hasn't signed up and, worse, that could be argued
to apply to the other four paragraphs of KES that aren't in any way
additional permissions thus undermining our community norm position as
ruling for everyone.

I also think it's unfair to characterise these concerns as "politics"
since they have the potential to have a fundamental effect on the way
the ecosystem works and this is the reason we don't want KES codified
as an exception at all.

Now I think the GPL Cure Commitment can be used in the same way as KES
(as a community norm not an additional permission), so the reasons
above would potentially apply there as well, but assuming the people
that wrote it and use it do want it codified as an additional
permission, what about a compromise? If you didn't codify a KES
exception and only did a Cure Commitment one we wouldn't use it in the
kernel (so no DCO binding issue), but people determined to try to add
it downstream could add it as the GPL cure commitment exception, since
really the only potential additional permission in the whole of the KES
is the cure commitment, so as long as the authorship research is done
and correlated properly you've captured the precise licence state of
the file without having any impact on the KES or its current uses.

James


Bradley M. Kuhn <bkuhn@...>
 

James Bottomley wrote:
Actually, you've missed the most important one raised by several people
that KES isn't an exception at all.
I don't think Karen missed it, in fact, she pointed out that she thought we
have consensus on the same point:

In our current use case, KES mostly reads like and is used like the SFC
principles of enforcement, which I think we'd all agree isn't an exception
and shouldn't be codified as one.
Yes, there is actually consensus on that.

This was discussed on the conference call that you missed, during which
someone (not me) actually complained "why did the Linux community mix an
additional permission with other meta-information in one statement!?!".

Alexios and others already volunteered to properly extract the parts that are
an additional permission and codify them into what gets listed in SPDX -- of
course leaving out the material that is not an additional permission. We all
agreed, before this went back to the mailing list from that conf call, that
not the entire kernel-enforcement-statement.rst would be what SPDX would list
as the "exception text". SPDX has its own way to list these and a database
of them, so it's all ready to go.

My feeling is that the indented three paragraphs in the middle from
"Notwithstanding the..receipt of the notice." would be what SPDX lists, but
we can in due course work together to figure out what part is or is not. Of
course input from upstream is welcome on that.

It's clear from your other statements, James, that you agree that there is an
additional permission under the copyright license included within
kernel-enforcement-statement.rst, and I'm sure SPDX only wants to list the
parts that are an additional permission. So, that's consensus.

BTW, this is a problem SPDX has often solved, as this is not the first
exception to present this drafting annoyance.

If you didn't codify a KES exception and only did a Cure Commitment one we
wouldn't use it in the kernel
SPDX wants to codify any exceptions in use in the wild, and there are legally
significant differences between Red Hat's CC and KES-exception.
KES-exception is indeed in the wild, and the body of copyrights that have
that exception is growing, not shrinking.

If Linux wanted to get all the existing and future KES signers to agree to
Red Hat's CC *instead*, thus deprecating the KES-Exception entirely, that
would be another story entirely, but I don't think that's what you proposed.
--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/


Michael Dolan
 

To be frank, I haven't had time to read all the list traffic today but I see there are lengthy discussions. 

Given Jilayne's backlog for this release it's clear this won't reach any usual consensus anytime soon so I would suggest we all give her some room to get what needs done for the next release. 

My proposal would be that we:
  • punt further discussion on the KES into a future release timeframe
  • move forward with the GPLCC (see my rationale below) and 
  • thank Jilayne for her tireless contribution to this project and chip in where we can on the long list of open issues for this release
I have not seen and am not aware of any objections to the GPL-CC being added since it does apply to the entire project and can be used on contribution. Red Hat also may have some projects it will actually use it for. From my perspective I respectfully disagree with Richard that they're both intertwined. I would be fine seeing the GPL-CC added to the list. It's substantively different enough from the KES in how it works and it was designed to be like other exceptions already on the list. Just because something may grant an additional permission in the GPL context does not necessarily make it applicable to this list of license exceptions that apply to projects and not individuals' copyrights. Neither the current exceptions nor the GPLCC require a continuous, exhaustive copyright ownership analysis to determine if they apply. The copyright ownership data required is not in any cregit or in any readily available source, not to mention there are ambiguities in where it might apply (let's not even get into APIs). 

The KES is not and never was drafted to work like people who were not involved in the drafting may want it to work. I am happy to discuss the concerns with anyone. There were hundreds of parties involved in the review and commenting on the KES who are not on this list who I'm sure would show up if they were made aware. 


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



On Thu, Dec 13, 2018 at 12:34 PM Bradley M. Kuhn <bkuhn@...> wrote:
James Bottomley wrote:
> Actually, you've missed the most important one raised by several people
> that KES isn't an exception at all.

I don't think Karen missed it, in fact, she pointed out that she thought we
have consensus on the same point:

> In our current use case, KES mostly reads like and is used like the SFC
> principles of enforcement, which I think we'd all agree isn't an exception
> and shouldn't be codified as one.

Yes, there is actually consensus on that.

This was discussed on the conference call that you missed, during which
someone (not me) actually complained "why did the Linux community mix an
additional permission with other meta-information in one statement!?!".

Alexios and others already volunteered to properly extract the parts that are
an additional permission and codify them into what gets listed in SPDX -- of
course leaving out the material that is not an additional permission.  We all
agreed, before this went back to the mailing list from that conf call, that
not the entire kernel-enforcement-statement.rst would be what SPDX would list
as the "exception text".  SPDX has its own way to list these and a database
of them, so it's all ready to go.

My feeling is that the indented three paragraphs in the middle from
"Notwithstanding the..receipt of the notice." would be what SPDX lists, but
we can in due course work together to figure out what part is or is not.  Of
course input from upstream is welcome on that.

It's clear from your other statements, James, that you agree that there is an
additional permission under the copyright license included within
kernel-enforcement-statement.rst, and I'm sure SPDX only wants to list the
parts that are an additional permission.  So, that's consensus.

BTW, this is a problem SPDX has often solved, as this is not the first
exception to present this drafting annoyance.

> If you didn't codify a KES exception and only did a Cure Commitment one we
> wouldn't use it in the kernel

SPDX wants to codify any exceptions in use in the wild, and there are legally
significant differences between Red Hat's CC and KES-exception.
KES-exception is indeed in the wild, and the body of copyrights that have
that exception is growing, not shrinking.

If Linux wanted to get all the existing and future KES signers to agree to
Red Hat's CC *instead*, thus deprecating the KES-Exception entirely, that
would be another story entirely, but I don't think that's what you proposed.
--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/