Richard: On Mon, Mar 11, 2019 at 10:32 PM Richard Fontana <rfont...@redhat.com> 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3669): https://lists.spdx.org/g/Spdx-tech/message/3669 Mute This Topic: https://lists.spdx.org/mt/30299820/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
