I write code for a living. I shave nanoseconds off assembly routines, push bytes around for fun, and every so often I look up from the terminal and take stock of the world we've built around ourselves. What I see is a proprietary swamp, slowly closing in, and most people walked into it smiling because it came with a nice UI.
This post is going to make some of you uncomfortable. If you're a die-hard defender of corporate walled gardens, this piece isn't really written for you — though I'd still argue you're exactly who should read it. You're free to ignore everything I say here, free to tear it apart in the comments, free to think I'm exaggerating. Just argue with the substance, not the tone.
Here's the substance: corporations track where you are, catalog what you watch, and quietly build a profile of your entire life while selling you the convenience of "it just works." Understanding how we got here starts with one uncomfortable, brilliant, deeply inconvenient man.
I. Richard Stallman — Genius, Fundamentalist, and Yes, a Genuinely Difficult Person
Let's get one thing straight before I say anything positive about Richard Stallman: he is not a simple hero, and I'm not going to sell him to you as one. He's a legitimately polarizing figure, and I'll get to exactly why later in this section, honestly, without the sanitized version. But his ideas deserve to be separated from the man, because the ideas are load-bearing for everything that follows in this post.
Stallman wasn't just a programmer. He was — and still is — a fundamentalist of freedom. He didn't primarily care about software being free as in free beer. Price was almost beside the point to him. What he wanted was software that was free as in free speech, free as in free press, free as in freedom of movement. That was an ethical stance, not a business model.
He came up through MIT's AI Lab in the 1970s and 80s, inside a hacker culture where code was written, shared, and improved collectively as a matter of course. Then corporations started showing up, taking that code, closing it off, and selling it back to the people who'd built the culture it came from. Stallman watched that happen and reached a conclusion that turned out to be correct: if this kept going, people would lose control over the tools they depended on every day.
His four freedoms, the foundation of the entire free software movement:
- The freedom to run the program as you wish, for any purpose, without the copyright holder's permission standing in the way.
- The freedom to study how the program works and adapt it to your needs. This one requires the source code — without it, you can't actually understand or change anything. It's the software equivalent of buying a car with the hood welded shut.
- The freedom to redistribute copies. You wrote it, or you have it — you can hand it to a friend. Nobody gets to stop you.
- The freedom to distribute copies of your modified versions. You improved something — share the improvement, so the whole community benefits from your work the way you benefited from everyone else's.
Out of these four freedoms came the GPL — the GNU General Public License. It's a deceptively simple piece of legal engineering: any code you build on top of GPL-licensed code, any code you fork or modify from it, has to also be released under the GPL. People call it "viral," and they're not wrong — but it's a virus that only does one thing: it stops corporations from taking community code, sealing it shut, and reselling it back to the community that built it.
Now, why is Stallman actually controversial? Not for the romantic reason some people want to tell you — that corporations smeared him because his ideas threatened their business models. That story is more comfortable than the real one, and comfort isn't the goal here. In 2019, Stallman resigned from both the Free Software Foundation and MIT after making comments about the Jeffrey Epstein case that came off as minimizing what happened to Epstein's victims — comments he later said were mischaracterized and clarified he never intended to defend Epstein, but the damage to trust was real regardless of intent. He returned to the FSF board in 2021, which triggered a fresh wave of backlash, including several organizations formally cutting ties with the foundation. On top of that, he's had a long track record of blunt, socially abrasive behavior — dismissive comments about gender-neutral language, a general refusal to read a room — that alienated plenty of people who otherwise agreed with his politics on software freedom.
None of that makes the four freedoms wrong. None of it makes the GPL less brilliant as a piece of legal architecture. It just means the messenger is a genuinely flawed, difficult human being, and pretending otherwise doesn't do the ideas any favors. Judge the license on its own merits. It holds up fine without a saint attached to it.
II. The GNU Project, the Linux Kernel, and the Naming Fight Nobody Agrees On
Here's where it gets genuinely contentious, and I want to walk the actual history instead of the flattened meme version of it.
By the late 1980s, Stallman's GNU Project already had most of a full operating system built: the GCC compiler, the coreutils you use every day on any distro (ls, cp, mv, grep, awk), the Bash shell, the glibc C library. What GNU didn't have was a working kernel. Stallman's team was building one — the GNU Hurd — but it was architecturally ambitious in ways that made it slow to mature.
Then, in 1991, a Finnish university student named Linus Torvalds released a kernel he'd been writing as a personal project: Linux. It was pragmatic, it ran on commodity hardware, and — critically — it was stable enough, fast enough, to actually finish. People combined it with the existing GNU userland tools, and the result was a complete, working, free operating system. Technically: GNU tools and libraries, running on top of a Linux kernel. Which is exactly why Stallman has spent decades arguing the correct name for the whole system is GNU/Linux, not just "Linux."
This is a genuinely disputed point, and I'm not going to pretend it isn't. Stallman's argument is straightforward: the kernel is one component among many, and naming the entire OS after the newest and smallest piece erases the project that supplied most of the actual code and, more importantly, the licensing philosophy that made the whole thing free in the first place. It's a fair point about credit and about visibility for the ethical framework underneath the tools.
Torvalds, for his part, has been consistently pragmatic about it — publicly framing himself as an engineer, not an ideologue, and generally shrugging off the naming debate rather than fighting for it. Whether that's admirable humility or a missed opportunity to credit the project that supplied the userland is genuinely a matter of perspective, and reasonable people land differently on it. What isn't really in dispute is why "Linux" won out as the common name: it's shorter, it's catchier, and once companies like IBM, Red Hat, and later Google started building products and marketing campaigns around it, brevity won, the way it usually does in naming fights. That's not necessarily a grand conspiracy — it's also just how language and branding behave under commercial pressure. Though it's worth noting the outcome is convenient either way: "Linux" as a brand carries none of the GPL's ethical baggage, and companies that wanted the code without the philosophy got exactly that.
Even Linus Bent the Knee to Proprietary Software — And the Community Made Him Pay For It
Here's the part that gets left out of the hero narrative, and it deserves to be told plainly, because it proves a point that goes beyond any one person: the pressure to trade ideological purity for convenience is universal, and not even the guy who wrote Linux was immune to it.
Starting in 2002, Torvalds chose BitKeeper, a closed-source, proprietary version control system built by a company called BitMover, to manage Linux kernel development. Richard Stallman objected to this publicly, right when it happened, calling it out for exactly what it was: the flagship project of the free software world was being coordinated using tooling nobody could inspect, fork, or fully trust. BitMover handed out free licenses to kernel developers, but with strings attached — developers weren't allowed to work on competing version-control tools while using it, and BitMover retained control over certain project metadata. Several respected kernel developers, including Alan Cox, refused to touch it on principle and kept working through other channels instead.
The arrangement held for three years, until 2005, when a developer named Andrew Tridgell reverse-engineered enough of BitKeeper's protocol to expose the metadata BitMover had been keeping locked away — the same kind of version history data that's a basic, unremarkable feature in any real version control system. BitMover's response was to revoke free access entirely. Torvalds, furious about the position this put him in, spent about ten days writing an alternative from scratch. That alternative is Git — now the version control backbone of essentially the entire software industry, free and open, no BitMover in sight.
Draw your own conclusion from that story, but here's mine: even the person most people point to as living proof that "pragmatism beats ideology" got burned specifically because he leaned on proprietary infrastructure for something that mattered, and the fix that came out of that mistake is more free, more resilient, and more widely used today than anything BitMover ever built. Stallman was right about the mechanism in that argument too, years before Torvalds was forced to agree with him in practice.
III. Free Software vs. Open Source — A Distinction That Actually Matters
The term "Open Source" was coined in the late 1990s, and I need you to understand it is not a synonym for "Free Software," even though the two get used interchangeably constantly.
- Free Software (Stallman's framing) is about user freedom. The four freedoms, the GPL, an ethical position about what software should be allowed to do to the people who use it.
- Open Source is about development efficiency. The pitch is that visible code means faster bug discovery, more contributors, better business outcomes. It's a pragmatic, commercially-friendly argument. It says almost nothing about whether the user of the software actually retains control over it.
This is a subtle swap, but it's a genuinely important one. Corporations gravitated hard toward "Open Source" precisely because it let them adopt the productivity benefits of collaborative development without inheriting any of the ethical obligations the GPL forces onto you. Google built Android around an open-source Linux kernel, then wrapped it in a proprietary layer of Google Play Services that most manufacturers can't ship without agreeing to Google's terms — the openness stops exactly where the tracking and the business model begin. Microsoft shipped Linux inside Windows via WSL, a genuinely useful tool that also happens to make Linux another feature living inside a proprietary host OS, on Microsoft's terms. Kubernetes and Docker are unambiguously open source, and they're also the default on-ramp into AWS, Google Cloud, and Azure — architectures that are extremely easy to get locked into and expensive to leave.
None of that makes "Open Source" a scam. It's produced enormous, genuine public value — the modern internet runs on it. But it's a different value proposition than Free Software, and treating the two as interchangeable is exactly how people end up trusting a "it's open source!" label on something that still phones home every few seconds.
IV. Canonical, Ubuntu, and the Slow Enclosure of a "Free" Distro
Ubuntu was, for a long time, the on-ramp most normal people used to get into Linux at all. That matters, and I'm not going to pretend Canonical hasn't contributed real engineering to the ecosystem. But the trajectory of Ubuntu over the last decade and a half is a textbook case of exactly the pattern this post keeps circling back to: take something genuinely open, wrap a layer of corporate control around it, and call the whole package "open source" because most of the underlying pieces technically still are.
The Amazon ads fiasco. Back in the Unity desktop era, Ubuntu shipped a "feature" that sent your local search queries — including searches inside your own files — off to Amazon by default, so it could show you shopping results inside your desktop search bar. This wasn't a plugin you opted into; it shipped on by default, and it took real public backlash before Canonical made it easy to turn off.
Snap and the walled garden inside your package manager. Canonical's Snap format was pitched as a universal packaging solution — one package format that works across distros, easier for developers to ship. Fine in theory. In practice, the client tooling for Snap is open source, but the Snap Store backend — the actual server that serves and signs every package — is closed-source and controlled entirely by Canonical. There's no way to run your own independent Snap Store the way you can mirror an APT repository. On top of that, recent Ubuntu releases will silently substitute a Snap package when you type a normal apt install firefox, overriding what you actually asked for. Linux Mint, historically one of Ubuntu's closest downstream relatives, found this troubling enough that it disables the Snap Store by default and patches its own package manager to stop the substitution from happening.
The pattern underneath it. None of this makes Ubuntu malware, and Canonical isn't Microsoft. But it's the same playbook in miniature: take a genuinely open foundation, build a proprietary chokepoint on top of it at exactly the layer where distribution and control matter most, and let the "it's built on open source" label do the reputational work of making people feel like nothing has changed. It has changed. The difference between "Linux distro" and "platform Canonical fully controls the supply chain of" is not a small one, and it's worth knowing which one you're actually running before you feel too smug about having ditched Windows.
V. What This Actually Costs You Today
If you're wondering why any of this history matters in the present tense, here's where it lands.
Your hardware isn't fully yours. Both Intel and AMD ship processors with an embedded, proprietary management subsystem — Intel Management Engine (ME) and AMD Platform Security Processor (PSP), respectively. These run below your operating system, with their own firmware, their own network stack access on many platforms, and code that neither company publishes for independent audit. Nobody serious has proven a secret backdoor sitting inside them waiting to be triggered — but that's precisely the problem: the honest answer to "what can it do and who can access it" is "we don't fully know, because it's closed," and that opacity, on hardware you supposedly own, should bother you regardless of whether anyone's found a smoking gun yet. Projects like Libreboot and Coreboot exist specifically because enough people found that unacceptable and decided to try to build their way around it.
Software you've paid for still watches you. Windows 11's Recall feature is the cleanest modern case study: it screenshots your desktop every few seconds and builds a locally-indexed, searchable timeline of everything you've ever looked at on your PC. Microsoft's first attempt at shipping it in 2024 stored everything in an unencrypted, trivially readable database — security researchers cracked it open within days of release, and Microsoft delayed the launch to rebuild it. The rebuilt version, rolled out through 2025 and into 2026, added encryption, Windows Hello authentication, and a hardware-isolated secure enclave — and independent researchers have already demonstrated ways to ride along with a legitimate Windows Hello authentication and pull the stored data out anyway. Microsoft made it opt-in, which is a real improvement over the original default-on rollout, and the processing genuinely stays on-device rather than shipping to the cloud. But the underlying design — a rolling, AI-searchable photographic memory of everything you've ever done on your own computer — is still exactly the kind of capability that should never have needed this many rounds of public backlash to get even partially right.
GitHub Copilot and the quiet erasure of licenses, not the "insertion" of one. People sometimes describe this story as "Copilot inserting its own license into your code" — that's not quite what happened, and the real version is worse in a different way. GitHub trained Copilot on billions of lines of public code, a meaningful share of it released under copyleft licenses like the GPL that require attribution and license-preservation whenever the code is reused. Independent researchers, and GitHub's own admissions, confirmed Copilot would sometimes reproduce sizeable chunks of that training data nearly verbatim — GitHub itself has acknowledged that roughly 1% of Copilot's suggestions match training data closely enough to be a concern. What gets dropped in that process is exactly the thing the license required: the attribution, the license notice, the copyleft obligations that are supposed to travel with the code. A group of developers sued GitHub, Microsoft, and OpenAI over this in late 2022, arguing the tool was effectively laundering GPL and MIT-licensed code into a form stripped of the terms that made it free in the first place. The presiding judge narrowed the case in 2024, dismissing some of the strictest copyright and DMCA claims for lack of specific proof of identical copied code, but let the core breach-of-license and terms-of-service claims move forward, and the underlying question — can an AI tool strip a license's obligations just by rephrasing the code slightly — is still unresolved as of this writing. It's not that Microsoft is stamping its own copyright onto your work. It's that the free licenses attached to other people's work are quietly disappearing on the way into yours, and you're the one left holding legal exposure you never agreed to.
DRM means you rent, not own. You "buy" a film, a game, a book, and what you actually purchased is a revocable license to access it for as long as the platform's terms allow. Licenses expire, platforms shut down, publishers pull titles, and your "ownership" evaporates without you ever agreeing to give it up in any moment you'd have noticed.
Your cloud data isn't really your data. Anything stored primarily on someone else's server can be deleted, throttled, or access-revoked at that company's discretion, under terms you clicked through without reading. Convenience and control are functionally opposed here, and most of us have been trading away the second for the first without ever consciously deciding to.
Your Internet Is Slowly Becoming Not Yours (Or Never Was)
Step back from any single product and look at the shape of the whole thing. The open protocols that built the early internet — SMTP, IRC, RSS, XMPP — have almost all been quietly replaced in daily use by proprietary, closed platforms that happen to run on top of the open internet's plumbing. Email still technically works the way it always did, but most people's actual mail experience is mediated by Gmail's ranking algorithm. RSS readers still work fine, but most people get their news filtered through a recommendation engine they don't control and can't inspect. Even the physical routing of the internet increasingly passes through a small number of CDNs and cloud providers who can, and occasionally do, make large chunks of the internet unreachable when something goes wrong on their end.
This isn't a conspiracy with a single villain. It's the accumulated result of thousands of individually reasonable-looking business decisions, each one trading a little more centralized convenience for a little less user control, until one day you notice the "open" internet runs almost entirely through a handful of proprietary chokepoints — and even the free software world's most stubborn advocate for decentralization eventually leaned on a closed tool when the deadline was real. That's not hypocrisy exactly. It's just how strong the gravity of convenience actually is, on absolutely everyone, including the people who built their whole identity around resisting it.
VI. IT Used to Be a Science. Now It's Often Just a Trade — And That's Not an Insult
I want to say this part carefully, because it's easy to hear it as gatekeeping, and that's not the intent.
There was a period, not that long ago, when working in computing meant you were close to something that looked and behaved like an actual science: understanding algorithmic complexity, memory layout, how a compiler actually turns your code into machine instructions, how a network packet actually gets from one machine to another. It was a field where the foundational literature mattered — Knuth, Dijkstra, Lamport, the actual CS canon — and where "I don't fully understand what's happening under my own code" was considered a problem to fix, not a normal state of being.
Today a huge share of the industry is people assembling pre-built components — a React app calling a REST API that wraps a database ORM that wraps a database none of the three layers really need you to understand — and calling that "software development," full stop. And to be completely clear: I am not looking down on those people, and I'm not diminishing the actual value of what they build. Plenty of real businesses run on exactly that kind of work, it pays well, it solves real problems, and treating it as somehow illegitimate would be dishonest and unkind. My point isn't a judgment of the people. It's a description of a field that has quietly split into two different disciplines wearing the same job title: one is closer to applied science, working with an understanding of what's actually happening at the layers below the abstraction; the other is closer to a skilled trade, working productively and often profitably on top of abstractions without needing — or in many cases being able — to see underneath them.
Both are legitimate. Both are useful. But conflating them, and pretending the second one automatically confers the depth of the first just because the job title says "developer" in both cases, is exactly the kind of comfortable lie that keeps people from noticing how much control they've handed to the black boxes underneath their stack. If you don't know what your framework's build step is actually doing, you're not in a position to notice when it starts doing something you wouldn't have agreed to. That gap is precisely where a lot of the quiet data collection, the vendor lock-in, and the "it just works, don't ask questions" culture of modern software gets to operate undisturbed.
VII. So What Do You Actually Do With This?
I'm not going to pretend total digital withdrawal is realistic for most people reading this — you have a job, most of your team is on Slack and Google Docs, and going full off-grid isn't a serious plan for 99% of working engineers. That's a fair objection, and I'm not going to wave it away.
But "realistic" doesn't mean "zero effort." A few things that are actually within reach:
- Run a real Linux distribution as your daily driver where you can, not as a VM you spin up to feel superior in. Arch, Fedora, Debian — pick your fighter, and actually use it for real work. If you run Ubuntu, know what Snap actually is before you use it, and know there are forks like Linux Mint built specifically to avoid it.
- Prefer GPL and genuinely copyleft-licensed tools when you have a choice between comparable options, so you're voting with your toolchain, not just your opinions.
- Look at your hardware, not just your OS. Coreboot and Libreboot-compatible machines exist. They're a hassle compared to whatever's on the shelf at a big-box retailer, and that hassle is the actual price of the audit trail you're buying.
- Audit what you've opted into. Recall, telemetry settings, cloud backup defaults, Copilot's org-level license filters — most of this ships opt-out by design, buried three menus deep, because the company's incentives and your incentives aren't the same. Go find the switches. It takes twenty minutes and it isn't complicated, they just don't want it to be quick.
- Self-host what you reasonably can. Not everything, not as a purity test — just enough that you remember what having actual control over your own data feels like.
- If you're an engineer, spend some time below your usual abstraction layer. You don't have to become a kernel developer. Just occasionally read the source of something you depend on daily. It's the fastest way to remember that "it just works" is a sentence someone wrote for you, not a law of physics.
You don't have to become a monk about this. You just have to stop pretending that "convenient" and "free" are the same word, because they haven't been the same word for a long time, and the gap between them is where all of the above lives. Stallman was right about the mechanism even when he was wrong about plenty else — and even Linus Torvalds, the industry's favorite pragmatist, found out the hard way what it costs to lean on someone else's closed system for something that mattered. Corporations didn't take your control over your own tools by force — you clicked "I agree" and handed it over one dialog box at a time. The good news is that's also how you get it back: one deliberate choice at a time, starting with the next piece of software you install.