I was seeing a lot of news about the colors.js library. I would like to know if the open source license entitles the developer of the colors.js library to make it dysfunctional and create the damage to the community (as we all have seen).
Asked
Active
Viewed 9,093 times
35
10 Answers
83
Open source licenses apply to other people. They do not apply to the author and copyright owner of the project. The author/owner can always do whatever they want. Software licenses can't prohibit the authors from making large changes to software, nor can they determine whether a change is 'good' or not.
curiousdannii
- 7,768
- 1
- 27
- 51
-
52And it is important to note that none of this has anything to do with Open Source. It is perfectly possible, and indeed has happened numerous times, that vendors deliberately break functionality in new releases of proprietary software. – Jörg W Mittag Jan 26 '22 at 10:53
-
33
-
22In fact, my employer did just that: in early versions, we were selling licenses for specific features, but we were not actually checking them. So, a customer could technically configure a feature they didn't pay for. A couple of years later, we implemented license checking in an update, and it broke pretty much every customer system we had ever sold, because pretty much all our customers had started using unlicensed features. In the end, it was such a mess that we decided to give every legacy customer free licenses for every feature. – Jörg W Mittag Jan 26 '22 at 10:56
-
2All licenses apply to other people; that's not relevant for the case. What's important is that free software licenses often come with a sentence "... provided as-is without a claim to fit any particular purpose". Some jurisdictions probably forbid such clauses for commercial sales, and then the author has an obligation. – Peter - Reinstate Monica Jan 26 '22 at 12:23
-
12@Peter-ReinstateMonica Even commercial licenses include things like that -- for example, the "Limited Warranty" section of Microsoft's Visual Studio 2022 Enterprise license: "Microsoft excludes all implied warranties and conditions, including those of merchantability, fitness for a particular purpose, and non-infringement." – Herohtar Jan 26 '22 at 20:38
-
The author/copyright holder may even change the license of a project when releasing a new version - including to a non-open or even proprietary/commercial license. It won't affect older version or forks from earlier versions, but newer version will be. Of course, if the project uses for example GPL libraries or uses code contributed by others under an open source license, the author/holder may not be allowed to change to a more restrictive license. – Baard Kopperud Jan 27 '22 at 04:12
-
It might still be against the ToS of the registry (.e.g npmjs.org) to upload malware. So its not a license issue, but a ToS issue. – Polygnome Jan 27 '22 at 10:52
-
@Peter-ReinstateMonica This obligation is mandated by law and still have nothing to do with license. – Oleg V. Volkov Jan 28 '22 at 10:17
-
@OlegV.Volkov Well, yes and no. It is mandated by law; but the law dictates the contents of the license (especially that all "no warranty whatsoever" clauses nominally part of the license are factually void). – Peter - Reinstate Monica Jan 28 '22 at 10:30
41
The simple answer is "yes", if nothing else because there is no judge of what is "dysfunctional" and what is "removing legacy features".
However, I'd argue you're thinking about this the wrong way: the damage was caused by people downloading and using code without verifying that it was fit for purpose.
Philip Kendall
- 19,156
- 1
- 57
- 82
-
1Do you know of any such cases? It was not that straughtforward to get your production affected by this. The real damage is that the developer intentionally broke it being "fit for purpose" in a minor version bump thus causing a lot of people to spend time looking into this and causing headache and confusion about having to lock the exact version and stop updating it. It was a serious violation of trust for sure. – Džuris Jan 27 '22 at 05:04
-
@Džuris The answer is a general one; the specific details of exactly what happened with colors.js are not really that interesting. – Philip Kendall Jan 27 '22 at 11:16
-
1@Džuris Nothing in any open-source license says that https://github.com/yourname/yourlibrary has to contain useful code – user253751 Jan 27 '22 at 14:11
-
It doesn't even have anything to do with dysfunctional code or removing legacy features. What sort of code an author is allowed to publish has nothing to do with open source licences, or any licenses for that matter. They're only about what others can do with the code. If there was some prohibition on distributing "broken" code (with whatever definition), it would have to be elsewhere. – ilkkachu Feb 02 '22 at 15:03
24
There are really two separate issues here:
- Is the developer allowed to sabotage their own code? - Yes, because it's their own code. The license has nothing to do with this, because the license does not bind the copyright holder in the first place (and typical open source licenses don't have a "don't release broken code" clause anyway).
- Can the developer be held liable for sabotaging their own code? - Maybe, depending on jurisdiction.
In the US, and some other common law jurisdictions, the warranty disclaimer at the end of a typical open source license completely eliminates liability for damages arising from broken code. This is the case even if the developer "has been advised of the possibility" of such damages - which to my non-lawyer mind rather strongly implies that arguments of the form "[developer] knew that their changes were going to break things, and made those changes anyway" are invalid.
However, in many other jurisdictions, the implied warranty cannot be disclaimed, and the developer can in theory be held liable for damages arising from their intentionally defective software. The practicality of doing this is going to vary quite a lot, however, because the plaintiff needs to show that the code caused some actual monetary harm. On the other hand, depending on jurisdiction and relevant law, the defendant may or may not be allowed to argue that the plaintiff was negligent in using the defendant's software without independently auditing it, which may reduce or eliminate the defendant's liability. There is also the more practical issue that the defendant may be judgment proof.
Kevin
- 5,307
- 1
- 17
- 23
-
4In this case the code introduced seems to be deliberately malicious, IANAL but that seems to me to bring it under various laaws against malicious code. – Jack Aidley Jan 26 '22 at 08:40
-
What if the secondary user did audit it, and it did work, prior to being updated with deliberately malicious code? I'm still guessing that the secondary user is not entitled to damages, as there is no relationship (contract). I mean, imagine a refund (snort)? Now, what if secondary has donated money to the author, because of using their work? – user3082 Jan 26 '22 at 09:47
-
4@user3082 You audit code and not a name. Meaning you audit library XYZ in version A.B.C. Anything else makes no sense, because it doesn't give you any security. For certain security sensitive projects we freeze dependencies and have to analyze all updates that change the dependencies very carefully. – Voo Jan 26 '22 at 10:26
-
While there are jurisdictions where implied product liability cannot be disclaimed, we are not talking about a salable product—we are talking about private speech. I can think of no jurisdiction that would consider an author who releases copyright only in the case the recipient agrees there is no merchantability or fitness—i.e., that they agree it is not a "product" at all—liable for damages, as that would violate the very terms under which copyright was released in the first place. – Geoff Nixon Jan 26 '22 at 14:54
-
-
-1. I have to side with @GeoffNixon . The open software is released AS-IS. Even for "products" such as consumer electronics, being sold "as-is" exempts the seller from any liability. I doubt FOSS licenses have this achilles heel as you suggested. – Mindwin Remember Monica Jan 26 '22 at 18:50
-
5@Mindwin: There's no such thing as "as-is" in some jurisdictions. That's literally the whole point of my answer. If you don't like that, write your legislator. Don't complain to me, I can't change it! – Kevin Jan 26 '22 at 20:25
-
Nothing is being sold here. The laws regarding sales terms and conditions likely do not apply here at all. There is also no consideration, thus no contract, so contract law likely does not apply either. – Chuu Jan 27 '22 at 14:55
-
-
Can't be serious damages because the damage done was so great that the most basic testing would reveal the code was unfit to use; that is an application using it would not pass a smoke test of any feature that tried to use it. – Joshua Jan 28 '22 at 02:42
20
colors.js is distributed under the MIT License. According to this license (emphasis mine):
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
the disclaimer is amost exactly the same in the GPL License:
THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Eric Duminil
- 301
- 1
- 4
-
5I think that's the relevant fact. Whether all jurisdictions consider such a blanket statement valid is an issue though. And it's probably relevant that the software is free: If you sell something you have most likely more responsibility you can't waive in this manner. – Peter - Reinstate Monica Jan 26 '22 at 12:26
-
1For comparison, some public-domain software (and some under other licenses) simply says "if it breaks, you get to keep both pieces", which is a cheeky way of saying the same thing, intentionally not using legalese. – Peter Cordes Jan 28 '22 at 04:10
7
It could very well depend on which kind of "corruption".
I can write a library, and then "corrupt" it in a way that makes it obviously unusable. If you downloaded my corrupted library instead of the previous version, and tried to use it, you would notice immediately that it is broken. You are in the same state as if you never had downloaded my library in the first place. That kind of change is quite low risk for the developer.
I can write a library, and then "corrupt" it in a way that makes it less obviously unusable. For example, any function that could produce an error in the wrong circumstances will produce an error. You can build your own product with my library, but as soon as you start testing, you will notice that it fails. That is still low risk for the developer.
I can write a library, and then "corrupt" it in a way that makes it slightly buggy. For example, any function that could produce an error in the wrong circumstances will produce an error on every thousandth call. You can build your own product with my library. It will go through your testing (quite likely). But customers will start complaining to you because sometimes your application doesn't work. If that is done intentionally, I might be in legal trouble. I don't know that any disclaimer would necessarily protect me against intentionally causing damage.
I can write a library, and then "corrupt" it in a way that serves criminal purposes. For example, you use my library in a banking application, but the new version sends any credit card number that the user enters to my email address. That is most likely totally illegal, but not because of any license terms, but because it's just illegal to do independent of open / closed source.
gnasher729
- 1,265
- 6
- 7
-
1Is there any difference if the code was used in a way that the changes affect the public (i.e. airline flight code, mass transit code, etc) ... now what you do has a potential to affect the actual lives of a not-insignificant number of people. – CGCampbell Jan 26 '22 at 13:03
-
3@CGCampbell, for safety-critical applications, the person/company "selling" the software must prove for each and every version that the product is safe and they must accept liability for any residual risk that remains in the product. The certifying agencies simply don't accept a warranty disclaimer. (Disclaimer: I work on safety-related devices). – Bart van Ingen Schenau Jan 26 '22 at 14:17
-
-
Does changing the API count as "corruption". If so, pretty much any major product that's lasted through a few generations will fail the test unless if it tries very hard to be backwards compatible. – doneal24 Jan 31 '22 at 18:51
6
A license is something that a content creator, who creates a work, can use, to specify how other people are allowed to use that work.
So it usually has nothing to do with whether that work is good or bad, works or doesn't for some specific purpose, or anything else about its actual or intended purpose.
It is purely about what others are allowed to do, or not do, with it.
So it isn't that the license makes the creator entitled to do anything. Its more that the license literally is not about what the creator can do, in the first place.
Stilez
- 325
- 1
- 3
4
Most of the answers describe the legal angle well: most (but not all) open source licenses have an explicit no warranty cause.
From the development perspective:
If a given library is critical to you, you should vet a new version before accepting it.
Once you vetted the version and realized that it's deliberately broken for your use-case, there is nothing stopping you from fixing the issues or reverting to an earlier release.
You might even develop and distribute your own version. This last part is an important one. While the original developer can remove an old feature, you can decide to maintain it and possibly develop your fork in a different direction.
dragonfi
- 41
- 1
1
To untangle the legal consequences, it is important to understand and each new version of a Open Source library is a release that is legally independent of any previous or future versions of itself. (Unless its licence says otherwise. I have never seen such a licence)
First an author releases some versions of some software and it is good. These releases remain. When using github, they will be available as long as the repository is not deleted. And even if it is deleted from github, you can get a copy from anybody who has one.
Now, the author has released a new version. This version is deliberately broken.
Some people, who trusted that author, will let their automatic package system update the library and now their whole system is broken. Very funny. Hah hah.
To fix all this, all it takes is for everybody to go back to the previous version. The licence of that version is not changed. The functionality is not changed. In the grand scheme of things, this was a minor annoyance.
And now we know not to trust that author.
Stig Hemmer
- 211
- 1
- 4
-
1"each new version [...] is legally independent of any previous or future versions" -- well, except that if there's multiple authors, the new versions are probably derivative works of the earlier ones, which would influence how they can be distributed. That is to say, if you include my code to your GPLv2 library, and I've only given permission to distribute under GPLv2, then you can't distribute a new version with my code under GPLv3. – ilkkachu Feb 02 '22 at 15:07
1
Do Open Source Licenses allow authors to corrupt their own code?
That's pretty much asking if F/OSS licenses allow an author to create some code, distribute it, then later decide to stop distributing it, possibly replacing it with some new code.
If that's allowed should be obvious, but it has nothing to do with licenses. More with the fact that in most parts of the world, anyone is allowed to do programming, and to distribute their own creations, or not to. Programming isn't an occupation that requires a particular training or certifications that would carry some requirements on what you can do (like doctoring or lawyering might be).
Licenses only have to do with what rights the author gives others. What you can do with a work created by someone else is limited by copyright statutes, and they basically say that you can't (re)distribute a work without permission. The open source and copyleft licenses give that permission.
In a case like colors.js, there's the additional question of Github killing the author's account and restoring the old version of the code. That's also more about Github usage terms than the license. The old version was distributed under a free license, so Github (or anyone else) has permission to distribute it under those terms, even if the original author doesn't like to distribute it any longer. (If they can just kill someone's account because they don't like what they did is a different matter.)
Of course, one could also try to pin a liability for any resulting damages on the library author, but that might a bit hard to do. After all, no user of the library is required to automatically pull new versions of it without verifying their operation. Doing just that seems rather negligent. Add on the fact that there was no contract between the library author and the user, no compensation, and (as other answers have noted) free and open source licenses usually disclaim any warranty anyway.
ilkkachu
- 168
- 6
0
Opensource projects (in particular GPLv3+ licensed ones, like RefPerSys or GCC) have no warranty, and might not even have any well defined purposes. Even GCC is so large a project that its purpose is not evidently defined: it is a collection of compilers. It did happen in the past that the Linux kernel had some unspecified or wrong behavior (e.g. some driver crashing the kernel).
And open source developers are allowed to make software bugs (mistakes). I think that even proprietary software developers can make bugs.
Sometimes, a bug is renamed as a feature. Sometimes, a requested feature trigger other bugs (in previously non-buggy code). The Rice's theorem is related.
In some countries (in France, see article 323-1 du Code Pénal) software has some legal limitations and legal barriers. These apply to both open source and proprietary software.
I am not a lawyer, but I understand that it is people's behavior, not open source software, which can be illegal.
Feel free to contact me by email.
Basile Starynkevitch
- 1,367
- 7
- 14
I am not a lawyer, but this is how I always interpreted things.
– gorgabal Jan 26 '22 at 11:54colorscaused issues. The problem in this case is that even with careful tests this change caused fails and intentionally required additional work solely for the amusement of the author. – Džuris Jan 26 '22 at 16:19While the author isn't bound by the license of the project, they're bound by the ToS of any hosting and distribution platforms.
NPM specifically reserves the right to determine what "suitable" content is, and NPM can continue to distribute after deletion if your license allows it. Github has similar provisions when it comes to forking as well.
– Selali Adobor Jan 27 '22 at 07:29package-lock.jsonmake this much less of an issue than people are making it out to be? – tim-phillips Jan 28 '22 at 16:34