1. posterid:1160316
  2. Messages

Re: Linux kernel enforcement statement discussion

J Lovejoy
 

I think this is getting closer to the crux, but I also think some terminology and associations of such is getting in the way: there seems to be focus on whether or not the KES is an “exception” or an “additional permission” to the GPL-2.0-only (that is, the license of the kernel) and then that that determination therefore decides whether it should be on the SPDX License List.  That is making a jump - please stop. 

I don’t think there is any doubt the the KES is designed to modify the termination terms of the underlying license of the project for only those copyright holders who sign up to it (i.e., add their name to the list). The last part is the crux issue - because it makes the implementation of the KES different from other “exceptions”. 

Given the specifics of how the Linux kernel is governed, it had to be done like this, because to try and apply it for all copyright holders and then be able to add it the additional permission across the board would be effectively like changing the license and require all copyright holders permission. 

The way it has been implemented, individual copyright holders can sign up to it, or not as they choose and it is not swept in via the DCO sign-off process.

The KES is also a bit of an odd bird due to it living in a separate file, not in the COPYING file, not in a license header, or the other usual places license info lives. 

These are essentially the reasons why it wasn’t added in the first place and nothing seems to have changed since then. 

In terms of use - use of identifiers is not a set requirement or bar to entry here but the fact that the very people who have been doing the very hard work of adding SPDX identifiers to the kernel (which is a monumental task) are not comfortable with adding the KES to the SPDX License List is worthy of consideration in the same way as we’ve tried to take into consideration the input of license authors, etc.

In light of strong opposition, my inclination is to keep the status quo - there is way too much energy and fire around this and if I’ve learned anything over the years of leading this project, it’s that when there is that much energy around an issue - caution for any change is warranted. I’ll also add that keeping the status quo, which means not adding the kernel enforcement statement should not be viewed as a “win” or “loss” for any particular person, group, or organization. Period. 


As for the GPL-CC: that started with company-specific commitments, then individual commitments - these have an implementation similarity to the KES in the sense of being applicable to specific copyright holders, not living in the license file or notice, but a separate statement of commitment to this principle of enforcement. This is why I thought having the conversation in tangent was a good idea (I now completely regret that…). 

More recently, Red Hat drafted the GPL-CC for projects, which is drafted to apply in the more usual way: as part of the license of the project, to apply across the board, to be added to the license information for the project. It can also be used by ANY project.  There is still a potential issue with applying it to old projects where previous contributors don’t contribute after the GPL-CC applications, and as such they would not have agree to the amended termination terms the GPL-CC applies. 

My point here being that, while we had discussed trying to be neat and tidy and combine the Company, Individual, and Project variants of the GPL-CC - I’m not sure that’s a good idea now. It might make more sense to focus on the Project variant, as it’s the most usable across the board to begin with and provide a note about the distinction.  Just a thought.

In any case, we don’t need to make the decisions on all of the above at the same time, so let me take that expectation off the table, since I sort of pushed that.

Let me re-state then where that leaves us: 
- KES is off the table for this release. I highly recommend everyone take a deep breath, step away from your keyboard and go enjoy the holidays. A little space always helps…
- GPL-CC - more discussion needed as per above. Maybe we can resolve in the next week, maybe needs to be pushed to 3.5 - TBD


Jilayne





On Dec 13, 2018, at 9:31 AM, James Bottomley <James.Bottomley@...> wrote:

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
Join Spdx-legal@lists.spdx.org to automatically receive all group messages.