Potential Licensing issues with npm #3959
Comments
|
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. |
|
@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. |
mscdex
added
the
npm
|
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.) |
|
@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. |
This won't happen. 2.14.1 is a security fix. And there are other reasons. |
|
@kemitchell I see that you wrote the terms, do you know if any of them cause incompatibilities with the MIT license? |
|
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. |
This is part of the open source terms of use for the registry, not the client software. You accept |
|
@mikeal please review the client software. This is the fundamental change. See the following specifically: Refer to this diff: 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. |
|
@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. |
|
btw, I don't see these lines in the current license: https://github.com/npm/npm/blob/master/LICENSE |
|
@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.
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 |
|
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,
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. |
|
@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 |
|
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 =). |
|
@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.
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. |
The license was rewritten in npm/npm@80acf20 (npm v3.4.1+ and v2.14.11+). |
|
@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 |
|
@scriptjs Am I getting this right that you don't see any problems with the above (new) license? |
|
Perhaps what we need to ask then is that npm do a release of the 2.x line with the new LICENSE? |
|
@mikeal See above, that's already done. |
|
Ok, looks like the LICENSE file changed between here and here: https://github.com/npm/npm/blob/v3.4.0/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. |
|
@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? |
You should check the new license (linked above). Does it look good? |
|
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. |
|
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. |
|
@jasnell indeed |
|
@mikeal You are confused. We all understand the license on the node site is the Artistic License. This is consistent with what I have said. No one is debating this. We know that this license is from about 2013. Of course seeing this license on the node site and in the installer, and then finding a different license appear on your system is a slight of hand and deception. As you already know the license that lands on your system binds you to NPMs terms. This is the license that contains the objectionable terms that were inserted into Artistic License by reference. As you know the terms of the Artistic License do not permit manipulation and this was wrong. Lawyers Roberta Cairney, John Sullivan, and Charles E. Gotlieb of the Perl Foundation could be contacted for clarification by the Node Foundation. This is the legal team that crafted the Artistic Licence.
This has been going on now for more than a year as you have seen. I won't repeat myself or details that have already been provided. The objectionable license is continuing to be downloaded. There has been no further releases of node and there is no more to be said about this until there are the changes I have recommended. I hope you understand that nothing can be interpreted from the following that would suggest the terms do not include the CLI client software. It is obvious here what the terms apply to. I hope you are reading and interpreting this clearly: I won't include the rest since you can read it for yourself. All the same license, all with the problem text. https://raw.githubusercontent.com/nodejs/node/v0.10.40/deps/npm/LICENSE How can there be some other interpretation that would suggest the CLI is not software or a product offered by NPM in this context? I fail to see how you could suggest this. Over the past week, NPM has continued manipulating its terms, and adjusting policy statements in an attempt to make some of these less offensive. It has also been taking steps to isolate statements like the one above that they bound to the Artistic License. The only thing that really needs clarity at this moment, and that Node Foundation lawyers could help with is the impact of NPM's manipulation of the Artistic License. That needs legal clarity since that is at the crux of whether the NPM license included in node could even be considered an open license or enforceable. It was a manipulation and slight of hand that had everyone for the last year and a half accepting terms without their knowledge or consent. I really don't want to debate any more what is in the documents. I have made it clear what my expectations are with this process. If you are concerned where all the license changes need to be made. NPM needs to complete their changes, then the Node Foundation needs to release patch versions of its software presenting the updated Artistic License 2.0 on the site and in the installer. The copyright holder of the updated Artistic License is npm inc. |
|
I have responded to the NPM issue dealing with this who decided to close the issue without responding to the topic. @vragg You seem to have the details incorrect in your request for legal advice from the Linux Foundation's legal team. You suggest that the license in Node 4.x.x is somehow different than that of 5.x.x. This is not the case. As you will see from Node 10.x, and 4.x.x, the objectionable license that distorts the Artistic 2.0 License was released in millions of downloads total. On the basis there are ~2 million downloads per month according to @mikeal, the scope of this issue is in the range of 20 - 30 million downloads (let alone other distributions direct to systems through native packaging such as rpms). https://raw.githubusercontent.com/nodejs/node/v5.1.0/deps/npm/LICENSE |
|
@scriptjs please run a diff and you'll see that they are different on v4.x to v5.x. It's minor, but they are different. Nobody is disagreeing atm that the parts of the license that are being objected to in this issue are included all the way back to early v0.10 and we have not yet released a version with the new license npm is moving everything to. We have assurances from npm that they are moving all of their releases that impact on Node to the new license in npm master so we will soon have v0.10, v0.12, v4.x an v5.x releases bundled with npm with their new license and I don't believe there are outstanding objections to that form the license. Regardless, the TSC wants to ensure that we have proper legal advice on this because we're not qualified to make judgments on the kinds of claims being made in this thread, that's in progress and we'll report back in #3979. |
|
@vragg Many thanks. |
|
Intellectual property law is beset by internal tensions. Ideas are generally not subject to ownership. We must be free to use ideas generated by both ourselves and others in order to engage in all human activity. Too much private property in ideas would limit our autonomy and block desirable economic activity by creating insuperable transaction costs. At the same time, exclusive control over certain intellectual products is necessary both to protect the ability of authors and inventors to get credit for their works and to create economic incentives to spur intellectual inquiry. Determining when products of human effort should be subject to the creator's control and when they should become the common property of humankind is the core problem of intellectual property law.
FYI being bound to terms sounds more like a contract than a license. Without consideration (an exchange of value) there is no enforceable license (agreement). Maybe we can find some basis for the license under property instead of contract law. What do you think? |
|
@reqshark Licenses and Terms of Use are different. It is unusual for these to be combined. NPM decided at some point to bind their terms to an open source license (Artistic 2.0 License). These statements were crafted by their lawyer and it was no accident. I believe we are going to find there was nothing open source about the resulting software. If this is so, one has to be concerned that is was represented as such and developers were deceived on a large scale. We will see as Linux Foundation lawyers examine this. There should be implications for what NPM has done. It should be deeply concerning how this ended up in the node release cycle without oversight. NPM made no one aware of this - not in their own changelogs or to notify the node team. It went into millions of downloads of node without detection because what people were seeing was the Artistic 2.0 (without the additional language that bound the terms) on the node site and in the installer, but what landed on your system was the tainted license binding you to terms. This is being audited from what I understand. I doubt anyone will consider this transparency and it raises an issue of trust. NPM has taken steps to restore the Artistic License for the NPM client. It will eventually be corrected in node releases. There is nothing to do at this point but wait for the updated license to come into the release cycle. Even it this is done, it does not change the effect for developers and companies that have entered into these terms without their knowledge in the past (that NPM may at their discretion decide to exercise). The only decent thing for NPM to do is to rescind these terms on the basis developers were duped by this slight of hand. With any luck Linux Foundation lawyers may determine the terms to be unenforceable. I still expect the Node Foundation and NPM to make general statements using their public channels about this issue to advise the community at large what has happened. Millions were affected by this. There needs to be accountability and assurance that developers interests are at the heart of Node Foundation operations. If there is nothing but defensive posturing, we can have no faith in the people managing the project. The affiliation with NPM must be monitored at the very least. It is difficult to suggest there was no foul here and it has a bad smell to it. I want alternatives to NPM. I believe It was a bad idea for Joyent to combine this software in node. There is nothing about the node module system that requires NPM as a client. On registries, we already have mirrors but currently they also feed from NPM. This is a vulnerability for the node ecosystem and this will not be addressed by this issue. Thus, I have put forward an issue to see that developers can respond to this so there can be change for the future (without being bound to a sole commercial entity that is manipulating our relationship with node and access to software we create for distribution to others). You will see this here: Even with the changes to the License, developers will be facing new restrictions for use of the NPM registry. These new restrictions are everyone's Christmas gift from NPM. These types of restrictions do not exist for other open language projects and languages because their repositories are managed by Foundations in the spirit of open source to ensure access to the software (and do not create a monopoly for self serving interests). |
|
What's the status of this? New npm has been included to all active branches (0.10/0.12/4.x/5.x) and releases have been made. @scriptjs, is there still anything left here? |
|
I'm pretty sure if there was a problem the aforementioned actual legal counsel would have noted it by now. |
|
In fact, 0.10/0.12/4.x still have the old version of the license that caused this issue:
5.x is fine. |
|
@ChALkeR Hi there. I have not yet seen anything in the way of advice from the Foundation's legal team that would inform the broader node community that inadvertently accepted NPM's terms as they were at the time. This thread has grown quiet but with the expectation there would be followup after the legal review (when it occurred). Please advise the date(s) of the review and who performed the legal review if it has occurred. From my perspective, it is important for the transparency of the node project to provide such information that has not materialized in this thread or been communicated. The advice of the Foundation's legal team remains a high priority since several million downloads were distributed under terms that brought into question the open source nature of the NPM client software. As we understand, this was due to combining the Artistic License with additional terms and policies of NPM. NPM and the Node Foundation bear responsibility for the distribution under these terms. There was never any movement on the part of NPM to rescind the over-reaching terms that impacted the NPM client software – only to make changes for future versions. I have never been satisfied with the lack of information provided to node users concerning this issue which undermines the trust relationship between users of node and the corporate interests that appear to be controlling the project. Beyond this, licensing changes were made to correct the issue but final verification is required to ensure that the updated licensing exists in all latest sources. A secondary point that may require a separate issue (to be thorough) is a mechanism to trigger a review of upstream projects with an impact on licensing so this does not repeat itself at some point in the future. Perhaps this aspect has been receiving attention that I am not aware of. |
|
Going to close this issue given that there's been no conversation since April. Further discussion on this topic should likely best happen in the nodejs/ctc or nodejs/tsc repositories. |
|
@jasnell When is it that you will report the advice received from your counsel? There has been no discussion on the basis no one has comeback with anything. Why is there no accountability for followup? I am confused and disappointed. I have been waiting for the best part of 8 months for some action on behalf of node project to inform and communicate with developers on this issue, not to sweep it under the carpet. |
|
As far as I know, the TSC is still waiting also. The better place to take up any further discussion on this is in the TSC repo (nodejs/tsc) |
|
@jasnell I am not sure why this be closed to be started somewhere else. The context is here. As you can see I have dedicated more than enough time to this and to suggest it must be started again. The only reason I can see for this is you want it removed from the top of outstanding issues. So far as I am concerned it should remain until resolved because this is its state. |
|
I've opened a PR to get this updated in lts / v2, I thought for some reason we were over this hump but it never seems to have been backported: npm/npm#13892 |
|
👍
|
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.
npm/npm@c2aa8b3
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:
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.
#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.
#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.
The text was updated successfully, but these errors were encountered: