Hi all, We are not in what should be the final days of prep for the next release. Looking over the list of issues tagged for 3.4, I’m not sure we’ll realistically get them all over the line, but

I guess I will further say that if the SPDX group would like to informally condition adoption of GPLCC-1.0 (or whatever) as an exception identifier on some assurance that Red Hat will actually use it

Just spotted another project using SPDX identifiers in source file: Western Digital appears to be using them in their newly-released Open Source RISC-V SweRV Instruction Set

We're not specifically planning to use the hypothetical SPDX identifier in source files -- basically we just haven't considered the issue. Currently, I know of one or two Red Hat-maintained projects

Richard, You stated: But, is Red Hat intending on using the SPDX identifier in source files of Red Hat projects that have adopted the project variant or SPDX documents? Jilayne

actually, on that note, if a project did want to adopt GPL-3.0 termination clause for L/GPL-2.0 licensed code (whether a new project or existing project), wouldn’t it make more sense to use the

It's still legally and accurately describable as the actual licence absent the WITH, surely ... that's the point of additional permissions: they're strippable. I really don't think we should ever

Somewhat breaking my own rule here, as I don’t really think the details of admissibility or ease of explaining external evidence to a court is really on-topic for the SPDX License List… but since

I proposed this because there was a strong consensus to add the KES to the exceptions list during an open discussion by the full attendance to the LLW meeting in April in Barcelona. I took the action

Michael Dolan wrote earlier today: How do you describe the license of someone's copyrighted material who has granted the KES additional permission using SPDX syntax without "KES-Exception"? Just a

Where would you insert this to create correct SPDX data for Linux"? What is the current "SPDX data for Linux" that is incorrect?

Michael Dolan wrote at 19:16 (PST) on Monday: Note that nearly all SPDX exception identifiers currently listed are: (a) specific to one project and (b) not used by that (or any upstream)

Thanks Dennis for weighing in here. While I generally agree that incorrect use is not a bar to something (if it was, we would have never gotten very far in this project), it does concern me and

Which leads back to my earlier point that the KES language specifically scopes the additional permission to the Linux kernel, so no one could use it "as-is" for another project. If the kernel

Hi, myself Baba Nayak. I am little confused where to start for contribution. Can anyone guide me?

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