Regarding the recent 'incident', what do you think? Note that this is not about whether NPM is allowed to retain the package or not, just if they should.
Yes. You don't inconvenience thousands of engineers for philosophical reasons like "someone signed away their legal rights and now they regret it". FOSS is FOSS. The end-users are entitled to those packages -- the licenses explicitly say so.
It would be a breach of trust for a package manager to unjustifiably revoke users' access to a package. They don't have an option to be kind to the package author, because their duty to their users comes first. Putting the author's wishes over the users' professional expectations isn't something they have agency to do.
Entitles them to what, exactly? If I publish a package that people use and decide to remove it, either by deleting the repository, the package from registries, or simply publishing dead code, are you saying it's a license violation? How does that make any sense?
I am wondering if there is a niche for a paid repository (npm or maven) that actually verifies/tests/analyzes libraries and recommends/bans libraries/versions that didn't pass such verifications. That could potentially prevent Equifax hack, Log4j, etc. Could be good for the enterprise.
I am frankly surprised that dependency attacks are not a big thing yet (or they are?) as we devs just throw in any dependency in if it looks like its doing the job.
Also many corporate repos are just a garbage bin of crap. I can quietly replace a library in the repo, make sure the projects grab my modified version before the release and rollback shortly after). I remember called this a "maven bomb" and discussed with my teammates and a manager - who didn't give a shit
What would prevent a free (gratis) repository from tracking everything the paid repository recommends, and simply cloning that? Like CentOS did with Red Hat. It's a difficult question when all the underlying work is FOSS.
The host who can according to the license continue to host it for the other 99.999% of users. The host for example NPM is the one who owns the service and need not provide the uploader with the privilege of revocation.
Well first by communicating with NPM which could take an extraordinary action to break builds in the case where this is the least bad actions or by doing something logical and providing developers or company contacts to register to receive warnings ideally based on parsing actual dep versions and transmitting a message directly to the designated contact for a project.
Yes. FOSS licenses are irrevocable. People should be able to count on that. NPM shouldn't let you cause harm to many other people just to enable you to more effectively throw a temper tantrum.
Genuine question to the people who voted “no”. Could you please elaborate on why NPM would not be allowed to retain the two packages?
If I understand correctly the libraries were under an MIT license. Is that incorrect? (The source seems to since been removed from Github and it’s too late in the day to go digging.)
If so, what is the legal reason for them mot being able to ignore the author’s wishes?
ps. The OP is asking explicitly if they are allowed. Not if they should. —- I do think that they should not retain the package, but I’m not sure about the allowed part. So please do chime in.
While this poll was a result of the recent incident, it is not about those two packages. It's about _all_ packages and authors, in general. The question is whether NPM should retain the package against an author's will such that infrastructure does not break, or adhere to the author's will and remove the package, breaking infrastructure in the process.
Edit: It is assumed that NPM does have what is legally necessary to continue hosting the package.
Indeed. It’s perfectly possible and recommended to run Artifactory or similar as a local mirror anyway to buffer upstream unavailability/slowness. (Beyond Maven it also does npm, pip, and I think deb and more via pluggable layouts). I don’t know if it has machinery to propagate upstream deletes, but if so there should be a switch to maintain a cache in any case if the license is irrevocable. It’s also good practice to locally mirror source of all dependencies. Gogs is light and runs in Docker and allows this. It would be good practice to ensure that builds can be made and published locally. Finally legal knows what is in use and probably has a whitelist of acceptable licenses and irrevocability should be a criterium.
CI really shouldn’t need to hit 3rd parties. That’s a service that NPM does not disincentivize afaik, but respecting author takedown requests would certainly do so. I agree it’s npm’s call how they want to manage their relationships and what service level agreements they offer, even tho they are covert agreements to most. A pattern of high profile takedowns would make it known. Businesses are to make money and CI management is ultimately the responsibility of each org.
If I write some code and decide to upload it to NPM for others to use under a FOSS license, that's my decision.
If I decide to stop hosting my code on NPM, that's my decision too.
If an end user downloaded that code when it was hosted, and are now using it, good for them.
If an end user sets up their build pipeline in such a way that it re-downloads the code X number of times per hour/day/week, and I decide not to do FOSS work any more, and thus take it down, then that's the end users problem.
I think this is the difference between expectations and reality that's causing this to be such a big conversation.
The code(each version of it, even the busted one) was FOSS licensed, and you can do what you want with it no questions asked. But nobody is under any obligation to continue providing you with that code indefinitely just because you decided to depend on it always being available on other peoples servers.
> If I write some code and decide to upload it to NPM for others to use under a FOSS license, that's my decision. If I decide to stop hosting my code on NPM, that's my decision too.
You are free to stop publishing new versions on NPM, but NPM is not obligated to stop distributing the package (as allowed by the FOSS license you previously granted) just because you decide you want to stop hosting your code there. Once you've published the code under a FOSS license you no longer have control over its distribution.
Obviously NPM is also not obligated to continue hosting the package, but if they take it down at the author's request when they didn't need to and the result is broken infrastructure, they are rightly going to get most of the blame for that breakage. The author may have made the request but in the end it was NPM's decision to take it down.
I see lots of comments on licenses. A FOSS license isn't a "I promise to host the built version of this artifact on npmjs.org forever" license. IANAL, but that's a right the developer grants to NPM when they choose to publish the package. If NPM's terms are written this way (and I imagine they are), then the developer can pound sand. But it's ultimately a relationship between NPM and the package publisher. We can say what we desire as consumers, but we're not party to that decision.
A FOSS license is generally “anyone can do whatever they like with this code provided they include this copyright notice”, and maybe some other conditions. “Anyone” here definitely includes NPM, so NPM is free to distribute, modify, host, or do anything else they like to your package provided they abide by those terms.
NPM should, because NPM is a platform for people to download dependencies.
However, I believe GitHub should not retain repos against the author's will, because GitHub is a hosting site.
As an analogy: if I upload an image to some web hosting platform / blog host / social media site / etc., and a lot of people hotlink it, and then I change or delete the image, that's my right. It would be wrong for the web host to decide the image is too popular and prevent me from touching it. But if I upload an image to Wikimedia Commons, it's no longer "my" image and Wikipedia has the right to keep using it even if I want to change or delete it. It would be wrong for Commons to let me modify the image retroactively.
Consequently, build tools and package managers that use GitHub directly are an antipattern, just as much as if your makefile did "wget ftp://ftp.example.edu/~someone/whatever-1.0.tar.gz" and expected that to not change.
> But if I upload an image to Wikimedia Commons, it's no longer "my" image and Wikipedia has the right to keep using it even if I want to change or delete it.
It's the license you choose that gives people that right or not. It has nothing to do with which site you upload to.
I don't care either way; they're a private company. I love FOSS, but that does mean it's out there and you can't "take it back."
I think the more interesting question is: should NPM be liable for breakage? Should they have to pay for harm caused when this sort of thing happens? If people are paying for NPM's services, probably yes.
From one perspective it's good to know a published artifact is there no matter what, on the other hand I can imagine I publish some licensed/private code by mistake and probably want to take it down to cover myself - and I wouldn't be able to? Need a 3rd option - Don't know!
I’d say yes as the license allows it. If open source is open source it should be allowed.
I do see the issue though. People making money with your code and not sharing the profit kinda sucks, especially when also making demands. The comments on GH are sometimes insane.
It’s unfortunate but I think the best solution is to not release under a FOSS license and choose something less permissive, something that requires purchasing a license for commercial use.
The other option is for open source projects to be backed by foundations that pay people to maintain projects.
Rather than force NPM to take a dogmatic approach, what about considering what a reasonable, pro-all-users "no" solution looks like?
Node already has tools like audit that tell you if there's problems of various kinds with your packages. (The quality of audit, and NPM in general, is pretty poor, but this could apply to many package managers, NPM is just the current example.)
So sure, allow people to pull their packages. But require a 60-day "cooldown" period where the package is still available and comes with a warning every time it's downloaded that on such and such a date it will be deleted, by request of its creator. The note could include a message from the creator and links to viable replacements.
Also, assuming licenses permit, do NOT delete any existing copies of the package or break when the user tries to update again later. Just keep sending warnings until the cached package is removed.
Finally, make it clear to authors of packages that if they submit to NPM, this is what will happen if they choose to remove their package.
What if the package bundles were stored on IPFS? They would be hash-addressable, and also verifiable (no danger of package hosts inserting malicious code), and npm would just be responsible for building, verifying that a given bundle based on the package source at a given commit/version builds to a package with a given hash. Then its main role to cli users would be to provide the index.
Once uploaded, content could not be removed, so maintainers couldn't pull packages, though npm could de-index certain builds if they were found to contain malicious code.
39 comments
[ 5.1 ms ] story [ 175 ms ] threadIt would be a breach of trust for a package manager to unjustifiably revoke users' access to a package. They don't have an option to be kind to the package author, because their duty to their users comes first. Putting the author's wishes over the users' professional expectations isn't something they have agency to do.
I am frankly surprised that dependency attacks are not a big thing yet (or they are?) as we devs just throw in any dependency in if it looks like its doing the job.
Also many corporate repos are just a garbage bin of crap. I can quietly replace a library in the repo, make sure the projects grab my modified version before the release and rollback shortly after). I remember called this a "maven bomb" and discussed with my teammates and a manager - who didn't give a shit
It does not enforce how a project is run or distributed.
If the author of is-even deleted his package who can tell him he is in the wrong?
At best the community can stand up and fork which means they have to move ownership to some rando
If I understand correctly the libraries were under an MIT license. Is that incorrect? (The source seems to since been removed from Github and it’s too late in the day to go digging.)
If so, what is the legal reason for them mot being able to ignore the author’s wishes?
ps. The OP is asking explicitly if they are allowed. Not if they should. —- I do think that they should not retain the package, but I’m not sure about the allowed part. So please do chime in.
Edit: It is assumed that NPM does have what is legally necessary to continue hosting the package.
CI really shouldn’t need to hit 3rd parties. That’s a service that NPM does not disincentivize afaik, but respecting author takedown requests would certainly do so. I agree it’s npm’s call how they want to manage their relationships and what service level agreements they offer, even tho they are covert agreements to most. A pattern of high profile takedowns would make it known. Businesses are to make money and CI management is ultimately the responsibility of each org.
If an end user downloaded that code when it was hosted, and are now using it, good for them. If an end user sets up their build pipeline in such a way that it re-downloads the code X number of times per hour/day/week, and I decide not to do FOSS work any more, and thus take it down, then that's the end users problem.
I think this is the difference between expectations and reality that's causing this to be such a big conversation.
The code(each version of it, even the busted one) was FOSS licensed, and you can do what you want with it no questions asked. But nobody is under any obligation to continue providing you with that code indefinitely just because you decided to depend on it always being available on other peoples servers.
You are free to stop publishing new versions on NPM, but NPM is not obligated to stop distributing the package (as allowed by the FOSS license you previously granted) just because you decide you want to stop hosting your code there. Once you've published the code under a FOSS license you no longer have control over its distribution.
Obviously NPM is also not obligated to continue hosting the package, but if they take it down at the author's request when they didn't need to and the result is broken infrastructure, they are rightly going to get most of the blame for that breakage. The author may have made the request but in the end it was NPM's decision to take it down.
However, I believe GitHub should not retain repos against the author's will, because GitHub is a hosting site.
As an analogy: if I upload an image to some web hosting platform / blog host / social media site / etc., and a lot of people hotlink it, and then I change or delete the image, that's my right. It would be wrong for the web host to decide the image is too popular and prevent me from touching it. But if I upload an image to Wikimedia Commons, it's no longer "my" image and Wikipedia has the right to keep using it even if I want to change or delete it. It would be wrong for Commons to let me modify the image retroactively.
Consequently, build tools and package managers that use GitHub directly are an antipattern, just as much as if your makefile did "wget ftp://ftp.example.edu/~someone/whatever-1.0.tar.gz" and expected that to not change.
It's the license you choose that gives people that right or not. It has nothing to do with which site you upload to.
I think the more interesting question is: should NPM be liable for breakage? Should they have to pay for harm caused when this sort of thing happens? If people are paying for NPM's services, probably yes.
I do see the issue though. People making money with your code and not sharing the profit kinda sucks, especially when also making demands. The comments on GH are sometimes insane.
It’s unfortunate but I think the best solution is to not release under a FOSS license and choose something less permissive, something that requires purchasing a license for commercial use.
The other option is for open source projects to be backed by foundations that pay people to maintain projects.
Node already has tools like audit that tell you if there's problems of various kinds with your packages. (The quality of audit, and NPM in general, is pretty poor, but this could apply to many package managers, NPM is just the current example.)
So sure, allow people to pull their packages. But require a 60-day "cooldown" period where the package is still available and comes with a warning every time it's downloaded that on such and such a date it will be deleted, by request of its creator. The note could include a message from the creator and links to viable replacements.
Also, assuming licenses permit, do NOT delete any existing copies of the package or break when the user tries to update again later. Just keep sending warnings until the cached package is removed.
Finally, make it clear to authors of packages that if they submit to NPM, this is what will happen if they choose to remove their package.
What would be wrong with such an approach?
Once uploaded, content could not be removed, so maintainers couldn't pull packages, though npm could de-index certain builds if they were found to contain malicious code.