toggle quoted messageShow quoted text
Thanks for this -- all good points and I agree, in the example you gave I'd represent it in the way you described.
As an FYI, regarding custom exceptions (and agreed that the example you gave wouldn't fit into the "exception list" category) -- there is an open issue for consideration in the 3.0 version of the SPDX spec, to add "ExceptionRef-" syntax that would explicitly permit custom exceptions to be used after WITH in SPDX license expressions. See https://github.com/spdx/spdx-spec/issues/153
and feel free to weigh in with thoughts :)
On Fri, Apr 24, 2020 at 5:08 PM Richard Fontana <rfontana@...
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
(which IIRC are not supposed to cover supplementary restrictive terms
anyway, though I seem to remember a debate many years ago about that
topic), would the only SPDX-sanctioned way of expressing this be to
use a LicenseRef for the whole expression? For example, suppose you
have a project that says it's licensed under GPL version 2 along with
an attribution-like requirement for web services (this is a real case
I was pointed to today, see:
To represent that in SPDX notation, I assume you wouldn't refer to
"GPL-2.0" unless you prefixed it with a LicenseRef, something like
where "GPL-2.0" doesn't particularly have any precise connection to
the SPDX GPL-2.0 identifier, but might have the benefit of
communicating to humans that the license in question here is, in part,
textually-intact GPL version 2.
This is a common enough case, though, that I wonder if there is some
value to having a way of representing it in an SPDX expression that
uses the official SPDX identifier in an official sort of way, not
prefixed by LicenseRef. Maybe you'd have to define a new operator and
perhaps SPDX wouldn't want to go down that road. I assume from reading
the spec that LicenseRef can't be used inside an expression to cover
just the identifier that follows the WITH operator.
On Fri, Apr 17, 2020 at 12:49 PM Steve Winslow
> Hi Luis, hope you (and others) are staying safe and healthy as well.
> Echoing Kyle, "LicenseRef-" is part of the spec syntax and is defined in Appendix IV of the spec.  In an actual SPDX document, it would be defined in a corresponding "Other License" section. 
> In the v2.2 release of the spec (for which a release candidate was circulated this morning), the spec now explicitly clarifies that LicenseRefs can be used in short-form identifiers in source code.  REUSE has also implemented this in their spec and described a mechanism for including the corresponding license text directly in a repo.
> Hope this helps!
> (links below are to sections of the v2.2 release candidate)
>  https://spdx.github.io/spdx-spec/v2-draft/appendix-IV-SPDX-license-expressions/
>  https://spdx.github.io/spdx-spec/v2-draft/6-other-licensing-information-detected/
>  https://spdx.github.io/spdx-spec/v2-draft/appendix-V-using-SPDX-short-identifiers-in-source-files/, scroll to the bottom
>  https://reuse.software/spec/, search for "LicenseRef"
> On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:
>> `LicenseRef-*` is technically part of the license expression
>> syntax, too. But it mostly comes up in the context of
>> (private, shared) SPDX XML files. I'm not aware of any
>> package managers that leverage it as a way for package
>> authors to express their own license terms.
>> Kyle Mitchell, attorney // Oakland // (510) 712 - 0933
> Steve Winslow
> Director of Strategic Programs
> The Linux Foundation
Senior Commercial Counsel
Red Hat, Inc.
+1 212 689-4350 (mobile)
Director of Strategic Programs
The Linux Foundation