@mjg59 Isn't "unreasonable" their entire schtick?

I mean, unreasonable got some good things started, but by this point, we probably need a completely different brand of unreasonable.

@mjg59 Since you bring up microcode as canonical example: I hypothesized in https://patrick.georgi-clan.de/posts/on-microcode/ that the cut-off point for on-ROM microcode is quite arbitrary and definitely before development is complete, with microcode updates available before market entry.

That has been true for ages, too: Some Via CPU (remember those?) failed to boot into the OS without a microcode update because the OS would start putting parts of the CPU to sleep, and the ROM-version of microcode was having none of that, so the CPU hung.

With that I think it's hilarious that the FSF has a "Defective by Design" campaign against DRM, while the same terms perfectly describe their general approach to computing.

The only way this approach would make sense is if this was putting some objective pressure on CPU vendors to either ensure that their ROM contains good microcode, or to make it Free Software. I don't think the FSF could ever exert that much pressure - and its influence only shrank over the years.

@mjg59
> users would benefit from most (if not all) firmware being free software

yes

> So I think this is less of a philosophical discussion

no, that does not follow

The stance of FSF is that developing proprietary software is immoral. Therefore, all software is *required* to be free

Just because something is beneficial to users does not mean it's morally required

Therefore, I think there's still a philosophical discussion here: where is the line between the vendors' rights and the users'

@mjg59 I remember reading similar things from @marcan.

@mjg59 Such a comprehensive and nicely worded explanation why the only thing worse than having proprietary firmware on your system is to have known broken proprietary firmware on your system 🤭

@mjg59 >Freedom isn't necessary.
Well there it is.


Unlike a PCIe Wi-Fi card, remote network servers don't have DMA access to the main memory space (IOMMU is a pretty shoddy workaround).


Microcode in ROM in an intel CPU is hardware circuits that don't have a proprietary software license attached to it that restricts you and you do have the right to do whatever you want to your own hardware - even to sell it.

As far as I can tell, the microcode in ROM doesn't contain malicious circuits, as intel knows that a decapping enjoyer is going to take a look eventually and report on any found malicious circuits.


Meanwhile, microcode updates are software, with nasty proprietary license terms that require acceptance and this line from the software license confirms that the updates are partially proprietary malware;
>3. No reverse engineering, decompilation, or disassembly of this software is permitted.

That's right "reverse engineering our updates and finding the malware is not allowed, even though we've made every effort at doing so extremely difficult with encryption and an undocumented instruction set and only around a dozen people knowing how microcode updates work".


All software running on a computer should be free and I am working towards achieving that.

