FSFLA

Well the thing with the "Guix System" is that is uses the LinuxLibre kernel. So if the hardware you have requires proprietary bits or driver, it just isn't included. That isn't to defend Guix in anyway, but the problem doesn't seem to be Guix when you read the fine print of the distro, the problem is your hardware.

So, do I agree necessarily agree with GNU's official distributions having this philosophy? Not really. Firmware and drivers is probably the one area I think the GNU people should finally throw in the towel. It keeps people out of running it, or doing so with relative ease. And the battle is for the most part lost on that end. But they do essentially tell you that it is likely it won't work across a lot of hardware out of the box.

But here is the download page
[0] https://guix.gnu.org/en/download/
That mentions the Libre kernel with link to information about the Libre kernel
[1] https://www.fsfla.org/ikiwiki/selibre/linux-libre/
With the following information:

"Linux, the kernel developed and distributed by Linus Torvalds et al, contains non-Free Software, i.e., software that does not respect your essential freedoms, and it induces you to install additional non-Free Software that it doesn't contain. Even after allegedly moving all firmware to a separate project as of release 4.14, Linux so-called "sources" published by Mr Torvalds still contain non-Free firmware disguised as source code.
Stux, a cute penguin. Few realize he's not Free

GNU Linux-libre is a…

> linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-updated microcode

This is FUD. The reason it's not possible to load microcode or other proprietary blobs from linux-libre is because of a limitation of the deblobbing process. From [0]:

Indeed, I became aware that some users have got the idea that blocking the loading of blobs is a feature. It's not; it's just a bug that's quite difficult to fix. The decision on whether or not to use a piece of software, be it Free or not, should belong to the users, and it's not our intent to make that difficult.

If you can make the deblobbing script leave an escape hatch for users to load their own blobs, at their option, I'm sure the pull request would be well-received.

[0] https://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-libre-interview-by-bruce-byfield.en.html

> that we deliberately changed the kernel to refuse to load

I've heard this myth before too. Here's someone else's succinct answer to it:

It's a common misunderstanding to think that the Linux-libre project forbids loading non-free modules/drivers by user's request after the kernel was installed. In fact, it's a bug that is very hard to fix due to the way that the Linux kernel itself is made, as Alexandre Oliva, member of Linux-libre project, states at http://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-libre-interview-by-bruce-byfield.en.html (when answering the question "Is there anything that the project wants to do that it can't do now? In general, what are the future plans for the project?").

Unfortunately some of the Linux kernel mainline has questionable licensing too. [1]
In short, [2] and [3] are probably linux-firmware territory in the mainline kernel.

[1] https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/appletalk/cops_ffdrv.h

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/appletalk/cops_ltdrv.h