If it is being updated by GRUB, then proprietary code is being executed on the main processor by the main operating system, so the secondary embedded processor exception in the RYF criteria doesn’t apply. This was exactly why I asked the FSF what it means by “software installation is not intended after sale” and why it wrote “not intended” instead of “not allowed”. It seems to me that the FSF must have known that there must be exception like this for security holes and bugs in the hardware:
The intention of the manufacturer is that the firmware doesn’t need to be upgraded after sale in order for the device to function, but something unexpected like a security hole or a bug may be discovered in the future that wasn’t intended.
My point is that the FSF should be upfront about this unacknowledged exception in its RYF criteria, so people don’t think that they have to live with hardware which might be discovered to be buggy or insecure in the future.
If I’m wrong in thinking that the FSF has an unacknowledged exception for problems like the Crucial SSD, then the Librem 5 could design a special boot mode that only executes on a “secondary embedded processors” (the Cortex-M4 core in the i.MX 8M Quad, the separate Cortex-M4 processor for the smartcard reader, or maybe the USB PD chip) for updating the firmware. Otherwise, the only solution is to put the Librem 5’s M.2 cards in your PC and upgrade them there, and do some strange workarounds like soldering wires on the Librem 5’s PCB and use an external device to flash the chips.
If the Librem 5 needs to have a special boot mode running on a Cortex-M4 core, I want Purism to have thought about it before releasing Evergreen, so it can be implemented later in the software and there is nothing in the hardware that prevents it from being implemented.
The more that I think about the RYF rules, the more I think that RYF is simply a poor strategy for promoting software freedom. You can’t build a modern ICT device without WiFi/Bluetooth, SSD controllers, and a dozen other things that require proprietary firmware updates.
At this point, we should acknowledge that the community has only managed to create free firmware for 2 families of WiFi/Bluetooth devices (Prism54 and some Broadcom 43xx) and the firmware is experimental (i.e., doesn’t work well) and it only runs on ancient devices that only support 802.11b/g. The idea that the community is going to reverse engineer the firmware for a modern 802.11n/ac/ad/ax device is ludicrous.
Every single free driver for a recent WiFi/Bluetooth device was either written by the manufacturer (Intel, Marvell, Redpine Signals, Qualcomm/Atheros, Realtek, Broadcom, Texas Instruments) or was based on code and/or documentation from the manufacturer (MediaTek/Ralink, Marvell), and not reversed engineered by the community. What happened was that WiFi/Bluetooth manufacturers decided that they wanted to be able to sell to the Android market and/or server markets, and the Linux kernel doesn’t deal well with proprietary drivers, because upgrades in the kernel can break the driver, and there were also security concerns with using binary blobs. The WiFi/Bluetooth manufacturers got feedback from device makers that they wanted them to release free drivers for the Linux kernel and market pressure made it happen.
The question is how to get WiFi/Bluetooth manufacturers to release free firmware for their devices (or documentation so the community can create firmware). The only viable strategy is to gather together a bunch of device makers who can pressure/incentivize the WiFi/Bluetooth manufacturers. It is the same situation with SSD controllers, USB controllers, cellular modem/GNSS, etc. The patent situation makes if very difficult, because no manufacturer wants to give competitors their implementation details for fear of patent lawsuits, but if we are ever going to pressure the component manufacturers to release free drivers and free firmware, we need to have a block of device makers demanding it.
As it stands now, the FSF has no ability to organize the device makers to call for free firmware, because most RYF device sellers just take equipment made by other companies and install free software, so they have almost no ability to influence the original component manufacturers. If Vikings, Ethnotechnical, MiniFree, Libiquity, Zerocat and NitroKey call up WiFi/Bluetooth manufacturers and say, “we would like free firmware for a WiFi/Bluetooth chip”, they will get laughed out of the room. If Purism and Raptor Computing Systems call up, they might get a polite email saying its not possible, because they manufacture new hardware, so they are talking to component suppliers.
Imagine, however, if we have a block of 40 Linux hardware manufacturers all asking for free firmware. Then, we have some real leverage in the electronic component industry. For that reason, I think that the FSF should create something like a “best practices” certification, which is based on classifying the manufacturers of each type of electronics component.
For example, in CPUs:
- “Heroes” category (provide free drivers and free firmware, or firmware is not needed):
IBM Power9 - “Contributors” category (contribute free drivers to mainline Linux):
Intel Core, AMD Ryzen, NXP i.MX 8M, Rockchip RK3399 - “Providers” category (provide free drivers, that the community can integrate into Linux):
Qualcomm Snapdragon, Broadcom BCM2711, Amlogic S912 - “Sharers” category (share information about hardware so community can create free drivers):
Samsung Exynos - “Community” category (the community has reverse engineered free drivers):
Allwinner A64 - “Garbage” category (there are no free drivers):
Apple A-series
Then, FSF can certify devices as “best practices” if they select the best available components. For example, for mobile devices, there is no CPU in the “heroes” category, but there are several in the “contributors” category, so the device has one of those. Then do the same with other component categories (WiFi, cellular modem, GNSS, SSD controller, etc.).
Then, component manufacturers will start looking at the list and plan how they can be moved from “contributors” to “heroes”, or from “sharers” to “providers”, because they know that it will help when trying to sell components to makers of “best practices” devices.