No valid value for license appropriate for proprietary code #5697

ygale · 2018-11-18T17:13:15Z

The only non-SPDX value allowed in the license field is NONE. But since cabal files are also human-readable, the text license: NONE cannot be included in a cabal file for proprietary code for obvious legal reasons, no matter what the machine-readable meaning. Nor can any SPDX-compliant value be used. Without a license field at all, cabal refuses to build the package.

By comparison, npm is also SPDX-compliant. There are several reasonable options for proprietary code in npm:

{ "license": "UNLICENSED"} - not great, but much better than NONE.
{ "license": "Proprietary", "private": true } - this disables the ability to upload the package to the public distribution channel, which is fine for truly proprietary code.
{ "license": "SEE LICENSE IN <filename>"} - allows upload with a custom license, possibly proprietary. We might not want to allow that for Hackage.

See also #2141. Now "AllRightsReserved" has not two meanings, but zero meanings, which is much worse. Not that we should necessarily resurrect "AllRightsReserved", but there needs to be some reasonable alternative.

The text was updated successfully, but these errors were encountered:

23Skidoo · 2018-11-18T17:22:13Z

/cc @phadej

IMO it makes sense to copy what npm is doing.

23Skidoo · 2019-03-16T09:30:16Z

See also https://bugs.linuxfoundation.org/show_bug.cgi?id=1289.

phadej · 2019-03-16T11:07:55Z

IMO it doesn't make sense what npm is doing.

cannot be included in a cabal file for proprietary code for obvious legal reasons,

They aren't obvious to me.

From the sdpx issue tracker, @23Skidoo linked (emphasis mine)

We (folks on tech call: Mark, Gary, Bill, Kate, Scott...) think the best practice is to recommend use of the LicenseRef where the text of the referenced license can be whatever the producer of the doc really intends. (if they want to say "All Rights Reserved" they can....)

Regarding the example below: if someone had no license and only a copyright notice (which would be captured via 3.16), then NONE would be correct - there is no license information in the package. How would adding "ALL-RIGHTS-RESERVED" or "NO-LICENSE" add any value? This seems like it would only create overlap and potential confusion, but maybe I'm missing something? I suspect the other thing to consider here, which I think may be touched upon in the NPM issue is creating a bit more of an affirmative statement that there really is 'no license,' rather than 'I can't find any license at all.' But I think the spec already allows for this. For example, if you are using a tool to look for licenses and NOTHING turns up anywhere in the package, then you could return "NONE" for 3.14 Declared License. Then, a human might check that a bit, maybe you even contact the copyright holder and they confirm, 'yup, no license. it truly is ALL rights reserved.' I'd then expect to see NONE for 3.12 Concluded License and a comment 3.15 with some explanation of why or what you discovered.

"PROPRIETARY" is not advisable to add as an identifier - does someone want to define what that means?!? If there IS a license and it's not on the SPDX License List, then use License-Ref (section 5 of the spec). I don't think we want to dilute that. If someone wants to add a field to create a license type classification for their internal use (which I can see being helpful) then they can use the optional fields to do so.

I recommend to close this issue as wontfix: if there IS a (proprietary) license: use LicenseRef, if there aren't use NONE.

ygale · 2019-03-16T20:29:37Z

I opened this issue because when I tried to use cabal init to create a cabal file for proprietary code, I got the error
The license must be a valid SPDX expression.
no matter what I entered other than an open-source license or NONE.

I'll clarify that in the description. Sorry I wasn't clear.

ygale · 2019-03-16T20:42:33Z

What is the syntax in a cabal file to get LicenseRef? Cabal rejects LicenseRef as the value of license, with the error
CabalFileParseError "./proprietary.cabal" [PError (Position 11 32) "\nunexpected Unknown SPDX license identifier: 'LicenseRef' \n\nLicenseRef\n"] (Just (mkVersion [2,4])) []

EDIT: So leaving the issue description for now. Unless there is some way to get LicenseRef as the value of license, or some other value that is not an SPDX license and not NONE, then this issue is still valid and should be fixed.

23Skidoo · 2019-03-17T01:19:37Z

