Earlier quoted context omitted.
I'm not arguing with your overall comment, because I think it's a decent summary of the FSF's position. But a few nitpicks with their position: > The FSF's argument is basically the following: Consider a blackbox hardware system, such as a chip. Inside the chip, you may find a bunch of logic gates, hardwired to be a finite state machine, or you may find a read-only Mask ROM driving the microprocessor. But it's irrele…
Thanks for the comment. I think your comment still has some unresolved problems on drawing the hardware and software boundary. Before I start, I have to say the same thing: I'm not arguing with your overall comment, I think it's an interesting argument. But some details need improvements. Using the same SMPS controller chip as an example. It can be either an analog system, a digital finite state machine, or be driven…
The FSF had to pick a boundary for their view of the problem (and hardware used to be much more open back then), but now that boundary is being rules lawyered it's important to point out that it is still an arbitrary boundary.
I also reject designating some hard "Libre" line, where we would say a device is either full "free" or "not free". Freedom in the wider world is not a binary property, and so we wouldn't expect software to be. That was the point of designating less free things with a lower number - so that as the norms and expectations of freedom advance, higher numbers can be allocated. For example, imagine a device that comes documented with a schematic. A schematic doesn't fall under the definition of "software freedom", and yet is quite handy to have if you're modifying the device's software!
In fact continuing this line of thought, I think a large part of the original topic's critique (which I share) is due to the FSF taking their hard line of "free and "non-free" software (which is a hard distinction because every software has a license), and attempting to transplant it to analyze devices.
The libreboot / AMD video card example was is to describe a different issue - the orthogonality of the freedom of a device's main domain versus its peripherals. In order to make use of a Libre device, we have to compromise on freedom of its surrounding peripherals. To support my Libreboot desktop, there are countless non-free blobs that I write off as "non-updateable", if I'm even aware of them.
If I do focus on any one of these devices specifically (say a USB hub, network card, or a video card), then it makes sense to talk about its own software freedom (cutting through this current "hardware" terminus). But its own Libre status doesn't reflect on the main domain, regardless of how it gets its firmware. If it runs a proprietary blob that gets loaded by the main CPU domain, then the main domain's freedom is only affected if the process of loading that blob is also a blob. If the loading is done by Free software, then the main CPU domain is still fully Libre. And so if we're talking about an integrated device, which is any device, then it makes sense to split out freedom scores into different categories of the main processor plus support systems.
And yes, I have completely ignored the microcode in my processor for that example. In fact, I personally even go against the FSF and install the updated microcode, because I don't see much philosophical difference to trusting AMD of when they manufactured my processors, or trusting AMD of when the virtualization-fixing microcode was released.
IMO the Freedom compromise isn't merely updating the microcode, but rather using a microprocessor with changeable microcode and other undocumented locked-down internals in the first place. But for a performant desktop, I believe this is one of the best solutions right now. This is also why I want to leave room at the top of the freedom scale, so that better solutions can get recognized for Freedom improvements, whether they are yet to be developed or currently existing solutions that trade off performance (eg some of the RISC-V/FPGA ideas).