For SPDX 2.3 I don't object to Gary and Alexios proceeding rapidly to close the issue using the currently-proposed LicenseRef- syntax. For SPDX 3.0 I strongly believe a much simpler approach should be used.
*Problems that are In-scope:* 1, 4, 5b *Problem #4* is easily solved with a *Unified License List*: the union of license identifiers contained in the set of recognized license lists: "Apache-2.0" is contained in the SPDX license list after SPDX's comprehensive legal vetting process. "abrms" is contained in the ScanCode license list after their vetting process registers licenses found in code, even silly ones such as https://scancode-licensedb.aboutcode.org/abrms.LICENSE. The radical difference in vetting requirements is irrelevant to the technical requirement to "efficiently reference licenses" by linking a unique identifier to a license text. Both Apache-2.0 and abrms appear on the unified list and can be used in SPDX files, CDX files, and any other files that use license identifiers. Apache-2.0 is accepted by both spdx and scancode, abrms is accepted only by scancode. *Problem #5(b)* is solved when two or more organizations agree on a list of recognized namespaces: *spdx: https://spdx.org/licenses/ <https://spdx.org/licenses/>**scancode: https://scancode-licensedb.aboutcode.org/ <https://scancode-licensedb.aboutcode.org/>* The policy considerations for SPDX to recognize a scancode namespace must be resolved in order to implement the LicenseRef- solution. The identical considerations apply to the unified license list. There is no 5(a) public relations requirement to "promote" other license lists; they just have to appear on the "recognized" list. *Problem #1* applies to licenses that do not appear on any recognized license list. A LicenseRef- that points to the text of a non-listed license is the appropriate solution to that problem. Regards, Dave *License namespace problem statement:* 1. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document. 2. Unable to reference or locate text for non-listed licenses when used in license expressions within source files 3. Unable to reference or locate text for non-listed licenses when license expressions are used in package manager meta-data files 4. Ability to efficiently reference common licenses which are not on the SPDX License List, including those which do not meet the SPDX license inclusion principles Reworded: Should we have a way to efficiently reference common licenses which are not on the SPDX License List, regardless of context (e.g. not specific to source code / Documents / package managers) 5. Ability to advertise the availability of license lists other than the SPDX license list 5(a): Ability to **promote** license lists other than the SPDX license list in a similar fashion to how we promote tools that support the SPDX standard 5(b): Ability to **locate/find** license lists other than the SPDX license list Well-known/registered namespaces: spdx: https://spdx.org/licenses/ scancode: https://scancode-licensedb.aboutcode.org/ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4633): https://lists.spdx.org/g/Spdx-tech/message/4633 Mute This Topic: https://lists.spdx.org/mt/92053148/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
