License Identification


David Kemp
 

(On a related note, we also support registration of a numeric identifier for each license identifier, as ISO 3166 (https://www.iso.org/obp/ui/#search) assigns both a number and a text ID to each country..  This is for use in efficient non-human-readable data formats such as Protobuf and CBOR.
[JL]  The SPDX License List already provides a machine-readable (text) unique id to each license. Why is that not enough?

For three reasons:
1) efficiency - a 16 bit integer is sufficient to identify 65,000 licenses.  CBOR uses variable-length encoding of integers (major type 0), and even in JSON a number (e.g. 942 - three bytes) is more efficient than a string ("AGPL-3.0-or-later" - nineteen bytes).  When SBOM files climb into the megabyte range, efficiency matters.
2) registration reliability - double-entry bookkeeping was invented to detect errors by enabling independent checks.  Assigning both numeric and string IDs to a license text promotes robustness in the registration process and facilitates anomaly detection.
3) precedent - for the same reason IANA manages ports ("http" = port 80) and status codes (404 = "Not Found"), and the same reason databases use things like numeric primary keys instead of strings.  Numbers are meaningless - nobody is going to claim copyright infringement on the number 279, even though there might be claims by native Americans against strings like "Apache-2.0".  In the off chance that courts force a license ID to be invalidated, the referenceNumber remains a constant identifier that can be mapped to a new string ID.

Regards,
David Kemp


David Kemp
 

[DK]:
Using different technical mechanisms to identify source-available licenses and other licenses is not efficient, and we strongly support the use of a single technical mechanism (a deconflicted unified license identifier list) for use in SBOM files.
[JL]: 
I interpret this as meaning you support the concept of having a more “transferable” way to use LicenseRef- as per the original intent of the proposal - that is, a license defined using LicenseRef- is not “limited” to just being identified in that specific SPDX Document. Note, there is also already a way to capture license text for LicenseRef- licenses and link it - this is part of an earlier call and there is a task to improve the explanation of this in the spec because no one was really aware (see previous meeting notes about that)

No, you are mistaken.  I am not looking for a way to use LicenseRef-, because LicenseRef- uses "a different technical mechanism" for different licenses.  Instead of jumping to the technical solution of using LicenseRef, I am looking at the problem LicenseRef- was created to solve and observing that there is a simpler alternative that applies to all licenses registered by a license registration authority.  License registration authorities, of which the SPDX legal team is one, assign license IDs to license texts using processes of their own choosing. The single technical requirement is trivial: IDs cannot be duplicated or re-used - once an ID has been assigned to a text by an authority, the same ID cannot be assigned to a different text.

Regards,
David Kemp

(now subscribed to spdx-legal)


J Lovejoy
 

(removing general mailing list and adding spdx-tech)

David, 

A few clarifications below:

Btw, you are not a member of the spdx-legal mailing list, so these emails keep bouncing. Could you please join it, so I don’t have to manage the bounces?  :) 

Thanks!
Jilayne


On Jun 17, 2022, at 11:43 AM, David Kemp <dk190a@...> wrote:

All,

I strongly support Gary's approach of identifying requirements first, then identifying and selecting from technical solutions that meet all requirements.

The requirements are:

* The SPDX legal team must:
  - define criteria for accepting licenses
  - evaluate licenses for conformance with the criteria
  - publish a list of licenses that meet the criteria

To be clear - this is already well-established as what the SPDX legal team already does for the SPDX License List. 
This is NOT part of the current proposal we’ve been discussing the last 3 Fridays b/c it doesn’t need to be. Please familiarize yourself with the explanation and links at the top of the license list page https://spdx.org/licenses/ in contrast to the section in the SPDX Spec regarding “Other License Info” and the use of LicenseRef- here: https://spdx.github.io/spdx-spec/other-licensing-information-detected/

The “namespace” proposal builds upon the LicenseRef option. 


* The SPDX technical team must:
  - define SBOM data formats that unambiguously identify licenses applicable to all software of interest in the cybersecurity domain.

I’m not sure that is entirely accurate. How licenses are identified is the domain of the SPDX legal team, although I recognize that “identify” is broad and we may be thinking of that in different ways.
And identifying licenses is certainly of interest to more than the cybersecurity domain.


