See https://www.fsf.org/campaigns/free-bios.html for the rationale.

Basically, FSF had to make a compromise here. If you use Flash ROM (or other writable medium), the firmware counts as a nonfree software. However, if you use actual ROM, the firmware might as well have been a circuit baked right in the product, so it counts as hardware; nevertheless, it counts as non-free.

FSF's ultimate goal would of course be to be able to certify that every component (hard or soft) of the system is actually free. However, this isn't very practical, since no consumer-grade computers will be considered free due to proprietary CPUs (e.g. Intel, AMD, ARM), which is why FSF is stuck in a weird situation. (How would you make exceptions for the CPU stock microcode and not the BIOS, for example?)

For that matter, I hope RISC-V helps us go a step forward...

Yes, they have a rationale, but it's a poor one. Followed to its logical conclusion, I can make any program free. All I have to do it put it in ROM. Then I can pretend it is part of the hardware. Software in ROM is not hardware, it's just software that can't be improved or fixed.

The other point they ignore that if some part is programmable but currently requires proprietary firmware, it's possible (and this has happened) that people reverse-engineer it and produce free software that runs on it. BUt if you bought the FSF-blessed version of that device you're then stuck with the proprietary version of that program forever, and worse, you can't get any updates for that program. You can't get a security fix, and you can't replace it with the free program.

> The other point they ignore that if some part is programmable but currently requires proprietary firmware, it's possible (and this has happened) that people reverse-engineer it and produce free software that runs on it.

If this is possible, then device makers should do it, ship the free-software firmware on the device, and then get it RYF-certified. No blobs needed, ROM or otherwise! Problem solved!

It seems like a feature, not a bug, that the RYF certification process makes it more painful and expensive to release devices that rely on proprietary software.

> If this is possible, then device makers should do it, ship the free-software firmware on the device, and then get it RYF-certified. No blobs needed, ROM or otherwise! Problem solved!

The device maker could ship with programmable proprietary firmware and have the possibility of being RYF-certified in the future if someone writes free firmware. Or they could ship with proprietary firmware in ROM and be guaranteed RYF certification immediately. The rules encourage them to pick the second option, and it's no surprise that companies such as Purism have done so.

Yet that option is never better for user freedom, since making software un-upgradeable does not make it any more free. And occasionally it is worse, in the event free firmware becomes available later on.

It sure sucks that device makers just have to wait and hope someone writes free firmware. If only they had some way to cause the firmware to be written, perhaps involving things like "money" or "employees" or "contracts with vendors".

The alternatives to this policy are allowing all blobs, in which case the RYF certification isn't actually verifying anything, or not allowing any blobs, in which case RYF cannot certify any devices made after 2009 (something the author also takes issue with). Making it expensive and risky for device makers to rely on blobs is the only middle ground that makes sense.

You seem to miss that these devices are often full of patented parts, so in most cases even if the manufacturer wanted to, they can’t provide sources. Also, modems are often legally mandated to have certain firmware (so that restricted frequencies are adhered to)

> even if the manufacturer wanted to, they can’t provide sources

In many cases they don't even have them or may not be aware that there's an upgradable firmware in some of the components they're using at all.

Why would they spend time and effort on this, when there's a far simpler way to get the certification with existing non-free blobs?

No, the alternative is to not be a binary yes or no certification, but to construct a nonbinary scale to measure how free it is.

Whether it's loaded into RAM or ROM is the most useless distinction to make. It's functionally identical. Now whether a driver requires executing proprietary code on the host CPU, that is a useful distinction to make, because it allows independent OS implementations to create free drivers.

It isn't identical. With a fixed ROM, every user is denied an opportunity to upgrade rather than just those without an anointed OS. It's about equal access.

Sounds like a good reason to certify hardware that puts firmware in RAM.

Most peripheral ICs have an on board micro with internal RAM and flash. Their RAM isn't typically accessible.

Nevertheless, the first thing the driver for wifi in my laptop does is load up a big firmware file from disk, caused to be shoved into IC RAM, and then proceed to connect to the network. That this process could somehow become more free by embedding a frozen firmware image blows my mind.

And it's not like I haven't seen what the other side looks like. The Broadcom "full MAC" chipsets are also supported, with their remotely exploitable firmware. But those are also "fully" free. Hurray.

RISC-V is foremost about freedom from licensing rather than open-source so I'd hold my breath

The FSF had to make a compromise, but many people think they drew the line in the wrong place. When no reasonable hardware can meet the "compromise" version of RYF it just causes users to bounce off.

I think the issue isn't that much that no reasonable hardware can archive it, but that the "compromise" actively encourages not just insecure systems, but also making systems even less free.

It's a bit like saying that a Windows notebook is only "free" if you can't install other systems and updates are disabled. There probably is more or less reasonable hardware which could implement these restrictions, but such hardware would in no way be more "free" than a notebook where you could just install Linux.

I think a good analogy is the parable of the cobra problem. A city suffers from too many cobras so the government puts a bounty on each dead cobra you hand in. The result? People massively breed cobras to hand them in. The government realizes this and stops the program. Subsequently all breeders lose interest and dump the cobras, leading to an even bigger problem.

So first off, putting something in mask ROM[0] does not make it equivalent to a circuit. Circuits cannot be copyrighted[1] but mask ROM programs can be; meaning the latter is just as non-Free as rewritable software. It is legally silly to distinguish between read-only and rewritable software, even if it might have a small engineering upside of prohibiting the imposition of new antifeatures.

