nodejs / node

Node.js JavaScript runtime βœ¨πŸ’πŸš€βœ¨
https://nodejs.org
Other
108.1k stars 29.86k forks source link

Potential Licensing issues with npm #3959

Closed scriptjs closed 8 years ago

scriptjs commented 9 years ago

What most developers using node may not realize, and that NPM has not shared with the community, is that we entered into a changing legal landscape for the use of our own packages recently. With the 4.2.0 LTS release, additional terms were inserted into the client package by NPM that include acceptance of NPMs terms of service, whether we use it or not. This also affects node 5.x.x stable. Versions of npm@2.14.0 or greater include the changed terms.

Rather than simply accepting a software license as had been the case in the past for the CLI software, everyone is now entering into broad and changing terms of service agreements without consultation, acknowledgement, or consent. It is deceptive and unfair on a number of levels.

https://github.com/npm/npm/commit/c2aa8b38ca4cb02b233113c6d926a0528c93bd4c

Further, additional terms are being incorporated with additional restrictions and providing NPM with additional rights including those of restricting or denying access to the repository service.

https://github.com/npm/policies/commits/master/open-source-terms.md

This is deeply troubling. I am requesting the the TSC discontinue bundling NPM in 5.x.x until this is sorted. I believe there are also legal issues being assumed by the Foundation to include the NPM client on the basis users were not adequately informed of the changes nor what it meant when we downloaded what we believe to be MIT licensed software. It appears we are now entering into wholesale acceptance of NPM terms without our knowledge or consent.

This includes use of your software for any reason or purpose whether it is open or closed source:

You own Your Content, but grant npm a license to use it free of charge. 
That license allows npm to do whatever it needs to do with your content, 
within reason, to provide and improve npm Services, for you and other users. 
That license lasts, for each piece of Your Content, until the last copy disappears
from npm's backups, caches, and other systems, after you delete it from the
Website or the Public Registry.

I am also asking the TSC's legal team to provide advice to users of Node concerning the insertion of these terms that may change without our notice at any time. What does this mean for the LTS since the terms have undergone further changes since the release? Is the agreement enforceable on the basis this was done without our knowledge?

Simultaneous to this, I have requested the TSC to begin examining a decentralized approach to module distribution which I believe is the future. Systems like dat can be used to to provide scale for module distribution without centralizing control over our software under a single commercial provider. I see a possibility of this working in a way that is analogous to apache mirrors. dat is completely decentralized and works in a similar way to git except for binaries and can be used to fetch dependencies.

https://github.com/nodejs/node/issues/3955

NPM is currently an upstream project and the TSC has no control over it other than deciding whether to continue bundling NPM or not even when there are issues that impact its users.

https://github.com/nodejs/node/issues/3949

This is unacceptable in many ways since package management is critical to the node user experience. A decentralized approach (as opposed to what today is centralized) for module distribution is safest at scale. The Web itself was designed around this philosophy and it is a useful model for the scale of node.

I believe it is better for the TSC to determine the future of node – where the community and not NPM is at the center of determining and applying metadata standards that serve the interests of developers. This future can evolve with es6 and with the purpose of moving away from a legacy of being served by a single upstream service that puts developers, module delivery and the node project at odds with each other.

ChALkeR commented 9 years ago

Most of things that seem to bother you are related to npmjs.org, not to the npm client. Are you aware that npm client can install anything that has a package.json? You could use other registries, GitHub, or even direct links to the tarballs. No one forces you to use npmjs.org.

scriptjs commented 9 years ago

@ChALkeR The client is now only offered with the terms of service of NPM. There is no distinction between accepting the software license and the terms of service of NPM. That is what I have said above. They have included acceptance of these terms in the License by reference and this was inserted without our knowledge or consultation as of 2.14.0 that went into 4.2.0 LTS.

You can review this here:

https://github.com/npm/npm/blob/v2.14.0/LICENSE

Review the history to see the difference. Everyone downloading node and receiving the client is implying acceptance of these terms wholesale and this is outrageous. There was no notification to users of such changes or their impact as NPM continues building additional policies and restrictions and making changes without notice to anyone.

Fishrock123 commented 9 years ago

Unshipping npm from node 5 is not an option unless we are no longer legally able to bundle it. It would be a major version change.

