Hej Marius,

[I see this is being CC'd to @libreboot.org. I'm answering only as a GNU
 Guix user and contributor, and assume people who live and breathe this
 stuff will find plenty of holes in my opinion. Which this is.]

Marius Bakke wrote on 08/01/18 at 19:26:
> In my opinion, CPU microcode falls under "non-functional data", as
> expressly permitted by the GNU FSDG.

I'm not sure how tongue-in-cheek this is, so I'm not sure how to
respond. I hope nobody on the Internet is wrong^Wseriously suggesting
that microcode or any other firmware isn't machine code and —
unfortunately for everyone everywhere — very (dis)functional indeed.

(Don't get me wrong: I wish it weren't so, or that there were some sort
 of commonly-agreed-upon wink-nudge fiction that it wasn't. If there is,
 then Debian isn't playing along: microcode blobs are ‘non-free’[0].)

I think the real and thornier question for GuixSD is: if the recent CPU
vulnerabilities require a microcode update to fully mitigate, then how
do we square not recommending proprietary globs like this in official
channels with giving users all knowledge required to decide for themselves?

> It is not required for the processor to function, it is merely *a
> posteriori* data that the CPU can use to fix erratic behaviour.

AIUI, at least on x86 CPUs, the microcode *is* a large and/or functional
part of the processor. I suspect that's the case for most sufficiently
modern (complex) chips, but it's not my field.

Kind regards,

T G-R

[0]: https://lists.debian.org/debian-devel/2012/11/msg00109.html,
     https://packages.debian.org/search?keywords=microcode