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.
> 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-... 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.)
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/
[1]: https://libreboot.org/news/merge.html
[2]: https://libreboot.org/news/policy.html