RMS printer moment, but it's about my fridge failing to run the ice maker fill tube heater for long enough so it freezes so the ice maker gets no water and makes no ice, but also the software controlling this is in ROM so the FSF says it's fine even though there's no way I can fix it even though I am entirely capable of reverse engineering and patching it otherwise

Yeah great ok the manufacturer also has no ability to patch my fridge but how does that help me this differentiation between software in ROM and software in flash is absolute bullshit, it's all software and it should all be free and modifiable

@mjg59 While I agree with the sentiment, I am suddenly thinking that software running on, say, a security chip in a credit card, or a Yubikey, or on a TPM2, should maybe not be possible to ever be modified.

@liw I actually have a bunch of use cases for wanting to modify that, which pushes us into an interesting space

@mjg59 imagine if someone made a phone following these guidelines lol.... lmao

@mjg59 what the fuck. actual ROM? as in, like, .....? we didn't think they made actually fully read-only chips anymore. Surely it's a fucking SPI flash module

@freya

Real ROM is fairly rare, but embedded shops tend to use microcontrollers and SoCs which support DEBUG e-fuses. When the DEBUG fuses are burned, the pins on the chip that allow for dumping or programming flash are permanently disabled.

So, same difference.

@cas @mjg59 android and all the blobs in ROM

yay freedom!

@mjg59 There is no proprietary software - only proprietary hardware - but you know that.

There is a hardware problem with one of the sensors or something and the fix is to physically fix the broken hardware - running the fill-tube heater longer may not fix the issue after all.

All hardware requires at least some ROM to work as an initial bootloader - but you know that.

Unless that's a really old fridge, there is likely a microcontroller with internal EEPROM that could be reprogrammed if you had sufficient information and sources.


The FSF are clearly not going to complain if there's an EEPROM and there's the free source code for the free software on that EEPROM and included installation information.

@Suiseiseki Software doesn't stop being software just because it's in ROM

@mjg59 >Read Only Memory
>Look inside.
>Physical hardware circuits that cannot be reprogrammed that happens to contain microprocessor instructions (which is only a little different from proprietary hardware circuits, as discrete component hardware circuits usually allow for limited hardware modification, while ROM is tiny and usually buried in an IC or at least below packaging material and is therefore almost always not feasible to modify).

Yes, it is possible to dump the contents of a ROM into a file on a filesystem and then you have software, as you can actually change that, but that software and any modifications are usually useless, as they cannot be applied to the hardware and usually do no useful operation outside the hardware.

@Suiseiseki Code that executes on a general purpose core is software, end of discussion

@mjg59 The cold unyielding reality of ROM takes away the soft and replaces it with hard.

In such configuration, the processor is not in fact general purpose - all it can do is execute instructions in the ROM and nothing else - if you want something else, you need to desolder the whole processor and solder another one on.

@Suiseiseki Hardware executes things. Software is what is executed. Making software immutable doesn't make it not software.

@mjg59 Hardware is ware that is hard (something that requires physical modification to change (with limited changes possible), or replacement to be changed).

Software is ware that is soft (something that can be reprogrammed into any configuration, via electricity or via adjustment of the bit layout of the wire wrap).


ROM is hardware, no matter what the circuits encode.

@Suiseiseki whoops, managed to post as a top level rather than a reply, but:

The ROM is hardware, what the ROM contains is software. Otherwise you end up arguing that software on a pressed CD is hardware, which is clearly nonsense.

@mjg59 A pressed CD is hardware, as you cannot change what's on that CD can you?

If you can't change it, it's nonsense to call it software.


Although, you can trivially copy the contents off that CD and turn it into files on a R/W filesystem and then you have software.

@Suiseiseki If I give you a computer that only has a CD drive and the computer boots from that, is the computer running software?

@mjg59 If you boot from a mostly empty CD-R or a CD-RW, yes.

If you boot from a pressed CD, you are running hardware, although it would be very easy to turn it into software with one of those new-fangled CD-RW disks.

@Suiseiseki So there's no need for a device that boots from CD to run free software, since it's actually hardware and therefore out of scope?

