The Free Software Foundation is licking its chops at one of the last bastions of proprietary code in the smartphone with LibrePhone. It’s a multi-year effort to rid every layer of the handset of closed-source software well beyond its GNU/Linux base.
The mission is audacious: a phone with an inspection and modification environment as secure as possible. This project has begun, and FSF will work to magnify the momentum it receives. This is a long game, not a quarterly sprint, as FSF frames it.
- What a Real Free Phone Really Takes to Build
- Why Previous Efforts Fell Short of Full Freedom
- The LibrePhone Strategy and First Steps for Launch and Growth
- The Hardest Technical Knots to Untangle in Hardware
- Why This Matters Outside Philosophy and Ideology
- What Success Might Look Like for LibrePhone Users
What a Real Free Phone Really Takes to Build
Following the FSF’s Free Software Definition and its Free System Distribution Guidelines, “free” means users are in control of software—not just apps or even the kernel, but the hidden code that wakes radios, speeds up graphics, and produces camera images.
That means bootloaders, device drivers, firmware running on coprocessors, and even software that runs on separate chips such as secure elements and digital signal processors.
On modern phones, those pieces are a dense mixture of open drivers stacked on top of opaque “binary blobs.” Basebands communicating with cell towers, Wi‑Fi and Bluetooth chipsets, GPU firmware itself, and image signal processors are the more common forms of proprietary firmware. The removal or replacement of these blobs with free, auditable replacements is what LibrePhone is all about.
Why Previous Efforts Fell Short of Full Freedom
We have witnessed credible steps but not closure. Replicant, for its part, swapped out swaths of Android with free software years ago, only to slam into undocumented modems and graphics engines. PostmarketOS (and Ubuntu Touch and GrapheneOS and /e/OS) deliver de-Googled or Linux-first experiences, but they still rely on loading proprietary firmware to actually get enough of the hardware working.
The structural factors are well established. Chipmakers frequently put specs behind stringent NDAs and there are a lot of subsystems (firmware aside) that have no available source. Legal systems provide friction: anti-circumvention rules put those circumventing protections at risk, and while reverse engineering for interoperability is a legal doctrine, it’s not a great one—it’s narrow and incompletely understood. Nor does market concentration help—analysts such as Counterpoint Research estimate that Android and iOS cover well over 99% of shipments, which will leave component makers with little reason to open documentation for tiny niche volumes.
The LibrePhone Strategy and First Steps for Launch and Growth
LibrePhone begins with pragmatism: first, find a handset with the least and most fixable “freedom blockers,” then replace those proprietary parts incrementally. Engineering focus will be on clean-room reverse engineering, reproducible builds, and upstreaming drivers into mainline Linux where applicable. The team will reportedly first prioritize selecting hardware that can be unshackled quickest, rather than picking the flashiest specs, according to Android Authority.
Rob Savoye, longtime GNU contributor in the embedded space, is leading this effort technically. Look for regular use of test harnesses to record behavior on devices, absolute segregation of baseband and application processors, and ruthless compartmentalization so that unfree elements are ring-fenced and controlled where they cannot yet be replaced. The PinePhone and Purism’s Librem 5 have already demonstrated how valuable modular radios and hardware kill switches can be; it is likely that some level of inspiration will be drawn from those projects as well, with the goal to take things even further by doing away with blobs entirely.
The Hardest Technical Knots to Untangle in Hardware
Cellular modems are still the stickiest bottleneck. One company bolsters the other, and please don’t tell me or any reader of Ars that vendors are happy to reach the promised land voluntarily. Regulatory requirements demand compliance, carriers require certification, and both push zero-choice, locked-down basebands with their own proprietary stacks. Even when the baseband runs on a different processor, FSF criteria classify firmware as non-free unless it can be studied and replaced by users. Wi‑Fi and Bluetooth have similar issues, with most chipsets loading closed firmware during boot.
Graphics and camera subsystems are another layer. Although community projects like Freedreno and Panfrost have provided free acceleration for certain GPUs, many devices rely on proprietary microcode or ISPs with opaque pipelines instead. And then there’s the secure boot chain: what devices block on today is having vendor keys and trusted execution environments. Swapping that for a user-controlled, verified-but-embargoed boot flow—without also tearing down defenses—is going to be tricky, and will require some careful cryptographic design plus upstream enablement.
Why This Matters Outside Philosophy and Ideology
Security matters to more people than free software purists. Firmware that can be audited minimizes the attack surface and expedites incident response. Baseband and Wi‑Fi vulnerabilities that can be remotely compromised receive so much new attention today, in part because of research by Google’s Project Zero and several university labs; the opacity of those parts allows the community to inspect how they are repaired—or even to patch them in their entirety.
There’s also digital sovereignty. More and more journalists, NGOs, and public agencies demand that systems provide them with verifiable supply chains as well as reproducible builds. An FSF-certified stack, with mainline Linux drivers and public documentation, would provide a new gold standard for trust in mobile computing—valuable to civil society and sensitive enterprise deployments.
What Success Might Look Like for LibrePhone Users
Short-term, success is choosing a workable reference device, getting free drivers upstream, and publishing replicable ways of replacing certain components with free alternatives to specific blobs. Mid-term, this could mean an FSF-endorsed mobile distribution that conforms to the Free System Distribution Guidelines and a hardware route to the Respects Your Freedom certification, which no smartphone has earned so far.
And, longer term, real victory would be cultural as much as technical: chip vendors releasing open documentation, permissive firmware licensing for radios and GPUs, perhaps even new designs like a RISC-V design or whatever else that acts free from the word go. It will take years. But if LibrePhone can incrementally transform a single closed subsystem into a free, auditable one, the industry will find itself tugged in that direction. The project is shooting for a moving target, and that’s precisely why it matters to start now.