Encouraging the user to accept a proprietary license for proprietary peripheral software only leads the user away from freedom, as such software almost never gets replaced (there are arguments that RAM loaded proprietary software is easier to replace than EEPROM installed proprietary software, but for some reasons EEPROM installed proprietary software gets replaced much more often? (maybe it's something to do with how the RAM loaded software often has license terms and digital handcuffs that try to prevent replacement, while EEPROM included software on peripheral devices usually has no such restrictions)).

@mjg59 Fun anecdote: A friend of mine once tried to get a certain piece of open hardware RYF-certified. At the time Linux would run on the hardware, without free GPU acceleration. The shipping software/firmware did not include any nonfree components.

They rejected it because users could hypothetically install nonfree GPU drivers. They said if he could get the GPU permanently fused off, they'd certify it.

It was never certified. A few years later, free GPU drivers were available. Had he followed the FSF's ridiculous demand, users would have owned an intentionally crippled piece of hardware and lost the ability to have free GPU acceleration in the future, once it existed.

@mjg59 I don't think it's always the best strategy to "demand" things. I always *want* open-source firmware, and I want this to work for everyone involved. Intellectual property won't hold up forever - how do we buy it out wholesale, for the commons?

@mjg59 This rather reflects their software positions with the FSF and GNU, they gain and keep control over projects to keep them "safe" by removing options. Having a project become a part of them essentially removes any autonomy you have, the RYF does it by doing it this way.

@mjg59 I think they should go harder and declare drivers to be uncopyrightable too :3

@marcan @mjg59 By that line of reasoning that hardware should still not be certifiable because users could _still_ replace the free driver with the nonfree driver. Taking that thought further I could void any device's certification by releasing a nonfree driver, never mind thst a free one exists. The opportunities for trolling are endless

@marcan @mjg59 Nothing says freedom like fusing components purely so that users can't do what they please with it.

@marcan @mjg59 That...seems really backwards. I like the idea of "free software" firmware, but going scorched earth on anything that doesn't fall under a particular definition just bothers the hell out of me. I can totally see not offering support out of the box, but forcing it to be hard-disabled "in case" just means that the user now...can't do what they want with the hardware they bought.

@marcan @mjg59 If you get a product certified then the manufacturer releases a proprietary driver for an undocumented part of the SoC does the FSF revoke your certification?

@marcan @mjg59 they also have blacklists for "bad software" on some of their "certified distros", and don't allow distros like Gentoo to be certified despite being able to be installed without any proprietary software and by default don't allow installation of it without accepting the license, because they allow you to install proprietary software at all

@marcan @chjara @mjg59 > They rejected it because users could hypothetically install nonfree GPU drivers. They said if he could get the GPU permanently fused off, they'd certify it.

Isn't that basically equivalent to tivoization, except in hardware rather than software locks?

@lispi314 @chjara @mjg59 Kind of, yeah. But clearly the FSF doesn't care about moral arguments or not being hypocritical these days.

@Suiseiseki Microcode in an Intel CPU is not hardware circuits - it's software. Pretending otherwise is dishonest. When you power on an Intel CPU it runs code out of ROM that performs a series of operations (including performing cryptographic validation of other blobs) before jumping to the reset vector. And, well, good luck making the argument that there's no license associated with that - would you argue that a copy of Linux in ROM creates no GPL obligations?

@Suiseiseki (And, indeed, Intel v. NEC established that microcode was copyrightable all the way back in the 80s!)

@mjg59 >it's software
The circuits are circuits that are hardware, even though they happen to encode microprocessor instructions.

>(including performing cryptographic validation of other blobs)
If you don't include any proprietary software on core 2 duo's, such cryptographic validation is not done.

>would you argue that a copy of Linux in ROM creates no GPL obligations?
There would be no obligation under the GPLv2 to provide installation information, but the source code would need to be provided.

@Suiseiseki The only way that source code distribution could be required is if software licenses can apply, so why do you think that would apply to Linux in mask ROM but not Intel microcode?

@mjg59 You do not need a license to operate hardware.

The user does deserve the source code to the hardware microcode, alas Intel does not provide it.

@Suiseiseki But microcode is copyrightable software, as established in decades-old case law.

@mjg59 I don't really care about what bizarre conclusion a court arrived at decades ago, as the conclusion is not applicable to operating hardware.

@Suiseiseki Your claims are simply wrong. Microcode doesn't change state simply because it's embodied in ROM - its copyrightability isn't related to the physical layout of gates, it's related to be functionality they embody (ie, if I were to encode the same microcode in a different physical layout, it would still be a copyright violation). It's software, it can (for good or bad) be bound by software licenses. In the US, first sale doctrine likely still applies, but other restrictions may exist.

@mjg59
Now, as to why FSF may've thought ROMs are ok:

The purpose of Free Software is to remove a power imbalance between vendor and user.

If the vendor can change the software, but the user can't, that gives the vendor coercive power over the user.

So one might conclude that if firmware is in ROM, then vendor is as powerless to change it as the user, so there is no power imbalance.

1/

@wolf480pl The vendor no longer has the power to change it, but they still have the power to control how the hardware behaves in the first place and this may not be to the user's benefit. Proprietary software that the vendor never updates is just as harmful as proprietary software that the vendor ships optional updates for.

@darkling @mjg59 Read the article. Their "unreasonable" perspective isn't unreasonable in the sense that it tries to enforce that everything is free or push a maximalist freedom argument.

It's "unreasonable" because, in practice, it actually advocates for *removing* freedoms from users by removing their ability to update (and possibly even find ways to free) their firmware, instead promoting the existence of non-free firmware that's just invisible.

It's just a completely backwards position that advocates for misleading users into believing their systems are "more free" while actually causing damage without increasing freedom in any measurable way. Freedom PR, basically. The FSF has completely lost it with RYF.

@marcan @darkling @mjg59 FSF's approach is the worst of both worlds. It genuinely baffles me that they keep doing it. Do they have *any* argument for carrying on with it other than the "ROM is hardware" BS?
It's not even like the practical consequences of this classification are unproven. Lots, if not most of hardware I've seen that proudly boasts RYF take inane steps to pretend firmware doesn't exist, in ways that don't limit their capacity for harm whatsoever...

@marcan @darkling @mjg59 this is the disconnect that has made me completely lose interest. they've forgotten that the point is user freedom, including freedom of choice. they've turned it into a bizarre purity test where the only way forward is to deny more and more tangible freedom in exchange for more and more ludicrous notions of abstract freedom.

@asu @marcan @darkling @mjg59 As far as I can guess, it breaks down into two fundamental concerns:

1) We can't allow our flock to be tempted. Make them rip out anything that would run proprietary software.

2) We need a way to "grandfather" into compliance the devices we have already been using. If we say the proprietary firmware in the Embedded Controller (and countless other cores) in RMS' Thinkpad is "just part of the hardware" for <some reason> we can pretend it doesn't exist.

@developing_agent @asu @marcan @darkling the EC firmware that exists in flash and can be upgraded? Huh.

@mjg59 @asu @marcan @darkling The EC specifically is something I pulled out of thin air, but yeah, it's not ROM. I'm not sure anyone of authority has ever addressed it directly.