10 ms·

This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everythi

This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.

throw_m239339 5y ago
> This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything. You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.
- dathinab 5y ago
  Except if they have reason to believe the code was uploaded with the permission of the copyright holder. The they have gotten the right for npm to distribute the source code in context of npm.
  - throw_m239339 5y ago
    > 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.
    - mschuster91 5y ago
      You can't legally retract opening up software source code under most if not all popular open source licenses.
      - josephcsible 5y ago
        It is indeed all, even if you ignore the "popular" qualifier. If a license could be unilaterally revoked, it would fail to meet the Open Source Definition for that reason.
      - throw_m239339 5y ago
        open source =/= free software. That's the first mistake you are making.
        josephcsible 5y ago
        While they are indeed sightly different, I fail to see how the differences are at all relevant in this context.
        vurpo 5y ago
        The differences between the two are extremely minimal, basically only relating to patent rights relating to the software. Go read https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html - the FSF's Free Software definition, and https://opensource.org/osd https://opensource.org/osd - the Open Source Definition (both by the respective parties that coined the terms and maintain them to this day) and see what the actual differences are. They're not many.
    - deleted 5y ago
      [deleted]
    - dathinab 5y ago
      First you agreed to ToS when you uploaded things to npm. I haven't read the terms but it should be enough for npm to publish on npm no matter the license. 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.
    - Dylan16807 5y ago
      Your Content belongs to you. You decide whether and how to license it. But at a minimum, you license npm to provide Your Content to users of npm Services when you share Your Content. That special license allows npm to copy, publish, and analyze Your Content, and to share its analyses with others. npm may run computer code in Your Content to analyze it, but npm's special license alone does not give npm the right to run code for its functionality in npm products or services.
- mjlawson 5y ago
  Not only does it require more steps, it also has to meet the following criteria[1]: * 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. [1] https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish
  - throw_m239339 5y ago
    None of these points have any legal standing, from a copyright perspective. https://news.ycombinator.com/item?id=29868199 https://news.ycombinator.com/item?id=29868199
    - tomrod 5y ago
      Despite the need to keep it clear, copyright does not reign supreme.
      - throw_m239339 5y ago
        > Despite the need to keep it clear, copyright does not reign supreme. neither do NPM TOS, or whatever Microsoft thinks they are entitled to, since NPM is owned by Microsoft.
        tomrod 5y ago
        Which is not what I argued :^)
    - mjlawson 5y ago
      You are technically correct. The best kind of correct! In practical terms, it depends on the license used. Since most licenses used in open source will prevent you from making these kind of requests, this consequence isn't likely to have any practical implications.
- dane-pgp 5y ago
  > If NPM gets a DMCA takedown request they will absolutely have to fulfill it. 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_youtubedl/ https://www.theregister.com/2020/11/16/github_restores_youtu...
  - pc86 5y ago
    > but I would hope that such a poison-pill would be caught long before the package became widely depended on. I'm not sure what about the current open source ecosystem makes you think anyone would catch something like this.
    - zdragnar 5y ago
      Funny, my company couldn't use Webpack 1 because a dependency of a dependency... depended on an ancient package from the days when it was common to not bother with attaching a license. 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.
      - Dylan16807 5y ago
        You couldn't override the package locally? Or was too much of that code actually needed?
  - jonas21 5y ago
- dragonwriter 5y ago
  > If NPM gets a DMCA takedown request they will absolutely have to fulfill it. 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.
wbl 5y ago
Why does a new version break projects without action by the project owners? In Go you would have to explicitly update to the broken version.
- bspammer 5y ago
  Because npm install has the insane default behavior of adding a fuzzy qualifier to your package.json, for example ^6.0.2 means all of the following versions are accepted: 6.0.2, 6.0.9, 6.7.84
  - samhh 5y ago
    That's not an issue, that assists in quickly viewing wanted package upgrades. The problem is in not using a lockfile.
  - K0nserv 5y ago
    It’s not particularly insane. package.json and package-lock.json have different purposes, namely package.json specified intent e.g. I want a version that satisfies >=5.2.3 && < 6.0.0 and package-lock.json records the exact resolved version. 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.
  - jbverschoor 5y ago
    Welcome to JavaScript, where every division is a bad one
- david_allison 5y ago
  *I revoke my comment. Child comment is correct.
  - K0nserv 5y ago
    That's not true. 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`. 0: https://docs.npmjs.com/cli/v6/commands/npm-install https://docs.npmjs.com/cli/v6/commands/npm-install
maxwell86 5y ago
THat's why you specify the exact version of your dependencies.
pc86 5y ago
You're never going to be able to prevent that at a technical level. You can prevent it with workflow, though: 1) sync packages locally and build from those versions; 2) peg to a specific version and don't auto-update; 3) deploy to a test environment and not directly to production.

