Earlier this month, open-source software developer Marak Squires drew the disdainful ire of many in the software community after publishing sabotaged versions of two popular software libraries that he authored and now maintains—or did, at least, maintain.
New versions of the popular npm packages colors (23 million weekly downloads) and faker (2.4 million weekly downloads) were published. These sabotaged versions caused any piece of software using them to output a short message—"LIBERTY" repeated nine times—followed by never-ending random text.
It's important to note that the earlier, working versions of these packages have remained available on npm for this entirety of this saga[1]. As far as I am aware, Marak has made no effort to un-publish the older versions, despite npm supporting this feature.
I had a load more half-written spiel about this before I found Gavin Howard's post about the same subject, published before I'd even caught wind of the saga. Gavin hit the nail on the head, so read his post. We even chose the same title, almost! After that, there's one more point I'd like to add.
The philosophy of ethics is often divided in to two distinct categories: consequentialism and deontology. The former school of thought grants moral superiority to actions based upon their results, their consequences. The latter grants moral superiority to actions based upon their perceived intrinsic morality.
As usual, human life is not as binary as we sometimes like to think, and I would argue that most of us fluctuate between these two mindsets depending on the subject at hand. It's probably easier to be a consequentialist about matters in which one is not emotionally invested, for instance.
Nevertheless, I think there is a similar divide between engineers and visionaries, for lack of better terms. I use the term "engineer" here loosely, including civil engineering, mathematics, mechanics, and software development, to name a few. Ultimately, I refer to people who have an interest in the specific workings of a system, perhaps at the expense of their interest in the inputs to and outputs from a system. A visionary, by contrast, is analogous to the consequentialist, interested in conditions and outcomes and more than happy to allow their engineers to abstract away the details of the systems upon which their visions depend.
Picture the cliché Bond villain getting impatient with their chief scientist—"I don't care about that! Just tell me when the Genocidomatic 3000 will be ready for me to enact my dastardly plan!" Or, for that matter, picture a product owner who's just made the mistake of asking a software developer face-to-face for a clear, direct time estimate.
Most open-source software, unlike most proprietary software, is led, and, in many cases, exclusively staffed, by engineers. The fact is, most open-source projects are small half-finished pet projects lying abandoned on GitHub. The people who care about the end result of the project and who will compel its creators to stick it out to the end—that is, the product owners—are absent. Engineers, left to their own devices, will engineer for the sake of engineering and for the sake of scratching a curious, academic itch. Those goals are much quicker and more enjoyable for an engineer to achieve than a complete, capable, documented final product.
This evenings-and-weekends type of open-source software is very different from the commercially backed open-source software that usually takes the limelight. Most of Google Chrome is open-source, most of Visual Studio Code is open-source, and most of Java is open-source. Without Google, Microsoft, and Oracle, however, those projects would look very different, assuming they still existed.
These two broad categories of open-source differ in many ways, one of which is the expectations it is reasonable to have of their respective projects. Although the authors may not have any legal commitments to their user in either instance, it seems more justified to have expectations of functionality, stability, and fitness for purpose of a commercially backed project. At least, that is what people have come to expect thanks to projects like nginx, React, and Android. A lot of commercially backed open-source software is of a phenomenal quality considering it's free.
Software developers are generally aware of the value they draw from open-source software, both in their commercial work and in their own projects. Open-source by default is a prevalent mindset amongst engineers, particularly when they're not beholden to the whims of their visionary day-job directors.
And so, when developers publish their own projects, particularly the less mature ones, I think they do so with an intent that is unfamiliar to a lot of people in other professions. Approximately, the intent is to contribute the fruits of their labour to the public domain; think not "I made this thing" but rather "this thing was made". The intent is not to provide anyone with anything on an ongoing basis, such as any guarantee of functionality, but rather to contribute a finite one-time unit of work for others' benefit. The latter situation is predictable and free of commitment for the author, which is important for someone who is not set to gain in any significant way by releasing their software permissively.
In many cases, the "for others' benefit" justification may not even cross a developer's mind. Open-source is normalised enough that a developer may publish their work as a matter of habit, having already accomplished what they needed to with the software and having no intention of turning it into a business. To do this comfortably relies on an understanding that publishing work for free will not come back to bite the author in the rear.
The state of intellectual property which most closely represents this intent is probably the public domain. Unfortunately, explicitly donating work to the public domain is a foreign enough concept to society that legislation largely fails to include provisions for people to do so[2]. As a result, a plethora of permissive software licences have been written—MIT, BSD, and Apache licences and countless derivatives—all summarised quite concisely by the name, although not the content, of the WTFPL, the Do What the Fuck You Want to Public License[3]. The only conditions these licences typically impose are that attribution is given and the licence message remains intact.
The fact that releasing work for free, both gratis and libre, is so normalised in software development has its downsides. This practice is not the norm in photography, filmmaking, writing, art, or really any endeavour I can think of in which copyright is relevant. Perhaps this creates a general unfamiliarity in most people with receiving something without any guarantee and thus leads them to unjustified expectations. There's no obligation on any developer to release their work at all, let alone for free, let alone permissively, and let alone with any hint of any warranty of any kind. I think developers understand this implicitly when publishing their own work but can all too easily forget it when their day is ruined by their own misplaced dependency on some else's continuous unpaid work.
Back to Marak and his npm packages.
These packages were widely depended upon. You could argue, although many have beaten you to the punch, that Marak's actions constitute an irresponsible abuse of influence. If Marak's software was of critical importance to medical equipment and he was aware of that fact I think his actions would be less justifiable, for reasons of pragmatism more than inherent morality. Of course, much more blame would lie with the designer of the medical equipment for not minimising and auditing their software dependencies.
In reality, though, Marak's color and faker packages both solve relatively mundane problems and can be readily replaced. Marak never removed anything, but instead merely published new versions of the same packages that already existed. Thankless consumers of these packages blindly updated to these new versions, and soon enough people started writing their impassioned GitHub comments and their tedious blog posts. 🙋
A couple of remarkable tweets caught my eye:
You release the right to kill a project when you make it open-source
–@forresthopkinsa, 2022-01-10 23:22
Everyone has the right to hold a copy of the source code or build artefact of a piece of open-source software. If that project changes or disappears, every open-source licence I've ever read would permit others to re-publish the work as they had previously obtained it. Marak did not kill any project, but rather changed a project over which he had full legal and moral jurisdiction. Indeed, shortly after people started noticing the issue, a fork by another maintainer had already gained traction as the new authoritative version.
This is fucking irresponsible.
If you have problems with business using your free code for free, don't publish free code.
By sabotaging your own widely used stuff, you hurt not only big business but anyone using it.
This trains people not to update, 'coz stuff might break.
–@VessOnSecurity, 2022-01-09 14:47
Yes, things may break! That's called a breaking change. In fact, the sabotaged faker release bumped the version from 5.5.3 to 6.6.6, which, by widely recognised Semantic Versioning, indicates a breaking change. Development tools including npm respect this versioning scheme, so it would have been very difficult to even download this sabotaged version without meaning to. If this is what it takes for developers to pay more attention to their dependencies, so be it.
Perhaps Vess is right, though. Perhaps acts of sabotage will discourage individuals and businesses from updating software and possibly even discourage them from relying on open-source at all. Alternatively, perhaps a general misunderstanding of the not-so-implicit contract of open-source will discourage developers from contributing their work to the community in the first place.
It's true that if Marak didn't want commercial parties to profit from his software without compensating him, he should have chosen a copyleft or even proprietary licence which more closely matched his intent than the MIT licence which he actually used. Unfortunately, there is a disappointing disdain amongst some developers for copyleft licences—not dissimilar in tone to the disdain some have shown for Marak—so I can understand a desire to stick with the MIT licence, seeming the de facto default these days. It's also true that one cannot predict the future popularity of a project when releasing it for the first time and changing the licence only after popularity arrives could easily alienate users.
Marak's misunderstanding of the terms of his chosen licence does not, however, excuse the entitled misunderstanding by his users of those same terms. A greater awareness of the variety of available licences would be a benefit to software, so I'll cross my fingers that this ordeal may bring us some. May I recommend the Open Software License?
Footnotes
☝ Based on Internet Archive snapshots of the packages' npm pages:
colorsandfaker.☝ This is the problem that the Creative Commons CC0 licence was an attempt to solve. "Dedicating works to the public domain is difficult if not impossible for those wanting to contribute their works for public use before applicable copyright or database protection terms expire."
☝ Don't use this absurd licence for anything you care about. Its explicit and anti-intellectual denunciation of verbose block-capital disclaimers in software licences makes me hesitate to even mention it.