New license request: Generic Proprietary license

rnjudge commented 1 year ago

Introduction

As more companies adopt SPDX to generate SBOMs for their proprietary software, it would be nice if there was a generic "proprietary" license identifier. I know that it's possible to use a LicenseRef for this, but using a LicenseRef requires advanced parsing of plain text to be interoperable with consumption tools and it would be nice to have a way to clearly indicate that a license is proprietary for automation purposes.

License Name

PROPRIETARY

Suggested short identifier

proprietary

URL to license text

N/A

OSI Status

I don't know

License author or steward

Unknown

URL to project(s) that use license

link is N/A. But large companies distributing non open source software to customers can utilize this.

jlovejoy commented 1 year ago

HI @rnjudge - If I understand your proposal correctly, this would be a sort of umbrella id that does not refer to a specific license text? In which case, this goes against the historical and current purpose of the SPDX License List (and, as I think you point out, "LicenseRef-") as a shorthand way to refer to a specific license text.

Even if we deviated from this aspect of the standard - How would one know when to use Proprietary? Licenses that are included on the SPDX License List must meet the inclusion principles, thus, I think you are implying that anything "proprietary" would NOT meet the SPDX License List inclusion principles, but then that would require review by... SPDX-legal to make that determination. And what is "proprietary" anyway? Presumably it wouldn't be any license that does not meet the SPDX license inclusion guidelines.

There is "NOASSERTION" in the spec which would be used.

I'm also not sure why LicenseRef could not be used here. If it's an issue that someone doesn't want to "publish" the license text in an SPDX doc, then having a category for the license that one cannot read isn't really that helpful

Maybe I'm not clear on what problem this is trying to solve, feel free to add comments here and maybe we can put some time on an upcoming SPDX-legal call to discuss!

tpepper commented 1 year ago

The way I'm thinking of this is that I want to exchange supersets of software package information in documents for software I'm involved with delivering and consuming. I imagine a future of very composable SBOMs. And where software is composed of packages from a variety of sources, some open/free and some commercial/proprietary. If I receive a software bill of materials for such software, one of my goals around licenses identified across the package set is to understand my obligations on individual packages and the composition of packages. For that it would be useful to be able to iterate on a packages list something like:

sh cat an_sbom.spdx.json | jq -c '.packages[] | {licenseConcluded}' It seems though that if Declared License and Concluded License are only strings in today's open source licenses list, then SPDX License List inclusion principles might ensure that an SPDX document is only capable of articulating the open source subset of exchanged software. And yet that outcome seems very limiting relative to the project's broadening goals and usage today.

NOASSERTION has been discussed in other contexts in the past, but feels factually incorrect where there is a declared license known, albeit not open. In this sense it's likely obvious to one who would need to use the hypothetical Proprietary identifier because they want to make an assertion of license, make a declaration, but the license is one considered not open and thus not in today's list of allowed assertions. Is the "Proprietary" word the hang up perhaps? Would "OTHER" or "NONOPEN" or something in that direction make more sense?

I'm certainly content to and expect to have conditional code which goes off to LicenseRef for next level comprehension of licensing, but it feels illogical when NOASSERTION is used that LicenseRef would be non-empty.

Also the actions one would take for these two cases, NOASSERTION and proprietary/nonopen/other, will be different. When NOASSERTION is used, one is likely to condition next action in the direction of go work to find the license or stop using the ambiguous component. The conditional action if there's some notion of proprietary/nonopen/other as an explicit assertion would be in the direction of comprehend the terms of the full license text and comply or shift usage.

rnjudge commented 1 year ago

+1 to Tim and I'll also add that one of the real benefits to an official proprietary/non-open license key is the machine readability/tooling interoperability aspect to all this. Putting text in a LicenseRef definition is not inherently machine readable or actionable, even using the most advanced text parsers. A nonopen/proprietary license key is actionable in that, as Tim mentioned, a tool can understand that a proprietary/nonopen license key implies there is an obligation to followup with the vendor to comprehend the terms of the full license text.

swinslow commented 1 year ago

