921–930 of 1001 posts
Obviously he has this right to do what he wants and he did. But the consequences are that his reputation is in tatters. Probably doesn't bother him but equally the repos will be forked and utilization continues of the predecessor. Might not be a maintainer mind you so the dependent repos will quickly find alternates.
This is called activism, his reputation is growing.
Earlier quoted context omitted.
I don't think he pushed malware, did he? He just broke his own project and published the broken version. That's not pushing malware. I don't get why people don't just pin versions, honestly. I'm not saying he did a good thing. But neither did he push malware nor has he any obligation to publish unbroken packages. If you're using FOSS projects without a service contract, don't whine if something breaks.
"Not pushing malware", _wink wink_. Let's say I set up a lemonade stand in my neighborhood every weekend, where I pour a bunch of cups for people to take, put up a sign that says it's free, and I set out a tip jar. After a few weeks, I get upset that people have been taking the lemonade without leaving tips, so the next time I set up the stand I add a toxin that I know will cause immediate damage to anyone who ingest…
While I disagree with his move. 1.It is totally in his prerogative to mess up the package he manages, but not to install into it malware. I am on the fence if this would count as malware. (Because of the open loop, but my leaning is that this is not malware.) 2. Github is, IMO, breaking any trust that I might have had by assuming control of the package, removing the last commit and keeping it online. If they feel the…
I pretty much agree with you especially on the point that there are far more effective and nuanced ways to for the maintainer to have made their point, like relicensing (imagine what would happen if the license suddenly became AGPL and everyone at big corps automatically updated without checking the new license—it would be a raucous for both legal and engineering, author could offer a non-gpl version for money and pr…
For these particular packages? Very unlikely.
Earlier quoted context omitted.
> 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 withou…
The developer can DCMA claiming the code doesn’t follow his license as famously happened with Bukkit (the Minecraft server tool).
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...
Earlier quoted context omitted.
I haven't actually checked if the README or description of the package was updated to reflect the new (malicious) behaviour of the code, but even if it was, I think that knowingly exploiting people's trust to stop their software working should be treated as evidence of hacking. It's like if you went to work one day with a spray can hidden in your jacket and started graffitiing the office walls, but justified your act…
> I think that knowingly exploiting people's trust to stop their software working should be treated as evidence of hacking How so? The license that you accept each time you install or update the library explicitly states: "IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY [...]" Use of automation software (npm, yarn) to auto-magically fetch newer versions of your d…
A license isn't a "get out of jail free" card. If he had put in the license "the authors shall not be liable for murdering you" that would not count as a defence in court.
> doesn't absolve you of respecting the terms of the license.
You don't have to respect any term that isn't legally valid. If you sent someone an email attachment pretending to be spreadsheet, but it actually contained a destructive virus, with an accompanying licence saying "by running this code you agree to accept all the damage done to your computer", that licence would be legally void.
> It's like your boss called you into the office (i.e. explicit software update), gave you a signed waiver that said you couldn't be held liable for anything that you did to the building (i.e. LICENSE)
In this case the person granting the licence is also the one doing the damage, so it's like your boss calling you into his office and informing you that he was going to punch you in the face and that you couldn't sue him. Even if you signed an employment contract which said he could do that, it wouldn't override legislation which criminalises assault. (None of this is legal advice, and there are probably exceptions to all these rules).
> professional software developers and end users should be held to a different standard.
I don't know of any situation where a judge decided that a crime didn't happen because the victim was smart enough that they could have avoided being victimised. It's like saying "well if you didn't want the murderer to break your window and sneak into your house at night and kill your family, then you should have known that was a risk and put bars on the windows". It doesn't matter if someone is a home security expert, or a millionaire, or had any other advantage, it is still a crime to take advantage of someone's less-than-perfect security and murder people.
The whole point of having laws is that we can't put in place guarantees that crimes won't happen, and it makes more sense for society to put in place after-the-fact punishments to provide disincentives against people doing socially negative things. It doesn't matter if you could have prevented someone from harming you, you are still allowed to rely on the legal system to punish the person who causes that harm.
Obviously this is all predicated on whether a DoS attack really does meet the legal definition of "malicious" software, and I don't want to pre-empt what a jury would decide in this specific case, if it ever went to trial, but I think that there is enough evidence of intent and harm here to at least investigate it, and I don't see how a software licence can be used as a defence, any more than the "by accepting this brick through your window" defence, which was jokingly invented during the infamous Sony rootkit incident:
http://www.robhyndman.com/2005/11/22/by-accepting-this-brick...
Earlier quoted context omitted.
> Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and there is a strong temptation to just give everything all permissions. A lot of that stems from permissions systems being implemented outside of the code they constrain. In theory a compiler knows every reachable system call and all points of data input that c…
> In theory a compiler knows every reachable system call and all points of data input that could reach them Sorta yes, sorta no. Imagine I'm making a chat client, and I want users to be able to drag and drop images to share. But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too. Or if I'm making a web browser and I w…
Further, you can restrict a process to only open specific files in a number of ways on Linux, including based on path. There's room for improvement, though.
Earlier quoted context omitted.
> it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. There is nothing inherent in using packages that means you have to blindly trust the code, neither does providing a package mean you have to accept any more responsibility over providing a .php file (packages are just .php files with a few metadata…
> There is nothing inherent in using packages that means you have to blindly trust the code I use about a dozen different package managers and I have no idea how to check the code they download before they install/deploy it. I often check the source on Github if I need to look something up, but I have no idea how I'd go about verifying that the code on Github is the same as whatever the package managers install.
Earlier quoted context omitted.
This wasn't AWS CDK, it was a package to fake data and a package with some ANSI escape sequence constants. The comparison doesn't make sense. The problem is that developers apparently can't even differentiate between when you should use a library and when you shouldn't; they just pull in the first result from an NPM search. You can probably trust AWS, which is good because CDK is complicated. You can't necessarily tr…
It wasn't a comparison. As the article states, AWS CDK depends on colors, if I want to use AWS CDK, I have to use colors too. I don't get the choice to re-implement that myself unless I want to stop using the official CDK library
Should I get paid for my multiple contributions to faker (I don't think I should)? I've submitted several PR's for generating data all of which were accepted. Even back then the maintainer was barking about money... Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why…
> at this point I just see him as holding other committers contributions as hostage No he's not, and you're just trying to be outraged. Just fork the code if you don't trust him. Oh, but you don't want to take his place as the maintainer? Maybe deep down you know that there's still a difference between being in charge and submitting the occasional pull request? Your actions contradict your words here.
A maintainer role could be to just accept some occasional pull request if he don't want to make it a bigger project.
But conversely, if people are benefitting from something you've created then it's only fair for the person who created this value to get some financial compensation commensurate to the value they've created.
The author of this package has chosen a method to get some compensation for their work that has resulted in a lose-lose situation where neither the author nor the users are happy.
But it doesn't have to be this way.
The [Opensource guide][2] has some useful tips on [Getting Paid for Open Source Work][3]. For people interested in web3 and crypto, [Gitcoin][4] is platform where you can [get paid to work on open source software][5].
Hopefully, by becoming more informed on ways to make money from open source software we can avoid situations like this in the future and create a fairer system that works for everyone.
[1]: https://en.wikipedia.org/wiki/Public_good_(economics)
[2]: https://opensource.guide/
[3]: https://opensource.guide/getting-paid/
[4]: https://gitcoin.co/