On Mon, 2018-12-10 at 15:58 -0700, J Lovejoy wrote: [...] > C) The issue comes down to how the short identifier would be > effectively used due to the KES's slightly different implementation > as

I think that a KES Exception on the SPDX list should consist only of the three indented paragraphs in the text at

Hi folks, I'm a little late to this discussion, but I think I should weigh in. To me this discussion is very odd, at least from the context of the Kernel Enforcement Statement. I don't think it

Hi all, I was hoping that others long-standing members of the SPDX legal community would jump in on this thread, but a few days have gone by now and no further discussion, so let me summarize some

Hi Richard, Let me try to answer, since I was the one who did the "unifying" markup. Our goal is obviously to match the three GPLCC variants and (ideally) not match anything else. Unfortunately, the

I've thought further about the issue of whether GPLCC, as a possible future SPDX exception identifier, should cover the three GPLCC variants (Corporate, Indivdiual and Project), as seemed to be

Note: 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

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

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

That's absolutely not what I was saying. It obviously has a legal significance for the *file* but to have legal significance to downstream it would have to be present in all (or at least all

James Bottomley wrote: At the beginning here, it seems like you are saying the LinuxEnforcementStatement-1.0 has no legal significance and is not legally binding as an additional permissions. I

[...] I think this is effectively asking if the kernel community would in any way care about codifying the Kernel Enforcement Statement into SPDX. I think the answer is "not really". We already

I 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. The current enforcement statement is maintained

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

I 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.

Michael Dolan wrote: Indeed, that's precisely what every "additional permission" does (going back to the Bison Exception in the 1980s). So, you've basically stated there the very definition of a

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

If this can help, we have tracked in ScanCode all the 15 known text variations to

Hi all, I know I just wrote in the minutes that this task was on Richard F, but I was too curious not to have a cursory look myself! Attached is a compare of the project to corporate variant; and of

Hi all, 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