LWN: Comments on "The FSF's Librephone project"

blob or not to blob

decorum — Wed, 15 Oct 2025 06:23:49 +0000

One can only hope that they don't fail to meet this high standard. With current hardware, you won't get by without blobs. Or you get a RISC-V based smartphone where the drivers are open source.

Perfection is the enemy of good

marcH — Wed, 15 Oct 2025 05:35:54 +0000

> It seems to me that it's for "intellectual property" reasons, not functional ones.

How so? I really fail to imagine the legal conspiracy here...

Firmware is just software and exists for the very same reasons. Why do people use software ? Hardware is faster after all!

Perfection is the enemy of good

raven667 — Wed, 15 Oct 2025 03:03:24 +0000

I've only played a little with postmarketOS, the GNOME variant, and it looked like you could run waydroid on it, but I haven't had time to fiddle with it properly, is it possible to run F-Droid and Android apps on a postmarketOS phone, so you can get the best of both? Or are the other postmarketOS UI spins just as totally unfinished as the GNOME one, so only suitable for the enthusiast who wants a *Linux* phone.

Perfection is the enemy of good

dskoll — Wed, 15 Oct 2025 02:51:24 +0000

It depends on the hardware and on the blob. In some cases, it's for regulatory reasons... a provider of radio hardware might not want you to be able to use it at frequencies or power levels that are illegal in your jurisdiction and might choose to keep the firmware closed to make it harder for you to do those things.

In other cases, it's just way simpler to perform a function in software rather than hardware, and if you're going to need software anyway, you might as well make it field-replaceable so if bugs are found, they can be fixed on the fly. It's unlikely that said software contains intellectual property of any value and far more likely that it's embarrassingly badly-written and tied so tightly to a very specific piece of hardware that it would be almost useless for an end-user to try to tinker with it.

I don't know where the line should be drawn between "this restricts freedom" and "it's pointless to let users change this". It's definitely at a higher level than the hardware and a lower level than the operating system, but in between is fuzzy.

Perfection is the enemy of good

Trelane — Wed, 15 Oct 2025 02:29:36 +0000

Why does "nearly all modern hardware require require" binary blobs? It seems to me that it's for "intellectual property" reasons, not functional ones.

I would always prefer to not have my hardware held captive by a corporation if I can reasonably prevent it.

Perfection is the enemy of good

mikebenden — Wed, 15 Oct 2025 02:15:45 +0000

> With modern hardware, this distinction is even less meaningful [...] So even the hardware itself is really just "frozen" software.

I happen to fully agree with this perspective (hardware is a program compiled into a graph of gates, then either carved into silicon or configured into an fpga).

Working on that premise, where *should* the line rightfully be drawn between "give the users source so as to respect their freedom" vs. "it's obtuse of <insert activist / organization name here> to insist that source at/below this level of abstraction be provided so as to respect users' freedom" ?

Perfection is the enemy of good

dskoll — Wed, 15 Oct 2025 01:34:28 +0000

The FSF is ok with hardware that implements a function, no matter how complicated or buggy, but not with blobs that implement the same function and can be upgraded.

With modern hardware, this distinction is even less meaningful because the hardware is likely synthesized from VHDL or Verilog, which you could look at as being software written for a very weird machine architecture. So even the hardware itself is really just "frozen" software.

Perfection is the enemy of good

rsidd — Wed, 15 Oct 2025 01:09:43 +0000

Not only that, those blobs are actually better (for the user) than if they were hard-coded into the chips. A blob can be upgraded (proprietary or not), plus it's a lot cheaper. The FSF is ok with hardware that implements a function, no matter how complicated or buggy, but not with blobs that implement the same function and can be upgraded.

In the context of CPU microcode the FSF's attitude is even worse, as well laid out here.

In the context of mobile phones, are they planning to develop the hardware as well as the software? Because commercial manufacturers will have zero interest in doing so.

Perfection is the enemy of good

ttuttle — Wed, 15 Oct 2025 01:01:46 +0000

I mean, what you've described -- considering both parts -- isn't something most people would consider a phone.

Perfection is the enemy of good

hailfinger — Wed, 15 Oct 2025 00:42:18 +0000

Having a phone with kernel and userland drivers from postmarketOS and the Android UI from LineageOS would be a nice baseline from a usability perspective (Android apps available, and still kernel+userland completely free).

I love my postmarketOS phone and it is the most mobile Linux "desktop" I ever had, but it fills a different niche (Linux+mobile feeling) compared to the Android feeling. For me, right now the answer for "postmarketOS vs. LineageOS" is "both", each on its own device.

That said, I mostly agree with the previous poster on the unfortunate requirement of proprietary firmware blobs as those are not likely to go away soon. Having a free Android-style kernel+userland combined with firmware blobs is probably a realistic 2-year goal on a very limited set of phones. If blob-free implementations are a hard requirement, the easiest way to go forward is to remove/outsource the mobile radio functionality to a dedicated device and use VoWiFi on a blob-free handset. That way you could even get a RYF certification for the handset because the blobs live in a different device. The usuability would be severely limited, though.

Perfection is the enemy of good

ttuttle — Wed, 15 Oct 2025 00:37:11 +0000

Unfortunately, it sounds like that's exactly what they plan to do here.

Perfection is the enemy of good

pizza — Tue, 14 Oct 2025 22:29:50 +0000

The state of smartphone sofware is growing ever-crappier, but I hope the FSF doesn't let their highly myopic "RYF" attitude scuttle this effort before it ever gets started.

Nearly all modern hardware requires some sort of proprietary firmware blob to function... But those blobs barely register as a rounding error on the grand scheme of things (eg mandatory DRM and always-on ties to a datamining mothership)