@Suiseiseki It seems like the FSF disagrees with you - RYF hardware can't include a pressed CD that include proprietary drivers (https://ryf.fsf.org/about/criteria), and it's also made clear that software in ROM is, well, software

@mjg59 >So there's no need for a device that boots from CD to run free software, since it's actually hardware and therefore out of scope?
It's up to the user to decide whether they find that proprietary hardware acceptable or not - after all.

As it is actually possible for the user to replace the proprietary hardware with for free software on a CD-RW disk in this case, I would recommend doing so.


windows drivers are designed to be copied from the disk and installed onto a filesystem before they are executed and thus windows drivers are proprietary software, even if encoded on a CD-ROM prior to install.

@Suiseiseki you're ignoring the bit where software in ROM is called software

@mjg59 Yes, software is software, even if it is encoded in ROM prior to it being installed.

A program in ROM that is not possible to replace without replacing the hardware is hardware.

@Suiseiseki so why does the FSF call it software?

@mjg59 The FSF called a windows driver software, as it's software.

@Suiseiseki "The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product"

@Suiseiseki so, by the FSF's definition, my fridge contains software

@mjg59 If a fridge contains an EEPROM encoding CPU instructions, it contains software - but if the manufacturer doesn't demand you sign a proprietary license, doesn't offer updates and the software doesn't contain malicious functionality - such software functions equivalently to proprietary circuits (i.e. proprietary logic gates) - thus "RYF" offers an exception for such when for auxiliary processors.

It would be good if a superio for example ran free software, but you usually cannot program a superio without desoldering it first (they tend to be provided to the manufacturer pre-programmed), which may leave you with a proprietary brick due to hardware damage.

@Suiseiseki and if it contains a ROM encoding CPU instructions, it also contains software, as the FSF makes clear in the quote I provided

@mjg59 The exception does not apply to hardware as that is out of scope.

Clearly "which software installation is not intended" excludes the case where software installation is impossible.

@Suiseiseki It's talking about CPU microcode, which is stored in ROM.

@mjg59 CPU microcode ROM is in the main processor and is not in an auxiliary processor.

Such proprietary hardware is out of scope.

Proprietary software microcode updates are not acceptable (although free software updates are).

@Suiseiseki the CPU microcode ROM contains software, as the FSF makes clear.

@mjg59 Just because you read something wrong doesn't mean anything.

The FSF has pointed out that proprietary software microcode updates are unacceptable, but otherwise has no comment.

@Suiseiseki "This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."

Things that are in ROM are still software. The FSF says so.

@mjg59 @Suiseiseki
The FSF doesn't say that. You say that.

"The ethical issues of free software arise because users obtain programs and install them in computers; they don't really apply to hidden embedded computers, or the BIOS burned in a ROM, or the microcode inside a processor chip, or the firmware that is wired into a processor in an I/O device. In aspects that relate to their design, those things are software; but as regards copying and modification, they may as well be hardware" https://www.fsf.org/campaigns/free-bios.html

A ROM can contain software, such as in the case of an EEPROM, which can be electronically reprogrammed. However, the microcode embedded in a CPU’s MROM is not software — it is physically etched into the silicon as part of the chip’s design and cannot be modified without completely redesigning and remanufacturing the chip.

An MROM is a section of the circuit where the manufacturer permanently fixes a binary sequence during fabrication by connecting or leaving disconnected specific silicon pathways — similar to fuses, but at the level of lithographic mask design. That is to say, the microcode is not executable software but hardwired logic: a behavior physically implemented in the chip’s design through fixed connections in the silicon. The CPU does not execute it as a program but operates according to a finite state machine implemented directly in hardware, which determines step-by-step how to internally execute certain complex instructions.

Microcode updates loaded at boot time do not modify the physical MROM or the hardwired microcode — instead, they overwrite a small internal volatile memory or cache that temporarily alters the CPU's behavior. Such software is often proprietary and potentially malicious.

That’s why you have free BIOSes like GNU Boot: https://gnu.org/software/gnuboot

