Change Proposal: Expand Options for Data License in SPDX Documents

[Pizza-Ria]

Owners
• Ria Farrell Schalnat (Pizza-Ria) – Open Source Program Manager for Hewlett Packard Enterprise and Chris Hibbard – Open Source Security Architect

Issue Statement
• SPDX Version 2.3 Section 6.2 contains a Data License Field (see also, associated file under the spdx-3-model) as part of the SPDX document creation information section which requires that any SPDX-Metadata be subject to the terms of the Creative Commons CC0 1.0 Universal license. The stated intent of this license choice is to alleviate concerns “that content (the data or database) in an SPDX document is subject to any form [emphasis added] of intellectual property right that could restrict the re-use of the information or the creation of another SPDX document for the same project(s).” See also, Legal Team/Decisions/SPDX-Metadata-License - (January 18, 2012). The explanation continues that “individuals can still contract with each other to restrict release of specific collections of SPDX documents (which map to software bill of materials) and the identification of the supplier of SPDX documents.”
• The decision surrounding the license for the SPDX metadata, while positively intended to foster communication and collaboration, was made prior to the advent of SBOM requirements in various jurisdictions including the those in the United States stemming from Executive Order 14028 (May 12, 2021). These requirements will eventually cover the entire software supply chain for a software product sold to the federal government. This may involve many tiers of both open source and proprietary software including code distributions subject to confidentiality or other contractual restrictions. Sharing such SBOMs under a license that effectively waives any copyright and database rights carries the potential for, at least, confusion and misinterpretation regarding the ability to share such documents especially if contradictory provisions are attached in other fields such as comments.
• While Hewlett Packard Enterprise (HPE) recognizes that the original choice of license satisfies many use cases for SPDX documents that may be freely shared throughout the supply chain, we are concerned that these clauses contradict one another where information outlined in an SPDX document (e.g., SBOM) may be subject to confidentiality or trade secrecy (either inherently or via additional contractual restrictions) especially since the CC0 license may be considered “public domain” (see, “CC0 enables scientists, educators, artists and other creators and owners of copyright- or database-protected content to waive those interests in their works and thereby place them as completely as possible in the public domain. [emphasis added]”).
• HPE is particularly concerned that utilizers of the SPDX document may not be aware of such confidentiality/trade-secrecy/contractual obligations and, either directly or via machine automation, not recognize the obligations associated with such documents. The consequence is that a recipient may inadvertently share such SBOMs under the assumption that the CC0 license permits such sharing. Adding commentary or additional metadata to the SPDX document runs the risk of further confusing the issue or having such additional restrictions overlooked.
• Entering an alternative identifier for the Data License field results in SPDX validators failing which raises questions from recipients as to the efficacy of the SPDX document.
• Thus, use of the SPDX standard for communicating SBOMs either runs a risk of disclosure or creates friction/manual work in explaining why our SBOMs do not pass validators if a different license is chosen. Furthermore, we do not believe this situation is unique to HPE and could have a prohibitive effect regarding adoption of SPDX as the chosen SBOM standard in the industry.

