npm init for closed source modules

[kesla]

I've had the habit of setting license to closed for closed (work) modules.

In the latest version of npm that's not possible, and simply pressing enter will set the default license (ISC). Can I use npm init somehow for these closed source modules without needing to go in and remove the attribute afterwards?

[kenany]

$ npm config set init-license closed

https://docs.npmjs.com/misc/config#init-license

[kesla]

That will change license for all modules I create, right? I don't want that.

Also, npm is now warning if a license isn't spdx- compatible so I'll seeing a bunch of warnings...

—
Sent from my iPhone

On Sun, May 17, 2015 at 3:13 AM, Kenan Yildirim notifications@github.com
wrote:

$ npm config set init-license closed

https://docs.npmjs.com/misc/config#init-license

Reply to this email directly or view it on GitHub:
#8291 (comment)

[ralphtheninja]

@kesla You can use config on cli as well, e.g. npm init --init-license closed. Make that into an alias and you should be good to go :)

[timoxley]

I've never seen "closed" before but I have see a lot of "license": "private", afaik "private" is the defacto standard for this thing.

[kesla]

@timoxley I'd gladly change to private, is that an acceptable name by spdx standards? We should probably document that somewhere.

[kesla]

@ralphtheninja Thanks! Will work for now!

[kenany]

Unfortunately I don't see "private" nor "closed" here https://spdx.org/licenses/

[othiym23]

@kemitchell is the person with the most domain knowledge for best practices, but I believe the commonly accepted practice is to include LicenseRef-LICENSE, and then have the text of your license in LICENSE or LICENSE.md. Because proprietary licenses vary from project to project, it's not really possible to boil them down to a standard like SPDX does, and as a consumer, you're going to have to review the text of proprietary licenses anyway to use them responsibly and legally. Does this address your concern, @kesla?

[kemitchell]

I am summoned, and lo! I do appear.

@othiym23 and I recently added new guidance to npm's documentation, visible with npm help package.json. The new license metadata docs address non-standard licenses here.

What's this LicenseRef- garbage? It's the specification-compliant way to refer to a license that hasn't been assigned an SPDX identifier. The standard itself is actually much broader than the list of identifiers, comprising an RDF spec and other goodies. LicenseRef- is used in full-blown compliance to refer to a resource describing the non-standard license. Since npm isn't adopting SPDX wholesale, we defined a "magic" but standard-compliant value for these situations that means "check the license file in the package."

[kesla]

@othiym23 @kemitchell

Ok, thanks for explaining. Sounds promising and super helpful for proprietary and distributed modules - but what I don't understand is if this extra work is needed/necessary for scoped modules that will never be distributed outside of our private register.

[kesla]

Or can I set license: 'LicenseRef-LICENSE' and then just skip adding the LICENSE-file? That'll work for me.

[kemitchell]

@othiym23 has discussed doing a check to see if LICENSE or LICENSE.md or somesuch exists in the package tree. As far as I know that hasn't been implemented, and it still more of a proposal. That's as far as npm goes.

As for whether it's a good idea to have files lying around without any kind of license attached, that's really up to your judgment and your legal department or lawyer, if you have one. npm sets guidelines for package metadata and encourages certain best practices, but nobody guarantees that those practices have any good legal effect.

Sorry for the disclaimer. Lame to read and lame to write. But necessary. Please be careful!

[kesla]

@kemitchell thanks a lot for the reply, sounds reasonable. Will think a little more about it. Cheers!

[jandrieu]

This is a bit too much work for my default internal development process. I regularly build temporary one-off modules and private internal modules that will never get published to npm or any other registry. We may reuse them internally or I may just use them for structuring my code effectively.

It used to be straightforward to use npm init, then manually add "private":true to the package.json. The new SPDX license expression requirement makes npm init more of a hassle than a value.

The reality is, there is no license for the module in question and there never will be. Requiring me to specify a LICENSE by reference, then simplly putting a (c) statement in a LICENSE file is unnecessary make work.

This is echoed in #8542

[othiym23]

This is now handled by npm@2.12.0, which has support for UNLICENSED as a license value (or, if you have a specific proprietary license you like to use, SEE LICENSE IN <filename>). "Closed" and "proprietary" are classes of licenses, not specific instances, so adding support for them is doing the people who need to review licenses later on no favors.

[jcollum]

This is unclear after reading the whole thread. When I put in UNLICENSED:

license: (ISC) UNLICENSED
Sorry, license should be a valid SPDX license expression and license is similar to the valid expression "Unlicense".

So the actual valid value is Unlicense, which sounds like "The Uncola" to me, but it works.

What's wrong with None?

[kemitchell]

@jcollum it is tricky:

Unlicense is a valid SPDX license identifier for the Unlicense.

