> Making it inaccessible to tinkering is strictly worse for the user in all respects.

"all respects" is wrong. It also makes it so the proprietary developer can't say "here is a new version, but you must agree to some very nasty license terms, or accept some malicious feature along with it." NOT having a capability does have advantages, a physical book is impossible to be remotely deleted out of existence by DRM, but sure, you can't tinker with the software.

edit: yes, I understand in that the case of sticking the exact same software in a rom vs a read-write memory hurts the ability of a user reverse engineering it, which could ironically decrease user freedom over time. Calling this out for FSF to address is a good thing.

You're taking the vendor at their word. You can't do this. It has happened before (see Intel vPro) that some feature is not actually impossible to activate, etc.

> proprietary firmware that is inaccessible to the user like in the Purism example. I hate that

Personally I'd hate that too - thankfully, that's not what happens on the Librem 5 (see my other comments in this thread for details).

People are parroting "the purism example...". Just stop it! Librem-5 is NOT certified!

But they want to be certified, and the hilarious RAM initialization workaround was absolutely done as part of trying to get certified.

Here's where Purism says that the reason for the workaround is indeed for attempting to get RYF certified: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

At most, the Purism case is a good a example of how hard it is to game the certification.

What the article describes is not particularly difficult to implement. But claiming that storing the firmware in a way that prevents the user from updating it via software somehow makes the device more "free" is absurd.

FWIW, nothing stops Librem 5 users from just throwing away all that nonsense code they wrote to load the firmware from a dedicated flash, and just flash standard U-Boot (which already includes a mechanism to embed the blob, which is the normal way to do it), at which point you can of course modify it or replace it.

Basically, it's a whole bunch of wasted engineering effort, but it in no way accomplishes actually turning the blob into "hardware" or making it immutable. It's just rules-lawyering. Which makes it even more pointless and nonsensical. The sticking point seems to have actually been not having the main CPU touch the physical bits of the blob (not execute; touch); avoiding that magically made it RYF-certifiable. This is why they moved the loading process to a secondary core (that still runs open source code, which then loads the blob into a third core that runs it).

> storing the firmware in a way that prevents the user from updating it via software

Nothing prevents the firmware being updated by the user on the Librem 5. The default kernel marks the SPI flash as read-only (mostly to prevent accidental soft-brick situations), but you can simply lift it up, or reflash it from the bootloader where there's no such restriction applied.

The firmware update is not intended to be done by the user - PureOS does not ever ask you to do that and it does not even provide the blobs in its repos; but if you want to update it for some reason, you're not prevented from doing so. You could always reflash the SPI flash with a hardware flasher (or even completely replace it) anyway, so it would be pointless to artificially prevent a motivated user from doing so in software. After all, they may be trying to use a free replacement that may show up in the future.