Hacker News Reader

Comment by _Marak_ | Hacker News Reader

So wait...if I decided I want to remove my work from the internet and become a recluse, I'll have to get permission from Isaacs?

What if I just don't want to be bothered anymore by developers looking for support on my projects?

NPM jumped the shark a year or so ago. A package manager shouldn't be a ventured capital funded business. We are all going to suffer from Isaac's leadership on NPM.

View on HN

So wait...if I depend on a package but the developer randomly wants to remove his work from the Internet and become a recluse, my entire site breaks?

What if I just don't want to be bothered anymore by having to rewrite entire modules I depended on?

NPM jumped the shark a year or so ago. A package manager vitally depended on should be forced to work for free. We are all going to suffer from Isaac's leadership on NPM.

If you are depending on another persons package and haven't bothered to lock in a version or bundle the version into your application, your site is not your site.

If you want to depend on other's peoples work without taking care to insulate yourself, you'll have to deal with it. Why is it none of my applications were affected by `left-pad` this week? Good question.

NPM had plenty of chances for realistic ( non-venture capital based ) funding. They took too much cash and hired too many people. Now everything is starting to fall apart.

So, if you're okay with me locking a package myself... why can't NPM just do the locking for me? That's what's happening with this new change.

After all, I'm not a developer because I like administrative work – I want to build stuff, and NPM takes the hassle out of this.

Wow. Just wow. Before npm you'd grab a tarball and keep a copy in an external modules directory. If the author pulled their work, you'd keep using that tarball, and eventually migrate to another package.

But agreed. Isaacs seems to do quite a few unilateral changes that cause a hell of a lot of disruption.

If you remember the actual history of NPM, you will remember that TJ had a competing package manager called "kiwi" which was entirely github / git / and bash based ( using semver ).

Nodejitsu ( me ) choose to back NPM over Kiwi starting in 2009. It's all public information if you start crawling through emails.

Should there be another package manager?

If your site breaks because NPM is down, or a package is removed, you have designed your site poorly and you deserve to have your site taken down.

This is how open source code works. It has nothing to do with Isaacs, npm, or how npm is funded. Once you give a bit of software to someone with an open source license, they can continue to distribute it to other people, even if you stop distributing it yourself. This is crucial to how the whole thing works.

I really like NPM. It's awesome.

Your "control" of your code is an illusion if you publish it as open source. This policy now makes clear the way it already works (or should have in the case of last week).

This has always been the case, and if you'd like to be able to revoke distribution rights from someone at a later time, you'd need to put that in your license terms. No major open source license that I'm aware of features such a clause.

You don't have to use a standard open source license. In fact it appears you can have packages on NPM with no specified license.

To be clear as to what you're saying: npm does not require you to use a standard license. This is true. So in those cases, it would be different. That's my point: you'd have to specifically use a license which had this term in it. left-pad, for example, did not have this clause.

It's unclear to me they had the right with left-pad.

https://github.com/azer/left-pad has no license file, and the license in package.json is meaningless. I can interpret it as referring to anything I want with the same acronym.

I agree that the spirit from the author seems to have been to allow this re-publishing, and I don't really think npm did anything wrong by doing so, but that's not generally applicable in the way their new policy is. I think their lawyers should have a serious problem with this new policy.

I'm not 100% sure if there's ever been rulings about metadata vs in-tree, but agree having it in-tree as well would be helpful.

npm's lawyers were intimately involved in this new policy, so I can assure you they don't have a problem with it.

hmm, I mean, I guess there's no harm having it be stated policy. There are any number of hypothetical situations where I'd expect their lawyers to advise them not to follow that policy when faced with the threat of litigation.

The license in package.json seems to refer to http://www.wtfpl.net/

But as copyright holder you're not bound to use that license ever-after. You can change the terms for all versions to be "strictly proprietary."

I would love to hear from a lawyer but I would speculate that it would mean that you would effectively subject yourself to infringement if you published a derived work even if those terms changed after your publication.

  >  You can change the terms for all versions to be "strictly proprietary."

You can change the terms for the versions that _you_ are distributing, but if you previously distributed that code to someone else, they are free to use that code you gave them previously under that license.

Unless the license you gave them specifically includes a clause which allows you to retroactively revoke that license. I'm not aware of any major open source license which contains such a clause.

