Add “NONE” to the license expression syntax

[wking]

Spun out from today's legal meeting, I think we should add UNLICENSED NONE to license expressions, because external tools like npm's package.json are currently defining UNLICENSED as an extra for the “all rights reserved” case. I'm happy to work up a pull request if/when #37 lands.

[pombredanne]

Nice, but bad idea IMHO: this is a wart in the NPM doc if you want my take: using no-assertion or nothing is better. Furthermore this would be confusing because of the unlicense is itself a license http://unlicense.org/

Having a generic "proprietary" license id when the terms are not FLOSS and the license is not specified would be best: FWIW this is the approach I use in scancode https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/proprietary.yml

[wking]

On Tue, Nov 14, 2017 at 08:25:49AM +0000, Philippe Ombredanne wrote: Nice, but bad idea IMHO: this is a wart in the NPM doc if you want my take: using no-assertion…

No-assertion has a different meaning [1], and is not a good way to represent “all rights reserved, no license granted”. I think the proper SPDX for this is NONE [1], and I've updated the issue title and topic-post accordingly.

… or nothing is better…

Are you suggesting [2]: SPDX-License-Identifier: with an empty value? I'd much rather see something explict there when the author intends to mark “all rights reserved”.

Furthermore this would be confusing because of the unlicense is itself a license http://unlicense.org/

Distinct names are good. Since SPDX already has NONE, we shouldn't have any problems making it a part of the license expression syntax [3], vs. our current approach of grafting it on afterward [1].

Having a generic "proprietary" license id when the terms are not FLOSS and the license is not specified would be best…

That would work too, and would come down to what SPDX considers in-scope. However, we already include a number of non-free (according to various folks like the FSF) licenses, and we already specify NONE as a concluded-license value [3], so it seems strange to me to decide to scope license expressions more narrowly. [1]: https://spdx.org/spdx-specification-21-web-version#h.ihv636 [2]: https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b [3]: https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60

[kestewart]

This needs more discussion in technical meeting.

[pombredanne]

we have enough of NONE is the spec as it is IMHO. No license should not be stated, that's just it. Let's not over complicate things there.

[wking]

we have enough of NONE is the spec as it is IMHO.

If we add it to licence expressions, we can remove it from all the other places.

No license should not be stated...

What would you suggest an author put in SPDX-License-Identifier: for "all rights reserved"?

[david-a-wheeler]

It's important to distinguish different cases, that's the whole point of having a standard language.

Section 3.13 (Concluded License) already adds 2 additional values that really should be built into the SPDX license expression itself, namely NONE and NOASSERTION.

NONE means "if the SPDX file creator concludes there is no license available for this package". I interpret NONE as meaning "all rights reserved, there isn't even a proprietary license available for its use". E.g., if the source code is a trade secret. That probably needs clarification, to make it clear that NONE means "all rights reserved, there is no license available for it, not even a proprietary license".

NOASSERTION is to be used if:

• (i) the SPDX file creator has attempted to but cannot reach a reasonable objective determination;
• (ii) the SPDX file creator has made no attempt to determine this field; or
• (iii) the SPDX file creator has intentionally provided no information (no meaning should be implied by doing so).

I think it's important to distinguish between "NONE" (no license available) and "NOASSERTION" (no license information is provided, there may be a license, but that information is expressly not being claimed).

I should note that the "Unlicense" has SPDX license expression "Unlicense", not "Unlicensed". It's easy to miss the difference, so I recommend avoiding the term "UNLICENSED" to avoid confusion.

It might be useful to assert that "the license is some proprietary license and I don't want to give the details right now". If that's actually useful, I would use PROPRIETARY for that. But that would be in addition to what's already in the spec.

I think at least NONE and NOASSERTION should be baked into the SPDX license expression syntax itself, and it should be clearer that "NONE" means "no license available, not even a proprietary license".

[wking]

I think it's important to distinguish between "NONE" (no license available) and "NOASSERTION" (no license information is provided, there may be a license, but that information is expressly not being claimed).

NOASSERTION is a separate issue (#50). I'd like both of them to be part of license expressions, but think we can discuss them individually.

I should note that the "Unlicense" has SPDX license expression "Unlicense", not "Unlicensed". It's easy to miss the difference, so I recommend avoiding the term "UNLICENSED" to avoid confusion.

We already have NONE in the spec for this; I'd rather not get into renaming it. I'd just like to move it from “things we stack on top of license expressions” to “actually part of license expressions”. I'd work up a PR, but am still waiting on #37 to settle.

[pmundt]

Any progress on this? In experimenting with scanning on a mix of proprietary and open source code I noticed that the proprietary ones report NOASSERTION, which is certainly not accurate given the known state of the licensing. Whether NONE or a new 'PROPRIETARY' are added is perhaps a larger discussion, but in either case a clear separation from NOASSERTION is warranted.

I would also suggest that an effort should be made to avoid confusion with "Unlicense" vs. "Unlicensed" - this mistake was already made in this thread, and this mix up would involve a rather drastic difference in implication for someone who may get this wrong when annotating their code.

[pombredanne]

@pmundt no progress from what I can see here. What would be your ideal solution?