LicenseRef-Foo works for me as an identifier with cabal-version: 2.4.

@phadej That thread also mentions that NOASSERTION is a valid value in addition to NONE, shouldn't we support it too?

sboosali · 2019-03-17T06:35:09Z

phadej · 2019-03-17T07:25:56Z

“NONE” is not a license. It’s says there are no license. Same as omitting `license:` field (which is completely fine).

…

Sent from my iPhone

On 17 Mar 2019, at 8.35, Spiros Boosalis ***@***.***> wrote: iiuc, isn't NONE problematic as a license? even if they don't care about the licensing, the user should at least choose between a "all rights reserved" variant or a public domain variant. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

phadej · 2019-03-17T07:30:58Z

NONE is a fancy way to say Nothing. We don’t care to distinguish between “tried [to find a license] but gave up”, “did not try”, and “won't tell you”?. All flavours (i.e. `NONE`) mean the same: only copyright holder have rights

…

Sent from my iPhone

On 17 Mar 2019, at 3.19, Mikhail Glushenkov ***@***.***> wrote: LicenseRef-Foo works for me as an identifier with cabal-version: 2.4. @phadej That thread also mentions that NOASSERTION is a valid value in addition to NONE, shouldn't we support it too? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

sboosali · 2019-03-17T07:59:38Z

got it, thanks

…

On Sun, Mar 17, 2019, 00:31 Oleg Grenrus ***@***.***> wrote: NONE is a fancy way to say Nothing. We don’t care to distinguish between “tried [to find a license] but gave up”, “did not try”, and “won't tell you”?. All flavours (i.e. `NONE`) mean the same: only copyright holder have rights Sent from my iPhone > On 17 Mar 2019, at 3.19, Mikhail Glushenkov ***@***.***> wrote: > > LicenseRef-Foo works for me as an identifier with cabal-version: 2.4. > > @phadej That thread also mentions that NOASSERTION is a valid value in addition to NONE, shouldn't we support it too? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5697 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACNoMVx2itcmfPCDwA7NlePm0O4ju8Yaks5vXe80gaJpZM4YoCXh> .

ygale · 2019-03-24T10:00:11Z

@phadej Aha, you can just omit the license: field? That works. But it's not one of the choices in cabal init. Can we add that? Or perhaps print a message when you select NONE that you can just delete the license field in the cabal file if you want. Or perhaps allow the empty string as a "valid SPDX license" for "Other" (which is arguably so), and change the prompt to "Other (specify or omit):".

@sboosali Yes, NONE is problematic as a license. @phadej is talking about the machine-readable meaning of NONE. But in English, the simplest meaning of "License: NONE" is a problem. None of the various legal teams I have worked with would allow that wording to appear in this file. In a litigation context, the fact that you could eventually prove that "License: NONE" doesn't mean what it sounds like hardly reduces the legal cost.

@23Skidoo are we using different versions of cabal? In my build of cabal 2.4.1.0 in cabal init there is only a choice of LicenceRef-PublicDomain, which isn't usable for proprietary. I tried manually editing "license:" with various other syntax to put something besides PublicDomain, but I couldn't get it to work. See the error message above.

phadej · 2019-03-24T14:15:06Z

Again, NONE is not a license. It’s a placeholder value, as `license: ` is (or at least should be) invalid syntax. I think we could make `cabal init` be able to skip license information, or/and omit `license` field if its value is `NONE`.

…

Sent from my iPhone

On 24 Mar 2019, at 12.00, ygale ***@***.***> wrote: @phadej Aha, you can just omit the licesne: field? That works. But it's not one of the choices in cabal init. Can we add that? Or perhaps print a message when you select NONE that you can just delete the license field in the cabal file if you want. Or perhaps allow the empty string as a "valid SPDX license" for "Other" (which is arguably so), and change the prompt to "Other (specify or omit):". @sboosali Yes, NONE is problematic as a license. @phadej is talking about the machine-readable meaning of NONE. But in English, the simplest meaning of "License: NONE" is a problem. None of the various legal teams I have worked with would allow that wording that to appear in this file. In a litigation context, the fact that you could eventually prove that "License: NONE" doesn't mean what it sounds like hardly reduces the cost. @23Skidoo are we using different versions of cabal? In my build of cabal 2.4.1.0 in cabal init there is only a choice of LicenceRef-PublicDomain, which isn't usable for proprietary. I tried manually editing "license:" with various other syntax to put something besides PublicDomain, but I couldn't get it to work. See the error message above. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

