Basically, if the firmware is not intended to be updated it’s fine. But distributing updates, like security fixes, for firmware as blobs is somehow bad.
However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software.
Not really weired. For example, a keyboard has a firmware. 99% of keyboards have no way of it being updated or changed. It is part of its electronics. So not a big deal. But, if a keyboard has a way to update the firmware or install another one, then it should be FOSS.
Yeah, the FSF stance on firmware is really weird.
Basically, if the firmware is not intended to be updated it’s fine. But distributing updates, like security fixes, for firmware as blobs is somehow bad.
https://ryf.fsf.org/about/criteria
Here’s an article from the previous time (?) this topic came up.
https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/
Not really weired. For example, a keyboard has a firmware. 99% of keyboards have no way of it being updated or changed. It is part of its electronics. So not a big deal. But, if a keyboard has a way to update the firmware or install another one, then it should be FOSS.