I think that a KES Exception on the SPDX list should consist only of the three indented paragraphs in the text at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/kernel-enforcement-statement.rst 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 <opensou...@jilayne.com> 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 > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2466): https://lists.spdx.org/g/Spdx-legal/message/2466 Mute This Topic: https://lists.spdx.org/mt/28714103/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
