To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them
You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.
The they have gotten the right for npm to distribute the source code in context of npm.
There is absolutely no copyright or publishing right transfer that takes place when one "publishes" a package on NPM (or on Github). None.
The original author is absolutely entitled to a DMCA takedown notice and NPM would have to oblige him.
That's the first mistake you are making.
Secondly and as important if you publish something under an Open Source license(1) then you _cannot unpublish it_. You granted copyright to _everyone_ for and existing both now and in the future to distribute and use it(2) (legally it's a bit more complex but that's what it boils down to).
(1): Assuming you had the legal right to do so, but if not you are liable for any fall out, not npm (because ToS, they still need to take it down reasonable fast, but they might be able to sue you).
(2): Within the constraints of the license.
* no other packages in the npm Public Registry depend on
* had less than 300 downloads over the last week
* has a single owner/maintainer
So while your point is taken that unpublishing is possible under some circumstances, it is not for popular packages that are in use today.
neither do NPM TOS, or whatever Microsoft thinks they are entitled to, since NPM is owned by Microsoft.
Assuming the package is released under a Free Software licence, what grounds would there be for a DMCA takedown?
I suppose a developer could include the lyrics to a pop song in their code (possibly encrypted), and then tell the copyright holder about it (since I don't think you can make a DMCA request on behalf of a copyright holder without their permission), but I would hope that such a poison-pill would be caught long before the package became widely depended on.
Perhaps you're thinking someone would risk perjury(?) charges for making a false DMCA request against their package, and NPM would act on the request without questioning it; but remember that NPM is owned by Microsoft and they have previously stood up to frivolous DMCA requests (after a fashion)[0]. That article has the lede: "Software warehouse also pledges to review claims better, $1m defense fund for open-source coders".
[0] https://www.theregister.com/2020/11/16/github_restores_youtu...
Tell that you Youtube's copyright trolls
You're probably right, though, that there is enough imprecision in the system for someone to claim that someone else's code snippet infringes on the copyright of a code snippet the claimant had previously published.
[0] https://torrentfreak.com/u-s-indicts-two-men-for-running-a-2...
[1] https://freebeacon.com/culture/google-youtube-algorithm-copy...
In theory, you're right. In practice, there's never any actual consequences for filing a false DMCA claim. Worst case is that the thing doesn't get taken down, but that's no worse than if they didn't file it at all.
Some parties that are distributing other peoples' stuff lose a safe-harbor protection from liability themselves if they ignore it.
This means intermediaries who don't benefit much directly from distributing a given bit of content will immediately comply with the DMCA takedown process. But this does nothing if you send the notice to someone who is actually using it.
The correct move is to send DMCA to the infringer's ISP/host. Then the ISP has to take it down unless counter-notified that they say they're not infringing. In turn, that counter-notification improves your position for any litigation that may ensue.
I'm not sure what about the current open source ecosystem makes you think anyone would catch something like this.
Legally, that meant that noone could use it. In practice, nobody but our legal department cared, so we had to wait for version 2 when the dependency chain was updated to remove it.
Noncompliance with the license, e.g. by removing required copyright notices/attribution in the code (this has happened in the past). Or straight-up uploading someone else's non-free code.
This seems like an edge case that wasn't anticipated by the DMCA, but I can see the argument that mixing GPL code with proprietary code is creating and distributing a derivative work, in violation of the GPL. Without proprietary code being present, though, I don't think a developer can DMCA takedown their own GPL software.
[0] "As the Minecraft Server software is included in CraftBukkit, and the original code has not been provided or its use authorized, this is a violation of my copyright." https://github.com/github/dmca/blob/master/2014/2014-09-05-C...
No, they don't. Honoring DMCA takedowns allow benefit from an additional safe harbor from any existing infringement liability for the alleged infringing content, but are not mandatory in their own.
Off the top of my head Bundler, CocoaPods, Cargo, SPM, Pipfile(and various other Python dependency managers), and composer also all work like this.
Cargo even makes it implicit that a version like “1” means “^1.0.0” in Cargo.toml.
The first line of NPM install's documentation[0] says(emphasis mine):
> This command installs a package, and any packages that it depends on. If the package has a *package-lock or shrinkwrap file, the installation of dependencies will be driven by that*, with an npm-shrinkwrap.json taking precedence if both files exist. See package-lock.json and npm shrinkwrap.
What does happen is: if you have added a new package in package.json it will be installed based on the semver pattern specified there, or if you run npm install some-package@^x.y.z the same thing happens. Further, if you modify package.json by changing the semver pattern for an existing package that will also cause this behaviour.
Running `npm install` in a package that already has a package-lock.json will simply install what's in package-lock.json. `npm install` only changes the lock file to add/remove/update dependencies when it detects that package.json and package-lock.json disagrees about the specified dependenices and their semver patterns e.g. having foo@^2.3.1 in package.json and foo@1.8.3 in package-lock.json will cause foo to be update when running `npm install`.
npm install will traditionally install the most recent packages that match your constraints. You need “npm ci” to use true version locks
Incidents like this highlight that this may not be the best idea.
When you have a package-lock.json NPM will install exactly the same version of everything in your dependency tree, making the CI builds much more like what's on your dev machine (modulo architecture/environment changes)
Admittedly, I don't think it has nearly as wide a usage as it has in the NPM world. Dependabot (I know I'm not the first to mention it, here, today) is probably more of a factor.
Still, it strikes me that this sort of "attack" (or mishap) is exceedingly rare in the Java ecosystem, while it's pretty common in the NPM world, and I don't immediately understand why that would be so.
> while it's pretty common in the NPM world, and I don't immediately understand why that would be so.
I think it boils down to Node projects typically specifying dependencies in the form “any version >= X”, effectively “always use the latest.” Dependencies can therefore get bumped silently just by rebuilding, essentially. Whereas in the Java world updating dependencies is a deliberate process.
You also can't unpublish once a single person has downloaded the package, I believe.
All together I don't see how GP's "email php files around" is as any better than this system in any way.
Autobumping versions, or version ranges as they're called in Maven land.
Dependencies should only use fixed versions and all updates should be manual.
You should only use auto-upgradable versions during development, and the package manager should warn you that you're using them (or your dependencies are).
Dependency management is not as simple as only upgrading one direct dependency at a time after careful review.
The NPM ecosystem is particularly difficult to work with as it has deep and broad transitive dependency trees, many small packages, and a very high rate of change.
You either freeze everything and hope you don't have an unpatched vulnerability somewhere or update everything and hope you don't introduce a vulnerability somewhere.
The JS ecosystem will probably have to change but because it's so decentralized, that change will be orders of magnitude harder than, for example, PHPs transition from 3 (4, 5) to 7.
Is it? Everybody is pulling from Microsoft owned servers now, as Microsoft owns both Github and NPM.
I don't think you're right in the builder/building practices sense.
Most package managers won't allow these stunts and conflicts have to be resolved UPSTREAM. NPM chose to go the "YOLO" way and will fetch every single version of a package that meets the dependency demands. Terrible design, but the purpose of that was growth for NPM, the company, not the best interest of the ecosystem.
You need to ask npm to upgrade or delete your lock file and node modules to run into this issue.