@freetar @Suiseiseki "In aspects that relate to their design, those things are software; but as regards copying and modification, they may as well be hardware" - they're software, the FSF just argued that they be treated in the same way as hardware.

@freetar @Suiseiseki further, the description of microcode may have been true in the 8086 days, but it's not for modern CPUs. Look at how microcode updates were used to provide mitigations for Spectre vulnerabilities - that wouldn't have been possible if its functionality was so constrained.

@mjg59 @Suiseiseki
What has changed is the addition of an update layer loaded into volatile memory at boot, which can patch, modify or add behaviors. Using microcode updates for mitigations like Spectre does not mean the base microcode ceases to be hardwired, nor that the physical MROM is altered. These updates act on internal volatile memory that dynamically overrides behavior, while the MROM remains intact. Thus, modern CPU microcode operates on two levels: a hardwired base layer and a software layer that adds flexibility without changing the underlying hardware.

It is also important to note that vulnerabilities such as Spectre are not "mitigated" exclusively through proprietary microcode updates. Many effective mitigations are implemented at the operating system level —especially in the kernel— such as retpolines, kernel page table isolation, speculative execution barriers, et cetera.

@freetar @Suiseiseki what has changed is that microcode is now software targeting the CPU's underlying instruction set, and that merely happens to be fixed in ROM.

@mjg59 @Suiseiseki
The FSF does not claim that these elements are software, but rather that, although they can be considered software from a design perspective, in practice they are hardware.

Writing instructions on a sheet of paper does not constitute software by itself, but rather a tangible representation of software (like printed source code). That sheet is merely a physical medium. For those instructions to be software, they must be in a format that a computer can interpret or execute.

The base microcode etched into a CPU's silicon is not a program that the processor executes or interprets. Instead, it functions as a finite state machine implemented in hardware — a fixed set of rules and physical connections (states and transitions) that guide the CPU’s internal behavior to execute complex instructions.

@freetar @Suiseiseki your understanding of modern microcode is simply incorrect, and whether something is software or not is not determined by the tangible form it is fixed in

@mjg59 @Suiseiseki
Microcode updates loaded into volatile memory at boot are indeed software (usually proprietary and potentially malicious) — snippets of code that the CPU can interpret to modify or patch its behavior. However, this does not turn the base microcode into software nor change the physical MROM. It just adds a software layer on top of the hardware.

@freetar @Suiseiseki software in ROM is still software, just as software on a CD is still software

@mjg59 @Suiseiseki
>your understanding of modern microcode is simply incorrect
You can't just say it's simply incorrect. You need to correct my supposed misunderstanding.

>and whether something is software or not is not determined by the tangible form it is fixed in
I did not claim that. In fact, I made it quite clear: for those instructions to be software, they must be in a format that a computer can interpret or execute.

@freetar @Suiseiseki right. Modern microcode is software written for the CPU's native instruction set. It reads state from flash. It performs cryptography. It is built from source code. It is the code that brings up the CPU when power is initially applied. Nobody manually lays out the transistors that embody the version of it stored in ROM.

@mjg59 @Suiseiseki
Although it's true that modern microcode is written in a language the CPU can interpret and that it can be updated or loaded from flash memory, this does not mean that all microcode is software.

The base microcode stored in MROM is physically implemented in silicon and serves as the hardwired circuitry that defines the CPU's core logic and fundamental behavior. It is not interpreted or executed like a program; it is hardwired to control the CPU's internal signals and state transitions.

Microcode fragments loaded from flash memory at boot time (updates or patches) are software: they consist of instructions that the CPU interprets to dynamically alter its behavior. However, the foundational layer —the original hardwired microcode— remains intact and is not executed in that way. These updates are not executed directly from flash; they are copied into the CPU internal volatile memory during the boot process, where they temporarily override specific behaviors, while the physical MROM remains unchanged.

@freetar @Suiseiseki the base microcode loaded from ROM is what validates the signature on any ACMs that are loaded from flash. It is not simply an instruction lookup table, it is software.

