Richard:

On Mon, Mar 11, 2019 at 10:32 PM Richard Fontana <rfontana@...> wrote:

This sounds appealing to me (if I'm understanding it correctly). From
Red Hat's perspective one of the great impracticalities of SPDX has
been that, after many years of SPDX's existence, its adopted
identifiers still represent only a small portion of the licenses
encountered in much of the the software we encounter in our product
and project development.

Let me recap my understanding:

I think everyone agrees that we want want more licenses in SPDX.
Anyone against this, please voice your concerns now.

The review of new licenses for list is an all-volunteers process with
a certain level of ceremony explained here
https://spdx.org/spdx-license-list/license-list-overview and therefore
it takes time. But it takes too much time.

Why do I want an id for stable/well-defined licenses? This would make
it easier to talk about and exchange licenses and it does not require
the reproduction of the license text at all times.

Why not using a LicenseRef for these? This would still require
reproducing always the license text in every SPDX document, which does
not help when there is no document (e.g. in a package manifest such as
an npm or an RPM). NOASSERTION as used for now in ClearlyDefined is
also fraught with problems as highlighted by Richard earlier.

There are two main use cases for more licenses: private or public
licenses. The main concern is to ensure that these license ids are
unique enough in both cases, and that there is minimum or no
duplication of license texts across ids.

- For private licenses, the only concern is to ensure that names are
unique enough. Mark suggested using a reverse domain name prefix for
this. I suggested a lightweight registration of a prefix that would
not require one to own/buy a DNS domain name. The two can likely work
together (e.g. you could use a domain name or anything and still do a
one time registration). In anycase, I become the master of the license
texts and ids in my namespace.

- For public licenses one could use a prefix/namespace plus the
optional registration of actual license id/name/texts. A
content-defined fingerprint id may not help in practice as I explained
in a previous email as too brittle.

In light of all this, here is my suggestion:


1. Establish a lightweight, easy and fast registration process for
SPDX license id prefix (aka namespace). As simple as a quick PR in a
Git repo. This prefix can be made of any character that would be a
valid license identifier. This is used to prefix ids (and not in
LicenseRef). This way you can use both DNS and non-DNS names alright.
This can be used for both public and private namespaces.

2. Establish a lightweight, easy and fast registration process for
prefixed SPDX license ids in an existing namespace. As simple as a
quick PR in a Git repo.

Submissions are very lightly moderated (we want to register licenses
but not cooking recipes).

There is no need for any markup or other annotations at this stage:
only basic id, name, text and possibly URLs.

When submitted, there is an automated deduplication triggered (e.g. we
run a license scan on this license text) and if a submission is the
same or mostly the same as any existing SPDX licenses, the check
fails. (This is a CI script). The submitter can then reuse instead a
pre-existing license id.

4. We add a status for licenses records such that they are either
reviewed/approved by the SPDX legal team or not. The submissions of
namespaced ids would NOT be in the approved status.

5. From that point on, the SPDX legal team can use not only direct
requests for license additions but also can funnel selected public
registrations as candidates for inclusion in the main SPDX
non-namespaced License List.

Done.

--
Cordially
Philippe Ombredanne