Hacker News Reader

Comment by _Marak_ | Hacker News Reader

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).

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.

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. :)

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.

> 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.

Reply on news.ycombinator.com