7 ms·

It's still his project. He could have deleted it for all I care, it's his every right. I wonder if GitHub/NPM even have the legal rights to modify the code you

It's still his project. He could have deleted it for all I care, it's his every right. I wonder if GitHub/NPM even have the legal rights to modify the code you publish, depending on your license.

saghm 5y ago
I mean, for almost every mainstream open source license, the answer to that is a pretty definitive "yes, they can", right? The most stringent of them require things like attribution and open source the modifications, neither of which seem like requirements that Github/NPM would have any qualms with following.
- xvector 5y ago
  But does GitHub/NPM have the right to modify his code and publish it under his account/his name? I doubt that is legal.
  - jffry 5y ago
    The MIT license doesn't require NPM to list marak as the publisher of the NPM package, as long as they still obey the license's requirements. Besides, the NPM Terms of Service are almost certainly broad enough to permit NPM to publish a modified version of a package or to delete a package.
naikrovek 5y ago
is it his right? to sabotage downstream code in revenge for not being paid for work he willingly took on knowing full well that he may never be paid? legality is defined at the behest of societal needs. if society says something legal should be made illegal, or vice versa, then it will be. GitHub/Microsoft chose to do the right thing for the society in the short term. in the long term, choosing a less stupid library update policy will benefit everyone AND let authors do all the "non-harmful" malevolent stuff they want. as if this wasn't a single-point denial of service attack... we are slowly (far too slowly) learning that our assumptions that all developers are benevolent is incorrect, and it's going to take another 2-5 instances of this kind of attack before people really start to understand why and see the danger of simply using libraries at all; especially in ecosystems like NPM where almost no one writes a single line of code on their own if it can instead be pulled in as a library dependency. this attitude is the exact opposite of a secure code approach and until people learn this, and learn it well, this kind of attack will continue, and the time between the attacks will gradually shorten.
- xvector 5y ago
  Should your users have control over the code you publish under your name? Because that is the precedent we are setting here.
  - fault1 5y ago
    Did he own this code? Colors.js had plenty of other contributors, and there was no CLA involved. github user "DABH" actually had more lines of code than marak did: https://github.com/Marak/colors.js/graphs/contributors https://github.com/Marak/colors.js/graphs/contributors npm and github both have terms of service that you agree to when you choose to distribute something over those systems. npm in particular has had a long policy of unrolling malicious changes to the registry of packages ever since left-pad.
    - yifanl 5y ago
      If the responsibility lies with the maintainer, then the responsibility lies with the maintainer.
- heavyset_go 5y ago
  > to sabotage downstream code in revenge for not being paid for work he willingly took on knowing full well that he may never be paid? Some consumers of his project chose to use his 3rd party dependency in their code for free knowing full well that it could disappear or break at any time, and yet they still chose not to mitigate those risks they chose to take on.
  - naikrovek 5y ago
    yes, that is the other half of the coin: don't run code if you don't know what it does. an extreme version of that: don't use libraries at all. I am trending more and more to this extreme as I age, because people aren't learning their lesson, and the npm ecosystem keeps biting them over and over...
- chaostheory 5y ago
lolinder 5y ago
Deleting it would have been less offensive because deleting it would simply have caused his code to stop executing on other people's machines altogether. What he did instead was execute malicious code (albeit a relatively benign malice) on the computers of people who previously trusted him. Deleting the package is within his rights. Modifying the package to be abusive may technically (legally) be within his rights but is certainly not ethical, and I'm not even convinced that it was legal. Had he modified the package to install a Bitcoin miner instead of just breaking apps, I suspect he'd be breaking the law, and it's not obvious to me that a DOS attack should be treated differently.
- xvector 5y ago
  > Modifying the package to be abusive may technically (legally) be within his rights but is certainly not ethical Of course it's not ethical. But, publishing whatever code he wants under his name, under his projects, is well within his rights. We are setting the precedent that users can modify the code you've published under your own name, if they don't like what you've done with it. That is not acceptable. My users should not have hegemony over my project. They can decide to fork, they can decide not to use it. But under no circumstances should they be able to edit my project under my name. Because that's also unethical. > I'm not even convinced that it was legal. Had he modified the package to install a Bitcoin miner instead of just breaking apps, I suspect he'd be breaking the law. I really doubt this. People are choosing to run his code, and choosing to update to whatever new code he publishes, regardless of the contents. It's not like he's forcefully installing his code on anyone's machine. By enabling automatic updates of his package, developers have implicitly granted him permission to run whatever he would like on their machine. Unethical, sure. But perfectly legal.
  - lolinder 5y ago
    > We are setting the precedent that users can modify the code you've published under your own name, if they don't like what you've done with it. Not users of your code, platforms you distribute on, and that precedent has been rolling forward for a while now, it's not new. Even so, I don't approve of GitHub's ban, but that doesn't mean I have to endorse the author. > People are choosing to run his code, and choosing to update to whatever new code he publishes, regardless of the contents. This line of reasoning would suggest that the authors of malware that requires affirmative action to start running (download an exe, open a PDF, whatever) are clean and clear legally because the victim chose to run their code. How is this any different than a malicious EXE sitting on a server somewhere waiting to be downloaded? It can't just be that the victims in this case ought to have known better, because the victims in most cases of malware ought to have known better.
