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