sboosali · 2019-03-25T04:12:46Z

i think an omitted license field makes more sense.

…

On Sun, Mar 24, 2019, 07:15 Oleg Grenrus ***@***.***> wrote: Again, NONE is not a license. It’s a placeholder value, as `license: ` is (or at least should be) invalid syntax. I think we could make `cabal init` be able to skip license information, or/and omit `license` field if its value is `NONE`. Sent from my iPhone > On 24 Mar 2019, at 12.00, ygale ***@***.***> wrote: > > @phadej Aha, you can just omit the licesne: field? That works. But it's not one of the choices in cabal init. Can we add that? Or perhaps print a message when you select NONE that you can just delete the license field in the cabal file if you want. Or perhaps allow the empty string as a "valid SPDX license" for "Other" (which is arguably so), and change the prompt to "Other (specify or omit):". > > @sboosali Yes, NONE is problematic as a license. @phadej is talking about the machine-readable meaning of NONE. But in English, the simplest meaning of "License: NONE" is a problem. None of the various legal teams I have worked with would allow that wording that to appear in this file. In a litigation context, the fact that you could eventually prove that "License: NONE" doesn't mean what it sounds like hardly reduces the cost. > > @23Skidoo are we using different versions of cabal? In my build of cabal 2.4.1.0 in cabal init there is only a choice of LicenceRef-PublicDomain, which isn't usable for proprietary. I tried manually editing "license:" with various other syntax to put something besides PublicDomain, but I couldn't get it to work. See the error message above. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5697 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACNoMTk5EnqhwGvcEAwXDbc0TXQ2v5JQks5vZ4hrgaJpZM4YoCXh> .

Anton-Latukha · 2022-02-11T13:31:09Z

(formed #7971 & reducted the message)

The simples solution: live as is & just allow people to discover that they can delete the license field.

With #7971 here - I think both reports cover *this (#5697) report fully, since #7971 uncovers direct technical usability to discover how to set licenses.

Mikolaj · 2022-02-11T13:40:19Z

@Anton-Latukha: thank you for your comment. Could you summarise you proposal in terms of code changes in cabal? Would that only be cabal init change?

Anton-Latukha · 2022-02-11T13:44:42Z

It is a case that deletion of the license field is allowed - so that is already implemented. (I just discovered that). So that is solved, which is a big step to close this report.

fgaz · 2022-02-11T17:35:41Z

Before closing, I guess we could clarify that omitting the field is allowed https://cabal.readthedocs.io/en/3.6/cabal-package.html#pkg-field-license

Mikolaj · 2022-02-11T18:07:39Z

What about cabal init? Is this sorted out on branch master?

I opened this issue because when I tried to use cabal init to create a cabal file for proprietary code, I got the error The license must be a valid SPDX expression. no matter what I entered other than an open-source license or NONE.

I'll clarify that in the description. Sorry I wasn't clear.

@ptkato, may one refuse to specify the license? I've just tried and I don't think so, but I'm a very unskilled cabal init user:

Please choose a license:
   1) BSD-2-Clause
   2) BSD-3-Clause
   3) Apache-2.0
   4) MIT
   5) MPL-2.0
   6) ISC
   7) GPL-2.0-only
   8) GPL-3.0-only
   9) LGPL-2.1-only
  10) LGPL-3.0-only
  11) AGPL-3.0-only
  12) GPL-2.0-or-later
  13) GPL-3.0-or-later
  14) LGPL-2.1-or-later
  15) LGPL-3.0-or-later
  16) AGPL-3.0-or-later
  17) Other (specify)
Your choice? 17
Please specify? [optional] 
The license must be a valid SPDX expression.