spankalee 5y ago
Why are you bringing up modifying his code? I haven't seen any indication that anyone did that. Changing the metadata around a npm-stored package is something that npm should have every right to do. Same for changing the metadata about a GitHub project. Neither the npm registry entry nor the GitHub project settings are the copyrighted code.
Too 5y ago
It’s not just a random personal repo on GitHub. It has a long documentation published on NPM describing the intention of the module. It is advertised as being something it now clearly and deliberately is not. Some would even call it a genuine fraud. Doesn’t matter if you paid for it or not, there are plenty of free services in meatspace that can be compared. Free quote of bathroom renovation - plumber changes all your locks when you look away while doing the inspection. Now should consumers be more careful about situations like this, yes. Can this guy expect to claim any rights after a move like this, no.
ratg13 5y ago
And all of the contributors to his code? What if he had done nothing more than create the repo and the community did all of the legwork? Is it still his right to delete all of their work?
- xvector 5y ago
  Yes, it's his repo after all. If I let you grow flowers in my garden, it's still my right to burn it all down. Otherwise, a multi-owner org should be used, or we need new concepts (like changes to repositories signed by multiple contributors.)
  - fault1 5y ago
    But with contributors, it's literally not his to "own", in terms of the actual work. Copyright law says roughly that you own the characters you type, unless you assign it to someone else. The guy who actually wrote more of colors.js (by lines of code) than marak actually got npm to nuke the offending releases: https://github.com/Marak/colors.js/issues/317 https://github.com/Marak/colors.js/issues/317 right now they are reviewing a request to change the npm target to his repo
    - prmoustache 5y ago
      To write and merge code to Marak's version DABH has its own copy so your question makes no sense. Marak could decide to make his repo disappear it doesn't make the local or hosted repos of other contributors disappear. It seems that github managed to distort your mind into thinking that git was no longer a decentralized cvs.
      - fault1 5y ago
        I don't get your point. The repo, gh/npm accounts and such are just metadata and metadata of metadata, which is hosted and distributed based on the terms of service of gh/npm. The thing that matters most is what the npm project points to, since it is relied on by other packages and apps. The only thing this guy "owns", according to the law, is the copyright for the part of the codebase he wrote. Not that it matters much since it is MIT licensed.

It's still his project. He could have deleted it for all I care, it's his every right. I wonder if GitHub/NPM even have the legal rights to modify the code you publish, depending on your license.

saghm 5y ago

I mean, for almost every mainstream open source license, the answer to that is a pretty definitive "yes, they can", right? The most stringent of them require things like attribution and open source the modifications, neither of which seem like requirements that Github/NPM would have any qualms with following.

xvector 5y ago
But does GitHub/NPM have the right to modify his code and publish it under his account/his name? I doubt that is legal.
- jffry 5y ago
  The MIT license doesn't require NPM to list marak as the publisher of the NPM package, as long as they still obey the license's requirements. Besides, the NPM Terms of Service are almost certainly broad enough to permit NPM to publish a modified version of a package or to delete a package.

naikrovek 5y ago

is it his right? to sabotage downstream code in revenge for not being paid for work he willingly took on knowing full well that he may never be paid? legality is defined at the behest of societal needs. if society says something legal should be made illegal, or vice versa, then it will be. GitHub/Microsoft chose to do the right thing for the society in the short term. in the long term, choosing a less stupid library update policy will benefit everyone AND let authors do all the "non-harmful" malevolent stuff they want. as if this wasn't a single-point denial of service attack... we are slowly (far too slowly) learning that our assumptions that all developers are benevolent is incorrect, and it's going to take another 2-5 instances of this kind of attack before people really start to understand why and see the danger of simply using libraries at all; especially in ecosystems like NPM where almost no one writes a single line of code on their own if it can instead be pulled in as a library dependency. this attitude is the exact opposite of a secure code approach and until people learn this, and learn it well, this kind of attack will continue, and the time between the attacks will gradually shorten.

xvector 5y ago
Should your users have control over the code you publish under your name? Because that is the precedent we are setting here.
- fault1 5y ago
  Did he own this code? Colors.js had plenty of other contributors, and there was no CLA involved. github user "DABH" actually had more lines of code than marak did: https://github.com/Marak/colors.js/graphs/contributors https://github.com/Marak/colors.js/graphs/contributors npm and github both have terms of service that you agree to when you choose to distribute something over those systems. npm in particular has had a long policy of unrolling malicious changes to the registry of packages ever since left-pad.
  - yifanl 5y ago
    If the responsibility lies with the maintainer, then the responsibility lies with the maintainer.
