I've thought some more about certain unintended problems some of us were previously discussing regarding the use of SPDX-License-Identifier: in source files. In particular it's occurred to me that the

I feel like what some projects might find useful is something like: SPDX-License-Identifier-Concluding-What's-Been-Contributed-As-Of-Some-Past-Time: SPDX-License-Identifier-Of-What's-Been-Contributed-

The order of operations is a different issue, I think. I guess the SPDX spec assumes, as you say, that commutativity of AND and OR is implicit (like counterpart operations in propositional logic), but

I'm working on some draft documentation for Fedora around use of SPDX expressions in RPM spec file License: fields. I was surprised to apparently not see anything in the SPDX spec that says that the A

McCoy's topic reminds me of a question I asked here some time ago: https://lists.spdx.org/g/Spdx-legal/message/2706?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2Ccomposite%2C20%2C2%2C0%2

<jaeger=jbb.de@...> wrote: I am not sure SPDX should get involved in influencing norms around license text inclusion, as I think it should be responding to the world as it is rather than (a

Greetings, Over at Red Hat, we've been gradually increasing our support of the use of "SPDX-License-Identifier:" in source files for various reasons. We've encountered some situations where a traditio

Right, this is what I thought you meant. So to rephrase what I said in an earlier reply, the current interest among some involved in Fedora is solely to use valid SPDX short identifier expressions in

Hi Warner, Can you explain what you mean by "copyright + SPDX-Identifier but no boilerplate"? Sorry if it's obvious. :-) It's probably important to note that the current interest in adoption of SPDX i

My understanding from being on the linux-spdx mailing list is that this is intentionally tolerated for existing SPDX-License-Identifier notices because it was correct SPDX syntax under the earlier ver

If you have a standard license text (that maps to one of the SPDX license identifiers) coupled with some additional nonstandardized terms, which are not captured by anything in the exceptions list (wh

<carmenbianca@...> wrote: Except, apparently, if you're a conservative lawyer at certain U.S. federal government agencies! Richard

Suppose you're dealing with the following source file legal notice (example taken from https://www.mozilla.org/en-US/MPL/2.0/permissive-code-into-mpl/, itself adapted from the examples discussed by SF

The SIL Open Font License 1.1 (SPDX short identifier OFL-1.1) and its superseded predecessor (OFL-1.0) have a notion of a "Reserved Font Name". In the case of OFL-1.1, at least, this is contemplated a

This sounds appealing to me (if I'm understanding it correctly). From Red Hat's perspective one of the great impracticalities of SPDX has been that, after many years of SPDX's existence, its adopted i

I believe it was also pointed out that Linux's DCO policy, and the current wording of the DCO, could have the effect of seeming to force contributors to an existing file with "SPDX-License-Identifier:

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

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 t

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 the co

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 variants, Cor