UNLICENSED is an npm-defined magic value.

[jcollum]

Oh wow so Unlicense is actually the most permissive:

In jurisdictions that recognize copyright laws, the author or authors of this software dedicate any and all copyright interest in the software to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.

UNLICENSED appears to not be allowed by NPM in the current version.

I'd like to know what I should put in for packages that are only intended for the use of other employees at my company. Private? None? That's how I arrived here, trying to figure out what was the right value for that field in package.json.

[kemitchell]

@jcollum the usefulness and effect of The Unlicense are controversial. Unlicense is a valid SPDX license expression, but neither I nor npm have anything to say about whether it's a good license to use.

[jcollum]

Sure, no problem. Still not sure what to put in that field though. For now I'll just put "none" and be done with it.

[vmadman]

Yeah... this is a classic case of waaay overthinking it.

All I want to do is get NPM to be quiet about the value of my license field every time I type npm <anything>. I certainly see the value in SPDX or whatever for open source projects, but it just seems like a silly distraction for those of us who just want to create a Node app and move on.

I've tried several variants of "shut up about it", like "none", "unlicensed", and "private" and NPM gripes at all of them. It also gripes if I exclude it or leave it blank.

The thread above hasn't really helped either.. but I'm going to try "LicenseRef-LICENSE" with a LICENSE.md file now to see if it will work.

[vmadman]

{
        "name"            : "a-project",
        "version"         : "0.1.0",
        "license"         : "LicenseRef-LICENSE",
        ....
}

... as expected:

npm WARN package.json a-project@0.1.0 license should be a valid SPDX license expression

NPM version 2.14.2

[vmadman]

Ok, finally, a verdict .. thanks to @othiym23 ..

{
        "name"            : "a-project",
        "version"         : "0.1.0",
        "license"         : "UNLICENSED",
        ....
}

.. that seems to work just fine. Hopefully I won't have to see that warning again :)

[benoitrolland]

So if you want to work in peace with npm,
you just need to put your code in public domain using "UNLICENCED"

But If you want to protect your code, you need to systematically setup a specific licence configuration even for your tests in case your code would leek on the net.

Is that right ?

[jcollum]

put your code in public domain using "UNLICENCED"

No, that's not what UNLICENSED does.

@sindresorhus explains it here: #8773 (comment)

[benoitrolland]

Thank you very much, that's much more clear and simple at the link you provide.

[vmadman]

@benoitrolland

But If you want to protect your code, you need to systematically setup a specific licence configuration even for your tests in case your code would leek on the net.

First, I'm not an attorney nor do I claim to be qualified to give legal advice. You should contact an attorney if you find yourself in a position in which licensing, copyrights, or intellectual property rights matter. With that said:

The thing to remember is that all code not explicitly released to the public domain is, by default, copyright and protected. You just have to realize that if your code is leaked, and it's useful to someone else, they can use it regardless of what license you write in any file.

You just have to consider what, exactly, you're trying to protect your code from. First, keep in mind that your code is probably not worth protecting in the first place. Any value that source code carries stems from the planning and ongoing support and maintenance of the software. Without you, the author of the source, source code loses its value rapidly.

So, if you're trying to protect your code from independent developers, just don't bother... at the end of the day, it's just not going to matter.

Something actually worth protecting against, though, is mid-to-large sized companies. They have a lot to lose and, usually, they are more concerned about the license for an OSS component than the author is. Very few of them would even use your code, for any purpose, without first finding an explicit license telling them that they can do so.

Of course, though, if they do not care about licenses... then it doesn't matter anyway, they'll use it and you can't stop them, except by, of course, not leaking your code in the first place.

At the end of the day OSS licenses provide assurance to people who want to honestly and fairly use your source. Licenses do not protect against people who have no regard for intellectual property rights. Just do your best to affix the appropriate license information to your source and don't worry too much about the rest.

[alirobe]

This is daft, but "SEE LICENCE IN COPYRIGHT LAW" will do for me, as copyright is the default/implicit license for any creative works anyway. (disclaimer: I am not a lawyer)

[vmadman]

@alirobe : I'm also not a lawyer, but I think you're correct, and my small novella, above, said something similar. So, to reiterate: All creative works are protected, immediately and by default, in U.S. copyright law. You have to explicitly "release" your rights to make you works open to the public.

However, NPM uses/requires/recommends specific values for the license property in package.json and I do not think that "SEE LICENSE IN COPYRIGHT LAW" is supported.. so, I think you'll want to use "UNLICENSED", instead. That should serve the same purpose and allow you to avoid the NPM warnings that will result from any unsupported values.

[ghost]

You can read up on DCMA or the Berne Convention if you like. I'm simply just going to remove the license field from my manifest. No value, no interpretation - less code.