I wanted to clarify Philippe’s comment on how the SPDX-legal team chooses ids (which is generally documented here: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-fields.md ) as specific to the examples mentioned below:

(also note - this thread was cross-posted to the tech and legal mailing lists, but it looks like David (?) is not on the legal mailing list, so it then seems like all replies may only be going to the tech list. If there is a cross-functional topic, please be sure you are a member of the relevant mailing lists so responses don’t get sidetracked away from one list or another)

Re: Reminder - meeting tomorrow on License Namespaces
From: Philippe Ombredanne
Date: Wed, 15 Jun 2022 17:43:01 MDT


2) has the SPDX legal team agreed to not assign any SPDX IDs that case-insensitively match a current or future Scancode Key without matching license texts? (I hope so, otherwise migrating to qualified license IDs is unavoidable.)
Not that I know of, but that would be a fairly easy and super useful
thing alright.
As a practical conflict example, we have been tracking in ScanCode the
Arphic Public License with the "arphic-public" and SPDX
"LicenseRef-scancode-arphic-public". When this was eventually added to
SPDX in the license list 3.17 this May, the key picked by SPDX has
been instead: "Arphic-1999"

The way we resolve this in the ScanCode licensedb is to:
- use the new "Arphic-1999" as the SPDX license id
- move our now "old" "LicenseRef-scancode-arphic-public" to a list of
"other_spdx_license_keys" because our user and their tools may depend
on this.

FWIW, we have been tracking this "arphic-public" for at least seven
years since before ScanCode was called ScanCode. I am not claiming
precedence here, rather just stating the date since when we started
tracking these in ScanCode licensedb for reference. These licenses
likely have existed for a long while before.

The same also happened in that same SPDX license list release:
- SPDX picked "Baekmuk" over ScanCode's "baemuk-fonts" (in ScanCode
since before 2015)
- SPDX picked "Bitstream-Vera" over ScanCode's "bistream" (in ScanCode
since before 2015)
- SPDX picked "mplus" over ScanCode's "m-plus" (in ScanCode since 2019)

So if the SPDX process could kindly consider and reuse identifiers we
have already used in ScanCode that would be more than nice and surely
help diminish a possible source of confusion.

ALL of the examples referenced were licenses already recognized and used by Fedora on their list. SPDX adopted the ids already in use by Fedora. This is directly inline with the documented description of SPDX License List fields for short identifiers as per the link above. I would hope that we can all agree that we should adopt the id used by a long-standing community project.