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