I wasn't so sure, so I checked. IMO based on this info it's not settled.

http://law.stackexchange.com/a/837/4947

http://law.stackexchange.com/q/8132/4947

From [3]:

> If GPL or Creative Commons-type licenses are subject to later termination by authors (or their heirs), and this termination power cannot validly be waived, then users of such works must confront the possibility that the licenses may be revoked in the fiture and the works effectively withdrawn from public use, with potentially chaotic results. Although a number of judge-made doctrines may be invoked to restrict termination of a license granted for the benefit of the public, the better course would be for Congress to enact new legislation expressly authorizing authors to make a nonwaiveable, irrevocable dedication of their works, in whole or in part to the use and benefit of the public-a possibility that the Patent Act expressly recognizes, but the Copyright Act presently does not.

[3] http://scholarship.law.uc.edu/cgi/viewcontent.cgi?article=11...

Interesting, thank you for doing this work! I'll have to follow this more closely.

Yeah, kinda scary right? I'll keep digging, I'm surprised that a change in the wording of the license can't solve the problem. I'm assuming that if that's all it took, the author of that paper wouldn't have called for legislation changes.

It is also interesting because this is talking about the license of the code, but in this particular situation, we have two licenses: the one the author gives for the code, but also npm's TOS. I wonder if this applies to the TOS as well, or if this is a feature of copyright law specifically. I would assume the latter, but I am not a laywer.

npm's TOS is not quite the same because it's not a license. Therefore it's not governed by 17 USC (Copyrights). But if it were a contract, changing the terms of the contract probably is bound by some laws somewhere. I doubt that the TOS constitutes a contract but it seems like an analogous problem to whether the acceptance of the open source license constitutes a contract.

Right, that's what I was trying to say, but got a bit sloppy. :)

You can edit your name and email address. You can also update all your READMEs to say you no longer support the project. It's a lot better than breaking everyone's projects.

> Now they are telling me I don't have control over my own content in their directory.

Because that's literally true. You chose to relinquish that control when you published under a free software license.

This isn't limited to NPM. Say you publish an application on GitHub, and Debian decides to add it to their package manager. If you take down your GitHub repo, it'll still be in Debian's repository. If you ask Debian to remove it, they'll likely say no.

That's how pretty much every directory on the internet operates. A directory can list free information about anything. If you're publishing open source code that's free information. Directories don't have to take down information that's freely available.

If I wanted to create a directory of open source code on the internet I'm free to copy and host that open source code as long I keep the open source license on it. Authors could request it to be taken down, removed etc but under the open source license I'm free to keep it up and ignore them.

If I wanted to create a directory of Starbucks locations I could and starbucks could not take it down either.

Exactly. If you open source your code you are giving up certain rights to control that code. If you are having any reservations about that, everyone will be a lot better off if you just don't publish modules in npm.

Does NPM require you to only publish open source code? Can I publish a package that allows you to download it from NPM but requires you to get a license from me to run it? How about a limited open license that only allows straight white women to run the software?

They do not. I am speaking solely about the usual open source licenses here, which are the vast, vast majority of packages. Your hypothetical limited license is not open source nor free software, so it's out of the scope of my point here.

If you did publish some code on npm with such a license, their TOS covers npm's ability to distribute that code to end-users, who may or may not be allowed to actually run your code, per the license. But then your issue would be with those users, not npm Inc.

Wouldn't it be a bit unrealistic to try to enforce this?

i'd like to see an "orphan" command that just stripped your name and contact info off the package, registered it to a "node-orphaned-package" user as a signal that it was unmaintained, and prevented anyone else from using the name (i.e. adopting an orphaned package would require changing its name, with node supplying tools to track the transition).

You would have to get permission from NPM yes. However ten yearz ago you wouldn't be able to it at all, since you would have to hunt down everybody who had a copy of your source code.

If you don't want to be bothered by support requests, you can just ignore them - nobody owes anybody anything but what you have mutually agreed to - offer consulting about the problem to them at exorbitant rates (say 10k/hour, which is worth it for large enough businesses with my-hair-is-on-fire problems) or whatever else you want. If you have your own domain you can use a throw-away email address and just drop all email sent to it.

However the open source licence you published under specified that you gave away a non-revocable, permanent license so of course you can't demand others delete files on their systems.

Reply on news.ycombinator.com