policy: re-add section saying why fsdg sucks
but in a more diplomatic way, and fsf/fsdg/ryf isn't even mentioned directly, but their ideology is referenced, spoken in tongues. Signed-off-by: Leah Rowe <info@minifree.org>master
Leah Rowe
parent
3c4f5d78e3
commit
e8aaa24fb8
|
|
@ -176,3 +176,212 @@ exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
|
|||
* <https://libresilicon.com/>
|
||||
|
||||
(Sam literally makes CPUs in his garage)
|
||||
|
||||
Why?
|
||||
====
|
||||
|
||||
This next section previously existed in a less than diplomatic manner. It
|
||||
has been restored, as of August 2024, because the wisdom that it provides is
|
||||
important, yet being respectful of our friends in Massachussets is also
|
||||
a good thing to do, where feasible. This section was previously deleted, as
|
||||
a gesture of good will to this people, but it can't not be here, so without
|
||||
further ado:
|
||||
|
||||
Firstly, observe the following graphic:
|
||||
|
||||
|
||||
|
||||
Why does this policy page need to be written? Isn't it just describing basic
|
||||
common sense? The common sense that free software activism must demand all
|
||||
software to be free; why even talk about it?
|
||||
|
||||
This page has talked about Libreboot's *blob reduction policy*, but more
|
||||
context is needed. We need to talk about it, because there are many different
|
||||
interpretations for the exact same argument, depending on your point of view.
|
||||
|
||||
If you use a piece of hardware in Linux, and it works, you might see that it has
|
||||
free drivers and think nothing else. You will run free application software
|
||||
such as Firefox, Vim, KDE Plasma desktop, and everything is wonderful, right?
|
||||
|
||||
Where drivers and applications (and your operating system) are concerned, this
|
||||
is much clearer, because it's software that you're running on your main CPU,
|
||||
that you installed yourself. What of firmware?
|
||||
|
||||
Libreboot is not the only firmware that exists on your machine, when you have
|
||||
Libreboot. Look at these articles, which cover other firmwares:
|
||||
|
||||
* <https://libreboot.org/faq.html#what-other-firmware-exists-outside-of-libreboot>
|
||||
* <https://libreboot.org/faq.html#what-level-of-software-freedom-does-libreboot-give-me>
|
||||
|
||||
You may ask: should the other firmwares be free too? The answer is **yes**, but
|
||||
it's complicated: it's not always practical to even study those firmwares. For
|
||||
example, there are so many webcams out there, so many SSDs, so many devices
|
||||
all doing the same thing, but implemented differently. Coreboot is already
|
||||
hard enough, and there are so many mainboards out there.
|
||||
|
||||
For example: every SSD has its own controller, and it has to do a lot of
|
||||
error correction at great speed, to mitigate the inherent unreliability of
|
||||
NAND flash. This firmware is highly specialised, and tailored to *that* SSD;
|
||||
not merely that SSD product line, but *that* SSD, because it often has to be
|
||||
tweaked per SSD; ditto SD cards, which fundamentally use the same technology.
|
||||
Would it be practical for something like Linux to provide firmware for
|
||||
absolutely every SSD? No. Absolutely not; and this is actually an example of
|
||||
where it makes more sense to bake the firmware into the hardware, rather than
|
||||
supply it as a firmware in Linux (even if the firmware is updateable, which it
|
||||
is on some SSDs).
|
||||
|
||||
Another example: your wireless card implements a software defined radio, to
|
||||
implement all of the various WiFi protocols, which is what your WiFi drivers
|
||||
make use of. The drivers themselves are also quite complicated. However, the
|
||||
same driver might be able to operate multiple wireless cards, if there is
|
||||
some standard interface (regardless of whether it's documented), that the
|
||||
same driver can use between all the cards, even if those cards are all very
|
||||
different; this is where firmware comes in.
|
||||
|
||||
Coreboot only covers the main boot firmware, but you will have other firmware
|
||||
running on your machine. It's simply a fact.
|
||||
|
||||
Historically, a lot of hardware has firmware baked into it, which does whatever
|
||||
it does on that piece of hardware (e.g. software defined radio on a wifi
|
||||
device, firmware implementing an AHCI interface for your SATA SSD).
|
||||
|
||||
In some cases, you will find that this firmware is *not* baked into the device.
|
||||
Instead, a firmware is provided in Linux, uploaded to the device at boot
|
||||
time, and this must be performed every time you boot or every time you plug
|
||||
in that device.
|
||||
|
||||
Having firmware in Linux is *good*. Proprietary software is also *bad*, so why
|
||||
is having *more* proprietary firmware in Linux *good*? Surely, free firmware
|
||||
would be better, but this firmware has never been free; typically, most
|
||||
firmware has been non-free, but baked into the hardware so you just didn't
|
||||
see it. We can demand that the vendors release source code, and we do; in some
|
||||
cases, we even succeed (for example `ath9k_htc` WiFi dongles have free firmware
|
||||
available in Linux).
|
||||
|
||||
The reason vendors put more firmware in Linux nowadays is it's cheaper. If the
|
||||
device itself has firmware baked in, then more money is spent on the EEPROM
|
||||
that stores it, and it makes research/development more expensive; having an
|
||||
easy software update mechanism allows bugs to be fixed more quickly, during
|
||||
development and post-release, thus reducing costs. This saves the
|
||||
industry *billions*, and it is actually of benefit to the free software
|
||||
community, because it makes reverse engineering easier, and it makes
|
||||
actually updating the firmware easier, so more proprietary software can
|
||||
actually be *replaced with free software*. If some standard interface exists,
|
||||
for the firmware, then that makes reverse engineering easier *across many
|
||||
devices*, instead of just one.
|
||||
|
||||
Hardware is also very complex, more so now than in the past; having the
|
||||
hardware be flexible, configured by *firmware*, makes it easier to work
|
||||
around defects in the hardware. For example, if a circuit for a new feature
|
||||
is quite buggy on a bit of hardware, but could be turned off without ill
|
||||
consequence, a firmware update might do exactly that.
|
||||
|
||||
The existence of such firmware also reminds more people of that fact, so more
|
||||
people are likely to demand free software. If the firmware is *hidden in the
|
||||
hardware*, fewer people are likely to raise a stink about it. We in the
|
||||
Libreboot project want all firmware to be free, and we've known of this
|
||||
problem for years.
|
||||
|
||||
Some people take what we call the *head in the sand* approach, where any and
|
||||
all software in Linux must be excluded; certain distros out there do this, and
|
||||
it is an entirely misguided approach. It is misguided, precisely because it
|
||||
tells people that *compatible* hardware is more free, when it isn't; more
|
||||
likely, any hardware that works (without firmware in Linux) likely just has
|
||||
that same firmware baked into it; in other words, hidden from the user. Hence
|
||||
the *head in the sand approach* - and this approach would result in far less
|
||||
hardware being supported.
|
||||
|
||||
Libreboot previously had its head in the sand, before November 2022. Since
|
||||
November 2022, Libreboot has been much more pragmatic, implementing the
|
||||
policy that you read now, instead of simply banning all proprietary firmware;
|
||||
the result is increased hardware support, and in practise many of the newer
|
||||
machines we support are still entirely free in coreboot (including memory
|
||||
controller initialisation), right up to Intel Haswell generation.
|
||||
|
||||
You are advised not to put your head in the sand. Better to see the world as
|
||||
it is, and here is the actual world as it is:
|
||||
|
||||
These firmwares are *required*. In some cases, hardware might have firmware
|
||||
baked in but provide an update mechanism, e.g. CPU microcode update
|
||||
mechanism. These firmware updates fix security bugs, reliability issues,
|
||||
and in some cases even *safety issues* (e.g. thermal safety on a CPU fixed by a
|
||||
microcode update).
|
||||
|
||||
Baking firmware into the device means that the firmware is less likely to be
|
||||
seen by the user, so fewer people are likely to raise a fuss about it; if
|
||||
the main boot firmware for example was baked into the PCH on your Intel
|
||||
system, completely non-replaceable or even inaccessible, fewer people would
|
||||
demand free boot firmware and a project like coreboot (and by extension
|
||||
Libreboot) may not even exist!
|
||||
|
||||
Such is the paradox of free firmware development. Libreboot previously took
|
||||
a much more hardline approach, banning absolutely all proprietary firmware
|
||||
whatsoever; the result was that far fewer machines could be supported. A more
|
||||
pragmatic policy, the one you've just read, was introduced in November 2022,
|
||||
in an effort to support more hardware and therefore increase the number of
|
||||
coreboot users; by extension, this will lead to more coreboot development,
|
||||
and more proprietary firmware being replaced with free software.
|
||||
|
||||
Facts are facts; how you handle them is where the magic happens, and Libreboot
|
||||
has made its choice. The result since November 2022 has indeed been more
|
||||
coreboot users, and a lot more hardware supported; more hardware has been
|
||||
ported to coreboot, that might not have even been ported in the first place,
|
||||
e.g. more Dell Latitude laptops are supported now (basically all of the
|
||||
IvyBridge and SandyBridge ones).
|
||||
|
||||
The four freedoms are absolute, but the road to freedom is never a straight
|
||||
line. Libreboot's policies are laser-focused on getting to that final goal,
|
||||
but without being dogmatic. By being flexible, while pushing for more firmware
|
||||
to be freed, more firmware is freed. It's as simple as that. We don't want
|
||||
proprietary software at all, but in order to have less of it, we have to
|
||||
have more - for now.
|
||||
|
||||
Let's take an extreme example: what if coreboot was entirely binary blobs
|
||||
for a given mainboard? Coreboot itself only initialises the hardware, and
|
||||
jumps to a payload in the flash; in this case, the payload (e.g. GNU GRUB)
|
||||
would still be free software. Surely, all free firmware would be better,
|
||||
but this is still an improvement over the original vendor firmware. The
|
||||
original vendor firmware will have non-free boot firmware *and* its analog
|
||||
of a coreboot payload (typically a UEFI implementation running various
|
||||
applications via DXEs) would be non-free. *Coreboot does* in fact do this
|
||||
on many newer Intel and AMD platforms, all of which Libreboot intends to
|
||||
accomodate in the future, and doing so would absolutely comply with this
|
||||
very policy that you are reading now, namely the Binary Blob Reduction Policy.
|
||||
|
||||
You can bet we'll tell everyone that Intel FSP is bad and should be replaced
|
||||
with free software, and we do; many Intel blobs have in fact been replaced
|
||||
with Free Software. For example, Libreboot previously provided Intel MRC
|
||||
which is a raminit blob, on Intel Haswell machines. Angel Pons reverse
|
||||
engineered the MRC and wrote native memory controller initialisation (raminit)
|
||||
on this platform, which Libreboot now uses instead of MRC.
|
||||
|
||||
This is a delicate balance, that a lot of projects get wrong - they will
|
||||
accept blobs, and *not* talk about them. In Libreboot, it's the exact
|
||||
opposite: we make sure you know about them, and tell you that they are bad,
|
||||
and we say that they should be fully replaced.
|
||||
|
||||
Unlike some in the community, we even advocate for free software in cases
|
||||
where the software can't actually be replaced. For example: the RP2040 Boot ROM
|
||||
is free software, with public source code:
|
||||
|
||||
<https://github.com/raspberrypi/pico-bootrom-rp2040>
|
||||
|
||||
This is the boot ROM source code for RP2040 devices such as Raspberry Pi Pico.
|
||||
It is a reprogrammable device, and we even use it as a
|
||||
cheap [SPI flasher](../docs/install/spi.md) running `pico-serprog`. The
|
||||
main firmware is replaceable, but the *boot ROM* is read-only on this machine;
|
||||
there are some people would would not insist on free software at that level,
|
||||
despite being free software activists, because they would regard the boot
|
||||
ROM as "part of the hardware" - in Libreboot, we insist that all such
|
||||
software, including this, be free. Freedom merely to study the source code
|
||||
is still an important freedom, and someone might make a replica of the
|
||||
hardware at some point; if they do, that boot ROM source code is there for
|
||||
them to use, without having to re-implement it themselves. Isn't that great?
|
||||
|
||||
I hope that these examples might inspire some people to take more action in
|
||||
demanding free software everywhere, and to enlighten more people on the road
|
||||
to software freedom. The road Libreboot takes is the one less traveled, the
|
||||
one of pragmatism without compromise; we will not lose sight of our original
|
||||
goals, namely absolute computer user freedom.
|
||||
|
||||
The article will end here, because anything else would be more rambling.
|
||||
|
|
|
|||
|
|
@ -168,3 +168,212 @@ exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
|
|||
* <https://libresilicon.com/>
|
||||
|
||||
(Sam literally makes CPUs in his garage)
|
||||
|
||||
Why?
|
||||
====
|
||||
|
||||
This next section previously existed in a less than diplomatic manner. It
|
||||
has been restored, as of August 2024, because the wisdom that it provides is
|
||||
important, yet being respectful of our friends in Massachussets is also
|
||||
a good thing to do, where feasible. This section was previously deleted, as
|
||||
a gesture of good will to this people, but it can't not be here, so without
|
||||
further ado:
|
||||
|
||||
Firstly, observe the following graphic:
|
||||
|
||||
|
||||
|
||||
Why does this policy page need to be written? Isn't it just describing basic
|
||||
common sense? The common sense that free software activism must demand all
|
||||
software to be free; why even talk about it?
|
||||
|
||||
This page has talked about Libreboot's *blob reduction policy*, but more
|
||||
context is needed. We need to talk about it, because there are many different
|
||||
interpretations for the exact same argument, depending on your point of view.
|
||||
|
||||
If you use a piece of hardware in Linux, and it works, you might see that it has
|
||||
free drivers and think nothing else. You will run free application software
|
||||
such as Firefox, Vim, KDE Plasma desktop, and everything is wonderful, right?
|
||||
|
||||
Where drivers and applications (and your operating system) are concerned, this
|
||||
is much clearer, because it's software that you're running on your main CPU,
|
||||
that you installed yourself. What of firmware?
|
||||
|
||||
Libreboot is not the only firmware that exists on your machine, when you have
|
||||
Libreboot. Look at these articles, which cover other firmwares:
|
||||
|
||||
* <https://libreboot.org/faq.html#what-other-firmware-exists-outside-of-libreboot>
|
||||
* <https://libreboot.org/faq.html#what-level-of-software-freedom-does-libreboot-give-me>
|
||||
|
||||
You may ask: should the other firmwares be free too? The answer is **yes**, but
|
||||
it's complicated: it's not always practical to even study those firmwares. For
|
||||
example, there are so many webcams out there, so many SSDs, so many devices
|
||||
all doing the same thing, but implemented differently. Coreboot is already
|
||||
hard enough, and there are so many mainboards out there.
|
||||
|
||||
For example: every SSD has its own controller, and it has to do a lot of
|
||||
error correction at great speed, to mitigate the inherent unreliability of
|
||||
NAND flash. This firmware is highly specialised, and tailored to *that* SSD;
|
||||
not merely that SSD product line, but *that* SSD, because it often has to be
|
||||
tweaked per SSD; ditto SD cards, which fundamentally use the same technology.
|
||||
Would it be practical for something like Linux to provide firmware for
|
||||
absolutely every SSD? No. Absolutely not; and this is actually an example of
|
||||
where it makes more sense to bake the firmware into the hardware, rather than
|
||||
supply it as a firmware in Linux (even if the firmware is updateable, which it
|
||||
is on some SSDs).
|
||||
|
||||
Another example: your wireless card implements a software defined radio, to
|
||||
implement all of the various WiFi protocols, which is what your WiFi drivers
|
||||
make use of. The drivers themselves are also quite complicated. However, the
|
||||
same driver might be able to operate multiple wireless cards, if there is
|
||||
some standard interface (regardless of whether it's documented), that the
|
||||
same driver can use between all the cards, even if those cards are all very
|
||||
different; this is where firmware comes in.
|
||||
|
||||
Coreboot only covers the main boot firmware, but you will have other firmware
|
||||
running on your machine. It's simply a fact.
|
||||
|
||||
Historically, a lot of hardware has firmware baked into it, which does whatever
|
||||
it does on that piece of hardware (e.g. software defined radio on a wifi
|
||||
device, firmware implementing an AHCI interface for your SATA SSD).
|
||||
|
||||
In some cases, you will find that this firmware is *not* baked into the device.
|
||||
Instead, a firmware is provided in Linux, uploaded to the device at boot
|
||||
time, and this must be performed every time you boot or every time you plug
|
||||
in that device.
|
||||
|
||||
Having firmware in Linux is *good*. Proprietary software is also *bad*, so why
|
||||
is having *more* proprietary firmware in Linux *good*? Surely, free firmware
|
||||
would be better, but this firmware has never been free; typically, most
|
||||
firmware has been non-free, but baked into the hardware so you just didn't
|
||||
see it. We can demand that the vendors release source code, and we do; in some
|
||||
cases, we even succeed (for example `ath9k_htc` WiFi dongles have free firmware
|
||||
available in Linux).
|
||||
|
||||
The reason vendors put more firmware in Linux nowadays is it's cheaper. If the
|
||||
device itself has firmware baked in, then more money is spent on the EEPROM
|
||||
that stores it, and it makes research/development more expensive; having an
|
||||
easy software update mechanism allows bugs to be fixed more quickly, during
|
||||
development and post-release, thus reducing costs. This saves the
|
||||
industry *billions*, and it is actually of benefit to the free software
|
||||
community, because it makes reverse engineering easier, and it makes
|
||||
actually updating the firmware easier, so more proprietary software can
|
||||
actually be *replaced with free software*. If some standard interface exists,
|
||||
for the firmware, then that makes reverse engineering easier *across many
|
||||
devices*, instead of just one.
|
||||
|
||||
Hardware is also very complex, more so now than in the past; having the
|
||||
hardware be flexible, configured by *firmware*, makes it easier to work
|
||||
around defects in the hardware. For example, if a circuit for a new feature
|
||||
is quite buggy on a bit of hardware, but could be turned off without ill
|
||||
consequence, a firmware update might do exactly that.
|
||||
|
||||
The existence of such firmware also reminds more people of that fact, so more
|
||||
people are likely to demand free software. If the firmware is *hidden in the
|
||||
hardware*, fewer people are likely to raise a stink about it. We in the
|
||||
Libreboot project want all firmware to be free, and we've known of this
|
||||
problem for years.
|
||||
|
||||
Some people take what we call the *head in the sand* approach, where any and
|
||||
all software in Linux must be excluded; certain distros out there do this, and
|
||||
it is an entirely misguided approach. It is misguided, precisely because it
|
||||
tells people that *compatible* hardware is more free, when it isn't; more
|
||||
likely, any hardware that works (without firmware in Linux) likely just has
|
||||
that same firmware baked into it; in other words, hidden from the user. Hence
|
||||
the *head in the sand approach* - and this approach would result in far less
|
||||
hardware being supported.
|
||||
|
||||
Libreboot previously had its head in the sand, before November 2022. Since
|
||||
November 2022, Libreboot has been much more pragmatic, implementing the
|
||||
policy that you read now, instead of simply banning all proprietary firmware;
|
||||
the result is increased hardware support, and in practise many of the newer
|
||||
machines we support are still entirely free in coreboot (including memory
|
||||
controller initialisation), right up to Intel Haswell generation.
|
||||
|
||||
You are advised not to put your head in the sand. Better to see the world as
|
||||
it is, and here is the actual world as it is:
|
||||
|
||||
These firmwares are *required*. In some cases, hardware might have firmware
|
||||
baked in but provide an update mechanism, e.g. CPU microcode update
|
||||
mechanism. These firmware updates fix security bugs, reliability issues,
|
||||
and in some cases even *safety issues* (e.g. thermal safety on a CPU fixed by a
|
||||
microcode update).
|
||||
|
||||
Baking firmware into the device means that the firmware is less likely to be
|
||||
seen by the user, so fewer people are likely to raise a fuss about it; if
|
||||
the main boot firmware for example was baked into the PCH on your Intel
|
||||
system, completely non-replaceable or even inaccessible, fewer people would
|
||||
demand free boot firmware and a project like coreboot (and by extension
|
||||
Libreboot) may not even exist!
|
||||
|
||||
Such is the paradox of free firmware development. Libreboot previously took
|
||||
a much more hardline approach, banning absolutely all proprietary firmware
|
||||
whatsoever; the result was that far fewer machines could be supported. A more
|
||||
pragmatic policy, the one you've just read, was introduced in November 2022,
|
||||
in an effort to support more hardware and therefore increase the number of
|
||||
coreboot users; by extension, this will lead to more coreboot development,
|
||||
and more proprietary firmware being replaced with free software.
|
||||
|
||||
Facts are facts; how you handle them is where the magic happens, and Libreboot
|
||||
has made its choice. The result since November 2022 has indeed been more
|
||||
coreboot users, and a lot more hardware supported; more hardware has been
|
||||
ported to coreboot, that might not have even been ported in the first place,
|
||||
e.g. more Dell Latitude laptops are supported now (basically all of the
|
||||
IvyBridge and SandyBridge ones).
|
||||
|
||||
The four freedoms are absolute, but the road to freedom is never a straight
|
||||
line. Libreboot's policies are laser-focused on getting to that final goal,
|
||||
but without being dogmatic. By being flexible, while pushing for more firmware
|
||||
to be freed, more firmware is freed. It's as simple as that. We don't want
|
||||
proprietary software at all, but in order to have less of it, we have to
|
||||
have more - for now.
|
||||
|
||||
Let's take an extreme example: what if coreboot was entirely binary blobs
|
||||
for a given mainboard? Coreboot itself only initialises the hardware, and
|
||||
jumps to a payload in the flash; in this case, the payload (e.g. GNU GRUB)
|
||||
would still be free software. Surely, all free firmware would be better,
|
||||
but this is still an improvement over the original vendor firmware. The
|
||||
original vendor firmware will have non-free boot firmware *and* its analog
|
||||
of a coreboot payload (typically a UEFI implementation running various
|
||||
applications via DXEs) would be non-free. *Coreboot does* in fact do this
|
||||
on many newer Intel and AMD platforms, all of which Libreboot intends to
|
||||
accomodate in the future, and doing so would absolutely comply with this
|
||||
very policy that you are reading now, namely the Binary Blob Reduction Policy.
|
||||
|
||||
You can bet we'll tell everyone that Intel FSP is bad and should be replaced
|
||||
with free software, and we do; many Intel blobs have in fact been replaced
|
||||
with Free Software. For example, Libreboot previously provided Intel MRC
|
||||
which is a raminit blob, on Intel Haswell machines. Angel Pons reverse
|
||||
engineered the MRC and wrote native memory controller initialisation (raminit)
|
||||
on this platform, which Libreboot now uses instead of MRC.
|
||||
|
||||
This is a delicate balance, that a lot of projects get wrong - they will
|
||||
accept blobs, and *not* talk about them. In Libreboot, it's the exact
|
||||
opposite: we make sure you know about them, and tell you that they are bad,
|
||||
and we say that they should be fully replaced.
|
||||
|
||||
Unlike some in the community, we even advocate for free software in cases
|
||||
where the software can't actually be replaced. For example: the RP2040 Boot ROM
|
||||
is free software, with public source code:
|
||||
|
||||
<https://github.com/raspberrypi/pico-bootrom-rp2040>
|
||||
|
||||
This is the boot ROM source code for RP2040 devices such as Raspberry Pi Pico.
|
||||
It is a reprogrammable device, and we even use it as a
|
||||
cheap [SPI flasher](../docs/install/spi.md) running `pico-serprog`. The
|
||||
main firmware is replaceable, but the *boot ROM* is read-only on this machine;
|
||||
there are some people would would not insist on free software at that level,
|
||||
despite being free software activists, because they would regard the boot
|
||||
ROM as "part of the hardware" - in Libreboot, we insist that all such
|
||||
software, including this, be free. Freedom merely to study the source code
|
||||
is still an important freedom, and someone might make a replica of the
|
||||
hardware at some point; if they do, that boot ROM source code is there for
|
||||
them to use, without having to re-implement it themselves. Isn't that great?
|
||||
|
||||
I hope that these examples might inspire some people to take more action in
|
||||
demanding free software everywhere, and to enlighten more people on the road
|
||||
to software freedom. The road Libreboot takes is the one less traveled, the
|
||||
one of pragmatism without compromise; we will not lose sight of our original
|
||||
goals, namely absolute computer user freedom.
|
||||
|
||||
The article will end here, because anything else would be more rambling.
|
||||
|
|
|
|||
|
|
@ -170,3 +170,212 @@ Libreboot вирішує цю ситуацію *суворо* та *принци
|
|||
* <https://libresilicon.com/>
|
||||
|
||||
(Сем буквально виробляє процесори в своєму гаражі)
|
||||
|
||||
Why?
|
||||
====
|
||||
|
||||
This next section previously existed in a less than diplomatic manner. It
|
||||
has been restored, as of August 2024, because the wisdom that it provides is
|
||||
important, yet being respectful of our friends in Massachussets is also
|
||||
a good thing to do, where feasible. This section was previously deleted, as
|
||||
a gesture of good will to this people, but it can't not be here, so without
|
||||
further ado:
|
||||
|
||||
Firstly, observe the following graphic:
|
||||
|
||||
|
||||
|
||||
Why does this policy page need to be written? Isn't it just describing basic
|
||||
common sense? The common sense that free software activism must demand all
|
||||
software to be free; why even talk about it?
|
||||
|
||||
This page has talked about Libreboot's *blob reduction policy*, but more
|
||||
context is needed. We need to talk about it, because there are many different
|
||||
interpretations for the exact same argument, depending on your point of view.
|
||||
|
||||
If you use a piece of hardware in Linux, and it works, you might see that it has
|
||||
free drivers and think nothing else. You will run free application software
|
||||
such as Firefox, Vim, KDE Plasma desktop, and everything is wonderful, right?
|
||||
|
||||
Where drivers and applications (and your operating system) are concerned, this
|
||||
is much clearer, because it's software that you're running on your main CPU,
|
||||
that you installed yourself. What of firmware?
|
||||
|
||||
Libreboot is not the only firmware that exists on your machine, when you have
|
||||
Libreboot. Look at these articles, which cover other firmwares:
|
||||
|
||||
* <https://libreboot.org/faq.html#what-other-firmware-exists-outside-of-libreboot>
|
||||
* <https://libreboot.org/faq.html#what-level-of-software-freedom-does-libreboot-give-me>
|
||||
|
||||
You may ask: should the other firmwares be free too? The answer is **yes**, but
|
||||
it's complicated: it's not always practical to even study those firmwares. For
|
||||
example, there are so many webcams out there, so many SSDs, so many devices
|
||||
all doing the same thing, but implemented differently. Coreboot is already
|
||||
hard enough, and there are so many mainboards out there.
|
||||
|
||||
For example: every SSD has its own controller, and it has to do a lot of
|
||||
error correction at great speed, to mitigate the inherent unreliability of
|
||||
NAND flash. This firmware is highly specialised, and tailored to *that* SSD;
|
||||
not merely that SSD product line, but *that* SSD, because it often has to be
|
||||
tweaked per SSD; ditto SD cards, which fundamentally use the same technology.
|
||||
Would it be practical for something like Linux to provide firmware for
|
||||
absolutely every SSD? No. Absolutely not; and this is actually an example of
|
||||
where it makes more sense to bake the firmware into the hardware, rather than
|
||||
supply it as a firmware in Linux (even if the firmware is updateable, which it
|
||||
is on some SSDs).
|
||||
|
||||
Another example: your wireless card implements a software defined radio, to
|
||||
implement all of the various WiFi protocols, which is what your WiFi drivers
|
||||
make use of. The drivers themselves are also quite complicated. However, the
|
||||
same driver might be able to operate multiple wireless cards, if there is
|
||||
some standard interface (regardless of whether it's documented), that the
|
||||
same driver can use between all the cards, even if those cards are all very
|
||||
different; this is where firmware comes in.
|
||||
|
||||
Coreboot only covers the main boot firmware, but you will have other firmware
|
||||
running on your machine. It's simply a fact.
|
||||
|
||||
Historically, a lot of hardware has firmware baked into it, which does whatever
|
||||
it does on that piece of hardware (e.g. software defined radio on a wifi
|
||||
device, firmware implementing an AHCI interface for your SATA SSD).
|
||||
|
||||
In some cases, you will find that this firmware is *not* baked into the device.
|
||||
Instead, a firmware is provided in Linux, uploaded to the device at boot
|
||||
time, and this must be performed every time you boot or every time you plug
|
||||
in that device.
|
||||
|
||||
Having firmware in Linux is *good*. Proprietary software is also *bad*, so why
|
||||
is having *more* proprietary firmware in Linux *good*? Surely, free firmware
|
||||
would be better, but this firmware has never been free; typically, most
|
||||
firmware has been non-free, but baked into the hardware so you just didn't
|
||||
see it. We can demand that the vendors release source code, and we do; in some
|
||||
cases, we even succeed (for example `ath9k_htc` WiFi dongles have free firmware
|
||||
available in Linux).
|
||||
|
||||
The reason vendors put more firmware in Linux nowadays is it's cheaper. If the
|
||||
device itself has firmware baked in, then more money is spent on the EEPROM
|
||||
that stores it, and it makes research/development more expensive; having an
|
||||
easy software update mechanism allows bugs to be fixed more quickly, during
|
||||
development and post-release, thus reducing costs. This saves the
|
||||
industry *billions*, and it is actually of benefit to the free software
|
||||
community, because it makes reverse engineering easier, and it makes
|
||||
actually updating the firmware easier, so more proprietary software can
|
||||
actually be *replaced with free software*. If some standard interface exists,
|
||||
for the firmware, then that makes reverse engineering easier *across many
|
||||
devices*, instead of just one.
|
||||
|
||||
Hardware is also very complex, more so now than in the past; having the
|
||||
hardware be flexible, configured by *firmware*, makes it easier to work
|
||||
around defects in the hardware. For example, if a circuit for a new feature
|
||||
is quite buggy on a bit of hardware, but could be turned off without ill
|
||||
consequence, a firmware update might do exactly that.
|
||||
|
||||
The existence of such firmware also reminds more people of that fact, so more
|
||||
people are likely to demand free software. If the firmware is *hidden in the
|
||||
hardware*, fewer people are likely to raise a stink about it. We in the
|
||||
Libreboot project want all firmware to be free, and we've known of this
|
||||
problem for years.
|
||||
|
||||
Some people take what we call the *head in the sand* approach, where any and
|
||||
all software in Linux must be excluded; certain distros out there do this, and
|
||||
it is an entirely misguided approach. It is misguided, precisely because it
|
||||
tells people that *compatible* hardware is more free, when it isn't; more
|
||||
likely, any hardware that works (without firmware in Linux) likely just has
|
||||
that same firmware baked into it; in other words, hidden from the user. Hence
|
||||
the *head in the sand approach* - and this approach would result in far less
|
||||
hardware being supported.
|
||||
|
||||
Libreboot previously had its head in the sand, before November 2022. Since
|
||||
November 2022, Libreboot has been much more pragmatic, implementing the
|
||||
policy that you read now, instead of simply banning all proprietary firmware;
|
||||
the result is increased hardware support, and in practise many of the newer
|
||||
machines we support are still entirely free in coreboot (including memory
|
||||
controller initialisation), right up to Intel Haswell generation.
|
||||
|
||||
You are advised not to put your head in the sand. Better to see the world as
|
||||
it is, and here is the actual world as it is:
|
||||
|
||||
These firmwares are *required*. In some cases, hardware might have firmware
|
||||
baked in but provide an update mechanism, e.g. CPU microcode update
|
||||
mechanism. These firmware updates fix security bugs, reliability issues,
|
||||
and in some cases even *safety issues* (e.g. thermal safety on a CPU fixed by a
|
||||
microcode update).
|
||||
|
||||
Baking firmware into the device means that the firmware is less likely to be
|
||||
seen by the user, so fewer people are likely to raise a fuss about it; if
|
||||
the main boot firmware for example was baked into the PCH on your Intel
|
||||
system, completely non-replaceable or even inaccessible, fewer people would
|
||||
demand free boot firmware and a project like coreboot (and by extension
|
||||
Libreboot) may not even exist!
|
||||
|
||||
Such is the paradox of free firmware development. Libreboot previously took
|
||||
a much more hardline approach, banning absolutely all proprietary firmware
|
||||
whatsoever; the result was that far fewer machines could be supported. A more
|
||||
pragmatic policy, the one you've just read, was introduced in November 2022,
|
||||
in an effort to support more hardware and therefore increase the number of
|
||||
coreboot users; by extension, this will lead to more coreboot development,
|
||||
and more proprietary firmware being replaced with free software.
|
||||
|
||||
Facts are facts; how you handle them is where the magic happens, and Libreboot
|
||||
has made its choice. The result since November 2022 has indeed been more
|
||||
coreboot users, and a lot more hardware supported; more hardware has been
|
||||
ported to coreboot, that might not have even been ported in the first place,
|
||||
e.g. more Dell Latitude laptops are supported now (basically all of the
|
||||
IvyBridge and SandyBridge ones).
|
||||
|
||||
The four freedoms are absolute, but the road to freedom is never a straight
|
||||
line. Libreboot's policies are laser-focused on getting to that final goal,
|
||||
but without being dogmatic. By being flexible, while pushing for more firmware
|
||||
to be freed, more firmware is freed. It's as simple as that. We don't want
|
||||
proprietary software at all, but in order to have less of it, we have to
|
||||
have more - for now.
|
||||
|
||||
Let's take an extreme example: what if coreboot was entirely binary blobs
|
||||
for a given mainboard? Coreboot itself only initialises the hardware, and
|
||||
jumps to a payload in the flash; in this case, the payload (e.g. GNU GRUB)
|
||||
would still be free software. Surely, all free firmware would be better,
|
||||
but this is still an improvement over the original vendor firmware. The
|
||||
original vendor firmware will have non-free boot firmware *and* its analog
|
||||
of a coreboot payload (typically a UEFI implementation running various
|
||||
applications via DXEs) would be non-free. *Coreboot does* in fact do this
|
||||
on many newer Intel and AMD platforms, all of which Libreboot intends to
|
||||
accomodate in the future, and doing so would absolutely comply with this
|
||||
very policy that you are reading now, namely the Binary Blob Reduction Policy.
|
||||
|
||||
You can bet we'll tell everyone that Intel FSP is bad and should be replaced
|
||||
with free software, and we do; many Intel blobs have in fact been replaced
|
||||
with Free Software. For example, Libreboot previously provided Intel MRC
|
||||
which is a raminit blob, on Intel Haswell machines. Angel Pons reverse
|
||||
engineered the MRC and wrote native memory controller initialisation (raminit)
|
||||
on this platform, which Libreboot now uses instead of MRC.
|
||||
|
||||
This is a delicate balance, that a lot of projects get wrong - they will
|
||||
accept blobs, and *not* talk about them. In Libreboot, it's the exact
|
||||
opposite: we make sure you know about them, and tell you that they are bad,
|
||||
and we say that they should be fully replaced.
|
||||
|
||||
Unlike some in the community, we even advocate for free software in cases
|
||||
where the software can't actually be replaced. For example: the RP2040 Boot ROM
|
||||
is free software, with public source code:
|
||||
|
||||
<https://github.com/raspberrypi/pico-bootrom-rp2040>
|
||||
|
||||
This is the boot ROM source code for RP2040 devices such as Raspberry Pi Pico.
|
||||
It is a reprogrammable device, and we even use it as a
|
||||
cheap [SPI flasher](../docs/install/spi.md) running `pico-serprog`. The
|
||||
main firmware is replaceable, but the *boot ROM* is read-only on this machine;
|
||||
there are some people would would not insist on free software at that level,
|
||||
despite being free software activists, because they would regard the boot
|
||||
ROM as "part of the hardware" - in Libreboot, we insist that all such
|
||||
software, including this, be free. Freedom merely to study the source code
|
||||
is still an important freedom, and someone might make a replica of the
|
||||
hardware at some point; if they do, that boot ROM source code is there for
|
||||
them to use, without having to re-implement it themselves. Isn't that great?
|
||||
|
||||
I hope that these examples might inspire some people to take more action in
|
||||
demanding free software everywhere, and to enlighten more people on the road
|
||||
to software freedom. The road Libreboot takes is the one less traveled, the
|
||||
one of pragmatism without compromise; we will not lose sight of our original
|
||||
goals, namely absolute computer user freedom.
|
||||
|
||||
The article will end here, because anything else would be more rambling.
|
||||
|
|
|
|||
Loading…
Reference in New Issue