(real meaning: https://en.wikipedia.org/wiki/Libiberty)
All the heavy lifting is done by Coreboot.
- Release engineering and testing. When Libreboot started, upstream coreboot wasn't doing releases at all; now they are, but they're still not suitable for end-users who want to use stable tested software: "Our releases aren’t primarily a vehicle for code that is stable across all boards"[0]. Downstream distributions that test on a specific range of devices (such as Libreboot, mrchromebox.tech, and vendors such as Chromebooks, Purism, System 76, ...) are still important to the ecosystem to provide stable releases. In the words of a coreboot dev: https://news.ycombinator.com/item?id=33997880
- Pre-compiled and tested binaries, because lots of users aren't set up to build their own.
- A distribution of tools for more easily installing them than a sequence of long `flashram` incantations.
- Loads of documentation.
- Pre-configuration of common payloads, such as GRUB or SeaBIOS.
And let's not forget that the Libreboot project does contribute to upstream coreboot.
[0]: https://doc.coreboot.org/releases/checklist.html#purpose-of-...
I wouldn't call it drama. There's often important practical reasons to try to minimize closed parts of the firmware. See also the high-security / high-trustworthiness work of Purism.
The page https://libreboot.org/news/policy.html does a better job of showing how the Libreboot's policy is at odds with the FSF's RYF and FSDG policies. And that disagreement between Libreboot and the FSF definitely causes drama in the community.
Heck, a few Libreboot contributors split off and created a fork (also claiming the Libreboot name): https://libreboot.at/
After reading the posts from marcan_42 and GrapheneOS developer strcat, I have a much lower opinion of Purism.
https://hn.algolia.com/?query=strcat%20purism&sort=byDate&ty...
https://hn.algolia.com/?query=marcan_42%20purism&sort=byDate...
They recently included non-free binary blobs. They should probably rename to openboot
Most importantly it identifies devices, which can be booted with as little involvement of non-free blobs (binary large objects) and pre-configures coreboot to support exactly that use-case, whilst enabling features off by default in Coreboot like CMOS settings. Also it disables the Intel Management engine, not by patching it out, but by booting in a way which does not require it to load in the first place, if possible. Depending on architecture, like some laptops with Core2 and some server boards like any AMD processor from the Bulldozer era can be booted off-of firmware images, which contain no black-box blobs from the manufacturer or parts, which cannot be recreated from FOSS code. Most crucially, this also includes μCode updates.
So it could be seen as a tradeoff in stability and performance to get close to the ideal of extending FOSS into the realm of Hardware.
