To be frank, I haven't had time to read all the list traffic today but I see there are lengthy discussions.
Given Jilayne's backlog for this release it's clear this won't reach any usual consensus anytime soon so I would suggest we all give her some room to get what needs done for the next release. My proposal would be that we: - punt further discussion on the KES into a future release timeframe - move forward with the GPLCC (see my rationale below) and - thank Jilayne for her tireless contribution to this project and chip in where we can on the long list of open issues for this release I have not seen and am not aware of any objections to the GPL-CC being added since it does apply to the entire project and can be used on contribution. Red Hat also may have some projects it will actually use it for. From my perspective I respectfully disagree with Richard that they're both intertwined. I would be fine seeing the GPL-CC added to the list. It's substantively different enough from the KES in how it works and it was designed to be like other exceptions already on the list. Just because something may grant an additional permission in the GPL context does not necessarily make it applicable to this list of license exceptions that apply to projects and not individuals' copyrights. Neither the current exceptions nor the GPLCC require a continuous, exhaustive copyright ownership analysis to determine if they apply. The copyright ownership data required is not in any cregit or in any readily available source, not to mention there are ambiguities in where it might apply (let's not even get into APIs). The KES is not and never was drafted to work like people who were not involved in the drafting may want it to work. I am happy to discuss the concerns with anyone. There were hundreds of parties involved in the review and commenting on the KES who are not on this list who I'm sure would show up if they were made aware. --- Mike Dolan VP of Strategic Programs The Linux Foundation Office: +1.330.460.3250 Cell: +1.440.552.5322 Skype: michaelkdolan mdo...@linuxfoundation.org --- On Thu, Dec 13, 2018 at 12:34 PM Bradley M. Kuhn <bk...@ebb.org> 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: > > > 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!?!". > > 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. > > 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. > > 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. > -- > Bradley M. Kuhn > > Pls. support the charity where I work, Software Freedom Conservancy: > https://sfconservancy.org/supporter/ > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2495): https://lists.spdx.org/g/Spdx-legal/message/2495 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] -=-=-=-=-=-=-=-=-=-=-=-