heavyset_go 5y ago
> to sabotage downstream code in revenge for not being paid for work he willingly took on knowing full well that he may never be paid? Some consumers of his project chose to use his 3rd party dependency in their code for free knowing full well that it could disappear or break at any time, and yet they still chose not to mitigate those risks they chose to take on.
- naikrovek 5y ago
  yes, that is the other half of the coin: don't run code if you don't know what it does. an extreme version of that: don't use libraries at all. I am trending more and more to this extreme as I age, because people aren't learning their lesson, and the npm ecosystem keeps biting them over and over...
chaostheory 5y ago

lolinder 5y ago

Deleting it would have been less offensive because deleting it would simply have caused his code to stop executing on other people's machines altogether. What he did instead was execute malicious code (albeit a relatively benign malice) on the computers of people who previously trusted him. Deleting the package is within his rights. Modifying the package to be abusive may technically (legally) be within his rights but is certainly not ethical, and I'm not even convinced that it was legal. Had he modified the package to install a Bitcoin miner instead of just breaking apps, I suspect he'd be breaking the law, and it's not obvious to me that a DOS attack should be treated differently.

xvector 5y ago
> Modifying the package to be abusive may technically (legally) be within his rights but is certainly not ethical Of course it's not ethical. But, publishing whatever code he wants under his name, under his projects, is well within his rights. We are setting the precedent that users can modify the code you've published under your own name, if they don't like what you've done with it. That is not acceptable. My users should not have hegemony over my project. They can decide to fork, they can decide not to use it. But under no circumstances should they be able to edit my project under my name. Because that's also unethical. > I'm not even convinced that it was legal. Had he modified the package to install a Bitcoin miner instead of just breaking apps, I suspect he'd be breaking the law. I really doubt this. People are choosing to run his code, and choosing to update to whatever new code he publishes, regardless of the contents. It's not like he's forcefully installing his code on anyone's machine. By enabling automatic updates of his package, developers have implicitly granted him permission to run whatever he would like on their machine. Unethical, sure. But perfectly legal.
- lolinder 5y ago
  > We are setting the precedent that users can modify the code you've published under your own name, if they don't like what you've done with it. Not users of your code, platforms you distribute on, and that precedent has been rolling forward for a while now, it's not new. Even so, I don't approve of GitHub's ban, but that doesn't mean I have to endorse the author. > People are choosing to run his code, and choosing to update to whatever new code he publishes, regardless of the contents. This line of reasoning would suggest that the authors of malware that requires affirmative action to start running (download an exe, open a PDF, whatever) are clean and clear legally because the victim chose to run their code. How is this any different than a malicious EXE sitting on a server somewhere waiting to be downloaded? It can't just be that the victims in this case ought to have known better, because the victims in most cases of malware ought to have known better.

spankalee 5y ago

Why are you bringing up modifying his code? I haven't seen any indication that anyone did that. Changing the metadata around a npm-stored package is something that npm should have every right to do. Same for changing the metadata about a GitHub project. Neither the npm registry entry nor the GitHub project settings are the copyrighted code.

Too 5y ago

It’s not just a random personal repo on GitHub. It has a long documentation published on NPM describing the intention of the module. It is advertised as being something it now clearly and deliberately is not. Some would even call it a genuine fraud. Doesn’t matter if you paid for it or not, there are plenty of free services in meatspace that can be compared. Free quote of bathroom renovation - plumber changes all your locks when you look away while doing the inspection. Now should consumers be more careful about situations like this, yes. Can this guy expect to claim any rights after a move like this, no.

ratg13 5y ago

And all of the contributors to his code? What if he had done nothing more than create the repo and the community did all of the legwork? Is it still his right to delete all of their work?

xvector 5y ago
Yes, it's his repo after all. If I let you grow flowers in my garden, it's still my right to burn it all down. Otherwise, a multi-owner org should be used, or we need new concepts (like changes to repositories signed by multiple contributors.)
- fault1 5y ago
  But with contributors, it's literally not his to "own", in terms of the actual work. Copyright law says roughly that you own the characters you type, unless you assign it to someone else. The guy who actually wrote more of colors.js (by lines of code) than marak actually got npm to nuke the offending releases: https://github.com/Marak/colors.js/issues/317 https://github.com/Marak/colors.js/issues/317 right now they are reviewing a request to change the npm target to his repo
  - prmoustache 5y ago
    To write and merge code to Marak's version DABH has its own copy so your question makes no sense. Marak could decide to make his repo disappear it doesn't make the local or hosted repos of other contributors disappear. It seems that github managed to distort your mind into thinking that git was no longer a decentralized cvs.
    - fault1 5y ago
      I don't get your point. The repo, gh/npm accounts and such are just metadata and metadata of metadata, which is hosted and distributed based on the terms of service of gh/npm. The thing that matters most is what the npm project points to, since it is relied on by other packages and apps. The only thing this guy "owns", according to the law, is the copyright for the part of the codebase he wrote. Not that it matters much since it is MIT licensed.