Hi all, thanks for everyone's feedback here. I'd mention that this issue has come up from time to time previously (see #873 for one prior discussion of this a few years ago).

Since it would be a significant departure from the way the License List has worked to date, for an in-depth discussion of making a change like this, I'd suggest it might be helpful to have a discussion as part of a broader community discussion -- such as on the mailing list, as a change proposal and/or on one of the Thursday calls. That said, I'll include a few of my own personal thoughts on this below!

= = = = =

There's a few things I'd point out in considering something like this:

I'm not aware of any fully agreed-upon community definition of "proprietary". To the extent there's consensus on this (and really just speaking for myself), I'd probably view "proprietary" as "a license that is not open source," though others might differ on that.
But assuming that's the definition, the SPDX License List currently includes a number of licenses that are not open source. Some of the licenses on the list are source-available licenses with ethical restrictions, or non-commercial-use-only limitations, or other use restrictions.
The SPDX License List isn't intended to be a list of only (or all) open source licenses. Rather, inclusion is based on the license inclusion principles. Most of what's on the list are open source licenses, but some things on there would definitely be considered "proprietary" in most use cases.

Part of what follows from this is that, in any case -- no matter what the ID is, or whether it's on the license list or a LicenseRef- custom identifier, or a NOASSERTION -- is that it will always be necessary for someone to consider the license text as part of understanding obligations and responsibilities when using software. An SPDX identifier in and of itself doesn't assure anything other than that the SPDX Legal team thinks it meets the license inclusion principles. And introducing a "PROPRIETARY" identifier, among other concerns, may lead folks to incorrectly assume that anything not identified as "PROPRIETARY" is not proprietary.

One possible solution to this could lie in the concept of license namespaces which have been discussed from time to time over the last few years. The idea behind this was essentially to enable anyone to create their own namespaced, reusable LicenseRef- identifiers -- so e.g. anyone could create their own representation and definition(s) of "Proprietary" that they choose, and to have them be more easily reusable. Unfortunately, participants in the SPDX community have not been able to reach consensus on some details of license namespaces (I mentioned this on the mailing list recently as part of this thread), so this is not currently available as an option defined in the SPDX spec. But it's something that could be considered if there is a new effort to get consensus on it.

tpepper commented 1 year ago

Maybe I'm missing something really simple on the UX and this is already solved. Eg:

<ExtractedLicensingInfo rdf:about="licenseRef-SomeCorp-ede5c1663">
    <licenseId>LicenseRef-SomeCorp-ede5c1663</licenseId>
    <extractedText>"THE SOME CORP ETC ETC ETC LICENSE": pages and pages of misc boilerplate, terms and conditions, special obligations and responsibilities.</extractedText>
</ExtractedLicensingInfo>

And then across a packages list I could have:

<licenseDeclared>LicenseRef-SomeCorp-ede5c1663</licenseDeclared>

Reading Annex D it seems this is valid.

Have I been misled in the past by overzealous parsers requiring a license-id, NOASSERTION, or NONE and allowing less than what the spec seemingly allows?

swinslow commented 1 year ago

@tpepper Yes! This is exactly right. In the context of an SPDX document, any SPDX Document creator can define their own license texts in an "Other Licensing" section using the tags you indicated. The ID always starts with LicenseRef- as an indication that it is a user-defined license ID, and not one of the licenses on the SPDX License List.

After being defined, LicenseRef- IDs are fully valid per the license expression syntax, and can be used in expressions just like IDs on the License List. E.g., you could have a declared license expression which is LicenseRef-MyProprietaryLicense AND MIT.

Some tools out there will correctly generate LicenseRef- IDs for custom-defined licenses. But yes, I'm sure there are parsers that haven't taken the spec and license expression syntax into account, and aren't aware of LicenseRef- IDs.

tpepper commented 1 year ago

Ok! The current spec does have minimal viable functionality for the desired use case. Still doesn't quite feel like an intentional extensibility point for the common case of the intersection of the License List and non-License-List licenses, which real world SBOMs bring. I had not seen the namespaces discussion before and it's definitely interesting in how it would bring mechanically identifiable structure and unique identifiability/reusability to licenses in that intersection. I'll have to noodle on that some more, but I think we can treat this issue as a duplicate of the use case exposed in https://github.com/spdx/spdx-spec/issues/113

TomMiller-mas commented 7 months ago

Along with Proprietary, I would like to see Commercial. Have in IN "filename" option for both. At some point the usefulness of the feature to the WHOLE community needs to weigh into the decision. It seems this is only for Open Source projects.

spdx / license-list-XML