toggle quoted messageShow quoted text
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?
On Dec 10, 2018, at 5:04 PM, Dennis Clark <dmclark@...
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.
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.
SPDX Legal co-lead