[segfaultbuserr]

> how big of a project would it be to create a fully libre (whatever you want to call you it) laptop?

But what does it mean by "Libre"? You see, the entire disagreement is about a problem of our definition: How does one define "a hardware system without non-proprietary software"?

Ideally, if every single chip in a computer has free hardware design down to the logic gate or HDL level, that would certainly qualify as 100% libre in both hardware and software (if a free operation system is also used). But obviously it's not practical, and it's also out of scope of what the FSF does, it's the Free Software Foundation, and it only cares about software, not hardware. Thus, the FSF defines "Respect Your Freedom" as a hardware system that doesn't require you to execute any nonfree software to use.

This sounds like a straightforward definition, right? But for many different types of hardware - essentially 90% of all digital electronics - if you open it up, decap the chips, you'll find a general-purpose microprocessor core executing code in a hard-wired Mask ROM. The chip can be a CPU with embedded microcode, a serial port transceiver, a USB controller, or even a Voltage Regulator Module (just search "DigiVRM"). Sometimes you don't even know it's implemented in this way. Thus, a practical boundary between hardware and software must be drawn.

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. Externally they can even be indistinguishable, if not at the electrical level, at least at the software level. Thus, as long as the logic is not controllable by software, it's not considered as a form of "non-free software" and it gets "Respect Your Freedom" approval. I think there's little to no disagreement at this point, but it gets controversial next.

Now, consider two chips, one is a controller and another is its ROM. The FSF argues that, if the ROM is not reprogramable via software even by its vendor after it leaves the factory (if the ROM is 100% read-only, or if the Write function is permanently disabled at hardware level), the controller and its own ROM are collectively considered equivalent to some hard-wired electronic circuitry in the pure hardware realm, using the same argument. Thus it also gets "Respect Your Freedom" approval.

However, if the ROM can be reprogrammed (e.g. has an enabled "Write" function) or controlled by software (e.g. uploading a blob by the device driver to the chip), it's considered as a form of non-free software, thus the FSF say it "Does Not Respect Your Freedom".

And this is where the disagreement starts.

The FSF may insist that a software-controlled firmware is strictly a type of computer program, thus it must be non-free software, meanwhile firmware not controlled by software may as well be a collection of hard-wired logic gates, so it's a "don't care" item for a software user - or at least a form of compromise. The counterargument is that, regardless of whether the firmware control is enabled or disabled, you're ultimately running the same non-free software in both cases (even though, the first case is invisible to software and the second case is visible to software), and it's just a matter of location, either ROM or disk. Since running fixed non-free software is better than running vulnerable non-free software, the "Respect Your Freedom" hardware's "quasi hard-wired" firmware is a waste of time and provides less user freedom.

I only described the disagreements, it's up to you to decide. Now, I'm curious to know what would be your definition of "Libre", after learning what I've told you?

[iostream23]

You would make an EXCELLENT moderator or facilitator. You gave fair shrift and explanation to the various perspectives anc concerns this thread is full of. I will happily vote for you if you ever run for public office.

[mindslight]

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.

[segfaultbuserr]

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

[mindslight]

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