A proposal for SPDX Private License Identifiers. Example: .com.amazon.-.ASL-2.0
|
I would like to propose a syntax for SPDX "Private License Identifiers".
SPDX short identifiers and SPDX-License-Identifier declarations in source code and in compliance documents have proven to be useful. This proposal extends SPDX license tags to licenses created and used by organizations, that are unlikely to be applied to content by anyone other than the license author. And when I see an expanding namespace with worries about collisions and an overworked central naming authority, I always think "why not use the DNS?" Examples (these URLs are not correct): SPDX-License-Identifier: .com.amazon.-.ASL-2.0 SPDX-License-Identifier: .com.amazon.-.ASL-2.0 https://aws.amazon.com/doc/ASL-2.0 SPDX-License-Identifier: .com.amazon.-.ASL-2.0 https://github.com/aws/AmazonSoftwareLicense Private License Identifiers are indicated by a leading dot, followed by the reversed DNS name of the organization who created or authored the license, followed by a dot dash dot and then a short name of the same general form of a SPDX license short identifier. The leading dot is sufficient to separate this namespace from the registered SPDX short identifiers, and is inspired by the fact that DNS names have an implied trailing dot. The dot dash dot is to prevent someone from reversing the entire identifier string into a DNS name and trying to dereference it, because a bare dash is not a valid DNS name part. . DNS names be IDN (Internationalized Domain Name) and thus can contain non-ASCII characters. IDN components can be encoded in IDN Punycode, or in UTF-8, or in the Unicode encoding appropriate to the document. In a SPDX-License-identifier declaration, a Private License Identifier can optionally be followed by a URI pointing to the canonical license text. This URI should be under the control of the entity that controls the DNS namespace of the Private License Identifier. ..m Mark Atwood <atwoodm@...> Principal, Open Source +1-206-604-2198
|
|
|
|
Gary O'Neall
HI Mark,
toggle quoted messageShow quoted text
I like the idea of a DNS naming approach to the private license identifiers. It neatly solves the namespace issue. Rather than having a URL pointing to the canonical license text, I wonder if we could have a URL pointing to metadata about the entire license which would include the license text and reference URL's for the source. We could use the same license XML format we use for the license list. This would be more work for the creators of the private license identifier but would enable better machine matching algorithms. There is a use case we've been discussing where we could have an identifier for a license which has been submitted to the license list but not yet approved. Perhaps we solve this using a similar approach. Gary
-----Original Message-----Mark Atwood via Lists.Spdx.Orglicense author.the reversed DNS name of the organization who created or authored the license,of a SPDX license short identifier.registered SPDX short identifiers, and is inspired by the fact that DNS names have an
|
|
|
|
Just following up, does anyone have any comments or suggestions for my
toggle quoted messageShow quoted text
proposal for SPDX Private License Identifiers?
-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Mark Atwood via Lists.Spdx.Org Sent: Thursday, January 24, 2019 10:31 AM To: spdx-tech@...; spdx-legal@... Cc: Spdx-legal@... Subject: A proposal for SPDX Private License Identifiers. Example: .com.amazon.-.ASL-2.0 I would like to propose a syntax for SPDX "Private License Identifiers". SPDX short identifiers and SPDX-License-Identifier declarations in source code and in compliance documents have proven to be useful. This proposal extends SPDX license tags to licenses created and used by organizations, that are unlikely to be applied to content by anyone other than the license author. And when I see an expanding namespace with worries about collisions and an overworked central naming authority, I always think "why not use the DNS?" Examples (these URLs are not correct): SPDX-License-Identifier: .com.amazon.-.ASL-2.0 SPDX-License-Identifier: .com.amazon.-.ASL-2.0 https://aws.amazon.com/doc/ASL-2.0 SPDX-License-Identifier: .com.amazon.-.ASL-2.0 https://github.com/aws/AmazonSoftwareLicense Private License Identifiers are indicated by a leading dot, followed by the reversed DNS name of the organization who created or authored the license, followed by a dot dash dot and then a short name of the same general form of a SPDX license short identifier. The leading dot is sufficient to separate this namespace from the registered SPDX short identifiers, and is inspired by the fact that DNS names have an implied trailing dot. The dot dash dot is to prevent someone from reversing the entire identifier string into a DNS name and trying to dereference it, because a bare dash is not a valid DNS name part. . DNS names be IDN (Internationalized Domain Name) and thus can contain non-ASCII characters. IDN components can be encoded in IDN Punycode, or in UTF-8, or in the Unicode encoding appropriate to the document. In a SPDX-License-identifier declaration, a Private License Identifier can optionally be followed by a URI pointing to the canonical license text. This URI should be under the control of the entity that controls the DNS namespace of the Private License Identifier. ..m Mark Atwood <atwoodm@...> Principal, Open Source +1-206-604-2198
|
|
|
|
Kate Stewart
Hi Mark, On Mon, Feb 4, 2019 at 2:57 PM Atwood, Mark <atwoodm@...> wrote: Just following up, does anyone have any comments or suggestions for my
I like the notion of using the DNS names being IDN as a way of prefixing this. We have the mechanism of "LicenseRef-" as a reserved prefix already for any id not on the SPDX license list[1]. How do you feel about combining it with your DNS suffix idea? The benefit is that this can extend to use in SPDX docs as well as with external sites, and doesn't force a dependency on external entity to keep list up to date. 404's happen (as web sites move, etc). ie. In text use: SPDX-License-ID: LicenseRef-.com.amazon.-.ASL-2.0 Then if someone shipping a SBOM with the information in it and wanted to record the license contents as well, they could cut/paste into the document. LicenseID: LicenseRef-.com.amazon.-.ASL-2.0 LicenseName: Amazon Software License version 2.0 ExtractedText: <text> insert here info </text> and still be able to represent the known state of the source code without relying completely on the web sites to stay stable over time. Thoughts? Kate
|
|
|
|
Gary O'Neall
+1 on Kate’s proposal of pre-pending the ID with license-ref – It would make the ID’s backwards compatible.
Gary
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Kate Stewart
Sent: Monday, February 4, 2019 2:51 PM To: Atwood, Mark <atwoodm@...> Cc: spdx-tech@...; spdx-legal@... Subject: Re: A proposal for SPDX Private License Identifiers. Example: .com.amazon.-.ASL-2.0
Hi Mark,
On Mon, Feb 4, 2019 at 2:57 PM Atwood, Mark <atwoodm@...> wrote:
I like the notion of using the DNS names being IDN as a way of prefixing this.
any id not on the SPDX license list[1]. How do you feel about combining it with your DNS suffix idea?
The benefit is that this can extend to use in SPDX docs as well as with external sites, and doesn't force a dependency on external entity to keep list up to date. 404's happen (as web sites move, etc).
ie. In text use: SPDX-License-ID: LicenseRef-.com.amazon.-.ASL-2.0
Then if someone shipping a SBOM with the information in it and wanted to record the license contents as well, they could cut/paste into the document.
LicenseName: Amazon Software License version 2.0 insert here info </text>
and still be able to represent the known state of the source code without relying completely on the web sites to stay stable over time.
Thoughts?
Kate
|
|
|
|
Philippe Ombredanne
Hi Mark:
On Mon, Feb 4, 2019 at 9:57 PM Mark Atwood wrote: Just following up, does anyone have any comments or suggestions for myWe surely could use a way to have namespaces of sorts for extra, non SPDX-listed license identifiers. This is something that I could use alright for ScanCode where we track roughly an extra 1000 licenses and exceptions more than in the SPDX list (ScanCode has 1456 licenses and exceptions and there are 415 in the SPDX list) ScanCode handles this today by returning a well defined LicenseRef-xxx in SPDX documents for non SPDX-listed licenses . And a recent contribution by Tobias Furuholm created a "namespace"-like convention to use this for ids for such licenses: License-Ref-scancode-<scancode license key> The project guarantees the <scancode license key> to be stable overtime (e.g. they can be deprecated if needed but never deleted) . See https://github.com/nexB/scancode-toolkit/issues/532 for some discussions SPDX-License-Identifier: .com.amazon.-.ASL-2.0[...] In a SPDX-License-identifier declaration, a Private License Identifier canSPDX-License-Identifier is not declaring an id, but instead using ids in an expression so I think this would break the license expression syntax may be? Otherwise how would express something such as: my-private-license1 AND my-private-license2 As a recap I think that: 1. having some kind of namespacing is a great idea 2. I find reverse DNS and dots hard to read and I would likely make many typos when writing/typing these down. 3. an SPDX-License-identifier is a whole expression so changes should not break license expressions. 4. it might be clearer to distinguish naming (giving an id) and documenting that id separately (providing extra information about this id such as at a URL to a text or other data) and not try to put them all in one place. 5. LicenseRef (and possibly some specified or conventional way to structure them) may be a way to consider -- Cordially Philippe
|
|
|