@mjg59 @Suiseiseki
I'm not sure exactly what you mean. A ROM can be electrically programmable and erasable (EEPROM). A CD can be a CD-RW, CD-R, CD-ROM or CD-A — all of them are different.

@freetar @Suiseiseki software doesn't stop being software if it's on a pressed CD-ROM.

@mjg59 @Suiseiseki
>the base microcode loaded from ROM is what validates the signature on any ACMs that are loaded from flash.
Base microcode is not loaded, executed or modifiable. It is physically embedded in the CPU silicon as hardwired logic, commonly implemented as a hardwired finite-state machine. It functions as a control circuit that responds to input signals with predetermined outputs, without the need for interpretation or instruction execution. Among its functions is the validation of ACMs using integrated cryptographic modules.

>It is not simply an instruction lookup table, it is software.
Not being simply an instruction lookup table does not make the base microcode software; it indicates that it is complex circuitry.

>it is software.
Evidently, it is not.

@freetar @Suiseiseki "commonly implemented as a hardwired finite-state machine" ok where are you getting this from because it hasn't been true in decades

@mjg59 @Suiseiseki
The term "software" comes from "soft", implying something flexible or modifiable without physically altering the medium in which it resides. In contrast, "hardware" comes from "hard", referring to something rigid or fixed, which requires physical intervention to change.

A CD-ROM can store a computer program, but it does so in a fixed, physical, and immutable form. Because this data cannot be modified without physically altering the disc, it does not align with the notion of software as something "soft" or easily changeable. In such cases, we are dealing with a tangible, unalterable representation — in other words: hardware.

This analysis is logically consistent and valid within the conceptual framework based on etymology.

@freetar @Suiseiseki so a computer booting from a pressed CD isn't running software?

@mjg59 @Suiseiseki
Etymologically, no.

@freetar @Suiseiseki yeah this is a ridiculous position to hold and results in bad outcomes like not believing that it's an ethical requirement that the code a system runs be modifiable as long as that code is in a physically immutable form

I'm not the FSF and I don't speak for it, but, technically, IMHO, it's software encoded as hardware.

but even if it was in an EEPROM, ethically, being buried deeply in hardware to the point of being indistinguishable, it is equivalent to a hardware circuit

as in, if you're willing to tolerate a hardware circuit that nobody can modify, it would be ethically unsound to reject a clone thereof just because it has innards that you can't even tell whether they're hardware or software

now, when you can tell, and would like to modify it, then IMHO it makes sense to treat them differently. but it's still weird to me to reject hardware that nobody can modify because of software that nobody can modify that's deep inside it, and that's therefore not ethically different from an equivalent hardware circuit. why would you?

CC: @Suiseiseki@freesoftwareextremist.com @mjg59@nondeterministic.computer

@lxo @freetar @Suiseiseki The perspective I take is that someone choosing to design a system such that the software is sufficiently hidden you could maybe describe it as hardware is in itself a hostile act - it's a choice to take control of that system away from its owners. By choosing to treat that as acceptable we provide a perverse incentive for vendors to make devices that are harder to modify to meet the owner's needs.

I'll call that bullshit. it's not like hardware makers really care about FSF's opinion on what is or isn't acceptable WRT embedding software in hardware

but if you buy a piece of hardware, assuming it can't be modified, learning that there's a piece of software that can't be modified in there doesn't betray you or take away anything you expected when you got it.

whereas learning that the piece of software can be modified remotely makes it traitorous hardware

that's a key distinction to me


that the hardware can be modified (or even enabled) with software copies, if you go along with it, as with typical ROM-ed firmware and microcode, makes the modifications most evidently software, and then all the ethical reasons for software to be free kick in

but those reasons don't transfer to the hardware you got with expectation that it was hardware, thus unmodifiable

presenting them as if they do just because you label it as software is unreasonably dogmatic IMHO. it's missing the forest for the trees

unless you're just bringing this up to serve your masters. then it's totally understandable that you're poking the FSF because you have to.

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @freetar @Suiseiseki I don't think expectations have anything to do with it - most people who buy a TV have no expectations that the code it contains can be modified, but we both know that code is used to restrict them and they should be able to modify it. If hardware vendors know they can escape the FSF's attention by putting code in ROM then that's a disservice to everyone who receives that code, and we should expect better from them.

