(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 <dk1...@gmail.com> 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/ <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/ <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 > <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 > <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/ > <https://www.nsa.gov/About/Cybersecurity-Collaboration-Center/> > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#3154): https://lists.spdx.org/g/Spdx-legal/message/3154 Mute This Topic: https://lists.spdx.org/mt/91827020/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
