3 ms·

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

by 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.
Andaith 5y ago
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.
- nybble41 5y ago
  > 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.

by geoah 5y ago

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.

Andaith 5y ago

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.

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