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).
-
25Kind of reminding of someone deleting his own repos: How one programmer broke the internet by deleting a tiny piece of code– Andrew T.Commented Jan 26, 2022 at 5:16
-
28Someone got some code with a license. They tried it and it suited. Then they should use that code. If there's an update, they should check if the code and the license is still suitable. If not, they still have the right to use the old version. The problem is more in people carelessly upgrading without checking the changes.– Thomas WellerCommented Jan 26, 2022 at 11:42
-
6Where can I read more about this drama?– stopkillinggames.comCommented Jan 26, 2022 at 15:31
-
8@wha7ever - The Verge covered it; as has bleeping computer (no affiliation with either)– bertiebCommented Jan 26, 2022 at 16:10
-
4One aspect that hasn't been covered is the distribution platforms involved here. While 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 AdoborCommented Jan 27, 2022 at 7:29
|
Show 6 more comments
10 Answers
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.
answered Jan 26, 2022 at 0:35
-
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. Commented Jan 26, 2022 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. Commented Jan 26, 2022 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. Commented Jan 26, 2022 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."– HerohtarCommented Jan 26, 2022 at 20:38
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.
answered Jan 25, 2022 at 17:25
-
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žurisCommented Jan 27, 2022 at 5:04
-
@Džuris The answer is a general one; the specific details of exactly what happened with colors.js are not really that interesting. Commented Jan 27, 2022 at 11:16
-
1@Džuris Nothing in any open-source license says that github.com/yourname/yourlibrary has to contain useful code Commented Jan 27, 2022 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.– ilkkachuCommented Feb 2, 2022 at 15:03
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.
-
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. Commented Jan 26, 2022 at 8: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?– user3082Commented Jan 26, 2022 at 9: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.– VooCommented Jan 26, 2022 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. Commented Jan 26, 2022 at 14:54
-
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!– KevinCommented Jan 26, 2022 at 20:25
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.
-
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. Commented Jan 26, 2022 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. Commented Jan 28, 2022 at 4:10
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.
-
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. Commented Jan 26, 2022 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). Commented Jan 26, 2022 at 14:17
-
This answer nicely complements some of the other ones here. Commented Jan 28, 2022 at 8:22
-
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.– doneal24Commented Jan 31, 2022 at 18:51
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.
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.
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.
-
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.– ilkkachuCommented Feb 2, 2022 at 15:07
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.
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.
answered Jan 28, 2022 at 20:16