Proposed Solution
• Update the documentation and validators to accept alternative entries to the Data License field in the documentation metadata including licenses already recognized by SPDX
• (https://spdx.org/licenses/),
• “none”/”no assertion” as defined in https://spdx.github.io/spdx-spec/v2.3/file-information/#85-concluded-license-field, and
• other licensing information (e.g., EULAs or NDAs) as recognized by “license-ref-[idstring]” in https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/.

Describe the benefit to SPDX and its ecosystem
• Requirements for SBOMs are a feature in US EO14028, NTIAs SBOM Minimum Data Elements, CISAs standard form for SBOMs (Mar 14 2023), OMB M-22-18, SSDFv1.1/ SP800-218, SBOM requirements in other jurisdictions and other private/public measures. These requirements go beyond the simple standards of attribution documents practiced in the open source world by requiring identification of vendors, component relationships and other metadata associated with both open source and proprietary software components in products. Some of this information will be subject to contractual restrictions (e.g. non-disclosure agreements, EULAs, etc.) to protect information that needs to remain confidential/secret outside the mere identification of the open source package/license/copyrights.
• The proposed change will allow adopters of the SPDX format to prepare SPDX documents that correctly categorize such restrictions where they apply (SPDX recognized such special cases may exist in its 6.2 document) and honor obligations/restrictions received from their upstream vendors while clearly communicating such restrictions downstream to avoid accidental leaks/confusion.
• While HPE supports SPDX’s mission to promote open standards for communicating software bill of material information, there are certain circumstances where this is not desirable and the inability to designate an alternative license will damage credibility/trust in the provision of SPDX documents downstream. Inability for an SPDX validator to accept alternative license designations will also create friction in automation for organizations as they will not be able to seamlessly ingest such documents and will need to engage in additional tooling to automate inquiries or even manual effort to resolve such issues.

Scope of impact
This would require any update to https://github.com/spdx/spdx-3-model, for the section aligning with #62-data-license-field in the SPDXv2.3, as well as SPDX validation mechanisms which currently fail if an identifier other than CC0 is provided for the field “datalicense”.

Additional information
• This change proposal reopens spdx/spdx-spec#159 for discussion and acceptance.
• This change proposal also reiterates the concerns raised by Mark Atwood in Issue #850 (“I would like to reopen this issue. Amazon has severe reservations about being required to tag the SBOMs of our internal services and delivered products as CC0, even if there is also an NDA in place. We especially don't want to have "you put a CC0 on it" when someone else publishes something that was provided to them by someone breaking their NDA. The other SBOM standards do not require a CC0 or other license tag.”).

[goneall]

In support of this change proposal, I picked up feedback at the LF Open Source Summit NA conference that having this as a required field has negatively impacted adoption for security use cases.

I would also like to suggest that we make this property optional - that would remove all objections. From my discussions, even having a required license field incurs extra overhead for some of the SBOM producers.

[BrianInglis]

Are there not some Fedora/Cygwin?/RedHat?/IBM? concerns with licensing some things under CC0 raised by @richardfontana or is this considered allowed content under their rules?

[swinslow]

@Pizza-Ria Thanks for re-opening this discussion, and for the detailed issue statement and proposed solution.

Speaking for myself (and not for the SPDX legal team generally), I'm in favor of implementing this change proposal, with a few comments / caveats. CC0-1.0 is 100% sufficient for my own SPDX document-making needs, so I don't personally have a need for a change here, but I understand the desire for a broader range of options here.

In particular, I share your concern about the potential confusion arising from requiring the SPDX Document to be labeled as DataLicense: CC0-1.0, while also saying that it can be distributed under e.g. confidentiality terms. Regarding how we usually think about SPDX License Expressions, if something was released under CC0-1.0 together with terms imposing confidentiality restrictions, I would tend to think of the appropriate license expression being something more like DataLicense: CC0-1.0 AND LicenseRef-My-EULA-NDA or whatever. (Presumably with LicenseRef-My-EULA-NDA then defined in the same SPDX Document, in an "Other Licensing Info" section.) So it does seem to me that mandating the statement DataLicense: CC0-1.0 may be confusing and/or misleading in those use cases.

I think my bigger concern, though, is generally with mandating that an SPDX Document MUST be licensed under a particular license, whether CC0-1.0 or something else. I am not aware of any other data format specification which mandates a particular license for data expressed using that specification. (There may be some! I just don't know any.) I guess my concern with mandating CC0-1.0 is really about, between the DataLicense: CC0-1.0 requirement and the SPDX Trademark rules, essentially saying that an SPDX Document cannot be described as an SPDX Document if it is under anything other than CC0-1.0.

All that said, I do think that the community (both in the specification itself, and in ancillary materials) should continue to recommend that users SHOULD use CC0-1.0. I continue to think that, even for the newer use cases, the greatest utility for SBOMs and for software transparency will come from an absence of restrictions on their usage by recipients. I'm a bit skeptical of how useful an SBOM will be if a recipient / consumer has to figure out "OK, I can do X but not Y with it". And I know that a lot of bog-standard NDAs have terms such as "thou shalt not copy any Confidential Information" or other such terms which will be kind of nonsensical for SBOMs. So I think it's absolutely worth the SPDX community continuing to recommend that SBOM producers SHOULD use CC0-1.0, but I'm +1 on removing it as a mandatory obligation.

As far as what to change to, I tend to agree with the proposal that any SPDX License Expression should be permitted, including NONE and NOASSERTION. I also agree with @goneall's request that DataLicense should be an optional field. Again, if someone ends up producing an SPDX Document with NONE or NOASSERTION or no DataLicense field at all, then it's possible it'll be of very limited use to its recipients. I just don't see that as something that we should continue to police via the requirements of the spec itself.

[Artoria2e5]

Just going to get the point in spdx/spdx-spec#850 (comment) here too.

• Copyright-based licensing is not something you want to use to protect confidentiality. But since we call the field "license", we can, like @swinslow suggests, indicate any other restriction added to the thing.
• The US does not recognize "database rights". Trying to claim any copyright over an SBOM will be difficult, so we should definitely not tell users to expect this field to work with basically anything in the Annex A SPDX License List that is not CC0.

[BrianInglis]

The product list data in an SBoM may not be copyrightable in the US, but may be elsewhere in the world, as are the published documents in which they appear, and each products' licence expressions by the packagers, as this is typically not data included in the project source, although a licence instance may be (e.g. GPL2), or it may just be named (e.g. as GPL2+) or linked in the project docs, to a mailing list post, or quoted from a personal (e-)mail.
Given copyright anywhere, you need a licence to copy it in those jurisdictions which have copyright on all data and expressions (Europe and most other countries with related civil and criminal codes: just as the US has moved to criminalize formerly civil business issues, other countries' codes have long criminalized all attempts to steal all intellectual properties from their owners, particularly when those owners brought law).
And given Amazon and Fedora both have issues with CC0, it appears that a replacement is needed to address all the issues raised.

[Artoria2e5]

The linked Fedora issue is for code. SBOM is clearly not code but "content".

While the US is but one jurisdiction, it does show that there needs to be caveats spelt out clearly to the user if one wants to use a "copyright license" such as (well, most of the Annex A) GFDL. These licenses revolve around having some right to license out; there's no copyright without reaching a threshold of originality and DB rights are not widespread. And SBOM is exactly the type of thing that is likely to fail this bar: it's most commonly spit out by a program and never edited.

[richardfontana]

The Fedora policy is not applicable to this issue for two reasons: (1) an SBOM would be treated as "content" rather than "code" or "documentation" and CC0 is permitted for "content"; (2) there is pretty much zero likelihood that Fedora would ship an SPDX Document as far as I can foresee. Fedora's interest in SPDX is purely around the expression language and the license/exception list as a basis for license approval classifications and package license metadata.

[jlovejoy]

As @Pizza-Ria noted above, it would help if people commenting on this proposal familiarize themselves with the background on this field which is discussed in https://wiki.spdx.org/images/SPDX-TR-2014-1.v1.1.pdf and https://wiki.spdx.org/view/Legal_Team/Decisions/SPDX_Metadata_License:_Preamble_and_CC0_1.0_Universal

When this issue came up previously, I wondered about simply removing this field altogether... not sure how I feel about that or if that would make a bigger mess. In any case, having some flexibility as @Pizza-Ria suggests, is probably the best option.

I like @goneall suggestion of also making the field optional and agree with @swinslow idea of still encouraging CCO-1.0

[Artoria2e5]

TR-2014-1.v1.1 also does not actually consider CC0 incompatible with confidentiality. The only downside given was implying there could be any copyright on this data in the first place. The final decision text avoids that issue by saying "CC0 if copyrightable at all; a no warranty disclaimer otherwise".

What I think is needed is a short writeup from the legal team about how exactly CC0 is compatible with confidentiality. It will be made easier if we can use an AND syntax.

We could still go down the route of full license flexibility, but again we need some "copyrightable at all" language similar to the one we have in the decision. Adding restrictions based on rights you probably don't have is not very useful. The last thing we want is a bunch of computer-generated SBOMs floating around claiming they are CC-BY-NC-ND. That just wastes everyone's time.

[swinslow]

@Artoria2e5 I don't think I agree that a further analysis or writeup is needed here on "is an SBOM copyrightable or not."

Ultimately, broadening the DataLicense field to be both optional and also open to use any valid SPDX license expression essentially leaves it up to the SPDX document producer. Some folks will make SBOMs without using that field at all; some will continue to put CC0-1.0 on them (I will!); and some might pick other licenses from the License List and/or custom terms. That's fine; if someone produces an SBOM with terms that no one else wants to use, then it won't get used.

Or, if someone produces an SBOM with aggressive license terms, recipients are free to make their own determination that copyright doesn't apply and that they don't have to comply with those terms.

I guess what I'm saying is that changing DataLicense to be optional and also open to any expression gets the SPDX community out of being in the middle of specifying how SPDX documents need to be licensed, which I think is the goal here (at least, it's a goal I'm in favor of).

[MarkAtwood]

Amazon would prefer that this field be optional. And optional or not, that it allow any license tags, including “none” ”no assertion” and “license-ref-*"

[zvr]

Simply to confirm, this whole change proposal is only about the DataLicense property of SPDXDocuments in SPDXv2, correct?

More specifically it is not about SPDXv3, where dataLicense is not only a property of spdxDocument but of every piece of SPDX information.

Having different licenses in SPDXv3 context will be detrimental to adoption and use of SPDX in general.

As an example, I might receive the information that there is Package named zlib-1.2.13 with a downloadLocation value of https://zlib.net/zlib-1.2.13.tar.gz.
If I receive this same information under different dataLicenses, I would not be able to re-use one piece and have to keep all different instances.

The presence of different dataLicenses would seriously hinder any reusability or data-linking efforts.

Or, in a more likely scenario, SPDX consumers will decide that such information is not copyrightable and proceed to ignore dataLicense properties for some Elements (and maybe everything).

Since I think having data compatibility between SPDXv2 and SPDXv3 is a worthwhile goal, in my opinion, I am strongly in favor of only allowing CC0-1.0 in every case.

[zvr]

Ah, I've just noticed that, while the proposal is titled "... in SPDX Documents" and text keeps referring to "SPDX documents" and "SBOMs", the "scope of impact" also includes:

This would require any update to https://github.com/spdx/spdx-3-model

I would like a clarification whether this is a proposal about the data license of "SPDX Documents" or of every piece of information expressed in SPDX format.

Please keep in mind that in SPDXv3, "SBOMs" and "SPDXDocuments" are not the only/main way of structuring the information.

Having different licenses in every single piece of information (e.g., the validity of a CVE for a software package) will result in unusable data...

As I wrote above, I am (now even more) strongly in favor of only allowing CC0.

[goneall]

Having different licenses in every single piece of information (e.g., the validity of a CVE for a software package) will result in unusable data...

Although this can be quite inconvenient for the consumer to have to deal with the possibility of different data licenses for each element, I can see a use case where this is a benefit.

Consider the case where you are aggregating data from public and private sources and you want to make sure no private SBOM data is exposed. You can use the data license to filter appropriately and implement compliance procedures for what SBOM elements are provided publicly.

A couple possible compromises:

• Make it optional but if it is present it must be CC0
• Create a very simple profile who's only requirement is all element must have a data license of CC0 - something like a "SBOM Sharing Profile"

[Pizza-Ria]

I've been out on vacation and just catching back up on this thread. Open to discussing compromises but having a single hard requirement makes this very difficult for companies under NDA restrictions (+ other concerns) to be able to have a compliant SBOM under the current standard.