Hi all,

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).  

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. 

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). 

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

Thanks Dennis for weighing in here. 

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

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

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

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.

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

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

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

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

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

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/