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 by a microprocessor core with firmware. Since it's only an internal implementation detail in the silicon, in my original comment, I said that the FSF's opinion is to classify this chip as "hardware" and to ignore its existence.

You said this is undesirable, because software is still software, and for an organization that promotes free software, embedded firmware buried deep inside silicon should not be willfully ignored but seriously considered - as soon as it "rises to the level of using software" - especially when it's a piece of highly complex and sophisticated control system that we use every day but know very little on its internal workings. The same argument also applies to all types of firmware in controllers. Let me call it the Deep Firmware Argument, and to me it's very understandable.

And what you're proposing is that, instead of giving systems a Boolean pass or fail software freedom rating with edge cases and undesirable "rules lawyering", one should rate software freedom in a continuous spectrum: no system is fully free, only more free or less free. This is much more useful because the impacts of all non-free components are considered and reflected in a weighted score.

So far so good, I must say it's an interesting opinion.

But still, how do you define a piece of hardware that "rises to the level of using software"? In particular:

1. You argue that, in most controllers, true Mask ROM and One Time Programmable ROM are rarely used in today's systems. In fact, many are meant to be updated by the vendor. Thus, even if you make a motherboard and tying !write_enable HIGH in your own system, it's only a special case and doesn't change the big picture that the vendor is shipping non-free software to everybody. Thus, it is a strong argument for considering it as (non-free) software. Let me call it the Firmware Update Argument.

My question is, how would you apply this argument back to the SMPS controller chip example? To my best knowledge, most monolithic SMPS controllers are truly One Time Programmable, once the firmware is finished, it's set in stone, considered finished, and is only changed in a silicon update. Thus, I may as well push the Firmware Update Argument to the opposite conclusion - these systems are hardware, not software.

Thus, in this case, Deep Firmware Argument says yes, but Firmware Update Argument says no. How do you reconcile them? Are you suggesting that the firmware buried deep inside the silicon can be ignored, or at least is less important to care?

2. In your later example, you said a PC with proprietary GPU is still free enough, because "the main CPU domain is completely Libre." But is the main CPU domain really completely Libre?

The internal operation of an x86_64 CPU is controlled by a microsequencer running its own microcode. Furthermore, the microcode even supports runtime update. Using the Deep Firmware Argument, I argue that the CPU itself has already "rises to the level of using software", and using the Firmware Update Argument, it further strengthens this argument. Thus, the CPU is not completely Libre but you said it's Libre.

Yet when you were talking about a graphics card, you said because these graphics cards contain proprietary microcode or firmware, "you'd need some newly designed thing which also endeavored to be open, not just a video card from one of the big three full of proprietary software".

Therefore, I think you're contradicting with yourself in this example.

3. Where does the Deep Firmware Argument end?

If a digital power controller powered by a microprocessor core and a Mask ROM counts as software, a CPU powered by a microsequencer running its own microcode also counts as software, and "it's turtles all the way down" and we apply the argument repeatedly. Ultimately we come to the conclusion that even simple combinational logic formed by a bunch of AND and OR gates would be considered as software in some cases, which is an undesirable conclusion.

If you decap the chip and look at the die of a MOS 6502 from 1975, you see a large matrix in a rectangular shape. This is basically a large decoder ROM, responsible for generating all the control signals internal to the CPU. This is usually considered as pure hardware, because although it works as a ROM but it's not meant to be a general-purpose circuitry. Rather, it's hard-wired to output some prearranged signals already determined by the designers. Indeed, microcode-like CPU designs appeared very early in computer history long before software took over the world.

Then, consider a hypothetical MOS 6502 CPU in 2020. Inside the chip you'll find circuitry that resembles an off-the-shelf FPGA. Before this chip leaves the factory, a FPGA burner writes the bitstream data of a 6502 emulator into a ROM via a test point on the chip. The bitstream cannot be further changed after the fact.

Clearly, chip #1 is not using software, at least if the Deep Firmware Argument is not pushed to its extreme. Meanwhile, chip #2 is obviously using software according to your argument (although the FSF would choose to ignore it), because the 6502 emulator is clearly the work of a programmer.

Finally, consider another hypothetical MOS 6502 CPU. This time, the only difference is that we use a general-purpose PROM block in place of the hard-wired decoder ROM in the original 6502. Before this chip leaves the factory, a PROM burner writes the decoder ROM data into the PROM via a test point on the chip. The PROM cannot be further changed after the fact.

Now, does this CPU contain software? Perhaps not. Chip #1 and Chip #3 is essentially the same hardware, the only difference is a physical implementation detail. However, one can also argue it contains software because both Chip #2 and Chip #3 have programmed microcode, the only difference is how much.

4. If I were you, I think there is a simple solution to simultaneously fix all the problems in your argument. Just like how free and non-free can be rated on a continuous spectrum, whether something is more hardware-like or software-like can be rated on a continuous spectrum as well. A random logic controller can get a hardware score of 1.0, a hard-wired ROM controller can be 0.9, a OTP ROM controller can be 0.8, and finally a FPGA controller can be 0.2. The degree of "Libreness" can be calculated by taking both into considerations.

However, it introduces huge complexity to the evaluation process and I think it often requires access to the underlying chip design and thus impractical. Which lead us back to the original question: how do you define a piece of hardware that "rises to the level of using software"?

I'm not drawing a hardware/software boundary, but rather rejecting the hard dichotomy. The "deep firmware" argument is pointing out that calling something hardware or a "black box" is itself a convenient abstraction rather than some hard and fast rule. I would say that it doesn't "end" anywhere - end user understanding and modification is an asymptote to strive for. That also includes understanding and modifying hardware.

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).