From e8aaa24fb8b747f790a26931d7ba669a5f30ec97 Mon Sep 17 00:00:00 2001 From: Leah Rowe Date: Tue, 27 Aug 2024 16:27:19 +0100 Subject: [PATCH] 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 --- site/news/policy.de.md | 209 +++++++++++++++++++++++++++++++++++++++++ site/news/policy.md | 209 +++++++++++++++++++++++++++++++++++++++++ site/news/policy.uk.md | 209 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 627 insertions(+) diff --git a/site/news/policy.de.md b/site/news/policy.de.md index 203ab7d..037d059 100644 --- a/site/news/policy.de.md +++ b/site/news/policy.de.md @@ -176,3 +176,212 @@ exist, for example, the work done by Sam Zeloof and the Libre Silicon project: * (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: + +![](https://av.libreboot.org/firmware.png) + +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: + +* +* + +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: + + + +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. diff --git a/site/news/policy.md b/site/news/policy.md index b2e6b29..1686f9f 100644 --- a/site/news/policy.md +++ b/site/news/policy.md @@ -168,3 +168,212 @@ exist, for example, the work done by Sam Zeloof and the Libre Silicon project: * (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: + +![](https://av.libreboot.org/firmware.png) + +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: + +* +* + +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: + + + +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. diff --git a/site/news/policy.uk.md b/site/news/policy.uk.md index ad25505..4ba7616 100644 --- a/site/news/policy.uk.md +++ b/site/news/policy.uk.md @@ -170,3 +170,212 @@ Libreboot вирішує цю ситуацію *суворо* та *принци * (Сем буквально виробляє процесори в своєму гаражі) + +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: + +![](https://av.libreboot.org/firmware.uk.png) + +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: + +* +* + +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: + + + +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.