183

I've got a package.json that's expecting a SPDX-approved license acronym, but I can't find one that means 'proprietary commercial license, all rights reserved'.

Is there one for non-FOSS, where I want to specify that I want to allow no reuse?

Bryce
  • 2,029
  • 2
    There are some problems with your question, as it is currently written. 1. All copyrights are always reserved. 2. "Proprietary commercial" is a characteristic of many licenses. 3. There might not actually be an acronym for what you are requesting. – Robert Harvey Jun 05 '15 at 05:11
  • 3
    @RobertHarvey 1. Many software systems (eg, npm) require a license to be set explicitly. 2 and 3. Yes, the answer handles that 3. – mikemaccana Jul 12 '15 at 20:44
  • 2
    Since this is closed I can't give another answer. But according to [1] you should set license: "UNLICENSED",.

    [1] https://github.com/npm/npm/issues/8918

     – Jason Axelson Oct 02 '15 at 20:04
  • 1
    might not actually [have] an acronym for what you are requesting is still a perfectly valid answer to a perfectly valid question. – Qix - MONICA WAS MISTREATED Sep 15 '16 at 04:51
  • 1
    The equivalent for composer.json is "license": "proprietary" according to the docs. – Quinn Comendant Oct 16 '19 at 19:58

3 Answers3

169

As of npm 3.10 you have to use UNLICENSED:

{ "license": "UNLICENSED"}

or

{ "license": "SEE LICENSE IN <filename>"}

The value of license must either one of the options above or the identifier for the license from this list of SPDX licenses. Any other value is not valid.

The following is no longer valid for current versions of npm

For npm versions before 3.10 you may use:

{ "license" : "LicenseRef-LICENSE" }

Then include a LICENSE file at the top level of the package. It could be as short as:

(c) Copyright 2015 person or company, all rights reserved.

But you might want to be more explicit about what is not allowed.

lennon310
  • 3,212
Craig
  • 4,532
  • 22
    "all rights reserved", in that context, means EXACTLY what it says. NO permissions have been given. It is a legal term of art. Think of it as a magickal incantation that must be uttered in precisely that form to invoke the Law Demons. – John R. Strohm Jun 05 '15 at 20:45
  • 1
    Seems the npm docs have been updated. Now suggests using: { "license" : "SEE LICENSE IN <filename>" } – emertechie Jul 28 '15 at 04:31
  • Edit: Ignore last comment. "SEE LICENSE IN " doesn't work when doing npm init. LicenseRef-LICENSE works – emertechie Jul 28 '15 at 04:37
  • 5
    npm recommends to set { "license": "UNLICENSED"} "if you do not wish to grant others the right to use a private or unpublished package under any terms". That's an even easier option than an explicit license file. – Jörn Zaefferer Sep 28 '15 at 09:49
  • 3
    setting the license to UNLICENSED still triggers license should be a valid SPDX license expression for me – cdmckay Oct 09 '15 at 13:33
  • @cdmckay it didn't work for me too. But then I understood that my Node.js version was extremely outdated. Updating to v4.2.1 and npm to 2.14.7 solved the problem. – ivkremer Oct 21 '15 at 00:16
  • "license": "UNLICENSED" worked for me with [email protected] – botchniaque Apr 07 '16 at 08:59
  • 2
    The latest update for using custom license files is as follows: { "license" : "SEE LICENSE IN <filename>" } – Kent Bull Sep 16 '16 at 17:17
  • 22
    You can also just set "private": true and it won't bother you about including a license. – spex May 25 '17 at 20:31
  • 16
    Also make sure not to confuse the npm-recommended "UNLICENSED" with the SPDX compliant identifier "Unlicense", which is the exact opposite of "all rights reserved". – Levente Huszko Oct 17 '17 at 11:04
  • There was a typo where there was a space before " SEE..." and so on making this not work. – vidstige Mar 12 '18 at 03:02
  • 1
    answer needs updating. Would vote down if I could. – Kevin Buchs Jan 15 '19 at 23:33
  • 2
    @KevinBuchs Please elaborate and I will update the answer. – Craig Jan 16 '19 at 17:36
  • The irony is that SEE LICENSE IN LICENSE is notably less clear and less searchable than LicenceRef-LICENSE. I'm sure there were good reasons to not allow LicenseRef-, but this alone is enough to make me doubt that those reasons were good enough. – mtraceur May 21 '20 at 08:37
  • 3
    I would not use UNLICENSED - it can easily be confused with The Unlicense which does exactly the opposite of what you want. – TmTron Oct 24 '20 at 07:23
17

This does not exactly answer your question, but what about:

{
  "license": "Proprietary",
  "private": true,
}
MrIsaacs
  • 5
WooYek
  • 281
  • 2
  • 4
  • 3
    This answer reads more like a comment. – Mael Mar 13 '18 at 07:40
  • 3
    This answer also does what is needed: stops npm complaining about licenses, so it is a good one in my book. – Malcolm Holmes Apr 26 '18 at 09:20
  • 5
    Using "Proprietary" as the license type is not a supported SPDX type and will generate an error unless you also specify "private": true. That in turn prevents you from using NPM as a distribution channel for your proprietary package. So choose the answer above by @craig – abd3721 Nov 01 '18 at 21:18
  • 1
    To me, the following DOES answer the question and gives a full example of how to do it. I suggest, @WooYek, updating your answer.

    { "name": "my-descriptive-name", "description": "yeah, what it says", "repository": "npm/npm", "license": "Copyright Your Company 2019, all rights reserved.", "private": true, "dependencies": { "request": "^2.88.0", "request-promise-native": "^1.0.5" } }

     – Kevin Buchs Jan 15 '19 at 23:36
  • 1
    For brevity I did not want to put the usual copyright stuff. Just the bare minimum required for a packaged to be treated as proprietary software. – WooYek Jan 17 '19 at 07:38
3

Not so sure about specifically npm, but SPDX standard version 1.2 (2013) and later has provision for specifying arbitrary custom licensing terms, in their machine-readable license expressions format. Section Other Licensing Information Detected:

5.1.4 Data Format: "LicenseRef-"[idString]
where
  [idString] is a unique string containing letters, numbers, “.”, “-” or “+”.

This is also present in the latest (today) spec version 2.3 (2022).

So basically, we should be able to say:

  • {"license": "LicenseRef-Proprietary"},
  • {"license": "LicenseRef-Custom-Commercial-Agreement"},
  • {"license": "LicenseRef-PrivateUndisclosed"},

and so on, along those lines.

Relatedly, there's also the special keyword NOASSERTION — but it isn't considered a "valid SPDX License Expression", and I'm not positive if it's intended for package developers. See PackageLicenseDeclared: that keyword is apparently for license-scanning software to express "I failed to determine the SPDX ID of the package's license, or didn't even try".

ulidtko
  • 760