6 ms·

Poll: Should NPM retain packages against the authors will?

31 points by w4rh4wk5 5y ago

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.

perihelions 5y ago
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.
- deleted 5y ago
  [deleted]
- Kaze404 5y ago
  Saying the end users are entitled to those packages because FOSS is FOSS is also a philosophical reason.
  - perihelions 5y ago
    No: a FOSS license is a concrete and enforceable legal document that entitles the end-users.
    - Kaze404 5y ago
      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?
- democracy 5y ago
  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
  - perihelions 5y ago
    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.
    - zingplex 5y ago
      Perhaps customers would be able to sponsor the review of specific packages.
  - dehrmann 5y ago
    This is sorta what Linux distros do, though it doesn't work as well for Java as something like Python.
- Snetry 5y ago
  Users are entitled to the project as far as the License grants them. 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?
  - michaelmrose 5y ago
    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.
    - Snetry 5y ago
      And then if there is a CVE along the way someone has to go and maintain it and thats exactly what no one wants to do
      - michaelmrose 5y ago
        Seems like they could simply provide a way to notify users and service of something like that without providing the ability to unilaterally yank it.
        Snetry 5y ago
        How are you going to distribute that message? Over NPM? No one is going to read that. At best the community can stand up and fork which means they have to move ownership to some rando
        michaelmrose 5y ago
        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.
- deleted 5y ago
  [deleted]
josephcsible 5y ago
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.
geoah 5y ago
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.
- kbelder 5y ago
  Should the author be forbidden from making breaking changes?
- josephcsible 5y ago
  I think you completely misread the post.
- w4rh4wk5 5y ago
  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.
  - harlanji 5y ago
    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.
deleted 5y ago
[deleted]
88913527 5y ago
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.
- jwalton 5y ago
  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.
geofft 5y ago
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.
- josephcsible 5y ago
  > 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.
jrm4 5y ago
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.
aaron695 5y ago
parkingrift 5y ago
No. Best to be a neutral repository.
democracy 5y ago
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!
- rk06 5y ago
  Allow package deletion within 1 week and 100 download will suffice.
codeptualize 5y ago
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.
ivraatiems 5y ago
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 would be wrong with such an approach?
- hmsimha 5y ago
  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.
diamondyuan 5y ago
https://github.com/cnpm/bug-versions https://github.com/cnpm/bug-versions is another choice
deleted 5y ago
[deleted]

31 points by w4rh4wk5 5y ago

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.

perihelions 5y ago

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.

deleted 5y ago
[deleted]
Kaze404 5y ago
Saying the end users are entitled to those packages because FOSS is FOSS is also a philosophical reason.
- perihelions 5y ago
  No: a FOSS license is a concrete and enforceable legal document that entitles the end-users.
  - Kaze404 5y ago
    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?
democracy 5y ago
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
- perihelions 5y ago
  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.
  - zingplex 5y ago
    Perhaps customers would be able to sponsor the review of specific packages.
- dehrmann 5y ago
  This is sorta what Linux distros do, though it doesn't work as well for Java as something like Python.
Snetry 5y ago
Users are entitled to the project as far as the License grants them. 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?
- michaelmrose 5y ago
  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.
  - Snetry 5y ago
    And then if there is a CVE along the way someone has to go and maintain it and thats exactly what no one wants to do
    - michaelmrose 5y ago
      Seems like they could simply provide a way to notify users and service of something like that without providing the ability to unilaterally yank it.
      - Snetry 5y ago
        How are you going to distribute that message? Over NPM? No one is going to read that. At best the community can stand up and fork which means they have to move ownership to some rando
        michaelmrose 5y ago
        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.
deleted 5y ago
[deleted]

josephcsible 5y ago

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.

geoah 5y ago

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.

kbelder 5y ago
Should the author be forbidden from making breaking changes?
josephcsible 5y ago
I think you completely misread the post.
w4rh4wk5 5y ago
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.
- harlanji 5y ago
  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.

deleted 5y ago

[deleted]

88913527 5y ago

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.

jwalton 5y ago
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.

geofft 5y ago

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.

josephcsible 5y ago
> 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.

jrm4 5y ago

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.

aaron695 5y ago

parkingrift 5y ago

No. Best to be a neutral repository.

democracy 5y ago

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!

rk06 5y ago
Allow package deletion within 1 week and 100 download will suffice.

codeptualize 5y ago

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.

ivraatiems 5y ago

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 would be wrong with such an approach?

hmsimha 5y ago
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.

diamondyuan 5y ago

https://github.com/cnpm/bug-versions https://github.com/cnpm/bug-versions is another choice

deleted 5y ago

[deleted]