This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.

throw_m239339 5y ago

> This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything. You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.

dathinab 5y ago
Except if they have reason to believe the code was uploaded with the permission of the copyright holder. The they have gotten the right for npm to distribute the source code in context of npm.
- throw_m239339 5y ago
  > 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.
  - mschuster91 5y ago
    You can't legally retract opening up software source code under most if not all popular open source licenses.
    - josephcsible 5y ago
      It is indeed all, even if you ignore the "popular" qualifier. If a license could be unilaterally revoked, it would fail to meet the Open Source Definition for that reason.
    - throw_m239339 5y ago
      open source =/= free software. That's the first mistake you are making.
      - josephcsible 5y ago
        While they are indeed sightly different, I fail to see how the differences are at all relevant in this context.
      - vurpo 5y ago
        The differences between the two are extremely minimal, basically only relating to patent rights relating to the software. Go read https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html - the FSF's Free Software definition, and https://opensource.org/osd https://opensource.org/osd - the Open Source Definition (both by the respective parties that coined the terms and maintain them to this day) and see what the actual differences are. They're not many.
  - deleted 5y ago
    [deleted]
  - dathinab 5y ago
    First you agreed to ToS when you uploaded things to npm. I haven't read the terms but it should be enough for npm to publish on npm no matter the license. 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.
  - Dylan16807 5y ago
    Your Content belongs to you. You decide whether and how to license it. But at a minimum, you license npm to provide Your Content to users of npm Services when you share Your Content. That special license allows npm to copy, publish, and analyze Your Content, and to share its analyses with others. npm may run computer code in Your Content to analyze it, but npm's special license alone does not give npm the right to run code for its functionality in npm products or services.
mjlawson 5y ago
Not only does it require more steps, it also has to meet the following criteria[1]: * 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. [1] https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish
- throw_m239339 5y ago
  None of these points have any legal standing, from a copyright perspective. https://news.ycombinator.com/item?id=29868199 https://news.ycombinator.com/item?id=29868199
  - tomrod 5y ago
    Despite the need to keep it clear, copyright does not reign supreme.
    - throw_m239339 5y ago
      > Despite the need to keep it clear, copyright does not reign supreme. neither do NPM TOS, or whatever Microsoft thinks they are entitled to, since NPM is owned by Microsoft.
      - tomrod 5y ago
        Which is not what I argued :^)
  - mjlawson 5y ago
    You are technically correct. The best kind of correct! In practical terms, it depends on the license used. Since most licenses used in open source will prevent you from making these kind of requests, this consequence isn't likely to have any practical implications.
dane-pgp 5y ago
> If NPM gets a DMCA takedown request they will absolutely have to fulfill it. 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_youtubedl/ https://www.theregister.com/2020/11/16/github_restores_youtu...
- pc86 5y ago
  > but I would hope that such a poison-pill would be caught long before the package became widely depended on. I'm not sure what about the current open source ecosystem makes you think anyone would catch something like this.
  - zdragnar 5y ago
    Funny, my company couldn't use Webpack 1 because a dependency of a dependency... depended on an ancient package from the days when it was common to not bother with attaching a license. 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.
    - Dylan16807 5y ago
      You couldn't override the package locally? Or was too much of that code actually needed?
- jonas21 5y ago
dragonwriter 5y ago
> If NPM gets a DMCA takedown request they will absolutely have to fulfill it. 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.

wbl 5y ago

Why does a new version break projects without action by the project owners? In Go you would have to explicitly update to the broken version.

bspammer 5y ago
Because npm install has the insane default behavior of adding a fuzzy qualifier to your package.json, for example ^6.0.2 means all of the following versions are accepted: 6.0.2, 6.0.9, 6.7.84
- samhh 5y ago
  That's not an issue, that assists in quickly viewing wanted package upgrades. The problem is in not using a lockfile.
- K0nserv 5y ago
  It’s not particularly insane. package.json and package-lock.json have different purposes, namely package.json specified intent e.g. I want a version that satisfies >=5.2.3 && < 6.0.0 and package-lock.json records the exact resolved version. 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.
- jbverschoor 5y ago
  Welcome to JavaScript, where every division is a bad one
david_allison 5y ago
*I revoke my comment. Child comment is correct.
- K0nserv 5y ago
  That's not true. 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`. 0: https://docs.npmjs.com/cli/v6/commands/npm-install https://docs.npmjs.com/cli/v6/commands/npm-install

maxwell86 5y ago

THat's why you specify the exact version of your dependencies.

pc86 5y ago

You're never going to be able to prevent that at a technical level. You can prevent it with workflow, though: 1) sync packages locally and build from those versions; 2) peg to a specific version and don't auto-update; 3) deploy to a test environment and not directly to production.