(As of yesterday I'm unemployed, who are my masters?)

@mjg59 @freetar If something is physically immutable, then it is *physically unmodifiable* - therefore it is no possible ethical question as to modification, as nobody can.

@Suiseiseki @freetar systems should be designed such that there is no immutable software store

your obsession with hitting the FSF seems to get you very confused as to the power and influence it has. you also seem confused about its scope, which is surprising for a former board member. as a single-issue organization, its focus is on software, and on users' freedoms that enable them to control their computing.

as such, it does not oppose users' freedom over hardware, but they're outside its scope inasmuchas the hardware doesn't trump software freedom.

once you realize that a piece of hardware cannot be reasonably modified, if you accept that unfortunate reality, the ethical dimension of replacing some hardware component with an equivalent software+programmable hardware component vanishes, and no reasonable argument remains to reject it, provided that you've accepted that the hardware cannot be reasonably modified. there's no loss of freedom there, even if there's a loss of potential freedom. as in, it could conceivably be better if things were different. it's an argument analogous to "I demand a pony because I want one so much", which isn't very convincing.

if you're not happy with hardware that you cannot modify, you're welcome to join us in the hardware freedom cause, and to reject it outright if you find that reasonable. but not to conflate it with the software freedom cause.

now, I'll give you that there are undesirable side effects following from this ethical equivalence, and those who don't quite share our ethics may twist them. I'm not convinced that there's a more consistent and pragmatic position to take, that wouldn't bring about far worse side effects. but maybe you have a better one to suggest? let's see whether you have something useful to offer, shall we?

(so have they let you go for good, or are you still serving them in a more limited capacity, under some different arrangement? anyhow, I hope you find something else that enables your survival under the crushing economic environment we live in. nobody deserves to starve to death)

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @freetar @Suiseiseki We're talking about material that even the FSF describes as software! It just chooses to place it out of scope as a result of it being in a fixed form, which provides a perverse incentive for manufacturers to assert that they're aiding freedom by making it *impossible* for users to modify it. All executable code should be modifiable by the owner of a device.

Again, who do you believe my "masters" to be?

we're talking about software that is equivalent to a hardware circuit

yet you bring up software that isn't possibly equivalent to a hardware circuit as if that provided any value to that analysis. it's fallacious at worst; at best, it's a display of confusion.

it's not impossible to modify, it's no harder than modifying hardware, and just as hard to enshittify.

but it's likely to be in an EEPROM, so someone skilled with hardware who wishes to modify it can do it without replacing the EEPROM.

I read you as to the perverse incentive. but again, what's your suggestion that would draw the line at a better place? reject all storage devices because they carry controlling software inside the package? allow nonfree software? without a vision of how the situation could be made better your criticism is worthless

(when I speak of masters, it's just a way of giving you the benefit of the doubt, as if you were somehow being forced to behave so destructively and unpleasantly, rather than doing so out of your own volition and nature)

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @freetar @Suiseiseki GNU was originally built on top of proprietary kernels, because that was the only option at the time. The FSF should acknowledge that basically all viable free software platforms rely on some amount of proprietary software embedded in hardware, and encourage people to find solutions to that instead of encouraging vendors to make it harder for those solutions to exist.

@mjg59 >He does it totally gratis.
A TV should be a TV - it should just play the video signal without needing an internet connection or software updates (most computer monitors are what TVs should be).

I haven't heard of a single case of a hardware vendor who use ROM to store the programs, as it's inconvenient not being able to patch broken programs.

In the case one does use a substantial amount of ROM or PROM in a socket to store GPLv3 programs and compiles with the GPLv3, there is no issue, as the user can just pull that chip out and put an electrically compatible EEPROM in place containing the modified version (although there would be no documentations or instructions for such, that is likely to be much easier than trying to bypass digital handcuffs).

@Suiseiseki you're missing my point - whether something should be modifiable by the owner is unrelated to whether the owner knows that's possible or is capable of doing it themselves. Most people are unaware of the benefits that free software would give them, but that doesn't justify devices they own running proprietary software.

that's a twisted narrative. using nonfree software to develop its replacement is morally good; using nonfree software (as such; software equivalent to a hardware circuit is different) just because there's no alternative is accepting defeat, not an incentive to progress.

the certification program makes room for and incentivizes designs that embed software that users can improve on, but it tolerates software that's equivalent to a hardware circuit. that designers choose to go along with the external pressure for the latter, instead of adopting hardware that carried programs that users could improve on, is not an imposition of the certification program, it's a symptom of the broken environment out there. the incentives out there are far stronger than anything the FSF could offer. but as usual you pick on the FSF.

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @freetar @Suiseiseki you're arbitrarily declaring that some non-free software is acceptable because there's no alternative. I think this is self defeating.

no, you misread or misrepresent me. I'm only saying it's unreasonable to reject hardware containing software equivalent to hardware if you'd accept all hardware. you don't like that. I get it, you want a pony. and you wish to blame the FSF for not having one, because the FSF doesn't demand the universe to give you a pony.

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @freetar @Suiseiseki I'm saying it's unreasonable to draw a distinction between software in ROM and software on disk. It's all software, it should all be free.

I suppose people would make that assumption because so much hardware is made to not be modified. a lot of it is beyond current possibilities to modify. like, you can't remake an IC the way you can patch a program.

but you seem to mistake a conditional for a certainty. it's a fact that people frequently (are led to) hold the assumption, while challenging that assumption is an exception. it's up to hardware freedom activists to change this unfortunate environment.

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com @mjg59@nondeterministic.computer

erhm... when I speak of hardware, I mean largely computer hardware, things like microprocessors, memory. those are almost naturally impossible to modify. presumably for not being a native speaker, and having learned English mainly in the context of computing, the first thing that comes to mind when I hear the term "hardware store" is computer equipment, not hammers, drills, screwdrivers and the like. sorry about any confusion this may have caused.

integrated circuits are so incredibly hard to modify that it's pretty much a given that they are what they are and you take it or leave it. I suppose makers of such devices enjoyed the power that this afforded them, and started trying to transfer that to software, where these limitations are entirely artificial. more recently, after the anti-"circumvention" provisions of the DMCA and its counterparts in other countries, industrial makers have been trying to bring the artificial roadblocks to modification to other goods that carry electronics and software.

alas, the same attitude that so many ignorant (fooled?) users display towards software, that "I can't program, so the freedoms are not irrelevant to me" seems to have successfully (from the PoV of the abusers) transferred to other devices, despite general dissatisfaction. such movements as free software, free hardware, and right to repair are our resistance against that abuse. that's the struggle we're in. though more and more people perceive these movements as solutions to these abusively-induced problems, we're still a small minority, and have a long way to go.

unfortunately for us in the free software movement, custom hardware-only devices have been largely replaced with hardware containing general-purpose processors and embedded software. the move makes economic sense to manufacturers, and no visible difference to users: the devices can still do the same they did before the replacement, they still obey (or not) the same commands from users.

we're still the only ones who care about this difference, because of the potential it would bring and our habit of having the ability to change things, to make the software and hardware around us serve us to our liking, because we've demanded the essential freedoms, and rejected things that didn't respect them.

but if we were to reject devices that don't meet our standards, like we've been able to do with software for decades, we'd reject all existing hardware, whether or not it contained embedded software. even so-called free hardware is, at some free level, built out of lower-level nonfree components. we wouldn't have where to run our free programs. we wouldn't have storage devices in which to store our data. this would be the too-dogmatic, impractical, non-hypocritical consequence of mistaking the free software ethical imperative as applying to all these components

followers of dogma make several improper generalizations. some think it's unacceptable to interact with a phone company or with a bank or with a store just because these businesses run nonfree software. but what the free software movement stands for is that users should have control of their own computing. the phone company's, the bank's, the store's devices are most of the time doing the business's own computing, not ours, and inasmuchas they do, whatever software they use is none of our business. it's their choice to shoot themselves in the feet. it's fine to prefer businesses that ensure their own freedoms are respected, but that preference is not an ethical imperative.

likewise, it's fine and desirable when a program that took the place of a custom hardware circuit is available as free software, and can be modified so as to improve the device it lives in. (besides every other advantage software freedom brings with it.) but, inasmuchas the custom hardware circuit was acceptable, so should the software that invisibly replaced it. the moral imperative to reject it, out of solidarity with other software users, out of discouraging unethical behavior, is not there, unless there's a moral imperative to reject that custom hardware circuit as well. it's likely not even doing our own computing. the fundamental premise from the free software movement (that users should control their computing), the ethical calculus that leads to the logical conclusion that the four freedoms are essential and that denying them is unethical and thus such behavior must be rejected, none of them apply, they aren't there.

maybe there are other reasons to support analogous moral imperatives, but to the best of my limited knowledge they haven't been articulated. what I see is an attempt to force a dogmatic analogy without the underlying moral and ethical support, and persistent attacks by those who don't get or don't share the reasoning to those who do. they're typically divisive attacks, from people who seem to enjoy conflict and destroying what they can't understand, to the point of looking like infiltrated saboteurs. who needs opponents, having allies like that? 😞

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com @mjg59@nondeterministic.computer

@lxo @dan @freetar @Suiseiseki a direct consequence of this position is that vendors attempting to cater to the free software market have deliberately made it more difficult to alter the software that their hardware runs, because by doing so they can achieve RYF compliance. The nature of the underlying software is not changed by nature of the form it's fixed in, and the hardware's owners should be afforded the same freedoms regardless.

that's the root of our disagreement. this dogmatic position is not undesirable per se, but AFAICT it lacks an ethical rationale, and undertaking it most likely leads to hypocritical behavior, unless you were to give up all computing activities with the potential exception of building replacements to the (by your standards, IIUC) intolerable devices you use.

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @freetar @Suiseiseki using hardware that runs non-free software is an acceptable compromise in the course of achieving the long-term goal of all software being free, just as using SunOS to develop GNU was an acceptable compromise at the time.

again, we disagree. the exception of using something to build its replacement and thus solve the problem is much narrower than you make it. using intolerable hardware would be acceptable to make its replacement, otherwise it's a ruinous compromise

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @freetar @Suiseiseki much free software has been written by using non-free software to reverse engineer other non-free software and reimplement it

again I'll have to call that bullshit

it was difficult to replace custom hardware components (you'd have to replace the whole thing).
it was not that difficult to replace software burned in ROMs inside embedded hardware devices.
it is easier, not harder, to replace software in EEPROMs.
it's even easier when the EEPROMs are physically outside the hardware components.

what role has the FSF played in this? none whatsoever, it was an industry-wide shift. the FSF is still encouraging developers to make free software, hardware designers to choose freedom-respecting devices, and users to do their computing with software that respect their freedom, while it certifies as respectful of users' [software] freedoms devices that contain embedded programs that are technically and ethically equivalent to hardware circuits, and that are likely not involved in doing the user's computing.

again, I welcome you to live by these standards you've supposedly chosen for yourself, that you are trying to impose onto others, particularly the FSF. maybe some day, when hardware freedom truly analogous to software freedom is achievable, we'll even be together at it. but for now, it's a false analogy, it's not pragmatic, and I'm not on board with it. having freedom over embedded software equivalent to hardware circuits is desirable and useful, but it's not a moral imperative.

that said, we seem to have an unsurmountable disagreement. it doesn't seem useful to carry on.

CC: @dan@brvt.telent.net @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @dan @freetar @Suiseiseki what? RYF refuses any components with EEPROMs that contain non-free software, but accepts components with ROM that contain the same software. I've spoken to vendors who chose to use ROM in order to obtain RYF certification.

I don't doubt it, but I don't condone it either. it seems self-defeating to me: it makes up an excuse to become dependent on something intolerable that doesn't ensure the problem will go away even if you succeed.

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @freetar @Suiseiseki I'm always going to take a pragmatic attitude here. If using non-free software is the only way we get free software, I'll do it. If using hardware running non-free software is the only way we get free software, I'll do it. But the goal has to be to replace *all* that non-free software - the non-free software that helped people write free software, and the non-free software that runs on the hardware we depend on to write and run that software

what do you imagine I said about RYF? did you mistake my description of the worldwide hardware industry shift as in any way related with FSF's RYF certification?

vendors resented that the FSF didn't go along with the shift to externally-installable blobs? is anyone surprised?

programs in internal *ROMs can be equivalent to a hardware circuit

external programs can't possibly be

CC: @dan@brvt.telent.net @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @dan @freetar @Suiseiseki in some cases, RYF certified devices run exactly the same non-free software as non-RYF devices, but it's harder for the owner to replace it. That's a direct consequence of FSF policies. It makes no sense to care about the freeness of a blob loaded at runtime but not care about an identical blob in ROM. If it's to the user's benefit to be able to modify one, it's to the user's benefit to be able to modify the other.

FTR, I'm not familiar with this level of detail of the FSF RYF certification. it's not even the point of the discussion, unless your fridge happens to be RYF-certified. or was that bait?

CC: @dan@brvt.telent.net @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @dan @freetar @Suiseiseki sigh. The point of the conversation is that my fridge, which contains buggy software I can't fix, would meet the RYF criteria in this respect, and that's not a sensible outcome.

it makes perfect sense to treat software and anything equivalent to it as software, and hardware and anything equivalent to it as hardware, technically and ethically. it doesn't help you with your fridge problem, but having no fridge wouldn't help you with it either, would it?

would you like your fridge to be easily enshittified? get one that makes it easy to update its software.
see https://www.fsfla.org/~lxoliva/#Unshittify

the easier it is to install (nonfree) software updates, the easier it is for a vendor to strongarm you into accepting an alternate version that fixes one particular problem while it introduces numerous others. it's an illusion that the externalized software makes things better for users than for vendors, and one that you pursue fiercely. it's just saving the vendor the cost of the ROM, without bringing you any benefit, especially if the software is digitally signed, so that the hardware rejects your attempts at modifying it. its flexibility serves the vendor, not you. we gotta refuse to be suckers and reject that.

CC: @dan@brvt.telent.net @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @dan @freetar @Suiseiseki all software should serve the user, but we don't achieve that by locking the software away and pretending it isn't there

why can't you fix it? it's a matter of hardware, due to the equivalence, so you have to replace the hardware part with a fixed one, but it can be fixed. if it could be treated as software, it wouldn't get past certification, because it's nonfree software. I get it that you don't like it, and that you want a pony, but the criterion makes perfect sense to me.

what's not sensible to me is that you own a fridge that doesn't live up to your own standards. how did that come about? how do you live with that kind of cognitive dissonance? what's your plan to fix it? file a complaint with the FSF? (ha!)

CC: @dan@brvt.telent.net @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @dan @freetar @Suiseiseki I can't fix it because the manufacturer chose to put it in ROM, not flash. It's not the FSF's fault that that's the case for my fridge, but it *is* the FSF's fault that analogous situations play out in RYF certified hardware.

I agree with that goal. in this regard, we seem to differ in priorities, as in, what ought to be fixed first to make the path walkable.

CC: @freetar@freesoftwareextremist.com @Suiseiseki@freesoftwareextremist.com

@lxo @freetar @Suiseiseki the path is easier to walk if it's technically possible to replace the non-free software, which means we should prefer runtime loadable blobs over non-free software in ROM.

@mjg59 @freetar New oxymoron huh? If something is immutable, it is not soft and therefore it cannot possibly be software.

That would be impossible - if hardware wants to load microprocessor instructions, at the bare minimum it needs at least some ROM to do the initial init/load.

@Suiseiseki @freetar Not at all - traditionally CPUs would simply start executing code from the reset vector without any code executing on them beforehand. What's at the reset vector (ROM, flash, RAM that's had instructions bitbanged into it by hand) is irrelevant.