Hi David:

Thank you for your detailed feedback. See some comments inline below:

On Fri, Jun 10, 2022 at 10:47 AM Dennis Clark <dmclark@...> wrote:

Here is an example license list:

https://scancode-licensedb.aboutcode.org/

On Wed, Jun 15, 2022 at 12:16 AM David Kemp <dk190a@...> wrote:

Thanks Dennis. It appears that scancode has already done the administrative work to establish a unified (non-federated) license list.

Key Shortname SPDX ID
apache-2.0 Apache 2.0 Apache-2.0
apl-1.1 APL-1.1 LicenseRef-scancode-apl-1.1

Federated identity management is well-understood by users - nobody would mistakenly think that Dave99@... (or gmail:Dave99 using namespace:local notation) is the same person as Dave99@... (or outlook:Dave99). But switching to federated license IDs (spdx:Apache-2.0 and scancode:apl-1.1) doesn't sound like a user-friendly solution. The only thing that federation buys you is the ability to use colliding local IDs. But the cost is having to use qualified license IDs in order to avoid confusion and collisions. Is refusing to collaborate on deconflicting local IDs really worth that cost?

I am not sure I read you correctly but if are you suggesting that
Dennis, other ScanCode contributors and I are "refusing to collaborate
on deconflicting local IDs" for SPDX license ids, that's quite the
opposite.

For the record there are 530 licenses and exceptions in the SPDX
license list as of today (including obsolete ones). The latest
ScanCode license database (in git) has roughly 1300 **additional**
licenses that are not yet tracked in SPDX (1343 including deprecated).
We can contribute all these **today** to SPDX alright, but under the
current SPDX rules and staffing, it will take a very long while
(impossible to estimate) to have these reviewed and accepted; and they
may not be accepted at all based on current rules.

Questions:
1) has scancode assigned any Keys that case-insensitively match an SPDX ID but do not match license texts? (I assume not.)

No. We carefully ensure that there is no id conflict and have provided
and provide guarantees to our user community that ScanCode license
keys are aligned and do not conflict with SPDX license ids (ignoring
case) going as far as deprecating some of our license keys when new
SPDX assignments created a conflict (and these rare conflicts have
never been our making).

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.

3) for additional license authorities (e.g., "acme") is the same first-come-first-served id deconfliction rule acceptable?

I cannot see nor fathom why not... ids are cheap! So this is 100%
fine. The only value of an "id" is to "identify" and be easy enough to
read and memorize for humans.

4) What problem are you trying to solve by not agreeing on a unified local ID list?
A unified list can always include a registration authority column to communicate different registration requirements. I don't understand the need for anything else.

You may be incorrectly assuming that Dennis, ScanCode and its
contributors are "not agreeing on a unified local ID list". Again
that's quite the opposite and speaking on behalf of this community, I
am 100% for a unified license ID list which will benefit everyone and
be a disservice to none.

Please tell me if this is a correct reformulation: you are suggesting
having a single, unified list of license identifiers maintained at
SPDX and assigned on a first-come-first-served basis. And with a
simple rule that no two ids conflict ignoring case and no two ids
point to the same text (say using SPDX matching guidelines).

If this is what you suggest, I couldn't agree more and I would support
this 100%. Weirdly enough I do not think that this has ever been
suggested before. Let's do it! This feels massively simpler and more
efficient than qualifying license ids with a namespace.
--
Cordially,
Philippe Ombredanne