Comment by amosbatto

Purism has said that it will be providing proprietary firmware updates, and it already has instructions how to update the firmware for the RS9116 WiFi/BT on its web site.

Because Purism selected components for the Librem 5 that will be manufactured for many years, it is more likely to get firmware updates than most smartphones. Because the drivers are all FOSS, they can be updated by the community, and some cases the manufacturer helps maintain the mainline Linux drivers, so timely updates are very likely. For example, NXP promises to sell its i.MX 8M Quad processor until at least Jan. 2028 and it helps maintain the mainline Linux driver. Likewise, Redpine Signals helps maintain the mainline driver for the RS9116 WiFi/BT and likely to keep manufacturing the chip for at least the next 5 years.

In contrast, the SoC used in a typical smartphone is only manufactured for 1-2 years and it typically only gets 2-3 years of support from the manufacturer, so the Librem 5 is more likely proprietary firmware updates than most smartphones.

As for the question of whether it is better to store the proprietary firmware in the /lib/firmware directory or in the component or in Flash chips on the motherboard, there are advantages and disadvantages, so you have to weight what is important. When firmware is stored and loaded from the /lib/firmware directory, it is easier to update and the user will automatically get the latest firmware when upgrading the software on the device. In contrast, the user has do a separate procedure to upgrade the firmware and many users are unlikely to do it, so any potential security holes in the firmware are less likely to be closed with updates. However, a lot of this depends on what Purism does in the future to push firmware updates, so we shouldn't automatically assume that the Librem 5 will be insecure. The benefit of not storing the firmware in /lib/firmware is because it makes the user more conscious of the proprietary blobs on the device, and the user can make a deliberate choice whether to install firmware updates or not, after reading the description of each update. Also, it is harder for the firmware to be hacked by a bad actor when it is stored in the component or a separate Flash chip, because it requires a separate procedure to flash the firmware, so it can be argued that it is more secure. Another benefit is that system updates can be offered without including any proprietary files, so there are no restrictions on how they are distributed and installed.

In terms of promoting software freedom, I don't know of any cellular modems or any GNSS with FOSS firmware. There were only two WiFi/BT model series whose firmware was reverse engineered by the community but they never got past the experimental state and are now hopelessly outdated since they were 802.11b/g devices. There are some ath9k 802.11n models that required no firmware, but they have poor range and are energy inefficient and require proprietary firmware for the Bluetooth.

In other words, there is no realistic way to make a modern computing device without proprietary firmware, and the only hope is to pressure the manufacturers to release code or documentation for its firmware, but the modern patent situation with wireless communications makes that extremely unlikely to happen. However, the FSF's insistence on trying to separate the proprietary firmware and not let it be executed on the main CPU cores does draw public attention to the problem and show the component manufacturers that there is public demand for free firmware. When companies like Purism go through extreme steps to avoid executing DDR timing code on the main CPU cores, by adding a separate SPI Flash chip to the board to hold the blob and not using the Cortex-M4 core for any other purpose but to execute that blob, it sends a message to NXP that its customers really hate that proprietary blob and it should be eliminated. In contrast, a company that stick that blob in the main Linux file system tells NXP that its customers don't care about that blob and there is no pressure for NXP to eliminate it in future chips. The value of buying RYF products like the Librem 5, RaptorCS computers and Lulzbot is that it is creating a public statement that consumers care about not having proprietary blobs, and that the hardware industry should cater to that crowd. What Purism is doing value in promoting a public message and it is based on a long-term strategy to pressure the industry to free its firmware, whereas the people who criticize it have no strategy for ever achieving change. If they have an alternative strategy for how to free the firmware, I would love to hear it.

The more important point is that Purism selected components from hardware companies that are more willing to collaborate with the community and listen to Purism's requests, so there is more possibility of driving change up the supply chain. Purism paid Redpine Signals to modify its firmware so it could meet the RYF criteria and NXP engineers work with the community on the mainline Linux driver for the i.MX 8M, so it is possible to influence these component suppliers.