|
|
|
|
|
by dcbadacd
2520 days ago
|
|
You started the thread by saying that if you used a library that is broken by the maintainer you would call that malice. Things being broken is directly related to bugs and maintenance - detecting if and how a breakage is malice is the first problem in your arguments. I'm also trying to tell you that your whole base premise is wrong, that even expecting some library to work or to keep working is too much (unless you apply one of the solutions I offered). Calling certain behaviors stupid absolutely has a place in a discussion about when people play with fire and then are surprised they get burnt, I think you deliberately missed my point that if you put yourself in danger you only have yourself to blame and most laws do care about that nuance. In the end the job and obligation of keeping the software you write secure is just as much on the person writing some libraries. We can argue if x or y are effective defense in courts or not but as I said, that hasn't been tried out in the case of open-source software being broken. I also have to repeat that when you look at malicious software and changes in practice then the law applies retroactively and you have to deal with preemptive defense yourself - going back to my first point(s), you have to change the way you develop software instead of hoping what you randomly execute is good. Hopefully you now understand what I'm trying to say to you better, English isn't my first language, sorry. |
|
In this specific case, the code was written such that it deliberately broke installation for users. I consider that malicious. The “deliberately” is the important word here.
People make mistakes. Nobody wants this to happen, but my colleagues and I have sometimes pushed a bad deploy that broke our product, and we rushed to revert to a known good state.
That’s not malice, that’s (temporary) incompetence.
But if we deliberately broke something for our users, I would consider that malice.