Hi David: Thank you for your detailed feedback. See some comments inline below:
> On Fri, Jun 10, 2022 at 10:47 AM Dennis Clark <dmcl...@nexb.com> wrote: >> Here is an example license list: >> >> https://scancode-licensedb.aboutcode.org/ On Wed, Jun 15, 2022 at 12:16 AM David Kemp <dk1...@gmail.com> 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 dav...@gmail.com (or gmail:Dave99 using namespace:local > notation) is the same person as dav...@outlook.com (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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3149): https://lists.spdx.org/g/Spdx-legal/message/3149 Mute This Topic: https://lists.spdx.org/mt/91669820/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
