3 ms·

Libreboot is a fork of Coreboot, an open source system firmware/BIOS replacement. You are most likely to find it in Google's "Chromebooks" and other devices as

Libreboot is a fork of Coreboot, an open source system firmware/BIOS replacement. You are most likely to find it in Google's "Chromebooks" and other devices as Google hired most of the dev team behind the software Libreboot differs in that it refuses to include things such as CPU microcode. Because the FSF has an absolutely asinine definition of "free software" wherein any code that can be modified or updated is non-free, but if it comes from an untouchable ROM chip they can pretend it's still "free"

snvzz 4y ago
>if it comes from an untouchable ROM chip If it does, then it is hardware. >they can pretend it's still "free" Or rather, not software, thus out of scope.
- notpushkin 4y ago
  This never really made any sense to me. If I build a PC with Windows installed on a read-only flash drive, can I advertise it as running 100% free software?
  - anikom15 4y ago
    Does that mean Super Mario Bros. was free software until it was released on VC?
ThePowerOfFuet 4y ago
> Because the FSF has an absolutely asinine definition of "free software" wherein any code that can be modified or updated is non-free, but if it comes from an untouchable ROM chip they can pretend it's still "free" So mask ROM or OTP ROM are okay, but EPROM/EEPROM/flash are not?
- ahartmetz 4y ago
  Exactly. It is counterintuitive, but they have to draw the line somewhere, and then such things happen. No way around it without making up some rather arbitrary new definitions, with all that problems(1) that that brings. Well, actually. The distinction between hardware (here: basically 3D-printed VHDL et al) and software is already such an arbitrary definition. (1) like manufacturers tweaking details to fall under the desired definition, legal arguments about the definitions, etc...
- deleted 4y ago
  [deleted]
- zajio1am 4y ago
  No, distribution of non-free firmware is not ok, while interacting with firmware that is already there (e.g. from ROM or EEPROM) is okay.
LukeShu 4y ago
> Libreboot is a fork of Coreboot They've always called themselves a "Coreboot distro", not a fork. From the homepage: "In the same way that Debian is a GNU+Linux distribution, libreboot is a coreboot distribution."[0] That was a lot bigger deal when libreboot first started, because at the time Coreboot wasn't doing their own releases, so doing release engineering and such around Coreboot was a lot more of a value-add. > Libreboot … refuses to include things such as CPU microcode. That is false since the libreboot+osboot merger. Osboot was a fork of libreboot that had a more lax binary blob policy; they merged back together last month[1], taking osboot's more lax policy[2], which does block out some binary blobs from upstream Coreboot, but allows important blobs such as CPU microcode. > Because the FSF I'd be hesitant to say that libreboot does anything because of the FSF; libreboot and the FSF have had a... tumultuous relationship, for both technical/policy reasons, and personal reasons. Libreboot's policy page[2] has a big section about disagreements with the FSF's policy. It's more fair to say that libreboot does things because of Leah Rowe's position on things, which will tend to align with the position of FSF supporters, but not necessarily. [0]: https://libreboot.org/ https://libreboot.org/ [1]: https://libreboot.org/news/merge.html https://libreboot.org/news/merge.html [2]: https://libreboot.org/news/policy.html https://libreboot.org/news/policy.html
- pgeorgi 4y ago
  > because at the time Coreboot wasn't doing their own releases, so doing release engineering and such around Coreboot was a lot more of a value-add. Distributions can still offer value through release engineering steps that coreboot skips: https://doc.coreboot.org/releases/checklist.html#purpose-of-coreboot-releases https://doc.coreboot.org/releases/checklist.html#purpose-of-... says about releases: "Our releases aren’t primarily a vehicle for code that is stable across all boards ... Instead, the releases are regular breakpoints ..." Stable libreboot releases, MrChromebox's releases (over at mrchromebox.tech), vendor releases (Chromebooks, System76, Purism, Starlabs, ...) and so on are useful because they provide more rigorous testing for the subset of devices they actively support. Unless you're a developer and/or have tools to recover from a bad flash, these releases are more likely to get you a useful firmware image compared to coreboot.org releases. (That doesn't mean we're not doing _any_ testing before releasing on coreboot.org, but it's somewhat stochastic: whatever the release team has tested themselves or got reports on is good, everything else is of unknown quality.)
