(This post was originally written in January 2022. It might seem a bit dated now, but just wait until the next time Open Source Discourse rears its ugly head; it will seem prescient then.)
Last time I talked about Volkan Yazici, one of the developers of log4j, and his selfless response to a critical security bug that threatened users of many commercial products.
The event kicked off a flurry of discourse about how open source projects ought to be funded, and what these projects are owed by their users.
That discourse might have petered out, if not for Marak Squires, the creator of the open source project faker.js. A week after the log4j vulnerability was exposed, Marak sabotaged his own project by deliberately introducing a change that would cause it to fail on startup. He then claimed to be unable to fix it, while using his ownership of the project to prevent anyone else from fixing it. He would later go on to obliterate the repository on GitHub, and edit pull requests designed to point users to forks of the project to instead point to a /r/conspiracy post about Arron Swartz. This was, ostensibly, an act of protest against how companies “take advantage” of open source projects without contributing monetarily back to them. As a result, he was banned from GitHub, where he took to Twitter to assert his right to torch repositories he owned, should he choose to do so.
Given the timing, his behavior was clearly inspired by Yazici. And yet, reception to the stunt was significantly more mixed. People were pissed, obviously. Others sympathized with Marak’s frustrations and leapt in to defend him. Some took a middle road to assert that, “yeah, it sucks, but this was his project, others shouldn’t feel entitled to it, and he can deface it if he wants to.” I find this argument the most intriguing. I’m also marginally more sympathetic to it than the others, because it actually acknowledges the complexity of the issue and tries to reason about his actions as they fit into some value framework (in this case, the idea of “project ownership”). But it’s a value framework that I feel fundamentally misrepresents open-source.
Open-source, at its core, is a voluntary relinquishment of some or all of the concept of “ownership” of a project. Ownership, as an absolute right, is often seen as including “the exclusive right to destroy something or deny others its use.” An open-source license waives that right, either conditionally or unconditionally. Giving up that ownership means reduced responsibility, but also reduced control.
faker.js was published under the MIT license. The MIT license, like log4j’s Apache license, explicitly permits commercial use of the code, and also grants blanket permission to republish and modify the code. Once I publish code under this license, I can never again be its sole steward, because anyone else can fork it. Now, there’s nothing in it that waives my right to deliberately make the licensed code harder to access, or introduce bugs, or try to prevent people from finding the licensed code. But the spirit of MIT license is to allow others to preserve the licenced work by reuploading it, and permission to reupload a creative work is completely useless if no functioning copies of that work remain.
If I create something, and bequeath it to the world under an open-source license, I’m not under any obligation to help people use it or preserve it; no one is entitled to that from me. I can wash my hands of it specifically because it exists outside of me and does not need me. But if I commit something to open source and then actively attempt to make it more difficult to use, I should be rightfully called out for that. No one should be defending me with the argument that I have the right to cause misery to the users of a project simply because it belongs to me. The project doesn’t belong to me in the conventional sense; that’s the whole point.
There’s also the fact that Marak tagged the malicious revision with the “latest” tag, which meant that any users who used a package manager to update their software would be updated to the malicious version. This was an act that had nothing to do with any intellectual property claims to the underlying code. The argument of “It’s his project, he can do what he wants” ends as soon as he starts interfering with the operation of package managers and their users. These package managers are under no obligation to host his malicious content.
As an analogy: Just because I sell engine parts under a license that says “no liability”, that doesn’t mean I can just deliberately trash your engine or force a store to carry broken parts. That’s not how it works, legally or ethically. It’s not in the letter or the spirit of the license. (This is not legal advice, and I am not a lawyer.)
Marak doesn’t owe the open source community anything, just as the community doesn’t owe him anything. But his actions here are an affront to the same values that the open-source community claims to uphold.
Yazici found himself in a crisis, took on a responsibility to help his community, and then spoke out about the conditions that put him in an unenviable situation. Marak created a crisis, and then invoked ownership rights to justify harming members of his own community. These are not the same.
Marak framed his actions as an act of protest. And yes, a protest needs to be inconvenient for the masses, or else it’s merely ignored. But his behavior wasn’t just inconvenient; it actively harmed the people that he claimed to be trying to protect, while leaving the masses mostly unaffected. If it becomes necessary for project maintainers to plan for and handle the event that one of their dependencies might just decide to sabotage their own projects (and perhaps this is already a concern that any decently sized project needs to handle) it’s other third party and independent developers who are hurt the most by this, since the larger fortune 500 companies are going to be better able to allocate resources to handle such a disruption, or more likely to already be using their own forks of the project and be completely unaffected. And since competing for user’s attention and funding is a zero sum game, that means that roadblocks like this ultimately serve to help fortune 500 companies beat out their competition.
I once had an industry job maintaining a company-internal fork of an open source project. I was ordered not to contribute my changes back to the original project, for a variety of reasons: partly because we often introduced extensions to the DSL to suit our own use cases, or added features that, if pushed upstream, could create a maintenance burden for the original project. But also because, even though the company made every effort to ensure compliance with the project’s license, we were worried that even the appearance of noncompliance could open us up to time-consuming (if frivolous) litigation. Over time, our internal fork diverged to the point that it was effectively a different product uniquely suited to our needs (and at this point we also stopped pulling updates from their repo as well). My understanding was that this was the standard industry practice for this particular tool… provided that you were a big enough company to afford it.
The project owner’s income came from offering upgraded licenses and dedicated support. I can’t imagine they were thrilled that they weren’t making any money from us, or any of the other major industry players.
If something happened to the official code repo, we would have been completely unaffected by it. But this was only because we had the engineers and the resources to maintain our own fork. I can’t say the same for our smaller competition. The smaller corporations and the nonprofits and the hobbyists depended on the official repo in a way that we didn’t. If something happened to that repo, it would have given us an incredible competitive advantage. So even though we were benefiting from the project without giving back to it, its continued existence played an important role in mitigating our dominance in the field. Our (ab)use of the project didn’t stop it from being a source for good.
That’s not the most intuitive thing, so I’m going to emphasize it: just because we were a big company taking advantage of an open-source tool, that didn’t mean that the tools’ existence gave us a competitive advantage. If anything, the tool was an equalizer, and ending its support or development would have cemented our market position, not eroded it.
Returning to the volunteer firefighter comparison from the previous post, the solution to big players being reckless with fire isn’t to say “big buildings need to pay us or else we won’t fight fires anymore.” Because those big buildings are the ones who can afford their own dedicated firefighters. If the volunteers quit, it’s not the big buildings that lose out. It’s all the little ones.
The worst thing we could do would be to return to the days of for-profit firefighters. But to prevent that, we need to make sure that the volunteers stick around, that the community continues to be built around the values of distributing code not to make a profit, but because a rising tide lifts all boats. And that requires making sure that contributors have their needs met.
Supporting open-source development is essential for the future of the open web, and we should be exploring all our options. But I can’t in good conscience support “burning it all down” as the solution.
But this still doesn’t suggest a solution for struggling open source developers. Without a clear way to fund critical infrastructure, it makes you want to throw in the towel.
Next week we look at Christofer Dutz, who considered doing just that.