Thanks for the kind words guys. I figured it’s the least I could do policy-wise since I’ve been delinquent in participating through the list. But to be truthful, we’ve been seeing more projects

I don't think you need to apologize at all! My point was to answer your question about timing to give folks the full context to my original post and that it's not a new issue for anyone

+1! Alan, you’re setting a high bar for the rest of us hardware vendors. Dave

Hi Jilayne, thank you for all your efforts in keeping us moving towards the release! Here are my quick comments on a few of these, and I'll reflect this in the GitHub issues as applicable: 1. #729 -

To be fair to the SPDX community, this hasn’t been discussed here until recently, so I don’t think it’s fair to say the discussion has been going on for so long or that it’s been a year in

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?