Re: [spdx-tech] Reminder - meeting tomorrow on License Namespaces
Thank you for your detailed feedback. See some comments inline below:
On Fri, Jun 10, 2022 at 10:47 AM Dennis Clark <dmclark@...> wrote:On Wed, Jun 15, 2022 at 12:16 AM David Kemp <dk190a@...> wrote:Here is an example license list:
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
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: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
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
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?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.