ptkato · 2022-02-11T18:22:28Z

Yes, it is a bit counter-intuitive, but you need to select 17, then type in NONE. Maybe we could add SPDX.NONE to the list, or something else; any suggestions?

Mikolaj · 2022-02-11T18:27:19Z

And then there would be no license: file? Sounds good. Adding it to the list or mentioning as one of the options after 17) is chosen would indeed help. Or perhaps Enter should produce NONE? It says "optional", so I expected empty string and Enter to be permitted.

Anton-Latukha · 2022-02-11T18:35:02Z

fgaz · 2022-02-11T18:53:33Z

I'm for the second suggestion:

Or perhaps Enter should produce NONE? It says "optional", so I expected empty string and Enter to be permitted.

ie. changing the prompt to Please specify? [NONE], so that the default on "Other" is not an invalid string

...and also so that foss licenses have a more prominent placement :D

Anton-Latukha · 2022-02-14T21:15:45Z

Having one action do two things at the same time - is puzzling as hell.

Even literally, Please specify? [NONE] puzzles by its message.

The FOSS licenses have 16 prominent placements in the list & the default case in the world does not.

It is not a fanboy reasoning, it is a philosopher consideration to not be monadic in thought (relating to many obvious critiques of it, most well-known critiques on it are done in works of Gilles Deleuze & Nietzsche, for example, it is covered in https://www.philosophizethis.org/podcast/episode-158-the-creation-of-meaning-nietzsche-the-ascetic-ideal-f8k5h ~ on minute 17).

I do not understand why to not just introduce case before the last Other case, or as 18-th case the default legal case in the legal systems in the world. The All Rights Reserved case would not involve into distribution in any case - it can be used only privately, it is not really involved with open software licenses, precisely because it is the most closed & unpractical one - it is essentially almost impossible to distribute it, I'd wished all proprietary produces had this license :)

fgaz · 2022-02-14T21:37:52Z

edit: oops, that wasn't your point. yeah, NONE could also go at the end of the main list if someone wants to make the change

Mikolaj · 2022-02-14T21:44:13Z

andreasabel · 2022-12-07T19:06:09Z

I think something like NONE (keeping all right reserved) may be clear enough.

phadej · 2022-12-08T10:29:11Z

Argue with SPDX people: spdx/spdx-spec#49

Don't invent your own, incompatible extensions.

EDIT: If it's about how to show NONE in the menu selector like:

Please choose a license:
   1) BSD-2-Clause
   2) BSD-3-Clause
   3) Apache-2.0
   4) MIT
   5) MPL-2.0
   6) ISC
   7) GPL-2.0-only
   8) GPL-3.0-only
   9) LGPL-2.1-only
  10) LGPL-3.0-only
  11) AGPL-3.0-only
  12) GPL-2.0-or-later
  13) GPL-3.0-or-later
  14) LGPL-2.1-or-later
  15) LGPL-3.0-or-later
  16) AGPL-3.0-or-later
  17) NONE (no license, all rights reserved)
  18) Other (specify)
Your choice?

then it's fine!

phadej · 2022-12-08T10:35:27Z

If this issue is about cabal init menu, please edit the issue title, as it's misleading. There is value for "no license": NONE it's just not in the menu.

And the original description issue is incorrect, that what I referred to by spdx/spdx-spec#49 link. UNLICENSED used by npm is non-standard extension, and spdx people seems to agree that NONE is better (even still not yet standard license expression).

andreasabel · 2022-12-08T16:54:17Z

NONE (no license, all rights reserved)

Yes, this is even clearer.

It would be good if the docs could be more explicit, though: https://cabal.readthedocs.io/en/3.8/cabal-package.html#pkg-field-license

license: SPDX expression
Default value
NONE

fgaz added the re: license Concerning license identifiers, files etc. label Feb 11, 2022

fgaz added the documentation label Feb 11, 2022

Anton-Latukha mentioned this issue Feb 11, 2022

Troubles with setting the license field #7971

Open

6 tasks

ffaf1 mentioned this issue Aug 4, 2023

have some way to express AllRightsReserved in the license field #9161

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

