The FSF’s relationship with firmware is harmful to free software users

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 irrelevant: from the perspective of the software user outside the chip, it doesn't make any difference, it's just an implementation detail in the hardware realm that matters to a hardware engineer, not a software developer.

This contains an assumption about the behavior complexity of the black box chip. A digital SMPS controller could also be replaced by an appropriate discrete analog signal conditioning and an appropriate beefing up of the power electronics. Instead it uses some advanced digital processing (assorted operating modes based on current draw, etc), which is why the manufacturer chose to use a general purpose CPU programmed with software. As soon as something rises to the level of using software, I would say the FSF has "jurisdiction" - the complexity of software is being deployed without a way for the end-user to grok that complexity. It's only historic pragmatism for why the FSF gave it a pass.

> if the ROM is 100% read-only, or if the Write function is permanently disabled at hardware level

Except that for the most part true mask "ROM" isn't a thing except for tiny bootloaders, and we're mostly talking FLASH which remains writable. Tying !write_enable high and calling that a "ROM" is more rules lawyering than an appropriate description of the actual situation. Especially when the developer of the proprietary blob expects to release updates (ie has released unfinished software), and this one device's implementation is unusual to prohibit such updates.

> I'm curious to know what would be your definition of "Libre"

Due to "software eating the world", close to nothing these days is actually "Libre". I think it needs to be a scale, for things that afford you more or less freedom. Furthermore it needs to take into account anti-Freedom developments such as signature lockdowns and the upgrade treadmill. Furthermore a complex device needs multiple numbers to take into account where the code is running - on the main CPU domain versus an isolated subprocessor.

For example my desktop is a librebooted KGPE with an AMD video card. The AMD video card is locked down hard and itself is very poor for software freedom, but the overall device is excellent for software freedom because the main CPU domain is completely Libre. So ideally it would have a combined score saying "this is one of the best Libre options you have right now", combined with another metric on the same scale describing the peripherals. If you wanted an actual Libre video card, then 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, in assorted stages of being reverse engineered.

FWIW on such a scale I would make higher numbers more Free, as we obviously have a lot of headroom with regards to embedded/hardware freedom, and manufacturer community engagement.

The central problem here, is that RYF, just like the FSF itself, is outdated and hasn’t been relevant for a decade or more.

It’s a dinosaur from another era with its hypocritical RAM vs ROM policies, or “secondary processor” loopholes.

It assumes that there’s one Central processor in charge, something that hasn’t been true for a very long time.

Which parts of an SOC is central? The CPU? Great. Modern CPUs are multicore chips, so which one are central and which one are secondary?

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"?

> how big of a project would it be to create a fully libre (whatever you want to call you it) laptop? Like how feasible is it to use "free" components put together into a package and what kind of budget would be required?

Very big, and unfeasible?

I think, to start with, the goal can't be "a laptop". It'll be obsolete in an instant, likely even long before hitting the market. IMHO the goal should be building up a ecosystem of companies producing libre components (from which one hopefully eventually would be able to source everything needed for a laptop). There is some movement in this direction (e.g. OSHWA, FOSSi, Skywater PDK), but you know, starting from the bottom so currently mostly microcontroller level stuff. Long way from a laptop still.

> China

A regime hellbent on surveilling everything their citizens do suddenly caring about the personal freedoms Stallman worries about?

I'm quite sure that whatever China is doing to rein in the surveillance capitalists it's not because of their threat to personal freedom but rather because they have become powerful enough to pose a threat to the party.

> And then proceed to go into every industry with right to repair issues. Deere tractor competitors, home appliances, and so on. In the name of component longevity and repairability. All of this to repudiate forced obsolescence and to promote end user freedoms.

I have great hopes for the right to repair movement. They might eventually achieve something big. As opposed to RYF, which is problematic as the article and this discussion points out, and is destined to be nothing but an extremely niche thing only a few fanatics will ever care about.