Making the default licence "ISC" is extremely dangerous

[skeddles]

When running npm init, it defaults to ISC for a license (even though most other fields are left blank).

If someone isn't paying attention to it, or doesn't know what it means, then they could apply this license unintentionally. Then if they publish the repo, it's published with that license, which could be very bad if they didn't intend to license it publicly.

For the safety of your users, there should be no default license.

[dosaki]

I'm surprised how this issue doesn't have any comments.

This should definitely be changed. It's easier to add a licence to an unlicensed project than the other way around since you can't retroactively do that.

Additionally, by default, unlicensed projects mean regular copyright law applies. npm's default should mimic the real world's setting.

[IgorFIE]

This just happened to me, I intentionally didn't want a License on a project and didn't realized that ISC was the default on my package.json, which I found strange why people forked my project and changed my code and added a ISC license to it, without talking with me.

The default should be UNLICENSED and if people really want to add a permissive license they should be the ones to change it and not default to ISC.

Now I have a complete project with an ISC licensed on GitHub when I didn't want it to be licensed due to my own pixel art sprites being generated by code - which is now unprotected.

[wesleytodd]

I am not sure if it is still in the plans, but at one point the npm team had decided a community owned package init would be good. That work is in the pkgjs org as part of the Node.js project's Package Maintenance Working Group. When I saw this this morning I figured I would get some of the work over there kicked back off, so if you are interested please contribute over here: https://github.com/pkgjs/create-package-json

[KernelDeimos]

I just googled "why is npms default license ISC" and wound up here because I 100% agree with the title's description of this as "extremely dangerous". I have not ever made the mistake of accidentally distributing code under the ISC license, so I feel that my judgement on this is unbiased. Also surprised about how few people have commented on this.

[jwbth]

People in this discussion seemingly fail to realize that permissive licenses are the foundation of the open source culture that made projects like npm and GitHub flourish in the first place. Of course they are the default, how could it be otherwise? I feel sorry for you if you released something under a permissive license by accident, but the notions of "extremely dangerous" and "mimicking the real world's setting" are clearly misguided and overlooking that simple fact.

[KernelDeimos]

I agree with the sentiment of this statement:

permissive licenses are the foundation of the open source culture that made projects like npm and GitHub flourish

The rest of what you say suggests that understanding this implies one must also agree that the default license should be permissive. This is both a false cause fallacy and a non-sequitur. "UNLICENSED" is simply a more accurate default, because the author did not explicitly choose a license. Whether or not the potential danger is exaggerated, this remains to be the case.

To emphasize the potential danger of this, imagine someone working with not their own code but someone else's code. Suppose this code was initialized with npm init -y and nobody cared about the license because "it's in a private repo anyway". Suppose this someone then makes a mistake and exposes code in a public location. Others then see this code, see the MIT license in package.json, and assume they're free to do what they will with it.

On potential argument against what I said is that the person who exposed code in that scenario must have done something really irresponsible to expose - presumably - the entire directory tree. I can't think of an easy way to make that mistake myself, but it's well known that security and robustness works in layers and you cannot rely on somebody not making an irresponsible mistake.

Consider now that this isn't the "accidentally open-sourcing the code" situation that you presented. In the situation you presented, anyone who then uses the code is still free to do so. In the situation I presented, the person who "licensed" the code could be seen as the person who exposed it, and they are not authorized to license that code. That means anyone who then uses the code is unknowingly taking permission for granted which they don't have.

(TL;DR: I got carried away and wrote too much because I got hyper-focused; the most relevant point is at the top.)

[KernelDeimos]

I just thought of a very important point I forgot to mention. Your statement about permissive licenses being the foundation of opensource culture does not address the impact of copyleft licenses like the GPL. What if you wanted to use a copyleft license because you realize your project will have greater contribution and impact that way? Consider the Linux kernel as an example. In this way choosing the wrong license can have a negative impact on the open-source community as a whole.

[skeddles]

NPM doesn't exist exclusively to create open source projects - anyone making any js/node project is using it, plenty of which are not meant to be open source. If someone wants to make their project open source, they are going to, you don't need to coerce them by making the default open source.

Not to mention ISC is not even a very common license for open source projects, if you wanted to make one the default, why wouldn't it be one most people are using / familiar with, like MIT?

Either way, there is danger to users when setting the default to ISC, while there would be no danger to setting the default to unlicensed. Better to be safe than sorry. Like someone above said, the purpose of a license is to prevent legal troubles, and this could easily cause more.

[ljharb]

To clarify: the danger here has nothing to do with choosing the wrong license. If you've actively chosen a license, then that's your choice.

The danger is in publishing something as ISC, and then realizing that you didn't choose a license, and then changing it to something incompatible with ISC, like GPL. A court might interpret that as "your intention was GPL, therefore it was GPL the whole time, and anybody using ISC can now be sued". They might interpret that as "your intention is irrelevant, it was published under ISC and not GPL, and so that version is forever ISC and can be used without the constraints GPL enforces".

Those are just two possible court interpretations that "screw over" different cohorts of people. The point of having a license is to avoid potential court interpretations that deviate from the author's intentions.

Thus, the solution would be to default to "unlicensed" or similar, to avoid the risk of any court at any time in the future deciding something about your intentions and the license of the ISC code.

(additionally, it casts doubt on ANY package that's ISC, because, was that intentional? or was it just the default?)

[KernelDeimos]

An up-vote doesn't do this justice, this is a beautiful composition of reasoning.

[nukeop]

I'm surprised there's no way to change th default license for new packages. Extremely annoying in a monorepo, where new packages are created frequently. Why not make it public domain instead?

[ljharb]

There is - add init-license=MIT to ~/.npmrc (or whatever license you prefer)

[nukeop]

Thank you, this is very useful.

[danielbayley]

There is - add license=MIT to ~/.npmrc (or whatever license you prefer)

@ljharb Isn’t it init-license?

[ljharb]

oops yes, thanks. will update my comment.