No valid value for license appropriate for proprietary code #5697

No valid value for license appropriate for proprietary code #5697

ygale commented Nov 18, 2018 •

edited

Loading

23Skidoo commented Nov 18, 2018

23Skidoo commented Mar 16, 2019

phadej commented Mar 16, 2019

ygale commented Mar 16, 2019

ygale commented Mar 16, 2019 •

edited

Loading

23Skidoo commented Mar 17, 2019

sboosali commented Mar 17, 2019

phadej commented Mar 17, 2019 via email

phadej commented Mar 17, 2019 via email

sboosali commented Mar 17, 2019 via email

ygale commented Mar 24, 2019 •

edited

Loading

phadej commented Mar 24, 2019 via email

sboosali commented Mar 25, 2019 via email

Anton-Latukha commented Feb 11, 2022 •

edited

Loading

Mikolaj commented Feb 11, 2022

Anton-Latukha commented Feb 11, 2022 •

edited

Loading

fgaz commented Feb 11, 2022 •

edited

Loading

Mikolaj commented Feb 11, 2022

ptkato commented Feb 11, 2022

Mikolaj commented Feb 11, 2022 •

edited

Loading

Anton-Latukha commented Feb 11, 2022 •

edited

Loading

fgaz commented Feb 11, 2022

Anton-Latukha commented Feb 14, 2022 •

edited

Loading

fgaz commented Feb 14, 2022 •

edited

Loading

Mikolaj commented Feb 14, 2022

andreasabel commented Dec 7, 2022

phadej commented Dec 8, 2022 •

edited

Loading

phadej commented Dec 8, 2022 •

edited

Loading

andreasabel commented Dec 8, 2022

No valid value for license appropriate for proprietary code #5697

No valid value for license appropriate for proprietary code #5697

Comments

ygale commented Nov 18, 2018 • edited Loading

23Skidoo commented Nov 18, 2018

23Skidoo commented Mar 16, 2019

phadej commented Mar 16, 2019

ygale commented Mar 16, 2019

ygale commented Mar 16, 2019 • edited Loading

23Skidoo commented Mar 17, 2019

sboosali commented Mar 17, 2019

phadej commented Mar 17, 2019 via email

phadej commented Mar 17, 2019 via email

sboosali commented Mar 17, 2019 via email

ygale commented Mar 24, 2019 • edited Loading

phadej commented Mar 24, 2019 via email

sboosali commented Mar 25, 2019 via email

Anton-Latukha commented Feb 11, 2022 • edited Loading

Mikolaj commented Feb 11, 2022

Anton-Latukha commented Feb 11, 2022 • edited Loading

fgaz commented Feb 11, 2022 • edited Loading

Mikolaj commented Feb 11, 2022

ptkato commented Feb 11, 2022

Mikolaj commented Feb 11, 2022 • edited Loading

Anton-Latukha commented Feb 11, 2022 • edited Loading

fgaz commented Feb 11, 2022

Anton-Latukha commented Feb 14, 2022 • edited Loading

fgaz commented Feb 14, 2022 • edited Loading

Mikolaj commented Feb 14, 2022

andreasabel commented Dec 7, 2022

phadej commented Dec 8, 2022 • edited Loading

phadej commented Dec 8, 2022 • edited Loading

andreasabel commented Dec 8, 2022

ygale commented Nov 18, 2018 •

edited

Loading

ygale commented Mar 16, 2019 •

edited

Loading

ygale commented Mar 24, 2019 •

edited

Loading

Anton-Latukha commented Feb 11, 2022 •

edited

Loading

Anton-Latukha commented Feb 11, 2022 •

edited

Loading

fgaz commented Feb 11, 2022 •

edited

Loading

Mikolaj commented Feb 11, 2022 •

edited

Loading

Anton-Latukha commented Feb 11, 2022 •

edited

Loading

Anton-Latukha commented Feb 14, 2022 •

edited

Loading

fgaz commented Feb 14, 2022 •

edited

Loading

phadej commented Dec 8, 2022 •

edited

Loading

phadej commented Dec 8, 2022 •

edited

Loading