On Thu, 2018-12-13 at 09:32 -0800, Bradley M. Kuhn wrote: > James Bottomley wrote: > > Actually, you've missed the most important one raised by several > > people that KES isn't an exception at all. > > I don't think Karen missed it, in fact, she pointed out that she > thought we have consensus on the same point:
I didn't find any reference to the discussion about whether KES should be classified as an additional permission or not in the email. However the discussion of whether or not KES is an exception is surely the key point. Everything else in Karen's email depends on the answer and, as has already been pointed out, it's the issue that's directly on point for SPDX. > > 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. > > Yes, there is actually consensus on that. > > This was discussed on the conference call that you missed, during > which someone (not me) actually complained "why did the Linux > community mix an additional permission with other meta-information in > one statement!?!". So the answer to that would be because it isn't an additional permission, which is the problem I was pointing out above. > Alexios and others already volunteered to properly extract the parts > that are an additional permission and codify them into what gets > listed in SPDX -- of course leaving out the material that is not an > additional permission. We all agreed, before this went back to the > mailing list from that conf call, that not the entire kernel- > enforcement-statement.rst would be what SPDX would list > as the "exception text". SPDX has its own way to list these and a > database of them, so it's all ready to go. > > My feeling is that the indented three paragraphs in the middle from > "Notwithstanding the..receipt of the notice." would be what SPDX > lists, but we can in due course work together to figure out what part > is or is not. Of course input from upstream is welcome on that. > > It's clear from your other statements, James, that you agree that > there is an additional permission under the copyright license > included within kernel-enforcement-statement.rst, and I'm sure SPDX > only wants to list the parts that are an additional permission. So, > that's consensus. No it's not, that's the point. One of the authors of KES already said on this list that it wasn't the intention. So trying to read the intention in after the fact is one of the problems. > BTW, this is a problem SPDX has often solved, as this is not the > first exception to present this drafting annoyance. > > > If you didn't codify a KES exception and only did a Cure Commitment > > one we wouldn't use it in the kernel > > SPDX wants to codify any exceptions in use in the wild, and there are > legally significant differences between Red Hat's CC and KES- > exception. KES-exception is indeed in the wild, and the body of > copyrights that have that exception is growing, not shrinking. KES isn't an exception in the view of the authors and several others. It can possibly be construed to embody GPL CC, which you could then codify if GPL CC is added. > If Linux wanted to get all the existing and future KES signers to > agree to Red Hat's CC *instead*, thus deprecating the KES-Exception > entirely, that would be another story entirely, but I don't think > that's what you proposed. So you're talking the position that the language in paragraph 3 of KES isn't compatible with GPL CC? I suppose that's true if KES is not an exception at all and thus we could agree on that coupled point. As I've already said, KES contains four other paragraphs of community norms which you've agreed aren't additional permissions and which we definitely wouldn't remove in favour of the GPL CC because that would lose us a lot of content we need. The object, as I've said, from the kernel point of view is not to give a permission but to codify community norms for enforcement. James -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2496): https://lists.spdx.org/g/Spdx-legal/message/2496 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] -=-=-=-=-=-=-=-=-=-=-=-
