I tried to explain before why this is a total theoretical point. This firmware is already there! It is just hidden away from your sight by putting it into some chip where you can not see, analyze, study or change it. But it is there! And the, at least for me, wrong turn of the FSF RYF is that as long as this firmware is hidden away from you then it is OK while if you can see it and have even more freedoms (to replace it, study it etc.) then it is not OK.
Sorry, but this to me makes no sense at all.
Or to make this a bit clearer, just because some chip does not need a firmware download at runtime it does not at all mean that there is no firmware. Current silicon and hardware technology trends into more and more software defined hardware, i.e. by some form of firmware. We can not prevent that and IMHO it also does not make much sense. By trying to limit ourselves to components that run without a firmware download at runtime we either limit us to ancient hardware or to hardware which is even more locked down by their makers and vendors than the ones with the firmware download - if it gets downloaded at runtime then I can change it, replace it, eventually modify it etc. All of that I can not do (most of the time) if the firmware is in hardware. Take the Atheros WiFi we currently use as an example. The card has a firmware, but it is embedded in ROM on the card and can not be changed by the user. Is this really better?
I have tried to point this out before, if someone (regardless of who) would pull out these blobs, that are there anyway, into the open, then these IMHO must follow some rules that I would really never compromise on, like:
- irrevocable perpetual license to copy and redistribute the ‘blob’ as part of anything a user chooses
- the blob must not contain code that gets executed by the same CPU running the operating system
No. 1 guarantees certain freedoms that are vitally necessary, e.g. to ship the blob in any form or fashion someone would choose and that also the proprietor of the blob can never ever revoke that freedom and with that eventually jeopardize e.g. an OS distribution or such.
No. 2 is a safety precaution so that no untrusted code will eventually get executed in the operating system domain that could jeopardize user’s security.
The discussion is not and can not be about “closed source firmware” yes or no. These are already there and are accepted, even by the FSF and the RYF. The discussion we need to have is about where this kind of firmware can be stored, eventually what kind of firmware this can be and which rules we want to apply to it. Again, these firmwares are there, we have them already, the FSF RYF accepts them under certain terms, which IMHO are questionable, and these firmwares will not go away, rather the contrary.