Thanks Mike.
I had started another email earlier this morning, but got distracted (ha ha…) by the actual meeting and tying up the 3.4 release, so just sent now.
Let me make one thing very clear on a more personal note: 1) I am DONE commenting on this thread for the reasons stated in the email just sent and for the personal reason that this has also taken up much of my time in the past couple weeks, at the expense of not only other SPDX work but also other things I need to do generally.
2) Do NOT call or text my personal number about this issue or with some other “I need to tell you something” guise. That is so incredibly disrespectful to both the project and to me personally, I can’t believe I have to actually say this.
Jilayne
On Dec 13, 2018, at 11:19 AM, Michael Dolan < mdolan@...> wrote:
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
mdolan@...
--- On Thu, Dec 13, 2018 at 12:34 PM Bradley M. Kuhn < bkuhn@...> 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/
|
