@wizzwizz4 >all unencrypted software gives you freedom 1 because you can look at the binaries
Merely because you can reverse engineer the binaries doesn't give you freedom 1, as studying how the program works is much harder without the source code and changing it in nontrivial ways (to do your computing as you wish) is impractical without the source code.

As a result, you don't have any of the 4 essential freedom.

>Indeed, it's much easier to look at the binaries of most proprietary software than to read the ROM from a CPU's die
I would argue that it's usually easier to send the CPU off to a decapping enjoyer and then to read out the unencrypted microcode, than to work out how to decrypt software that you don't have the encryption key for.

>Goldmont / Goldmont Plus chips, it's easier to decrypt and disassemble the microcode updates than to get at the actual ROM microcode.
Yes, for those specific processors, microcode updates are easier to analyze than the ROM version, but that's a

>RYF's secondary embedded processor exception should apply to a GPCPU's microcode as well.
GCPU's don't run microcode - they run proprietary peripheral software and they're a primary processor.

The exception is designed to be temporary and it being expanded and made effectively permanent would be a ruinous compromise.

>someone's already written the rest of this rant
I'm not very impressed by that rant, as it calls for the increased installing and running of proprietary software, even when the device is functional without it (writing this now on a thinkpad without any of those proprietary microcode updates).