Expand License namespaces available

[kestewart]

From Mark Atwood:

Proposed: two methods for for organizations to self-declare SPDX license identifiers.
The two methods will be referred to a “organization names” and “dns names”.

Organization Name:
The SPDX Project maintains a list of organization names in github.
Organizations submit their entry into this list via github pull requests.
SPDX core maintainers sanity check the entry, discuss in meeting, and accept the pull request.
The entry contains a URL pointing to a SPDX doc maintained by the organization.
That file can contain the license definitions.
That file can contain XML URL external refers that point to more SPDX docs.
Completely ordinary XML parsing and external reference handling.

An example SPDX license tag: “License-Ref--amazon-ASL-1.1”. Notice the two hyphens.

The URL for the entry could be https://github.com/aws/spdx/registration.xml
The URL for the ASL-1.1 license could be https://github.com/aws/spdx/asl-1.1.xml

DNS Name:
An organization already has a DNS name, assigned via the ordinary DNS registration and name arbitration system.
The organization uses its DNS name, but reversed, similar to a JVM class name.
For example: “.com.amazon.”. Notice the leading and trailing dots, which are usually implicit in the DNS, but are made explicit here.
By using the DNS name, the organization can immediately start using their namespace without concern that it will conflict with a different organization.

An example SPDX license tag: “License-Ref-.com.amazon.-ASL-1.1”.

The organization may and should send a pull request to the SPDX github, treat similar to the “Organization Name” process.

[zvr]

👍 for the ideas of the two methods.

However, since I am not a Java person, I have to ask: as I think we don't anticipate any use of hierarchies, couldn't the DNS variant omit the reversal?
The example would be: License-Ref-.amazon.com.-ASL-1.1
We keep all the advantages of external registry (DNS) etc., and it looks (to people not used in Java class names) a little less foreign.

[kestewart]

From discussion on SPDX call - Mark Atwood & Gary agree that standard order DNS, with implicit dots, is preferred direction.

[kestewart]

Noting: external ref doc, can contain more external refs in them. Key is not to dictate policies on how companies organize internally.

For both flat and DNS names - allow register URL that points to SPDX doc (of Licenses).

Some further discussion of "contrib" in the SPDX github ecosystem where folks can contribute to an SPDX documents (possibly with a UI infront to easily enable the creation of SPDX document directly), has some support.

[goneall]

From our discussion on the April 2 tech call with @pombredanne , we agreed that this will require an update to the spec. License-Ref's with namespaces will not have license text within the same SPDX document. This may break some SPDX tools which require the text.

We agreed to create a pull request with some specific language to the spec. We are still thinking this could be 2.2 version.

[maddin778]

Duplicate of #

[goneall]

@maddin778 Did you forget to add the # this is a duplicate of?

[sschuberth]

Has the syntax for namespaces been finalized by now? I.e. which of these we supposed to use

1. License-Ref--amazon-ASL-1.1
2. License-Ref-.amazon.com.-ASL-1.1
3. License-Ref-amazon-ASL-1.1

FYI, ScanCode started to adopt the single-dash version (see 3.) a while ago.

[goneall]

Moving to 3.1.

[swinslow]

Although there has been interest in the concept of tying "license namespaces" to short-form license identifiers over the past several years, community participants have not be able to agree upon a concrete format for this. See for example #209 and #681 as past attempts. To my knowledge, there is no active discussion currently happening to try to resurrect this.

SPDX 3.0 (as with 2.3 and earlier) enables users to use LicenseRef-s to define their own custom license identifiers in an SPDX document. The existing license expression syntax (from 2.3 and earlier) enables using DocumentRef- prefixes to refer to these licenses, including in short-form license identifiers in source code. And external projects such as REUSE provide further recommendations for ways that projects can communicate the license text that corresponds to a LicenseRef-.

Given all of that, I don't see a need to keep this issue open. If a community effort re-emerges to develop a consensus around a format for license namespaces within the global identifier format, then perhaps we can revisit this, but I'm going to go ahead and close this issue.

[pombredanne]

What happens then is that everyone comes with their own namespace conventions.
Using a simple registry as a list of prefix is an easy thing and is used in many places.

[zvr]

Unfortunately I agree with @swinslow -- I would love to have this available, but it seems that the community is not ready to agree on crucial aspects of the implementation. Maybe sometime in the future the situation would be different.

[pombredanne]

I see namespacing using prefix used in Fedora, KDE, ScanCode and a few other places so actual users have already implicitly agreed on a simple approach. Not having a namespace is IMHO a disservice to SPDX.

[sschuberth]

I see namespacing using prefix used in Fedora, KDE, ScanCode and a few other places

ORT and Double Open do so as well.

it seems that the community is not ready to agree on crucial aspects of the implementation.

I'm a bit confused who "community" refers to here. If that's the wider OSS community around SPDX, isn't it exactly the responsibility of the SPDX working group to align those aspects and come up with an implementation decision?

[kestewart]

Community refers to a volunteer stepping up to do the homework of preparing a proposal to go into SPDX, and then building consensus so it can be merged. Last few attempts failed by people walking away and not engaging in the conversations.

We don't have a volunteer working on a proposal at this point, so if there is a volunteer it can be reopened.