Today's discussion presupposes a technical solution, e.g., using namespaces, tying namespaces to DNS names, resolving IP issues related to licenses and namespaces, etc.  Other technical solutions that avoid namespaces are on the table and have not yet been discussed.

Let’s keep in mind (because I fear it gets lost and that may contribute to why we’ve been talking about this proposal for… years!) the high-level goal of the proposal which is to create a standard way to use LicenseRef- such that a License-Ref can be used to refer to a specific license outside the context of an SPDX Document, by using a ’namespace’ along with LicenseRef-. 
The original intent was in the context of licenses that don’t meet the SPDX License Inclusion principles (which by the way, have been revised and softened since this discussion began). 

* Software licenses that apply only to executables and do not provide for the availability of the source code will not be included on the SPDX License List.
this is one of the current SPDX License List inclusion principles.  There is a long history and sensible rationale for this, which I’m happy to fill you in on separately. 


The U.S. Government has an interest in promoting cybersecurity through supply chain assurance, which includes SBOMs for software that is out of scope for SPDX registration (e.g., software for which source code is not available). 
In the case that the US Government is using SPDX for its SBOM format, then there is already a way to document such licenses by way of section 10 

The U.S. Government has an interest in promoting efficient SCRM solutions.

Using different technical mechanisms to identify source-available licenses and other licenses is not efficient, and we strongly support the use of a single technical mechanism (a deconflicted unified license identifier list) for use in SBOM files.
I interpret this as meaning you support the concept of having a more “transferable” way to use LicenseRef- as per the original intent of the proposal - that is, a license defined using LicenseRef- is not “limited” to just being identified in that specific SPDX Document. Note, there is also already a way to capture license text for LicenseRef- licenses and link it - this is part of an earlier call and there is a task to improve the explanation of this in the spec because no one was really aware (see previous meeting notes about that)

(On a related note, we also support registration of a numeric identifier for each license identifier, as ISO 3166 (https://www.iso.org/obp/ui/#search) assigns both a number and a text ID to each country..  This is for use in efficient non-human-readable data formats such as Protobuf and CBOR.
The SPDX License List already provides a machine-readable (text) unique id to each license. Why is that not enough?

  referenceNumber is already populated in the license list database https://github.com/spdx/license-list-data/blob/master/json/licenses.json but is not visible in the web version.)

Regards,
David Kemp
NSA Cybersecurity Collaboration Center
https://www.nsa.gov/About/Cybersecurity-Collaboration-Center/


David Kemp <dk190a@...>
 

All,

I strongly support Gary's approach of identifying requirements first, then identifying and selecting from technical solutions that meet all requirements.

The requirements are:

* The SPDX legal team must:
  - define criteria for accepting licenses
  - evaluate licenses for conformance with the criteria
  - publish a list of licenses that meet the criteria

* The SPDX technical team must:
  - define SBOM data formats that unambiguously identify licenses applicable to all software of interest in the cybersecurity domain.

Today's discussion presupposes a technical solution, e.g., using namespaces, tying namespaces to DNS names, resolving IP issues related to licenses and namespaces, etc.  Other technical solutions that avoid namespaces are on the table and have not yet been discussed.

* Software licenses that apply only to executables and do not provide for the availability of the source code will not be included on the SPDX License List.

The U.S. Government has an interest in promoting cybersecurity through supply chain assurance, which includes SBOMs for software that is out of scope for SPDX registration (e.g., software for which source code is not available).  The U.S. Government has an interest in promoting efficient SCRM solutions.

Using different technical mechanisms to identify source-available licenses and other licenses is not efficient, and we strongly support the use of a single technical mechanism (a deconflicted unified license identifier list) for use in SBOM files.

(On a related note, we also support registration of a numeric identifier for each license identifier, as ISO 3166 (https://www.iso.org/obp/ui/#search) assigns both a number and a text ID to each country..  This is for use in efficient non-human-readable data formats such as Protobuf and CBOR.  referenceNumber is already populated in the license list database https://github.com/spdx/license-list-data/blob/master/json/licenses.json but is not visible in the web version.)

Regards,
David Kemp
NSA Cybersecurity Collaboration Center
https://www.nsa.gov/About/Cybersecurity-Collaboration-Center/