1. Topics
  2. documentation/examples of License Ref?

documentation/examples of License Ref?

Luis Villa
 

👋🏼 hope everyone is doing as well as they can under the circumstances.

Is there any documentation for, or examples of, correct usage of License Ref? I've been looking this morning and can't find much, but I may just be looking in the wrong places.

Thanks!
Luis
Kyle Mitchell
 

Luis,

`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
 

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. [1] In an actual SPDX document, it would be defined in a corresponding "Other License" section. [2]

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. [3] 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!
Steve

(links below are to sections of the v2.2 release candidate)

[4] https://reuse.software/spec/, search for "LicenseRef"


On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:
Luis,

`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
Richard Fontana
 

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:
https://github.com/drwetter/testssl.sh/blob/3.0.1/Readme.md#license )

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
LicenseRef-GPL-2.0-Web-Services-Attribution
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.

Richard

On Fri, Apr 17, 2020 at 12:49 PM Steve Winslow
<swinslow@...> wrote:

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. [1] In an actual SPDX document, it would be defined in a corresponding "Other License" section. [2]

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. [3] 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!
Steve

(links below are to sections of the v2.2 release candidate)

[1] https://spdx.github.io/spdx-spec/v2-draft/appendix-IV-SPDX-license-expressions/
[2] https://spdx.github.io/spdx-spec/v2-draft/6-other-licensing-information-detected/
[3] https://spdx.github.io/spdx-spec/v2-draft/appendix-V-using-SPDX-short-identifiers-in-source-files/, scroll to the bottom
[4] https://reuse.software/spec/, search for "LicenseRef"

On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:

Luis,

`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
swinslow@...


--
Richard Fontana
Senior Commercial Counsel
Red Hat, Inc.
+1 212 689-4350 (mobile)
Steve Winslow
 

Hi Richard,

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  :)

Steve


On Fri, Apr 24, 2020 at 5:08 PM Richard Fontana <rfontana@...> wrote:
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:
https://github.com/drwetter/testssl.sh/blob/3.0.1/Readme.md#license )

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
LicenseRef-GPL-2.0-Web-Services-Attribution
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.

Richard

On Fri, Apr 17, 2020 at 12:49 PM Steve Winslow
<swinslow@...> wrote:
>
> 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. [1] In an actual SPDX document, it would be defined in a corresponding "Other License" section. [2]
>
> 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. [3] 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!
> Steve
>
> (links below are to sections of the v2.2 release candidate)
>
> [1] https://spdx.github.io/spdx-spec/v2-draft/appendix-IV-SPDX-license-expressions/
> [2] https://spdx.github.io/spdx-spec/v2-draft/6-other-licensing-information-detected/
> [3] https://spdx.github.io/spdx-spec/v2-draft/appendix-V-using-SPDX-short-identifiers-in-source-files/, scroll to the bottom
> [4] https://reuse.software/spec/, search for "LicenseRef"
>
> On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:
>>
>> Luis,
>>
>> `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
> swinslow@...
>



--
Richard Fontana
Senior Commercial Counsel
Red Hat, Inc.
+1 212 689-4350 (mobile)






--
Steve Winslow
Director of Strategic Programs
The Linux Foundation
Gary O'Neall
 

Hi Richard,

Here are some minutes from a previous review mentioning a potential long term solution for non-listed exceptions: https://wiki.spdx.org/view/Legal_Team/Archive/license_expression_syntax

I also recall a discussion on the topic. It has been a while (and my memory is far from perfect), but I recall the conclusion being not to introduces such a construct at the time due to the additional complexity and the assumption that any non-listed exception text would require a similar level of manual review as reviewing the full LicenseRef.

Gary

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of
Richard Fontana
Sent: Friday, April 24, 2020 2:08 PM
To: spdx-legal@...
Subject: Re: documentation/examples of License Ref?

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:
https://github.com/drwetter/testssl.sh/blob/3.0.1/Readme.md#license )

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 LicenseRef-GPL-2.0-
Web-Services-Attribution
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.

Richard

On Fri, Apr 17, 2020 at 12:49 PM Steve Winslow
<swinslow@...> wrote:

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. [1] In an actual SPDX document, it would
be defined in a corresponding "Other License" section. [2]

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. [3] 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!
Steve

(links below are to sections of the v2.2 release candidate)

[1]
https://spdx.github.io/spdx-spec/v2-draft/appendix-IV-SPDX-license-exp
ressions/ [2]
https://spdx.github.io/spdx-spec/v2-draft/6-other-licensing-informatio
n-detected/ [3]
https://spdx.github.io/spdx-spec/v2-draft/appendix-V-using-SPDX-short-
identifiers-in-source-files/, scroll to the bottom [4]
https://reuse.software/spec/, search for "LicenseRef"

On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:

Luis,

`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
swinslow@...


--
Richard Fontana
Senior Commercial Counsel
Red Hat, Inc.
+1 212 689-4350 (mobile)
Luis Villa
 

Thanks, Steve and Kyle. The link to the draft is particularly helpful.

I don't want to rehash the many, many discussions about which licenses should be included in the official list; suffice to say, are there any best practices folks here are aware of for naming these? I saw https://github.com/nexB/scancode-toolkit/issues/532 re namespacing but that's about it.


On Fri, Apr 17, 2020 at 9:46 AM Steve Winslow <swinslow@...> wrote:
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. [1] In an actual SPDX document, it would be defined in a corresponding "Other License" section. [2]

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. [3] 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!
Steve

(links below are to sections of the v2.2 release candidate)

[4] https://reuse.software/spec/, search for "LicenseRef"

On Fri, Apr 17, 2020 at 12:39 PM Kyle Mitchell <kyle@...> wrote:
Luis,

`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
1 - 7 of 7