Date
1 - 8 of 8
meeting minutes: Linux kernel enforcement statement / GPL Cooperation Commitment
|
J Lovejoy
Hi all,
toggle quoted message
Show quoted text
Thanks for a productive call today. I’ve posted a summary of the discussion in the meeting minutes here: https://wiki.spdx.org/view/Legal_Team/Minutes/2018-11-29 Please note: there was general approval to adding the Kernel enforcement statement and the GPL Cooperation Commitment to the SPDX License List. Theses are slated to be added to 3.4 version of SPDX License List, which is scheduled for end of the year. If there are any fundamental objections to adding these, that should be raised on the mailing list in the next week. Any details regarding implementation (markup, naming, etc.) should be discussed on the relevant issues in Github: or the relevant PR, when created. thanks, Jilayne
|
|
|
|
I'm just catching up late on a Friday night and noticed this. I have to say I'm surprised this suddenly went to last call for comments. I guess I missed the prior discussion on the list about this and apologize for showing up late. I honestly do not understand the rationale for doing this. When someone receives a SPDX file, how would you actually use one of these exception? The primary issue I had the first time I heard this suggestion was raised is that the Kernel Enforcement Statement (KES) was always a commitment from an individual author for their contributions. It was never drafted to be a project license or a modifier of a project license. It solely modifies an individual's contribution with additional permissions. So what would you have? The one thing I've always thought SPDX was focused on was laying a factual groundwork for the resultant license determination. And for that determination to survive without having to comb through who made every contribution since the last version. A unilateral additional permission cannot change the license for a project or even a file. I don't see how this would work and will explain my rationale below. SPDX-License-Identifier: GPL-2.0-only WITH KernelEnforcementStatement-1.0 I've looked at the details of contributions to a lot of files in the kernel as have others on this list. My assumption is there are likely very few files in the kernel that the statement above could be applied to. If you look at cregit, you can visually see how complicated this would be. I personally would never put that statement into a SPDX file or short identifier of a binary or file from the Linux kernel. IMO, and I think many of you would agree, one would have to have ALL authors and copyright owners agree to make the Kernel Enforcement Statement individually before this would be possible. Or ALL the authors would have to relicense the project under a new license with a similar exception added to the new project license. No one has ever made the KES a condition of contributing to the kernel. What reliance could someone take away if they saw that applied? And how many people would incorrectly apply it? That's a real issue IMO. Further you would have to required contributions to be made with that statement going forward in the future. Who will remove the KES exception when the next person who hasn't made a KES pledge sends in a contribution? How would you know? It takes a TON of compute power and resources for us to track this in cregit for just the Linux kernel - imagine all the dependencies that might be included. The moment someone new contributes, you can no longer rely on any analysis that was previously done for any file or binary associated with KES in a SPDX file. So now you have to redo the entire SPDX analysis - or someone downstream who receives an SPDX file will have to know this nuance and never be able to rely on it for the next version of the kernel they receive? There are MANY political and other hurdles we had to work through in creating the Kernel Enforcement Statement (KES) with developers in the Linux kernel community and many of the top contributing companies. Karen, Greg and I were deeply involved in that process and it was not easy. I realize I had to miss yesterday's call and haven't had time to catch up with whoever was on, but this is something I would honestly raise my hand and at least say I'm completely opposed to. Maybe I'm alone on this, but it makes no sense to me to do this - it undermines key principles behind the drafting and what it took to get support from nearly 100 maintainers in the kernel community and critical corporate copyright owners of code in the kernel. I will also point out there have been many unilateral grants of additional permissions. There are patent non-assertions from IBM, Google, and others. Some may relate to a project, some may relate to all OSS projects and some may have nothing to do with OSS but could be applied to OSS in certain uses (e.g. Tesla's). Most have nothing to do with any particular project. Those likewise do not modify the project license. They are not a part of a license or grant from any future contributors to a project either. It's no different than the KES. The Common Cure Rights Commitment (CCRC) which was based on the KES also applies to an indefinite pool of projects. If one or a few of the companies own all the copyright, my recommendation would be to just relicense the project with an appropriate additional permission as a license modifier and require all new contributors to give the same license. Instead it could apply to N number of projects, many of which we do not know about and for each one it only applies to contributions from that company and it doesn't change the project license. Even if the company wrote all the code in a file today, what happens when NewContributor makes a contribution - now you have to notify everyone to remove the "WITH CCRC-1.0" in the next SPDX review? Unless someone is running cregit and reviewing each of those files they would never know. To be clear, I'm a huge proponent of using these cure provisions to surgically reduce some of the issues we've seen. BUT I would never have thought that what we drafted would be used as a project license identifier. We always communicate we were not changing the project license and some of those involved in the discussion in the minutes were very adamant about that themselves. If I may point out Bradley's post (https://sfconservancy.org/blog/2017/oct/20/additional-permissions/) in which he stated, "This begs the question: what's the effective license of Linux? Well, more than likely, it's simply GPLv2-only." I do not understand how this interpretation has changed. I think if communities want to do this, we should be guiding them to revisit using a CLA or some other means to capture commitments from prior contributors and change the project license itself to include these exceptions in any future contributions. If there was a version drafted to do that, I'd be much more receptive. Imagine GPLv2+CureProvision being the project license in the LICENSE file and what everyone put into the headers - I'm far more comfortable if that were the approach in the projects. There is NO project doing that today and I don't believe the KES or the CCRC were drafted with that intended use. So I'll return back to my original question - why and how would someone ever insert this into a SPDX statement? What reliance should someone take from seeing that in a SPDX file or SPDX short identifier? Does anyone have an example of a community using it in such a manner? And now I'll add another - has anyone talked to the contributors to communities who would use this SPDX identifier? Kate Stewart went through a monumentally difficult task of adding SPDX identifiers into the kernel. Who if anyone has discussed this with the kernel contributors and what was their feedback? Sorry for the long email, but I thought this topic had been laid to rest and wanted to make sure my view was clear. I'm more than happy to join a future SPDX legal call to discuss but unfortunately had a conflict yesterday. -- Mike --- On Thu, Nov 29, 2018 at 1:34 PM J Lovejoy <opensource@...> wrote:
|
|
|
|
James Bottomley
On Fri, 2018-11-30 at 19:20 -0500, Michael Dolan wrote:
I'm just catching up late on a Friday night and noticed this. I haveI won't repeat all of your argument, but I think it boils down two two fundamental questions 1. How do you trust the kernel file SPDX tag when it includes a WITH additional permission 2. How do we preserve the tag going forwards The answer to 1., as you know because you were a large part of it, is that we ran a rigorous process to derive the existing licence of every file in the kernel using cregit and other tools. We now run rigorous scrutiny of patches seeking to update any existing file with SPDX tags. As a result, we have 19,996 SPDX tags in the current kernel (4.20-rc4- 350-gd8f190ee836a) out of 62,477 current files of which 1,312 have WITH as part of this (1,302 are the syscall note and the 10 others are no invariant sections for documentation and a couple of GCC exceptions) none of the current WITH tags have the cure provision. The answer to 2. is likewise simple; the DCO contribution process includes in all parts an attestation that the contribution is being submitted under the licence indicated in the file. This means that as long as we rigorously observe the DCO process for Signed-off-by (which we do as part of our community DNA), we automatically preserve any WITH additional tags in files for all contributions. I think the question of how the KES would get inserted into the Kernel breaks down into two questions 1. Would we accept a patch changing an existing file's SPDX tag to include WITH KernelEnforcementStatement-1.0 2. Would we accept a wholly new file containing a SPDX tag including WITH KernelEnforcementStatement-1.0 I think 2. is the easiest to answer: For a new file I think yes, we would, because we give authors reasonable discretion and once accepted the tag would be preserved going foward by the DCO process. 1. is much more complex: the submitter would have a huge burden to prove, as you say, that all authors and contributors to the file agreed. It's not impossible that this burden of proof would be met for newer files with small numbers of contributors, I think it highly unlikely that it would be met for older files with large number of contributors. However, the bottom line is that you can trust us to ask the question rigorously and reject the patch if the burden of proof isn't met. So the bottom line is I think you can trust us if we ever add a file with the KES exception. Finally, there's the question of what value does a file containing WITH KernelEnforcementStatement-1.0 provide to downstream? I think the answer here is pretty much none in legal terms. However, the KES is supposed to be an aspirational statement of reassurance driving the enforcement principles of the community and in those terms there might be value in adding it to some kernel files. So I think it's a question for the SPDX community to answer whether codifying this additional permission actually provides enough measurable value to the people the community is meant to serve. James |
|
|
|
James thanks for that explanation it helps me understand the angle you're thinking of using this for much better. Let me ask one follow-up if I may. Is it broadly the intention to change the license for new files in the kernel going forward to require the KES? I haven't had a conversation like this with anyone but would like to get a sense of how broadly the support is for this. I missed plumbers so maybe it came out of discussions there where there is support. We've also seen at least 4 new McHardy cases recently and I'm not sure if that maybe prompted it. I ask because we ran into complications when we previously discussed the possibility of making the KES a requirement to contribute. We never went that far and I'm also not sure we've resolved some of those concerns broadly. Finally, in the kernel we have the SysCall exception. Have you thought about adding a provision like this to that notice? There may be other options. My concern is this was drafted as an individual, unilateral additional permission from the copyright owner and I don't think it works as some are intending. On Sat, Dec 1, 2018, 2:12 PM James Bottomley <James.Bottomley@... wrote: On Fri, 2018-11-30 at 19:20 -0500, Michael Dolan wrote: |
|
|
|
James Bottomley
On Sat, 2018-12-01 at 14:36 -0500, Michael Dolan wrote:
James thanks for that explanation it helps me understand the angleI know of no such intention and as I explained we have a fairly rigorous SPDX tag change process that makes this very difficult in practice. haven't had a conversation like this with anyone but would like toThe current enforcement statement is maintained in Documentation/process/kernel-enforcement-statement.rst and anyone can submit a patch to add their name to the list. There were no conversations about it at Plumbers and there's certainly no requirement to add your name. I ask because we ran into complications when we previously discussedDevelopers don't like being dictated to, so I think that's wise. Plus we have no real way of adding something like this without modifying the DCO which I think we all agree would be a bad idea. So the current process is per file if someone chooses to add the tag or by voluntarily adding your name to the enforcement statement in the kernel Documentation directory. Finally, in the kernel we have the SysCall exception. Have youYou mean to the DCO? ... no, definitely not since we don't really want to modify it. There may be other options. My concern is this was drafted as anOK, could you elaborate the problem as you see it? We believe the system call exception is a very old promise made to (and relied upon by) users of the Linux Kernel. The current documented process in the kernel requires this promise to be included as "WITH Linux-syscall- note" in the header files which are exported to other development packages like glibc so there's a visible reminder. If you're asking how we preserve and keep it going forward, firstly as a promise relied on it's estoppel but secondly it's still explicitly mentioned in the kernel COPYING file which still documents the overall contract with users. If the fear is some future copyright troll saying their contributions in the syscall area were made without the syscall exception and therefore all userspace binaries are under GPL unless they get paid to waive it, I really don't see that flying in any jurisdiction because we have a promise made and notice given in the COPYING file. James |
|
|
|
So if I can summarize my the situation we're discussing: 1) The additional permission is from one or more of many authors and would only apply in a situation where that author(s)' code is being enforced as part of a work. 2) The license for the file, any resultant binary or the work would not change. 3) The KES was never drafted as a license exception that would apply to a file or compiled work. I think my concerns can be summarized as: A) Has there ever been a SPDX license exception where the exception only applied to only an individual's contributions of code in a file or work? We often rely on license headers or statements in LICENSE or COPYING files to identify a license exception. Here we would need to go to the KES in the documentation file and then cross check that against the git commit itself to identify the author. B) If the license for the file, compiled binary or overall work are not modified under this situation, what role does SPDX play in a file distributed between parties? What about in a SPDX license identifier? D) I'm concerned about the concept the DCO captures a KES on contribution. Further how would that be tracked? D) If we accept A), how likely is it this will be misapplied? Should we enable this at all? On Sat, Dec 1, 2018, 3:09 PM James Bottomley <James.Bottomley@... wrote: On Sat, 2018-12-01 at 14:36 -0500, Michael Dolan wrote: |
|
|
|
James Bottomley
On Mon, 2018-12-03 at 10:34 -0500, Michael Dolan wrote:
So if I can summarize my the situation we're discussing:Yes. As I said this is the reason I don't think we'd apply the tag unless it were reliable (i.e. all authors demonstrably agreed). However, there's no current kernel plan for this, it was just a speculative answer to a theoretical "how would we handle it if it arose" question. 2) The license for the file, any resultant binary or the work wouldthe KES is effectively a conditioned covenant not to sue, so it's very much like an additional right, like a patent grant. 3) The KES was never drafted as a license exception that would applyAgreed. The KES kernel process is designed to work on the single statement file which authors and companies sign to cover their entire contributions. I think my concerns can be summarized as:I'd strongly advise no to this. The SPDX tags are supposed to make reliable statements to downstream recipients about the licence of the file. Anything not all authors of the file agree to isn't a reliable statement ... and probably would cause all sorts of issues with the DCO on fairness grounds (if one author hasn't agreed, why do I have to?). Which would basically negate all the good SPDX and DCO work we've done. That's why I suggest we'd never apply the tag to a file we couldn't round up entire author agreement for ... and if there are legal questions like this around the tag I don't think we'd ever use it. B) If the license for the file, compiled binary or overall work areAt the moment there is no KES on file concept in the kernel. I merely theorised how it would work if someone one day submitted a file with one. If it's going to be legally problematic, we can just never allow it (although that decision would be for the kernel community to make not me). As for tracking: git ties the signoffs in commit messages to modified files, so that's about as strongly tracked as you can get. I can use git to go from any file to all the author signoff statements (well, at least as far back as signoff history goes). D) If we accept A), how likely is it this will be misapplied? ShouldMy answer is simple: don't accept A). Any SPDX tag and modifier must represent the reliable state of the licence which means it must have been agreed to by all authors of the file. James |
|
|
|
Richard Fontana
On Fri, Nov 30, 2018 at 07:20:15PM -0500, Michael Dolan wrote:
The Common Cure Rights Commitment (CCRC) which was based on the KES alsoNote: Common Cure Rights Commitment was an earlier name for what Red Hat later ended up branding the GPL Cooperation Commitment. As was pointed out on the call, GPLCC now exists as three variants, Corporate, Individual and Project. The Corporate version is a commitment made by companies, not specifically tied to particular projects or code. The Individual version is similar but is made by individuals. The Project version is designed be used in a project source repository. My original suggestion had been to have an SPDX exception identifier for the Project version only (I will comment on this issue in a separate posting). The Project version of GPLCC serves exactly as what Mike calls "an appropriate additional permission as a license modifier and require[s] all new contributors to give the same license". It is designed to be usable by existing as well as new projects, by applying prospectively to all contributions as of the date of adoption of the commitment. I think if communities want to do this, we should be guiding them toWith the GPLCC Project version, a CLA is not needed since it contemplates that past contributions might not be covered by the commitment while future ones will be. This may make an SPDX identifier for GPLCC unusual, in that it describes a licensing fact for an entire project that may not apply to all contributions made under the underlying project license. Nonetheless, Red Hat considers it highly desirable to have SPDX recognize GPLCC with an identifier. As for the KES, I don't have any concerns about SPDX separately recognizing an identifier for it. If it does, however, then I believe it would be no less justifiable to have an identifier for GPLCC. I do not think Red Hat itself would find any practical value in using a KES identifier, especially if the kernel developers themselves don't use it in individual source files, but admittedly we are making only limited use of SPDX identifiers at present. Richard |
|
|