zajio1am 4y ago
> Because the FSF has an absolutely asinine definition of "free software" wherein any code that can be modified or updated is non-free, but if it comes from an untouchable ROM chip they can pretend it's still "free" That is gross misrepresentation of their position. It is more like if a project is claiming to be free software, then it should not have parts that are non-free software (like redistributing firmware). If the firmware is in hardware ROM or EEPROM chip (or just downloaded independently from third source), then then it is not part of such project and therefore out of scope (i.e. somebody else's problem).

snvzz 4y ago

>if it comes from an untouchable ROM chip If it does, then it is hardware. >they can pretend it's still "free" Or rather, not software, thus out of scope.

notpushkin 4y ago
This never really made any sense to me. If I build a PC with Windows installed on a read-only flash drive, can I advertise it as running 100% free software?
- anikom15 4y ago
  Does that mean Super Mario Bros. was free software until it was released on VC?

ThePowerOfFuet 4y ago

ahartmetz 4y ago
Exactly. It is counterintuitive, but they have to draw the line somewhere, and then such things happen. No way around it without making up some rather arbitrary new definitions, with all that problems(1) that that brings. Well, actually. The distinction between hardware (here: basically 3D-printed VHDL et al) and software is already such an arbitrary definition. (1) like manufacturers tweaking details to fall under the desired definition, legal arguments about the definitions, etc...
deleted 4y ago
[deleted]
zajio1am 4y ago
No, distribution of non-free firmware is not ok, while interacting with firmware that is already there (e.g. from ROM or EEPROM) is okay.

LukeShu 4y ago

> Libreboot is a fork of Coreboot They've always called themselves a "Coreboot distro", not a fork. From the homepage: "In the same way that Debian is a GNU+Linux distribution, libreboot is a coreboot distribution."[0] That was a lot bigger deal when libreboot first started, because at the time Coreboot wasn't doing their own releases, so doing release engineering and such around Coreboot was a lot more of a value-add. > Libreboot … refuses to include things such as CPU microcode. That is false since the libreboot+osboot merger. Osboot was a fork of libreboot that had a more lax binary blob policy; they merged back together last month[1], taking osboot's more lax policy[2], which does block out some binary blobs from upstream Coreboot, but allows important blobs such as CPU microcode. > Because the FSF I'd be hesitant to say that libreboot does anything because of the FSF; libreboot and the FSF have had a... tumultuous relationship, for both technical/policy reasons, and personal reasons. Libreboot's policy page[2] has a big section about disagreements with the FSF's policy. It's more fair to say that libreboot does things because of Leah Rowe's position on things, which will tend to align with the position of FSF supporters, but not necessarily. [0]: https://libreboot.org/ https://libreboot.org/ [1]: https://libreboot.org/news/merge.html https://libreboot.org/news/merge.html [2]: https://libreboot.org/news/policy.html https://libreboot.org/news/policy.html

pgeorgi 4y ago
> because at the time Coreboot wasn't doing their own releases, so doing release engineering and such around Coreboot was a lot more of a value-add. Distributions can still offer value through release engineering steps that coreboot skips: https://doc.coreboot.org/releases/checklist.html#purpose-of-coreboot-releases https://doc.coreboot.org/releases/checklist.html#purpose-of-... says about releases: "Our releases aren’t primarily a vehicle for code that is stable across all boards ... Instead, the releases are regular breakpoints ..." Stable libreboot releases, MrChromebox's releases (over at mrchromebox.tech), vendor releases (Chromebooks, System76, Purism, Starlabs, ...) and so on are useful because they provide more rigorous testing for the subset of devices they actively support. Unless you're a developer and/or have tools to recover from a bad flash, these releases are more likely to get you a useful firmware image compared to coreboot.org releases. (That doesn't mean we're not doing _any_ testing before releasing on coreboot.org, but it's somewhat stochastic: whatever the release team has tested themselves or got reports on is good, everything else is of unknown quality.)

zajio1am 4y ago

> Because the FSF has an absolutely asinine definition of "free software" wherein any code that can be modified or updated is non-free, but if it comes from an untouchable ROM chip they can pretend it's still "free" That is gross misrepresentation of their position. It is more like if a project is claiming to be free software, then it should not have parts that are non-free software (like redistributing firmware). If the firmware is in hardware ROM or EEPROM chip (or just downloaded independently from third source), then then it is not part of such project and therefore out of scope (i.e. somebody else's problem).