This is effectively the norm with more traditional, curated package managers. Say I release a piece of open source software, and some Linux distro adds it to their package manager. Under a typical open source license, I have no legal right to ask them to stop distributing it. They can just say "sorry, you licensed this code to us under X license and we're distributing it under those terms. Removing it would break our users' systems, so we won't do it."
The difference is that NPM is self-service - publishers add packages themselves, and NPM has chosen to also provide a self-service option to remove packages. I honestly wouldn't have a problem with them removing that option, and only allowing packages to be removed by contacting support with a good reason. (Accidental private info disclosure, copyright violation, severe security bug, etc.)
I honestly wouldn't have a problem with them removing that option, and only
allowing packages to be removed by contacting support with a good reason.
(Accidental private info disclosure, copyright violation, severe security
bug, etc.)
No court is going to shed any tears over fact this has wider consequences than if you'd been able to comply with a narrower takedown request.
If you want to be your own provider then host your packages on your server(s) and tell your users to add npm.cooldev.me/packagename to their configuration.
If you don't want to host your own then you can choose from a few public providers like npmjs but then have to be subject to their guidelines, policies, and fees.
Throw in some automatic bittorrent support in the client to help offload costs and you've got something great.
Engineers often think that they are the first people in history to have thought "Hey, wouldn't it be easy to pull one over on the legal system?" This is, in fact, quite routine. The legal system interprets attempts to route around it as damage and responds to damage with overwhelming force.
+ the balance of hardships between allowing the conduct in question to continue vs. issuing the injunction;
+ whether the damage being caused by the conduct in question could be satisfactorily remedied by a payment of money as opposed to a mandate or a prohibition; and
+ (importantly) the public interest.
See, e.g., the Supreme Court's discussion of the four-factor test in eBay v. MercExchange, 547 U.S. 388 (2006), https://scholar.google.com/scholar_case?case=481934433895457...
Legal, shmegal.
"I've found a clever workaround for court orders" doesn't work around that bit.
magnet:?xt=urn:btih:14f146cdfaef83951ca9d3ac647e18e1977d1367
I'll wait
Even when the former is actually impossible, a court could still punish for the latter. "Ha ha ha I use technology to cleverly show how futile your orders are" is not the kind of thing you want to say to a court with broad contempt powers.
If the safe harbor law protection doesn't apply, and the defendant is responsible for the illegal behavior, the defendant can absolutely be held legally liable and pay the legally-appropriate punishment.
http://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdX...
> "So what you're saying is, your computers cannot possibly not continue damaging the plaintiff's interests." "That's correct."
> "You're being honest with me." "Yes, your Honor."
> "Will the computers continue harming the plaintiff's interests if shut off?" "No it wouldn't, your Honor.".....
And suddenly things like NPM can transfer the data to other machines, and those machines themselves can also provide to others. Deletions are impossible if people still want the content.
And IPFS guarantees that if a single node has the data, then any node can download it and also be part of the cloud that provides the data. Once it's out, it's impossible to retract.
In other words, Hulk Hogan vs Gawker.
You can experiment with ipfs-backed git remotes though. That's already possible.
Bonus: there's also a IPFS git remote implementation! https://github.com/cryptix/git-remote-ipfs
I've played around with ipfs.js for resolving links into eval'd js at runtime and imagine a npm replacement would be pretty trivial. The IPFS peer to peer swarm seems stable to me but you could also dump all your hash-named files into a s3 bucket or something as a fallback repo.
(And btw, We Nix users very much do hope to start using IPFS :).)
There are a lot of problems with NuGet, but they got this right. I do wish there was a way to mark a package as deprecated, though. For ages, there was an unofficial JQuery package that was years out of date.
That feels sort of like the online discussion equivalent of sticking your fingers in your ears and going "la la la I'm not listening".
I don't expect someone in their position to be unable to ignore a conversation and "take a break" but I would expect them to be capable of doing so without resorting to "suppressing" the ongoing group discussion.
1: See the recent systemd efivarfs issue at https://github.com/systemd/systemd/issues/2402 and associated HN discussions, which was solved through a kernel fix. Pitchforks abound.
Publish forever (barring requests to remove for legal compliance or whatever) is a good idea. Or at the very least, it should be a default option. And if you install a dependency that isn't "publish forever", you should get a warning.
"Would the real Slim Shady please stand up?"
We want multiple 'kik's and multiple Shady's simultaneously. So record the gpg sig of the author in package.json, and filter the name + semver against just their published modules when updating.
Depending on how unique you need to be:
npm install <module> --save
npm install <author>/<module> --save
npm install <gpg>/<module> --save
On a side note, npm-search really sucks. It lacks a lot of fine-grained filtering. I'd love to be able to search by tags, or exclude results with an incompatible license, or even prioritize results by specified dependencies. npm-search needs love.