spdx-spec
spdx-spec copied to clipboard
spdx
Add “NONE” to the license expression syntax
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.
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
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.
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.
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"?
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".
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.
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.
@pmundt no progress from what I can see here. What would be your ideal solution?
@pombredanne An ideal solution for me would be to simply distinguish between NOASSERTION and PROPRIETARY, where PROPRIETARY would simply be any asserted license for which there is no match in the license list. The main distinction to make between this and the NONE case is simply that there is a license assertion being made, it is only one that can not be immediately identified, which is rather different from having not provided any information in the first place.
I could also see this being useful for weeding out cases where the scanning fails or for tooling mismatches (e.g. a newer version of a license is released, but has not yet been implemented or trickled down to all of the SPDX tools used by the different parties).
A further consideration (although perhaps somewhat out of scope for this discussion) would be to allow an override provision when the integration of the proprietary component with the open source components is permissible, but which fall short of explicit dual-licensing (e.g. as governed by an external licensing agreement, or as a result of limitations of use, either of which may not be reflected in the scanned files). Examples of this could include things like patent non-assertion clauses only applying for non-commercial use. It is not currently clear to me how this is dealt with by the SPDX spec, if at all.
Its being used today in tools (NONE), so may as well make this explicit in the spec.
This is tieing in with the NOASSERTION #50 , assigning both of these to Steve to sort, and moving to 3.0
Looking back at the comments in this (quite old) issue:
The spec defines the meanings of NONE and NOASSERTION in the context of Declared License and Concluded License fields. Given that, I don't see a benefit for incorporating them into the SPDX License Expression syntax.
@swinslow - many uses of SPDX use only SPDX license expressions, not the entire SPDX file. E.g., many package managers have a single field called "license", and a source file may have "SPDX-License-Id:" with a SPDX license expression. In those cases there is no "declared license" or "concluded license" field.
@swinslow: not declaring/asserting a license is something different from asserting that it's unlicensable (in terms of one of the license values).
I think the issue would be elegantly solved if there existed a widely accepted standard proprietary license, with maximum possible rights reserved, added to spdx list alongside other FOSS licenses.
Benefits:
- no need to change syntax or create new keywords
- explicit disambiguation with no-accertion, concluded, declared, etc. keywords
- more symmetrical approach, accomodating and blending both FOSS and proprietary worlds
I.e. I propose to try starting the culture of using set of widely-known proprietary licenses understood by everyone, instead of unique proprietary licenses per each product/company (in which case it always was the problem of the company to distribute their named license).
So, I conclude creating some standard max-protection (by country law) proprietary license, which simply affirms authors rights, and adding it to SPDX catalogue is the way to go in future. If it's too hard for available lawyers to create new text of license -- even the text of Geneva Convention agreement may do :)
I’m sorry, a standard proprietary license is a pie in the sky. Especially in an international context.
@amerlyq - I think there is 0% chance of a standard proprietary license. But if you want that issue to be discussed, please create a new issue and make your case. This issue is about adding "NONE" to the license expression syntax. Creating a standard proprietary license is out-of-scope for this issue.
From a tooling perspective, a license expression for a declared license is commonly constructed through machine analysis of discovered licenses and inserting the appropriate AND and OR's. If during that analysis a license is identified as NONE or NOASSERTION, it would be useful to include that information in the resultant license expression.
If we did not support NONE and NOASSERTION in the license expression, what would be the proposed result in the above scenario? If you declare the entire package or file as NONE or NOASSERTION you loose a lot of valuable information on the discovered licenses. If you don't include the NONE or NOASSERTION than you may miss an important flag that some manual review of the analysis is required.
I think I've been persuaded that I am wrong :)
In particular @goneall's comment makes sense to me, about being able to express the fact that e.g. one part of a package is under a known license, while another part is not licensed. To be able to express this, there would be benefit in some circumstances to being able to say for instance Apache-2.0 AND NONE. And that this isn't possible unless NONE is part of the expression syntax so that it can be used in expressions.
Okay, I'm on board, makes sense. Thanks all for persuading me on this!
I'd love to use NONE in some situations. It looks like a consensus has been reached and the next step is implementation, is that correct?
Would definitely be great to have this. We have a couple of internal projects that we would like to annotate correctly. Right now we are falling back to doing LicenseRef-None or LicenseRef-companyNameProprietary. As these are internal projects right now "None" as a license type would make a lot of sense.
@mjbshaw re:
It looks like a consensus has been reached and the next step is implementation, is that correct?
Honestly, I do not see any consensus emerge yet from the discussion above.
@Blackclaws re:
Would definitely be great to have this. We have a couple of internal projects that we would like to annotate correctly. Right now we are falling back to doing LicenseRef-None or LicenseRef-companyNameProprietary. As these are internal projects right now "None" as a license type would make a lot of sense.
NONE as specified means that there is no license not that there is a proprietary license: 3.15 Declared License [...] NONE, if the package contains no license information whatsoever; or [...]
So IMHO NONE should never be used to report a proprietary license. Furthermore, I cannot see how NONE could ever be used as a placeholder for a license id in an expression: Apache-2.0 OR NONE would mean "Apache or no license information whatsoever" which is self-contradictory and would be better avoided entirely.
Something like LicenseRef-companyNameProprietary is what makes most sense for now until SPDX accepts tracking proprietary licenses, which I guess won't happen ever from observing for a good while.
FWIW, we track thousand++ extra license ids in the scancode license "namespace" at https://scancode-licensedb.aboutcode.org/ for use in ScanCode and elsewhere and is stable source of license ids beyond the SPDX license list and the largest open and curated licenses collection I know of.
We also have generic proprietary, commercial, and public domain licenses:
- https://scancode-licensedb.aboutcode.org/proprietary-license.html
- https://scancode-licensedb.aboutcode.org/commercial-license.html
- https://scancode-licensedb.aboutcode.org/public-domain.html
When used these need to be supplemented by actual terms. It's is easy to add a new proprietary license. Just submit a PR at https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/licenses and this will be merged quickly.
@pombredanne
So IMHO NONE should never be used to report a proprietary license. Furthermore, I cannot see how NONE could ever be used as a placeholder for a license id in an expression: Apache-2.0 OR NONE would mean "Apache or no license information whatsoever" which is self-contradictory and would be better avoided entirely.
I might have worded it a bit imprecise. We have code that currently is not licensed to the outside but for which we want to keep mostly accurate SPDX headers. For code that is adapted from open source sources that are for example MIT licensed our SPDX header looks a bit like this:
// SPDX-License-Identifier: LicenseRef-None AND MIT
or
// SPDX-License-Identifier: LicenseRef-companyNameProprietary AND MIT
We don't use OR here as its not dual licensed, its open source based so we need to track the license for compliance reasons and we have modified it, but the modifications are not under any license to an outside party.
If we license the code under a specific license to others we would change the SPDX header to reflect that specific license, but for internal code there isn't really any such license that applies aside from "None"
Though I guess "None" could also be misunderstood to mean: "There is no license to use this" which is of course the wrong implication.
FWIW, we track thousand++ extra license ids in the scancode license "namespace" at https://scancode-licensedb.aboutcode.org/ for use in ScanCode and elsewhere and is stable source of license ids beyond the SPDX license list and the largest open and curated licenses collection I know of.
That's actually quite a nice list, didn't know about that yet.
Furthermore, I cannot see how NONE could ever be used as a placeholder for a license id in an expression: Apache-2.0 OR NONE would mean "Apache or no license information whatsoever" which is self-contradictory and would be better avoided entirely.
It would be very valid to have an Apache-2.0 AND NONE, however per my previous comment above.
@pombredanne do you agree?
It would be very valid to have an
Apache-2.0 AND NONE, however per my previous comment above.
+1 -- this is what convinced me to change my mind from where I was previously against this.
A file can contain some content which is Apache-2.0 licensed, and other content for which there is no license. To describe the overall license expression for this file, I think Apache-2.0 AND NONE is the best way to describe this.
As @pombredanne noted, adding NONE to the license expression syntax could result in enabling people to create nonsensical license expressions, such as Apache-2.0 OR NONE (which I agree doesn't make sense). But that's already the case: people can currently create nonsensical expressions such as MIT+ or GPL-2.0-only+. I think that the use case @goneall described is useful enough in that context to warrant adding NONE to the expression syntax as an option.
Agreed with @pombredanne's earlier comment that NONE is not appropriate to use to represent a proprietary license. LicenseRef-'s are the right mechanism for licenses not on the SPDX License List.
I suggest creating a JurisdictionRef-* namespace where * is a valid ISO 3166 code. Rationale:
- Every (every?) jurisdiction grants creators maximum rights if no explicit statement has been made. It therefore corresponds to “All rights reserved.”
- Users of a work can consult the law of the jurisdiction. For example some jurisdictions automatically grant exceptions for fair use. You could look up what constitutes fair use in the indicated jurisdiction.
Problems:
- The legislative power about copyright law is not necessarily with a country. Technically it could be possible that (in the future) the European Union gains legislative authority about copyright law for its member states.
- A jurisdiction is not a license (a contract so to speak). The venue for copyright disputes is really a different issue.
Agreed with @pombredanne's earlier comment that NONE is not appropriate to use to represent a proprietary license. LicenseRef-'s are the right mechanism for licenses not on the SPDX License List.
@swinslow What if it's just not licensed?
Say the employees of a company don't have license to use some software except in connection with their specific job duties under the copyright-holding employer— would we be required to rez up a document saying as much? What advantage would that have over just using NONE to mean "this code may be copyrighted, and the packagers aren't hereby granting the reader any rights"?
It looks like NONE is not in the SPDX 3.0 license expression syntax. Since this is a non-breaking change, moving this to 3.1