In 2008, Marco d’Itri posted a brief but incendiary entry on his blog that most people outside the Debian community never read. The post, published on blog.bofh.it, detailed a problem that was, and in many ways still is, eating open source from the inside out: proprietary firmware blobs bundled into the Linux kernel. The piece was technical. It was dry. And it struck at something that the free software world has never fully resolved — the tension between ideological purity and making hardware actually work.
D’Itri, a long-time Debian developer, was working on the problem of separating non-free firmware from the Linux kernel source tree. The issue sounds arcane, but it matters enormously. When you buy a wireless card, a GPU, or a network adapter, the chip inside often requires a small piece of proprietary software — firmware — to function. Hardware vendors typically don’t release the source code for these blobs. They just hand over compiled binary files and say: here, ship this. For years, the Linux kernel included these binary blobs directly in its source tree, mixed in with genuinely open code. This created a philosophical and legal headache for distributions like Debian that promised users a fully free operating system.
The Debian project’s social contract is explicit. It commits to keeping the distribution 100% free software. But if the kernel itself contains proprietary firmware, how do you honor that promise without breaking people’s hardware? You can’t. Not cleanly.
D’Itri’s work involved extracting these firmware files from the kernel source and packaging them separately in Debian’s “non-free” repository. This allowed purists to run a kernel stripped of proprietary code while giving pragmatists a clear path to install the firmware they needed. It was a compromise. Not everyone loved it. The Free Software Foundation, for instance, has long maintained that any distribution shipping non-free firmware — even optionally — doesn’t qualify as fully free. Debian has never appeared on the FSF’s list of endorsed distributions, and this is one of the primary reasons.
The technical work was painstaking. Firmware files had to be identified, extracted, matched to the correct hardware drivers, and repackaged with appropriate licensing metadata. Some firmware came with redistribution permissions. Some didn’t. Some existed in a gray zone where the license was unclear or contradictory. D’Itri cataloged these cases and pushed for clarity, both within Debian and upstream in the kernel community.
Fast forward to today, and the firmware question hasn’t gone away. It’s gotten bigger.
In 2022, the Debian project held a general resolution — essentially a project-wide vote — on whether to officially include non-free firmware in installation media. The vote passed. Starting with Debian 12 “Bookworm,” released in June 2023, the official installation images ship with non-free firmware included by default. This was a significant policy shift for a project that had spent decades drawing a hard line. The decision was covered extensively by Phoronix, which noted that the move reflected the practical reality that most modern hardware simply won’t function without proprietary firmware.
The implications ripple outward. Intel’s Wi-Fi chips, AMD’s GPUs, Qualcomm’s wireless adapters, Broadcom’s everything — nearly all of them require firmware blobs. As hardware has grown more complex, the firmware has grown more essential. A modern laptop running Debian without non-free firmware might boot, but it probably won’t connect to Wi-Fi, render graphics properly, or use Bluetooth. That’s not a viable experience for anyone outside a very specific subset of users running very specific hardware.
And this is where d’Itri’s early work becomes historically significant. He was among the first to build the infrastructure that made the separation possible in the first place. Without the firmware-linux-nonfree packages and the tooling around them, Debian wouldn’t have had a clean mechanism to offer firmware as an optional add-on. The 2022 vote to include firmware by default was only possible because the groundwork had been laid years earlier to treat firmware as a distinct, manageable component.
The broader Linux kernel community has moved in a similar direction. In 2022, Linus Torvalds himself weighed in during a kernel mailing list discussion, expressing frustration with the idea that binary firmware is somehow more objectionable than binary hardware. “The firmware is just a part of the hardware,” he argued, a position that puts him at odds with the FSF’s stance but aligns with how most working engineers think about the problem. The kernel project now maintains a separate linux-firmware repository — a massive collection of binary blobs from dozens of vendors — that distributions pull from to support hardware.
But the philosophical debate is far from settled. The FSF continues to fund and promote fully free distributions like Trisquel and PureOS. The Free Software Foundation maintains its list of endorsed distributions, and the criteria remain strict: no non-free firmware, no non-free software, no compromises. For the FSF, the inclusion of proprietary firmware — even firmware that runs on a separate processor embedded in a peripheral — represents a concession to hardware vendors who should be pressured to open their code instead.
There’s a real argument there. Every time a distribution ships a proprietary blob without complaint, it reduces the incentive for vendors to release open firmware. Why go through the effort of opening your firmware source code if every major Linux distribution will ship your binary anyway? The counter-argument is equally real: users need their hardware to work today, not in some hypothetical future where all firmware is open.
This tension has produced some creative engineering. The Linux-libre project, maintained by Alexandre Oliva, produces a version of the Linux kernel with all proprietary blobs removed and replaced with stubs. It’s a technically impressive effort, but it means that hardware requiring firmware simply doesn’t work. For some users, that’s an acceptable trade-off. For most, it isn’t.
Recent developments have added new dimensions to the firmware debate. The rise of RISC-V, the open-source instruction set architecture, has generated hope that future hardware might not require proprietary firmware at all. But even in the RISC-V world, many implementations still rely on proprietary components for things like power management and security enclaves. Open hardware is advancing, but it’s advancing slowly, and the gap between aspiration and reality remains wide.
Meanwhile, the Debian project’s decision to ship non-free firmware by default has had practical consequences. User feedback since the Bookworm release has been overwhelmingly positive regarding hardware compatibility. Installation success rates on modern laptops have improved markedly. The project’s installer no longer requires users to hunt for firmware files on a separate USB stick — a process that was, frankly, hostile to newcomers and annoying even for experienced users.
So where does this leave the free software movement? Fractured, as it has always been, between pragmatism and principle. D’Itri’s 2008 blog post reads today like an early dispatch from a conflict that’s still unfolding. The technical problem he described — firmware mixed into kernel source — has been largely solved through separation and repackaging. The political problem — who controls the software running on your hardware — has not.
There’s a generational shift happening too. Younger developers entering the Linux world often don’t share the ideological intensity of the movement’s founders. They want things to work. They care about privacy and security, but they’re less likely to refuse a Wi-Fi driver on philosophical grounds. This isn’t a moral failing. It’s a reflection of how the computing world has changed. When Richard Stallman launched the GNU project in 1983, the line between hardware and software was relatively clear. Today, firmware blurs that line almost beyond recognition.
The work that d’Itri and others did to create clean separation between free and non-free components in Debian remains one of the most important pieces of infrastructure in the distribution’s history. It allowed Debian to maintain its principles for years while still being usable. And when the project finally decided to change course and include non-free firmware by default, it did so with full transparency — a public vote, open debate, and a clear record of the decision-making process. That’s how governance should work in an open source project.
Hardware vendors, for their part, have shown little movement toward opening their firmware. Intel publishes firmware binaries but not source. AMD has made some strides with open documentation for older GPU architectures but keeps current firmware proprietary. Qualcomm and Broadcom remain largely opaque. The market pressure to open firmware simply isn’t strong enough, because Linux distributions — Debian now included — ship the binaries without demanding more.
One exception worth noting: the coreboot project, which provides open-source firmware for system boot (BIOS/UEFI replacement), has made genuine progress. Companies like System76 and Purism ship laptops with coreboot-based firmware, and Google uses coreboot in every Chromebook. But coreboot addresses boot firmware, not device firmware. Your laptop might boot with fully open code and then immediately load a proprietary blob to run its Wi-Fi chip. Progress is piecemeal.
D’Itri’s blog post from 2008 didn’t predict all of this. It didn’t need to. It identified a structural problem and proposed a practical solution. The Debian project adopted that solution, built on it for over a decade, and eventually decided that even the compromise wasn’t enough — that users needed firmware available out of the box. Whether you see that as a victory for usability or a defeat for software freedom depends entirely on where you stand. But the engineering work that made the choice possible? That was unambiguously good.
The firmware debate will continue. It’s one of those problems that doesn’t have a clean resolution because it sits at the intersection of law, engineering, ideology, and market economics. What d’Itri gave the Debian project — and by extension the broader Linux community — was a framework for managing the mess. Not solving it. Managing it. Sometimes that’s the best you can do.
WebProNews is an iEntry Publication