what SPDX license should I use for private modules?

NPM now forbids the user to put non-spdx licenses in the license field during npm init, and complain thereafter if you have something weird in there. However, NPM is used also for private modules. What SPDX code should we put in? I do not want to reference ISC or MIT in closed-source modules.

Another solution is to ask "is this module private?" and do not prompt at all for a license, with the assumption that a private module does not require a license.

It's in the docs:

Finally, if you do not wish to grant others the right to use a private or unpublished package under any terms:

{ "license": "UNLICENSED"}

I'm going to close this as answered.

I got confused by UNLICENSED and Unlicense. Which means two completely
different things.

The user experience is kind of bad there, specially for newcomers, because
the information is not immediate to find (what is SPDX? google SPDX), as
UNLICENSED is not listed in https://spdx.org/licenses/, which is a place as
good as the NPM docs.
How about offering autocompletion or just a suggestion to use UNLICENSED
after a couple of tries.

BTW, the 'Is it private?' question still makes sense

Il giorno mer 1 lug 2015 alle 04:32 Rebecca Turner notifications@github.com
ha scritto:

Closed #8773 #8773.

—
Reply to this email directly or view it on GitHub
#8773 (comment).

Sorry for bothering again, but I tried putting UNLICENSED in npm init and it didn't work:

$ npm -v
2.11.3
$ npm init
This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help json` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg> --save` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
name: (mymodule)
version: (1.0.0)
description:
entry point: (index.js)
test command:
git repository:
keywords:
author:
license: (ISC) UNLICENSED
Sorry, license should be a valid SPDX license expression and license is similar to the valid expression "Unlicense".

Yeah, having the same problem.

@mcollina

@mcollina @cappslock you might try to put "private": true in your package.json, it solved my problem.

@tianp

@tianp - the private field should be set to true only if you don't want the package to be publishable. The question here was what license should be used when you dont want to grant others license to use the code.

@tianp

This shouldn't be closed.

Btw, @tianp... the problem is you can't get past the prompt in npm init without setting a license. Adding private:true to the package.json is fine, but doesn't fix the brokenness that is npm init right now.

if you use "private": true the license isn't checked. So you can put in your own copyright notice at license if you will.

This is a problem for me also. It makes npm init useless if one cannot state that the package one is building does not, and should not, have a license.

@robertkowalski

@robertkowalski @tianp what if I do want to publish the module, i.e. to a private NPM repository?

I agree with @jandrieu this should not be closed, @iarna?

Private module, in a Private npm repository, under Private license.
Sound's like important feature to have.

In newer versions of npm, UNLICENSED is supported and is the correct license to include for private packages. Your code always has some kind of license (depending on where you are), and having it be implicit rather than explicit is a potential source of problems for everyone who encounters your code outside your organization. Given the frequency with which today's private hack becomes tomorrow's published open source component, making sure this is taken care of makes it worth the inconvenience, IMO. "private": true has a distinct use and isn't going to be overloaded to override the need for a license declaration.

That is great, what version(s) of npm support this?

npm@3.3.1 and higher for npm@3, and npm@2.14.2 and higher for npm@2.

@othiym23

@othiym23, @iarna, @faceleg, @cappslock Getting to something that satisfies licensed proprietary software as easy as open source is just as important. Obviously the SPDX list does not capture everything in its entirety. I think the overriding concern for modules is that a license is supplied.

The concern expressed in this issue is not being properly heard or understood. UNLICENSED does not work. A proprietary license does not equate to UNLICENSED software – its just a set of terms that are not the same as an open license.

ie. Does the Apple Software Licence make it unlicensed? – not. Further, it is legally ambiguous to provide a download and use proprietary software that is identified as UNLICENSED when it is clearly meant for use under the terms of an identified that is supplied with the software.

I hope NPM is listening feedback you are receiving and will determine an appropriate fix this. I would urge folks to leave their licenses as they are, warnings aside, until this is fixed.

Agreed that private does not have anything to do with licensing. It only identifies whether the package is permitted to be published to a registry. That does not necessarily mean to the npm repository exclusively either.

@scriptjs

@scriptjs Doesn't SEE LICENSE IN <filename> exactly meet the need you describe? (Documented in the package.json documentation]).)

I understand that if I create something then I hold all rights. I understand the logic that UNLICENSED means no license is being provided. Since the default is that I hold all rights, then not providing a license implies that I am still holding all rights. Regardless, I still don't like the word. I'm not a lawyer, but it feels like it could be debated in court, at the very least, to cause confusion. I'd rather have ARR for a generic "All Rights Reserved" since that's been around since dirt and is extremely clear. I'd rather leave the file for "ARR with these exceptions to the rule."

The fact that the latest versions of npm support UNLICENSED is fine for me and I now consider this issue closed. After one uses npm init and marks their work as UNLICENSED, they can put copyright notices in all their files saying whatever they want, including "All Rights Reserved.", as well as change the package.json to say something other than UNLICENSED.

moved my response to #8918

This issue is becoming a magnet for off-topic discussion, and most of the discussion after the issue's resolution doesn't have anything to do with the original question, so I'm locking this issue. Further discussion about the ergonomics of UNLICENSED should either go in #8918 or new issues (especially if you're running npm@^2.14.8 or npm@^3.3.9 and are running into issues where UNLICENSED isn't working).

That issue also includes explanations of which versions of npm contain support for UNLICENSED and SEE LICENSE IN, as well as a more general discussion of the rationale of the npm CLI team as to why those features are implemented the way they are.

Navigation Menu

Repository navigation

what SPDX license should I use for private modules? #8773

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

what SPDX license should I use for private modules? #8773

Description

Activity

sindresorhus commented on Jun 30, 2015

iarna commented on Jul 1, 2015

mcollina commented on Jul 1, 2015

mcollina commented on Jul 2, 2015

cappslock commented on Jul 23, 2015

tianp commented on Aug 7, 2015

cchamberlain commented on Aug 7, 2015

jandrieu commented on Aug 30, 2015

robkorv commented on Sep 6, 2015

alash3 commented on Oct 13, 2015

faceleg commented on Oct 14, 2015

drom commented on Oct 19, 2015

othiym23 commented on Oct 19, 2015

alash3 commented on Oct 19, 2015

othiym23 commented on Oct 19, 2015

scriptjs commented on Oct 26, 2015

iarna commented on Oct 26, 2015

ergose commented on Oct 26, 2015

alash3 commented on Oct 26, 2015

scriptjs commented on Oct 26, 2015

othiym23 commented on Oct 27, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions