Mark Gisi: I disagree, for at least two reasons: 1. A vast amount of software does *NOT* require weird special-case licenserefs. 2. Many people who use SPDX will never see nor use a SPDX file. Instead

W. Trevor King: Gisi, Mark: I disagree. LicenseRef is not a cornerstone, and for many use cases it's irrelevant. Many tools and formats *only* support SPDX license expressions, so it's very useful to

J Lovejoy: I agree. I think the point of SPDX is to enable people to understand the licenses of the software being used (or under consideration). The "license of the license" is something that very fe

Regarding EPL-2.0 at <https://www.eclipse.org/legal/epl-2.0/>... Richard Fontana: I agree that the text in exhibit A, by itself, is just an "OR" if invoked. It may be wordy but it looks like a simple

Kate Stewart: Those are *syntactically* fine SPDX license expressions, of course. However - do they really *mean* "EPL-2.0 AND GPL-2.0"?!? That would mean that recipients would have to comply with *bo

The call yesterday revealed to me that there are *two* kinds of license version ambiguity in SPDX license expressions. I don't know if this is actually a problem, or if it is, that solving it is worth

Gary @ sourceauditor.com: I think "ONLY" is clear, and we already have other alphabetic keywords ("AND", "OR", "WITH"). If you want to cuddle up an operator like "+", I suggested "!" earlier, which wo

W. Trevor King: The "ONLY" would be an operator, so I'd expect to see: (GPL-2.0 ONLY OR GPL-3.0 ONLY) That is pretty clear. That would be ambiguous as written, under the current proposal, but there's

Based on feedback from W. Trevor King (thank you!!), here is round 2. Here I propose this Facebook rider as a new *license* instead of separate license *exception*. The proposal is below; I'm includin

I'm happy with that instead.. I just want a standard way to refer to it. I'd prefer "Facebook-Patents-2.0" instead of "FB" because "FB" isn't as obvious, but that is a nit, and either name (or many ot

INTRODUCTION: Many Facebook projects, including the widely-used React.js, have a different license approach than others: They use a stock OSS license *with* a special patent-related rider (in the case

Smith, McCoy [mailto:mccoy.smith@...] I can't be the only one to confuse "BSD+Patent" with "BSD+Patents". But in that case, I think there needs to be a *speedy* assignment (hah!) of a SPDX licen

Ah! Thanks so much for the clarification. In that case, what *is* the SPDX license id or expression for the license used by many widely-used Facebook projects, including React.js? If there isn't one,

Is the final formal SPDX name for React, etc., going to be "BSD-2-Clause-Patent"? That's what is listed here: https://opensource.org/licenses/BSDplusPatent Thanks. --- David A. Wheeler

Perhaps the term “exceptions” is confusing & should be renamed. If so, how about “additional terms”? It seems to me that “exceptions” have both *add* or *remove* requirements, but it appears that othe

Richard Fontana: > The way I read the matching guidelines this license does not actually match to BSD-3-Clause, even though it obviously should. I think the problem is that I am reading the matching g

J Lovejoy: I agree, I think something like "BSD-2-Clause-Patent" would be the better choice: * It's more consistent with the other licenses * All the existing tools can handle that, even if they can o

Typically the "WITH" clauses are for a separate fragment of text that can be added to the "end" of a base license as a "rider". It looks like this license text has it all merged in a single document.

J Lovejoy: Please DO NOT deprecate "GPL-2.0". DO NOT DO THIS. If you do, we'll have *exactly* the same problem again in a few years. We need at least *3* cases. Here they are, with potential names/exp

David Parrish: This appears to be an existing SPDX license, BSD-3-Clause. See: https://spdx.org/licenses/BSD-3-Clause This is a widely-used OSI-approved license. --- David A. Wheeler