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)
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.
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.
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.
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...