(Note: I have not looked at anything and likely won't over the weekend.)

scriptjs commented 9 years ago

@Fishrock123 Yes, this would need to be node 6. The only possibility for 5 is reverting npm to 2.13.0. If developers wish to accept the terms NPM has put forward, they could upgrade. Using the coupling to node to push these terms upon developers without consent is not acceptable.

Decoupling NPM from node is an appropriate solution that will encourage alternatives in the ecosystem to step up with solutions that are compatible with open development. This is becoming increasingly necessary given the circumstances. Frankly I expect NPM understands what they are doing and may feel the community has no alternative but to be held hostage.

Terms of service and a changing landscape of legal terms do not equate with a software license. Coupling these is as they have done is unusual, inappropriate and should concern every developer.

What is more disturbing is the way this has come into the first node LTS without information to developers or the community. It is important there is a legal opinion provided for those who have inadvertently consumed versions of npm@2.14.0 in the LTS and greater since I doubt anyone was aware of this impact. I am not certain it is enforceable given the circumstances.

ChALkeR commented 9 years ago

The only possibility for 5 is reverting npm to 2.13.0.

This won't happen. 2.14.1 is a security fix. And there are other reasons.

mikeal commented 9 years ago

@kemitchell I see that you wrote the terms, do you know if any of them cause incompatibilities with the MIT license?

mikeal commented 9 years ago

One problem I have with this issue is that it's actually like 5 issues, a few of which are logged separately but several are not.

mikeal commented 9 years ago

You own Your Content, but grant npm a license to use it free of charge. That license allows npm to do whatever it needs to do with your content, within reason, to provide and improve npm Services, for you and other users. That license lasts, for each piece of Your Content, until the last copy disappears from npm's backups, caches, and other systems, after you delete it from the Website or the Public Registry.

This is part of the open source terms of use for the registry, not the client software. You accept this by publishing a package to npm's public registry not by using the client software. It's a little confusing because npm has "open source" and "private" terms and the "open source" terms relate to the open source registry not all open software by npm.

scriptjs commented 9 years ago

@Mikeal please review the client software. This is the fundamental change. See the following specifically:

Additional policies relating to, and restrictions on use of, npm products and
services are available on the npm website.  All such policies and restrictions,
as updated from time to time, are hereby incorporated into this license
agreement. 

Refer to this diff:

https://github.com/npm/npm/commit/c2aa8b38ca4cb02b233113c6d926a0528c93bd4c

This is a fundamental departure from past where the license agreement and terms of use of NPM were separate. NPM has bound these together in the license. As a result, it affects everyone and implies acceptance of NPM terms of service as a result of downloading and using node. That is the issue. By binding the two together, anyone using the client, has entered into the terms of service of NPM without their knowledge or consent.

mikeal commented 9 years ago

@scriptjs What that line does, I think (I've asked already for clarification in that commit and I am not a lawyer), is states that violating the terms of use in another policy also revokes your public license to npm. While that is deeply problematic, the section you're quoting is about extending npm a license to content you publish to the registry and pertains specifically to the registry. It does not extend to publishing elsewhere and does not contain language that would revoke your right to any npm software or extend a license to software you do not publish to npm.

mikeal commented 9 years ago

btw, I don't see these lines in the current license: https://github.com/npm/npm/blob/master/LICENSE

scriptjs commented 9 years ago

@mikeal Have absolutely no idea how they are cutting their releases @2.14.0 to @3.3.12 include these terms. You will need to see this in their tags. @2.14.0 and above is what was included the 4.2.x LTS. @3.3.12 is what is currently bunded with node 5.x.x.

https://github.com/npm/npm/blob/v2.14.0/LICENSE

https://github.com/npm/npm/blob/v3.3.12/LICENSE

The terms including the statements of NPMs assertion of access to your module code are included by reference in the client licence.

While that is deeply problematic, the section you're quoting is about extending npm a license to content you publish to the registry and pertains specifically to the registry.

The statements do not differentiate the use of the client vs use of the registry. Further the terms are evolving and changing which means we have no idea of the legal impacts of using this software any longer and it can evolve without our knowledge or consent. This is what is happening in fact and our agreement is being implied as the result of downloading node.

Additional restrictions are continuing to be added here in just the last couple of weeks.

https://github.com/npm/policies/commits/master/open-source-terms.md

jasnell commented 9 years ago

Well first, pulling npm out of v5 certainly is not going to happen. That said, I do see a few problematic issues here: for one, the license seems to change quite a bit and the current license (update: that we currently ship) includes,

"Additional policies relating to, and restrictions on use of, npm products and services are available on the npm website. All such policies and restrictions, as updated from time to time, are hereby incorporated into this license agreement. By using npm, you acknowledge your agreement to all such policies and restrictions."

While I'm not a lawyer, my interpretation of this is that npm is free to change the licensing any time they feel like it and have those changes retroactively apply to code that's already shipped without necessarily getting any notification. The license also does not indicate where those additional policies can be found or how one would go about finding them. Note that the LICENSE file does not actually contain the URL of the npmjs.org website. Only by going to the npmjs.org website and finding the https://www.npmjs.com/policies/open-source-terms page can you find the additional terms you're agreeing to with this license. Then you have to scroll down a bit to find the text, "it is up to you to check for changes to these Terms". However, because the LICENSE file does not contain any actual links to the specific files that it is incorporating, I have absolutely no way of knowing if these terms actually apply.

Another troublesome part of the license, at least for those of us who publish commercial software is a bit further down in the open source terms: "You own Your Content, but grant npm a license to use it free of charge." Yikes! Looking at the history here, that bit of text appears to have shown up on November 11th 2015. If it existed as part of the npm licensing before that date I have no idea because the github history on that particular file only goes back to the 2015-11-11 and I can't find any historical data prior to that date.. I'd love to get some information on when particular bit was added to the license.

This is definitely the kind of thing that @nodejs/ctc and @nodejs/tsc should keep an eye on and be aware of.

mikeal commented 9 years ago

@isaacs @zkat any idea why the LICENSE we're seeing ship with no seems to be so different from the one in npm master?

mikeal commented 9 years ago

@ChALkeR that part is fine, the foundation manages the trademark policy and has a license to the mark but ownership and enforcement responsibilities are still with Joyent. You can read more here https://nodejs.org/static/documents/trademark-policy.pdf

ChALkeR commented 9 years ago

Ah, sorry. Discard my previous comment about the trademark (deleted).


Edit: @mikeal Sorry, didn't notice that you have replied. I checked the docs and deleted the comment, but that was too late =).

scriptjs commented 9 years ago

@jasnell Additional restrictions are only beginning to appear. As a preface to granting access to your software, it indicates 'such as' meaning this is not exhaustive or have limiting meaning. This leaves it up to NPM to determine what constitutes part of the npm Service including the cache on your local machine.

Nothing in this Agreement gives npm any ownership rights in intellectual property that you share with npm Services, such as your Account information or any Packages you share with npm Services (Your Content).

This could implicate private packages without any connection to the registry and interaction with your own package repository as the result of use of the client.

ChALkeR commented 9 years ago

@mikeal

@isaacs @zkat any idea why the LICENSE we're seeing ship with no seems to be so different from the one in npm master?

The license was rewritten in https://github.com/npm/npm/commit/80acf200006dafabfb225ec43f1b51db06f61d72 (npm v3.4.1+ and v2.14.11+). This ticket refers to npm v3.3.12- and v2.14.0.

scriptjs commented 9 years ago

@ChALkeR The license in master has no bearing on any of the shipped software. I don't know how they are managing their tags. We are at 3.3.12 with node 5

ChALkeR commented 9 years ago

@scriptjs Wrong. https://github.com/npm/npm/blob/v3.5.0/LICENSE https://github.com/npm/npm/blob/v3.4.1/LICENSE https://github.com/npm/npm/blob/v2.14.12/LICENSE https://github.com/npm/npm/blob/v2.14.11/LICENSE

ChALkeR commented 9 years ago

@scriptjs Am I getting this right that you don't see any problems with the above (new) license? If so, this issue could be closed β€” the license of npm bundled with Node.js will be updated with npm version update in v4.x LTS (npm 2.x) and v5.x (npm 3.x) branches.

mikeal commented 9 years ago

Perhaps what we need to ask then is that npm do a release of the 2.x line with the new LICENSE?

ChALkeR commented 9 years ago

@mikeal See above, that's already done. npm v2.14.11+ and v3.4.1+ have the new license.

jasnell commented 9 years ago

Ok, looks like the LICENSE file changed between here and here:

https://github.com/npm/npm/blob/v3.4.0/LICENSE https://github.com/npm/npm/blob/v3.4.1/LICENSE

A license change in a patch release is quite odd, but ok. We're still shipping the old version. I think the best thing to do at this point is invite @othiym23 and @kemitchell to the next TSC meeting and ask them to clarify the recent changes that have been made to the licensing just so there is no confusion.

scriptjs commented 9 years ago

@ChALkeR No idea what you mean. All released software includes the references stated to bind the terms of service to the client. We are at @3.3.12. Each release since @2.14.0 includes. I don't understand what they are doing in their repo. The LTS and node stable include these references. Nothing has been done to remove this. There is no assurance future releases will not follow this pattern. Currently every LTS and stable user are bound to these terms. If the license were going to be used why would it not be included in the recently released 5.1.0 a few days ago?

ChALkeR commented 9 years ago

@scriptjs

I don't understand what they are doing in their repo.

You should check the new license (linked above). Does it look good?

scriptjs commented 9 years ago

That is the license as it once appeared before the changes. So yes, if this were applied to the LTS and stable this would at least resolve the client implications with node with the downloads if applied to an update to released code.

It is bizarre that I could only get to the truth in the tags for what has been released and bundled in node. It seems deliberate but no one will know until NPM shares their intentions.

The license will need to be updated in both 4.2.x and 5.x.x if their intention is to put this license back into circulation. I am not certain this is the case. There is quite a bit of change going on the legal side as I have indicated. Developers are not being informed of these changes.

jasnell commented 9 years ago

The only thing that's certain here is that (a) the recent changes are confusing, (b) the timeline is a bit confusing, (c) we need to get the version of npm in master, v5.x and v4.x updated as soon as possible to the new license, and (d) we need to get npm here to give an update on all of the changes here.

scriptjs commented 9 years ago

@jasnell indeed

jasnell commented 9 years ago

I definitely don't want to give the impression that npm is trying to do anything shady here... I just think we need some light shed on what the changes are and the timeline. We also need a bit of clarification on the distinction between use of the npm client and use of the website. If I'm reading things correctly, the new license decouples these whereas the old license (that we're currently shipping) mixes them together.

scriptjs commented 9 years ago

@jasnell Yes, my intention is for a resolution. As things stand, updates can resolve the issue of the software in circulation and its implications if npm moves to the license we see in master. If not, there are serious problems.

Despite this, I am growing increasingly concerned about the compatibility of a sole commercial authority for the registry that is beginning to assert itself in ways the community could not have imagined.

Second, the TSC considers npm an upstream but the node experience is heavily tied to the client and registry where there little or no control.

These are vulnerabilities, as is the notion of continuing to rely on a single source of distribution for modules. I believe it is prudent in the near term to medium term to begin examining options to decentralize the registry to diffuse this. The notion of the TSC having broader control over manifest standards is a better idea as well since node is a developer driven phenomenon and will only continue to succeed if this remains so.

In the present circumstances whether it is legal, technical or otherwise, I can only see this ending in tears otherwise. The community has experienced this in the past. The magnitude of the registry has since grown substantially and there is much more at stake. I think the TSC has a role to play in the software and stabilizing the environment that is growing increasingly unhealthy.

reqshark commented 9 years ago

@scriptjs raises a few interesting points.

consider this:

the TSC considers npm an upstream

where else do you see upstream software source code built with runtime of downstream consumer?

scriptjs commented 9 years ago

@rod11 has replied on behalf on npm. His response is contrary to the circumstances. I have replied to this. Direct answers are needed from @kemitchell who is their lawyer that prepared this.

https://github.com/npm/npm/commit/c2aa8b38ca4cb02b233113c6d926a0528c93bd4c

The scope of this issue is significant and this is bad enough but can be corrected with an update with some communication with the community. @jasnell, @mikeal Any idea of the volume of downloads affected?

From what I am seeing this would be all of 4.x.x and 5.x.x. and io.js 3.3.x. thus far. This goes back just prior to Sept 15 from what I see in the changelogs. I am looking for the exact point in time 2.14.0 came into all releases or node and io.js when this began.

Seems it may be Sept 4 with 2.14.2:

https://github.com/npm/node/commit/c5ec03ebf2fe2d9a03def9080869425660c6544f

There were no mentions of the license changes or implications in NPM's change log to alert anyone when they released @2.14.0 on August 13.

https://github.com/npm/npm/blob/master/changelogs/CHANGELOG-2.md

I can also see there was some dialog on commits NPM made for the LTS but the changes affecting the license were inserted prior to that and I see nothing indicated this in the changelogs. My feeling is that tighter control is required on review or direct commits by NPM to node should be reviewed as a result. I cannot see anywhere yet where anyone was made aware of the changes, vetted or assessed their impact before this was incorporated into the long term service product (LTS) and extended into node latest for distribution.

jasnell commented 9 years ago

@scriptjs ... at this point it would be helpful just to hold off just a bit and give npm the chance to give us an update. It is a weekend after all ;-)

One thing that's helpful to look at is the history of the deps/npm/LICENSE file in each of the branches:

If you look at v0.12 and v4.x, you'll see that the LICENSE file there hadn't been changed since Aug 14th, 2014. That copy of the license includes the part that ties the license file to the website terms but isn't specific at all about what those additional terms are or where they are published. It's simply a bad way to write a license which, I assume is quite likely why @kemitchell rewrote it.

The more recent version of the LICENSE file that landed most recently in master and v5.x is nearly identical. The only changes were typo fixes (https://github.com/nodejs/node/blob/32b51c97ec3de688efae3a88163814501b6dbcc5/deps/npm/LICENSE).

As of right now there have been no PRs opened to update to a version of npm that uses the new license in any of our branches (https://github.com/nodejs/node/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+update+npm+). Which sucks because that means we're still shipping versions that use the old license that ties the use of the CLI to the website terms -- but again, that old license is not clear which website terms apply.

In any case, it's Sunday and I'm off to spend the day with family :-)

scriptjs commented 9 years ago

@jasnell Yes, for sure. This needs time and it will not get solved over the weekend. That said, I wanted to understand more clearly the timeline and scope. We know the license is clear that it infers all terms.

All such policies and restrictions, as updated from time to time, are hereby incorporated into this license agreement.

The ambiguity is that it would be left to NPM to determine how they would apply this and developers in a position of assuming what might apply. This part is as clear as mud at this point.

I have no idea what this means in legal terms for folks that have entered into these terms through downloads. Even if NPM returns the client license back to a state developers were familiar with (prior to being tied to the terms), this will need to be addressed. This might come by way of formal assurance from NPM that they would not bind developers and acknowledge their error. But that is for another day. Have fun with the fam.

isaacs commented 9 years ago

The recent changes to the LICENSE file shipping with the npm client and the terms of service available on the npmjs.com website are designed to make the separation between client usage and registry/website usage more clear.

The open source npm cli application is released under the Artistic License 2.0, a well-known OSI-approved license. You may use it to access any registry or local data you like, or repurpose and modify it within the terms of its license.

The npm registry is a repository of packages published using the npm cli application (or perhaps some other client application). This registry is operated free of charge, and at considerable expense, by npm, Inc. Use of our registry service is subject to our terms of service. There are several open-source and proprietary registries that you can use instead of ours, but I won't deny that ours is far and away the largest and most reliable.

We make it easy to get at the data, if you want to take all the open source packages and decentralize them to your hearts' content. Plenty of folks do this for various reasons.

The passage mentioned in the OP, regarding giving npm the right to redistribute code that is published, was always implicit in the use of the registry. If you publish something as open source, then you should assume we're going to share that content with other users. That's the point of publishing. This passage just makes that explicit.

The updated terms of service are being communicated to developers via numerous means including email and our website. Development on the terms happened in the open, via pull requests on GitHub. If we were trying to hide our intentions, we've done a terrible job of it!

If anything in the Artistic License 2.0 or the npm registry's terms of service is objectionable to the CTC or TSC, we welcome their feedback. I think it's probably premature for @othiym23 or @kemitchell to sit in on a meeting, though. I'd suggest that the relevant Node Foundation parties figure out their concerns first, with the help of their lawyers if they need it. Then, if necessary, someone from npm can address those concerns directly.

scriptjs commented 9 years ago

@issacs you have not identified what LICENSE you are referring to. There are three different versions, the one in circulation is contrary to what you are referring to. These are as follows:

If we were trying to hide our intentions, we've done a terrible job of it!

Look, there is no point in getting arrogant about this. We want a discussion and necessary fixes to update the license that are bound to the node releases. This deserves some respect.

You can see here in your release of 2.14.0, there was no mention of changes to bind the terms of service to the artistic license which creates a number of serious issues.

You can see the changes your lawyer made here:

https://github.com/npm/npm/commit/c2aa8b38ca4cb02b233113c6d926a0528c93bd4c

This is the license included in the releases I have referenced. It specifically bound your terms, policies and shifting restrictions to the license including changes without our notice.

Additional policies relating to, and restrictions on use of, npm products and
services are available on the npm website.  All such policies and restrictions,
as updated from time to time, are hereby incorporated into this license
agreement. 

Your changelog follows for the release where this occurred. There is no mention of the change, nor was there any communication concerning the changes. There was also no vetting of the changes when this entered into the LTS or 5 stable. This is the license we have here at this point. I don't consider this transparency nor is it funny.

There is a broader issue of resolving this if the updated license is what will be inserted, reverting the changes your lawyer inserted.

In my experience with lawyers, there is no accidental insertion of terms. My previous discussions with Kyle indicates he deeply considers what he does, so it is hard to imagine binding the terms to the artistic license (as was done) was an accidental oversight.

If it was ill considered, and it is being reverted, as appears to be the case to properly separate the license from the terms of service, there is a need to fix this and get pull requests into node for immediate changes since the questionable license is attached to every download at present and from about September of this year to the present. Given the LTS was the highlight for node users, I can't imagine the volume of downloads with this issue.

In addition to this, I believe some communication is necessary with the community on this since many thousands of people have downloaded and became bound to your terms with their downloads without their knowledge or consent.

Specifically the what, why and how of this and the remedy. I think it is fair to communicate that implicit acceptance of your terms of service as a result of downloading node was not your intention and a mistake was made. That the downloads people received for the client software will in no way bind them to the registry and service for use of the client (and you will not enforce this on this basis).

Lastly. If transparency is an issue for NPM, please consider changes to policy that are transparent (and not changes time to time without notice that you expect users to enter into without explicitly informing them). Kyle seems busing building up additional policy and restrictions for users of the registry which may seem alarming to some. This is not transparency, it is not consultative and it hard to imagine this is appropriate behaviour for one of the largest repositories of open source software.

After re-reading what you wrote about the phrase in the open source terms, I will add the passage in your terms seems to overstep what NPM's involvement is in distribution and providing service to users. This requires access and use of the metadata the distribution of a tarball. Can you explain how this should be more than this? What else is reasonable use of our software in the context of the service you provide?

You own Your Content, but grant npm a license to use it free of charge. 
That license allows npm to do whatever it needs to do with your content, 
within reason, to provide and improve npm Services, for you and other users. 

v2.14.0 (2015-08-13):

IT'S HERE! KINDA!

This release adds support for teens and orcs (err, teams and organizations) to the npm CLI! Note that the web site and registry-side features of this are still not ready for public consumption.

A beta should be starting in the next couple of weeks, and the features themselves will become public once all that's done. Keep an eye out for more news!

All of these changes were done under #9011:

A FEW EXTRA VERSION BUMPS

ALSO A DOC FIX

kemitchell commented 9 years ago

Season's greetings all around. @mikeal, @jasnell --- hope you're well. @ChALkeR --- hope we'll meet in Moscow someday. @scriptjs --- thanks again for caring about licensing.

As others have mentioned, I'm legal counsel to npm, Inc. Unlike my open-source contributions to npm CLI, which I do on my own, npm, Inc.'s licenses and terms of use are my professional responsibility. npm has specially instructed me to do as much of that work in the open on GitHub as possible, but they didn't ask me to weigh in here. I asked to weigh in here, and they agreed.

From my point of view, with the benefit of a legal read on the situation, I struggle to see any practical legal risk to justify all this anxiety. Unfortunately, I can't give detailed legal advice to the Node Foundation, IBM, or individual members of Node Core to spell that view out in detail. Suffice it to say that legal relationships don't "package" quite like software, isolated from history and context. If I thought the history, context, and content of npm, Inc.'s terms added up to a risky picture for users or packaging with the runtime, I'd have more work cut out for me. I don't think anyone mistakes npm, Inc.'s intentions here.

If other counsel---and participants in this issue have access to world-class open-source counsel---see things differently, for current or forthcoming Node.js releases, they should reach out to npm, Inc. The company will in turn connect them with me, and I'll be all ears. Frankly, though, I'll be surprised to receive that call.

In the meantime, I'd encourage all involved to be careful about speculating on what legal terms mean, in theory or practice, whenever that seems to matter. The brainpower and diligence on this thread is astounding. When all that horsepower comes unmoored from legal reality, though, it can take discussions way far out to sea.

scriptjs commented 9 years ago

@kemitchell. I find there is little isolated in the current context. You seem to have bound the terms of your service of NPM to the artistic license for each node bundle downloaded by developers world wide. Are you saying this because it is your opinion the terms are invalid and unenforceable in this context or that you feel it should not bother anyone that they agreed to them without their consent or knowledge.

I'd like to see some rationale for binding the two and what will be done about correcting this.

jasnell commented 9 years ago

Hey @kemitchell ... The new license on the npm cli is a great improvement so awesome work there and thank you! The only bit of concern I had is on the introduction of the new terms for the website and the possible overlap that exists with the old license. I've asked our legal reviewers to see if there's any real issue there tho. As I said in the beginning of this convo, we just needed to have things clarified which you and @isaacs have done nicely (thank you!). On Nov 23, 2015 2:45 PM, "Kyle Mitchell" notifications@github.com wrote:

Season's greetings all around. @mikeal https://github.com/mikeal, @jasnell https://github.com/jasnell --- hope you're well. @ChALkeR https://github.com/ChALkeR --- hope we'll meet in Moscow someday. @scriptjs https://github.com/scriptjs --- thanks again for caring about licensing.

As others have mentioned, I'm legal counsel to npm, Inc. Unlike my open-source contributions to npm CLI, which I do on my own, npm, Inc.'s licenses and terms of use are my professional responsibility. npm has specially instructed me to do as much of that work in the open here on GitHub as possible, but they didn't ask me to weigh in here. I asked to weigh in here, and they agreed.

From my point of view, with the benefit of a legal read on the situation, I struggle to see any practical legal risk to justify all this anxiety. Unfortunately, I can't give detailed legal advice to the Node Foundation, IBM, or individual members of Node Core to spell that view out in detail. Suffice it to say that legal relationships don't "package" quite like software, isolated from history and context. If I thought the history, context, and content of npm, Inc.'s terms added up to a risky picture for users or packaging with the runtime, I'd have more work cut out for me. I don't think anyone mistakes npm, Inc.'s intentions here.

If other counsel---and participants in this issue have access to world-class open-source counsel---see things differently, for current or forthcoming Node.js releases, they should reach out to npm, Inc. The company will in turn connect them with me, and I'll be all ears. Frankly, though, I'll be surprised to receive that call.

In the meantime, I'd encourage all involved to be careful about speculating on what legal terms mean, in theory or practice, whenever that seems to matter. The brainpower and diligence on this thread is astounding. When all that horsepower comes unmoored from legal reality, though, it can take discussions way far out to sea.

β€” Reply to this email directly or view it on GitHub https://github.com/nodejs/node/issues/3959#issuecomment-159091702.

scriptjs commented 9 years ago

@isaacs, @kemitchell, @jasnell Can we have some assurance that we can have pull requests to include the updated license without the bound terms of service and get that in the release pipeline asap. This will ensure immediate changes for the released node software. I think how the rest of this settles will take time.

piscisaureus commented 9 years ago

The explanation that @isaacs provided about separating the terms of the npm client from the terms of usage of their service seems reasonable and I have no reason to assume any malicious intent.

However there are two things that stand out to me:

1

The new LICENSE file in NPM doesn't actually distinguish between the "client" and the "service" clearly: https://github.com/nodejs/node/blob/8bc80386879538de63cd6f2aef288f59324eb004/deps/npm/LICENSE#L220-L263 . It reads:

The following additional terms shall apply to use of the npm software, the npm
website, the npm repository and any other services or products offered by npm,
Inc.:
<snip>
Additional policies relating to, and restrictions on use of, npm products and
services are available on the npm website.  All such policies and restrictions,
as updated from time to time, are hereby incorporated into this license
agreement.  By using npm, you acknowledge your agreement to all such policies
and restrictions.

Although probably not intentionally so, the license states that additional terms for using the software are posted on the npm website and may change at any time, which is indeed not in the spirit of open source, nor compatible with a free/liberal open source license.

2

The LICENSE file that's in the node root directory (and the one shown to users when they install node using the windows/mac installer) hasn't been updated.

cc @isaacs, @kemitchell

scriptjs commented 9 years ago

@piscisaureus, @kemitchell Also the reference to the Artistic license (without binding NPM terms of service) is posted on node's website, but the license in the code binding users to the terms was downloaded by all for node 4.x.x and 5.x.x. So in two other places it is out of step.

Binding any terms of service to an open software licence let alone a moving and legally binding landscape is highly unusual, what was meant by this specifically? I mean I can appreciate if you determined the result to be ill conceived but @kmitchell, no one acted to remove this or to remedy. This has been in circulation for some time. The fixed version did not enter node releases to resolve the situation if this was not intended – and it appears you made the change back in Sept for a possible fix for the future.

isaacs commented 9 years ago

@piscisaureus That's not the "new" license, it's the previous one. What we're moving towards is this: https://github.com/npm/npm/blob/master/LICENSE The license in Node's deps/npm/LICENSE file on master has not been substantially changed since 2014 Aug 19 (6a11bfe74bcbb4fbafb8877322c847fc2e2befc2). The update 2015 Oct 9 (41923c0c0795cfa6c465821387fca88fe8811367) was only to add a link to the trademark terms (which govern use of the logo) and correct the link to Tjarda Koster's website.

I strongly recommend against making any urgent move to a new npm version on the basis of licensing concerns. The prior license has been there for over a year, and I presume that the Node Foundation lawyers had ample time to review and approve it already. The new license will be in future releases of npm, but please let's not deviate from the established technical review and release process to scramble to put a new license in place. We have these processes for a reason, and the new license will end up in the right place as a result of that process. This is not a fire.

I agree that a service's terms do not belong in an OSS license. That's why we've changed it.

Re (2), good catch. We should make sure to keep that in sync. Is it possible to generate that file programmatically from the licenses it includes, or add a test to make sure it's in sync?

scriptjs commented 9 years ago

@isaacs that is the existing license, the new license is in master but unreleased in any node. The offending license has been there since September. Leaving things as they are is outrageous. It would only require minor release of 4.x.x and 5.x.x with the license changed, equivalent to a security patch.

I was assuming a process of review between the Node Foundation and NPM on license changes. But it appears no one was aware @kemitchell was there dialog? There was nothing in the commits indicating the license change or flagging it for review. Users were not aware and there was no notification by NPM or your staff in changelogs.

I understand your claim of NPM's transparency but surely you can see the lapse even if you choose to evade this. @kemitchell it would be good to have an explanation for the restrictions and changing legal landscape you are proceeding with. Withdrawing the terms of service with the open source licence is appropriate but you did not answer to why they were linked.

What specifically can we expect in future of the registry? Transparency would mean answering to the track you are on with the terms. I cannot imagine anyone would have envisioned a day that our reward for NPM's success would be an environment with an uncertain and changing legal landscape (with the kind of terms I see being crafted for the node module ecosystem).

jasnell commented 9 years ago

@scriptjs ... We definitely do need to get the npm in core updated in the near future but I'm satisfied with the additional information @isaacs and @kemitchell have provided on this. Hopefully we'll get a PR soon and things will get updated. Those of us who publish modules with commercial licenses will definitely need to take a close look at the new website terms of service but as far as core is concerned, the next npm update PR should resolve any issues there. There's likely not much else that can be said here :)

@kemitchell, can I ask a favor tho... If there are any further changes on the license for the cli can you give us a quick heads up here? :) On Nov 23, 2015 5:01 PM, "scriptjs" notifications@github.com wrote:

@isaacs https://github.com/isaacs that is the existing license, the new license is in master but unreleased in any node. The offending license has been there since September. Leaving things as they are is outrageous. It would only require minor release of 4.x.x and 5.x.x with the license changed, equivalent to a security patch.

I was assuming a process of review between the Node Foundation and NPM on license changes. But it appears no one was aware @kemitchell https://github.com/kemitchell was there dialog? There was nothing in the commits indicating the license change or flagging it for review. Users were not aware and there was no notification by NPM or your staff in changelogs.

I understand your claim of NPM's transparency but surely you can see the lapse even if you choose to be evade this. @kemitchell https://github.com/kemitchell it would be good to have an explanation for the restrictions and changing legal landscape you are proceeding with. Withdrawing the terms to the open source licence is appropriate but you did not answer to why they were linked.

What specifically can we expect in future of the registry? Transparency would mean answering to the track you are on with the terms. I cannot imagine anyone would have envisioned a day that our reward for NPM's success would be an environment with an uncertain and changing legal landscape (with the kind of terms I see being crafted for our module ecosystem).

β€” Reply to this email directly or view it on GitHub https://github.com/nodejs/node/issues/3959#issuecomment-159117979.

isaacs commented 9 years ago

If there are any further changes to the license, I or someone from npm will be glad to provide a heads-up. Since @kemitchell is npm's counsel, it puts him in a difficult position to talk to non-lawyer folks directly about these matters. If the Node Foundation's counsel want a legal contact to discuss legal things, then we'll put them in touch. Otherwise, this is firmly in the realm of business &/or technical discussions, so that's either me or the cli team, respectively.

othiym23 commented 9 years ago

@jasnell The reason there wasn't a PR for npm@3.4.0 or npm@3.4.1 is technical – both versions have a serious bug that can leave npm in a state so broken that it can't be fixed without reinstalling from a Node installer. npm@3.5.0 is probably OK, but as I mention in https://github.com/npm/npm/issues/10492, the fix was complex enough that I didn't want to rush it to npm@latest – there could be new regressions introduced by the fix.

Also, there is some more clarification around the license and ToS on the way in npm@3.5.1 and npm@2.14.13 – see https://github.com/npm/npm/pull/10532 (tl;dr: added clarification that the CLI can be pointed at any registry, not just npm's, and removing the licensing language from README.md). I leave to others to decide what the urgency and timing of getting things cleaned up in Node's tree, and am just noting that this change is on its way. My understanding is that this isn't urgent enough to trump the existing release process, but I defer to @isaacs here.

jasnell commented 9 years ago

@othiym23 @isaacs ... awesome :) +1

scriptjs commented 9 years ago

@othiym23 I guess that is good to know, 3.4.1 is on npm at present and I have been using in with 5.0.0 :/

@jasnell You are a steady hand at the rudder. But I have to say this has struck a nerve. It has me questioning whether developers including myself are on solid ground – or on the loosing end as NPM asserts itself in ways that are unhealthy for the ecosystem.

I wanted a clear explanation of why this was legally tied, about the climate NPM is in the process of creating, open and direct responses to the questions around communication and transparency, a pledge to improve transparency for both node and NPM, for NPM to come clean on the issue with the community, to commit to proper changelogs for LICENSE changes that impact users, for there to be proper vetting of license changes by the Node foundation. Finally, for the Node Foundation and NPM to assure developers that if they have inadvertently accepted terms, that they will not be bound for their use of the CLI due to the confusion around the releases and various forms of licensing they may have encountered. I raised the issue and committed my time for these outcomes.