He liked that "free" had a double meaning: "free as in speech" (an ethical proposition) and "free as in beer" (without cost). Stallman viewed the ambiguity of "free software" as a koan/conversation-starter: a normie, hearing "free software," would inquire as to whether this meant that the software couldn't be sold commercially, which was an opening for free software advocates to explain the moral philosophy of software freedom.

3/

For "open source" partisans, this was a bug, not a feature. They wanted to enlist other hackers to develop freely licensed codes, and convince their bosses to adopt this code for internal and public-facing use. For the "open source" advocates, a term designed to confuse was a liability, a way to turn off potential collaborators ("if you're explaining, you're losing").

4/

But the "open source" side wasn't solely motivated by a desire to simplify things by jettisoning the requirement to conscript curious bystanders into a philosophical colloquy. Many of them also disagreed with the philosophy of free software. They weren't excited about building a "commons" or in preventing rent extraction by monopolistic firms. Some of them quite liked the idea of someday extracting their own rents.

5/

For these "open source" advocates, the advantage of free software methodologies - publishing code for peer review and third-party improvement - was purely instrumental: it produced better code. Publication, peer review, and unrestricted follow-on innovation are practices firmly rooted in the Enlightenment, and are the foundation of the scientific method.

6/

Allowing strangers to look at your code, critique it, and fix it is a form of epistemic humility, an admission that we are all forever at risk of fooling ourselves, and it's only through adversarial peer review that we can know whether we are right.

This is true! Publishing code makes it better, and prohibitions on code publication make code worse. That's the lesson of the ransomware epidemics of the past decade: these started with a series of leaks from the NSA and CIA.

7/

Both agencies have an official policy of researching widely used software in hopes of finding exploitable bugs and then keeping those bugs secret, so that they will be preserved in the wild and can be exploited when the agencies wish to attack their enemies.

8/

The name for this practice is NOBUS, which stands for "No One But US": we alone are smart enough to find these bugs, so if we discover them and keep them secret, no one else will find them and use them to attack our own people. This is a provably false proposition, and a very dangerous one.

The Vault 7, Vault 8, and NSA cyberweapon leaks blew a hole in NOBUS.

9/

Failures in the agencies' own security protocols resulted in the release of a long list of defects (mostly in versions of Windows, but other OSes and programs were affected). Malicious software authors used these as can openers to pry open millions of computers, enlisting them into botnets and/or shutting them down with ransomware.

These leaks also provided some "ground truth" for researchers who study malicious software.

10/

Once these researchers had a list of which defects the spy agencies had discovered and when, they were able to compare that list of defects that malicious software authors had discovered and exploited in the wild, and estimate the likelihood that a spy agency defect would be independently discovered and abused by the agency's enemies, who they were supposed to be protecting us from. It turns out that the rediscovery rate for spy agency bugs is about 20% per year.

11/

In other words, there's a one in five chance that a bug that the CIA or NSA is hoarding will be used to attack America and Americans within the year.

NOBUS is a form of software alchemy. Alchemy is the pre-Enlightenment version of scientific inquiry, and it resembles science in many respects: an alchemist observes phenomena in the natural world, hypothesizes a causal relationship to explain them, and performs an experiment to test their hypothesis.

12/

But here is where the resemblance ends: where the scientist must publish their results for them to count as science, the alchemist kept their findings to themselves. This meant that alchemists were able to trick themselves into thinking they were right, including about things they were *very* wrong about, like whether drinking mercury was a good idea. The failure to publish meant that every alchemist had to discover, for themself, that mercury was a deadly poison.

13/

Alchemists never figured out how to transform lead into gold, but they did convert the base metal of superstition into the precious metal of science by putting it through the crucible of disclosure and peer-review. Both open source and free software partisans claim transparency as a key virtue of their system, because transparency leads to improvement ("with enough eyeballs, all bugs are shallow").

14/

