A new project supported by the Free Software Foundation is raising awareness of a particularly acute problem in the Android experience — proprietary blobs. Update: Ayache says Librephone is a project whose goal is to replace proprietary vendor code with open-source, auditable solutions like the one in his concept device below in at least one phone and hopefully more.
The concept is straightforward, even if the labor of implementation is not. Android itself is open source, but the vast majority of phones rely on proprietary components for core capabilities such as graphics, cellular connectivity, cameras, and sensors. Librephone will choose a device with the smallest number of replaceable blobs that someone wants working and bring those parts back into free software by clean-room reverse engineering them.
We Do Not Have Open Source Drivers And Here Is Why
Custom ROMs, like LineageOS for instance, aim to bring users transparent and community-maintainable software. In fact, they are still leaning on binary drivers and firmware ripped from stock images to even get newer hardware running at all. Even privacy-first distributions such as GrapheneOS have to ship or require users to bring vendor components for the cameras, GPUs, Wi‑Fi, Bluetooth, and modems to enable.
Project Treble and the Generic Kernel Image for Android improved modularity by keeping vendor code in separate partitions. That separation does help keep maintainers from falling too far behind on system updates, but it doesn’t eliminate opaque dependencies. Once a blob is buggy, insecure, or incompatible with an updated kernel, the community can’t fix it without access to the source or another driver.
That risk is not hypothetical. Security researchers have consistently found weaknesses in baseband stacks and device drivers, categories of code that are more difficult to scrutinize when the source is closed. And beyond that, once OEM updates cease completely, users are often left sitting on unmaintained firmware even when the Android side of things is patchable.
Inside the FSF Librephone Plan and Goals
According to the FSF, Librephone will start by scoping the proprietary bits in popular handsets and identifying a target that has “the fewest, most fixable freedom problems.” In practical terms, that probably means focusing on components where there’s a certain amount of community knowledge already (GPUs or some sensor stacks, for example) while understanding modems and camera ISPs may be tougher to crack.
At the heart of the process is clean-room reverse engineering: one team documents behavior and interfaces, while another writes original, compatible code without ever laying eyes on the original binaries. This approach has been the way things are done for a number of years now, and it’s worked out — Samba did Windows file-sharing interoperability this way, as have open source graphics drivers like Freedreno for Qualcomm GPUs and Panfrost for ARM Mali that are now part of Mesa.
Success will hinge on collaboration. The kernel developers, the Android HAL gurus, and the security researchers will have their parts. Among the project’s early milestones are open replacements for certain specific subsystems, which can be tested on a single phone before being expanded to other chipsets and devices with similar setups.
Legal And Technological Obstacle Course Ahead
Reverse engineering is legally nuanced. In the United States, some exemptions for interoperability and security research have been recognized by the Library of Congress, but teams are still required to adhere to strict clean-room methodologies to avoid infringing on licenses. In other areas, there are such exemptions in competition and consumer protection systems, but various interpretations exist.
Structurally, some layers are also more tractable than others. Open GPU drivers are coming of age and can drive desktop Linux environments with Vulkan support, so mobile graphics could have a future. In contrast, the cellular basebands commonly use signed firmware and communicate with strictly controlled radio stacks. Even if the completely free baseband seems hopelessly out of reach at first, isolating it and liberating everything around it can only increase transparency and decrease the size of this attack surface.
Cameras present another challenge. Contemporary image signal processors and vendor camera HALs can be intricate and performance-sensitive. Projects like libcamera show that open-ended frameworks can work in practice, but emulating proprietary tuning and features will be difficult and will require time to catch up, as well as ongoing device-specific expertise.
What Success Would Mean For Users And OEMs
And if Librephone wins even partial victories, the result is palpable. Users would have devices that could be expected to last longer, with fewer unpatchable components and code that independent researchers can audit. Custom ROM maintainers would then be able to update sooner, without waiting on vendor blobs lagging behind support.
History suggests that community drivers eventually reach or exceed vendor quality. The Linux drivers for graphics, based on Mesa, have gotten awesome over open development and constant testing. A similar arc on mobile might push chipmakers toward more open interfaces and documentation, especially as right-to-repair and sustainability concerns get policy traction.
The Broader Open Source Context for Librephone
Previous efforts demonstrate both the potential and the challenge of bringing a fully free phone to market. Replicant sought devices that could “work without needing any software that is not freely distributable (i.e., no proprietary drivers).” Support was found for only a few old devices. General-purpose Linux phones, such as the PinePhone and privacy-tinted options from vendors like Purism, show what can be done with openness — but they lag behind Android devices when it comes to camera quality and power efficiency.
That would be notable when you consider the somewhere-in-the-ballpark 3 billion active Android devices worldwide, but again, a single popular device that is far lower on blobs would be great. It would provide a more solid base for privacy-respecting ROMs and potentially set an example for obtaining freedom with further models.
It will be a long road that Nitrokey goes down, but the way forward seems clear: target something real-world-useful, throw away the replaceable junk as best we can, quarantine what we can’t, and work on showing these modern smartphones can be fast, private, and maintainable devices that don’t rely on secret code to raise their little arms up high.