That doesn't mean that mask ROM is free of antifeatures, though - in fact, often times mask ROM is the highest privilege level in the system and thus the best place to put antifeatures. In the case of x86 PCs, the BIOS gets it's own privilege level above the kernel; ARM PSCI also runs in EL3 above normal kernels or hypervisors. These can still actively damage user freedom even if it's "technically hardware" and non-updatable.

Also, the fact that it's not rewritable means that...

1. Security bugs[2] will never be fixed[3], rendering the hardware unsafe to use over time.

2. We cannot practically replace the firmware with a Free equivalent.

It should not be understated that the vast, vast majority of hardware did not come Free. We had to open it ourselves through painstaking reverse-engineering and reimplementation work. This is an ongoing burden that the community must meet for the foreseeable future. Manufacturers are not going to stop shipping hardware with proprietary firmware or drivers anytime soon. Ergo, anything that stands in the way of firmware or driver reimplementation is, in my opinion, bad. This includes making it more difficult to update or replace firmware by putting it into a mask ROM.

My personal opinion is that you can't really draw a line in the sand and say, "this hardware respects your Freedom, but this other hardware doesn't". Hardware manufacturers have zero interest in fully-Free firmware, and I don't expect this to ever change. Not even with RISC-V, which will almost certainly have even more "embedded" fragmentation than ARM does. Whatever standard the FSF writes for "Respects Your Freedom" hardware, someone is going to try and rules-lawyer non-Free software into getting that badge. So they should not provide a strict standard at all.

There's also another question of how much energy we actually want to burn on getting Free firmware into chips. An alternate interpretation of the idea behind the Free BIOS campaign is that the BIOS itself got "interesting" enough to be a Freedom threat. Back when it was still a ROM, Free kernels could ignore it entirely; now it gets it's own privilege level and has to at least be considered. CPU microcode is less of a threat than the BIOS, here - the microcode just lets you patch how certain instructions get decoded, while the BIOS can actively debug and spy on Linux.

[0] I am going to use the term "mask ROM" loosely. Consider one-time programmable memories like PROM or EPROM to be in the same category, as they cannot be electronically erased and then reprogrammed by the same circuit that uses them.

[1] There is a sui generis right for "mask works", but it is far less toxic than software copyright. For one, it has a reasonable term length.

[2] I am assuming security from the standpoint of an end-user, of course. Being able to defeat TiVoization is not a security bug for me.

[3] It is possible to swap ROM chips in some cases, if the part is socketed, or if it is soldered and the user has the appropriate level of soldering skill. However, at this point this is no longer read-only. It's just Flash memory with extra steps. There is no legal or ethical difference between reflashing a chip with proprietary software on it and replacing it with a new chip with new, proprietary software on it.

> Also, the fact that it's not rewritable means that...

> 1. Security bugs[2] will never be fixed[3], rendering the hardware unsafe to use over time.

But on the other hand: security bugs will never be introduced post-manufacturing. Additional DRM cannot be forced onto you, after you bought the product. Or: DRM bugs that allow you to fully use your hardware cannot later be patched by the vendor.

Without the source there could be all sorts of timebombs or tripwires in the firmware. For instance a device refusing to operate unless another device was present or changing behavior after a certain date.

This is the insight I wanted.

Now I want to hear what FSF has to say about this...

Bookmarking it.

The malicious/abusive parts of nonfree software are almost always tied to it's updatability. Avoiding updatable nonfree software prevents users from entering into an abusive relationship with a nonfree software vendor. https://www.gnu.org/proprietary/proprietary.en.html, 550 instances of malicious functionalities, I'd bet all instances are for software where the vendor can update it.

Your argument is like "Banning guns will incentivize people to use knives, people who want to only ban guns for violence sake are hypocrites." There is a kernel of truth, but it's really just ignoring the bigger reality.

People keep bringing this up like proprietary software can always be unilaterally updated by the vendor. That's not how it works with firmware blobs, the vast, vast majority of the time. The user has the choice to run whatever firmware version they want, for as long as they want. They have strictly more freedom than if the software were not updatable, since they can choose the least evil version.

I can't believe people are still trying to use this argument. It's plainly evident that mutable software gives you more choice than immutable software. Making the argument that autoupdaters are evil and can be abused doesn't suddenly make all mutable software more evil than immutable software.

Incidentally, I'm on their list as a victim:

> 2010-03

> Sony restricted access to the PlayStation 3 GPU, so people who installed a GNU/Linux operating system on the console couldn't use it at full capacity. When some of them broke the restriction, Sony removed the ability to install other operating systems. Then users broke that restriction too, but got sued by Sony.

I'm one of the people who got sued by Sony. And I still think the FSF's take on all this is terrible.

The rationale seems to be that if the vendor is able to update the firmware at a later date, then the customer should also have that ability in order for it to be certified.

I just wanted to say I appreciated this comment. You clearly condensed what the problem is, and now I feel like I better understand the situation. It does sound like hypocrisy but in an unworkable, non-starting situation for the FSF.

(Bravo.)

Thanks. I understand what the FSF is trying to do. I just think they've gone about it in a stupid way. I see it as an outgrowth if Stallman's old "microwave argument".

He is super zealous about using free software everywhere...until he isn't. His argument being that something like a microwave, despite having some non-Free software, isn't something that can be changed post-sale so he's ok using them.

1. It's actually an outdated example since we're now seeing appliances with Internet connectivity and EULAs.

2. It breaks down almost immediately with modern computer hardware. We're not running big beige towers whose only connectivity is some RS323 ports on the back. Most people are running computers with multiple highly regulated radios, internal batteries, and security subsystems. Fully user programmable functions of these are combinations of impractical, dangerous, and illegal.

I still donate every year to the FSF but these crusades just make me slap my forehead. They're feel good campaigns and encourage more harm than good.

This is what I missed, well put.