At the outset, "open source" and "free software" were synonyms. All code that was open was also free, and vice-versa. But over the ensuing decades, that changed, as Benjamin "Mako" Hill explained in his 2018 Libreplanet keynote, "How markets coopted free software’s most powerful weapon":

mako.cc/copyrighteous/librepla…

15/

How markets coopted free software’s most powerful weapon (LibrePlanet 2018 Keynote)

Several months ago, I gave the closing keynote address at LibrePlanet 2018. The talk was about the thing that scares me most about the future of free culture, free software, and peer production. A …

^{copyrighteous}

As Hill explains, the philosophical differences between "open" better code) and "free" code to enhance human freedom) may not have mattered at the outset, but they each served as a kind of pole star for its own adherents, leading them down increasingly divergent paths. Each new technology and practice represented a decision-point for the movement: "Is this something we should embrace as compatible with our project, or should we reject it as antithetical to our goals?"

16/

If you were an "open source" person, the question you asked yourself at each juncture was, "Does this new thing increase code-quality?" If you were a "free software" person, the question you had to answer was, "Does this make people more free?"

17/

These value judgments carried enormous weight. They influenced whether hackers would work to improve a given package or pursue a use-case; they determined who would speak or exhibit at conferences, they created (or deflated) "buzz," and they influenced the direction that new license versionss would take, and whether those licenses would be permissible on influential software distribution channels.

18/

For a movement that runs on goodwill as much as on dollars, the social acceptability of a practice, a license, a technology or a person, mattered.

Hill describes how chasing openness without regard to its consequences for freedom created a strange situation, one in which giant tech monopolists have software freedom, while the rest of us have to make do with open source.

19/

All the software that powers the cloud systems of Facebook, Google, Apple, Microsoft, etc, is freely licensed. You can download it from Github. You can inspect it to your heart's content. You can even do volunteer work to improve it.

But only Google, Apple, Microsoft and Facebook get to decide whether to run it, and how to configure it.

20/

And since nearly all the code our users depend on takes a loop through a Big Tech cloud, the decisions made by these Big Tech firms set the outer boundaries of what our code can do. They have total freedom while we make do with the crumbs they drop from on high.

In other words, the freedom mattered, and when we forgot about it, we lost it.

Which is not to say that free software doesn't benefit from open source's popularity.

21/

The vast cohort of people who have been won over by open source's instrumental claims to superior code are the top of a funnel that free software partisans can operate to convince these people to consider the ways that their lives have been made more free through open code, and to prioritize freedom, even ahead of code quality.

The free/open source movement is actually a coalition of people who share *some* goals even if they differ on others.

21/

Coalitions are politically powerful. Nearly everything that happens, happens because a coalition has been pulled together:

pluralistic.net/2025/01/06/how…

But coalitions are also brittle, because after they get what they want (transparency for code), then they have to resolve their differences, which means that some members of the coalition are going to be bitterly disappointed.

23/

After all, there's code that we don't want to improve - at least, not if we care about freedom. For example: code that helps ICE kidnap our neighbors. Code that powers drones. Code that spies on us, both for governments and for private-sector snoops, like the data-broker industry. Code that helps genocidiers target Gazans. Code that helps defeat adblockers. Code that helps locate new sites for fossil fuel extraction, and code that helps run fossil fuel extraction operations.

24/

Human freedom has an inverse relationship to this code: the better this code is, the worse off we all are.

Periodically, some free software advocate will follow this to its logical conclusion and propose a new free software license that prohibits use for some purpose: "you may not use my code in the military," or "you may not use my code for ad-tech," or "you may not use my code in ways that despoil the environment."

25/

It's not surprising that this is a recurring event. After all, if you care about software as a tool for enhancing human freedom, and you notice that your code is being used to make people less free, it's natural to want to do something about it.

And yet, every one of these efforts have foundered - and I think every one will. This isn't because ethics clauses in license are a foolish idea, but because they are logistically transcendentally hard to get right.

26/