-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add “NONE” to the license expression syntax #49
Comments
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.
[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
|
This needs more discussion in technical meeting. |
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. |
If we add it to licence expressions, we can remove it from all the other places.
What would you suggest an author put in |
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 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". |
We already have |
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:
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. |
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 If we did not support |
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 Okay, I'm on board, makes sense. Thanks all for persuading me on this! |
I'd love to use |
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:
Honestly, I do not see any consensus emerge yet from the discussion above. @Blackclaws re:
So IMHO Something like 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:
When used these need to be supplemented by actual terms. |
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:
or
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.
That's actually quite a nice list, didn't know about that yet. |
It would be very valid to have an @pombredanne do you agree? |
+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 As @pombredanne noted, adding Agreed with @pombredanne's earlier comment that |
I suggest creating a
Problems:
|
@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 |
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 |
Spun out from today's legal meeting, I think we should add
UNLICENSED
NONE
to license expressions, because external tools like npm'spackage.json
are currently definingUNLICENSED
as an extra for the “all rights reserved” case. I'm happy to work up a pull request if/when #37 lands.The text was updated successfully, but these errors were encountered: