As I've been following the issue queue for github.com/spdx/license-list-XML/issues over the past several months, it seems to me that you get a significant number of license submissions like this lates

Not speaking for SPDX or OSI: To some degree this is a known problem, and possibly viewable as not a problem in some cases. Some issues I see embodied in your list: 1. In some cases licenses published

On Thu, Nov 10, 2022 at 3:01 PM Luis Villa <luis@...> wrote: [...] > (1) Would SPDX be an appropriate mechanism for representing that opt-out clause in a machine-readable way, eg via a short identif

In contrast to Debian, Fedora does not have separate official/project-administered package repositories with different license inclusion criteria. Fedora has an explanation here that may be helpful: h

I think this is a good idea. The vast majority of FOSS licenses, licenses already on the SPDX list (FOSS or otherwise), and licenses likely to be added to the SPDX license list in the future, will not

In Fedora a license has been submitted for review that seems to match HPND-sell-variant except that the word "appears" in HPND-sell-variant is "appear" in this license. https://gitlab.com/fedora/legal

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