Canoeboot 20240504 and Libreboot 20240504 released. Simultaneous stable releases. Free BIOS replacement.
- Login o registrati per inviare commenti
Simultaneous Libreboot 20240504 and Canoeboot 20240504 releases came out today. Free BIOS/UEFI replacement:
https://libreboot.org/news/libreboot20240504.html
https://canoeboot.org/news/canoeboot20240504.html
Canoeboot is compliant with GNU Free System Distribution Guidelines and probably what more people in FSF/GNU channels are interested in. It's listed on the FSD. See:
https://directory.fsf.org/wiki/Canoeboot
Changes listed in the announcements.
Enjoy!
Installed Canoeboot 20240504 on a Lenovo X200, so far so good. Is there any security or technical improvement compared to version 20160907? Because the startup is a little slower. Why should I update to the latest version?
Thank you,
an old client of yours.
The GRUB maintainer have fixed a slew of reliability issues over the years, including security issues. The newer GRUB code is generally much more robust.
Also: although upstream GRUB doesn't have this, Libreboot adds custom patches that do this:
* One patch series adds USB3 support. It may be useful on some desktop machines with USB3 card.
* Argon2 KDF support, which means you can boot from encrypted LUKS2 easily
The newer GRUB also has better file system support in general.
Nobody should be using the Libreboot 20160907 release, but Libreboot has newer releases. In fact, as stated in the OP, I released new parallel versions of both projects today.
I have tested the new version of canoeboot on a Thinkpad X200, and after some problems I have returned to the 20160907 version.
I have had problems turning off the machine and a couple of slow startups (very very slow), this has happened to me both with a clean ROM and with one with modified M.A.C..
I have used the version of flashrom found in the Trisquel repositories, I think it is version 1.2
https://libreboot.org/docs/install/#target-thinkpad-x220t420t420s
About a lenovo thinkpad x220i bios version 1.31 provided by
lenovo. Getting
libreboot on the notebook requires external flashing? I do not
have the equipment for doing an external flashing.
Thank you.
Anyway...
I don't think this forum is the right place to post news about Libreboot, I quote:
Canoeboot complies with the GNU Free System Distribution Guidelines, whereas Libreboot adopts a more pragmatic Binary Blob Reduction Policy
Maybe Libreboot is more appropriate in the Debian forum, I personally don't understand that idea of the pragmatic Binary Blob Reduction Policy. It seems to me to be the pragmatism of the open source movement, perhaps with more ethics and less pragmatism we will now have more hardware compatible with free software. (phones, tablets, wificard...etc are increasingly a real headache) This is just my personal opinion
Regards.
Will it be "illegal" for me to try and reverse engineer Libreboot or Coreboot binary blobs, or even distribute/install them seeing Libreboot is under GPLv3 and Coreboot is under GPLv2, but those licenses have rules against having binary blobs in them.
Though I'm glad I can "legally" distribute/install/reverse engineer Canoeboot and Gnuboot.
https://savannah.gnu.org/projects/gnuboot/
I think that may be another reason why a large amount of people chose fully free as in freedom software, so as not to be sued, and not just wishing to see source code.
So both freedom to know what the software is doing, and the ability to install it on others computers without getting sued for copyright infringement is a nice reason to use only freely licensed software.
Binary blobs could be under a free license, but may not be legal of others than the developers of Coreboot and Libreboot to freely share if included in Coreboot and Libreboot.
Does Libreboot have a policy/exemption so people like the developers of dasharo are not infringing copyright of Coreboot developers?
Though I do not know if dasharo, I think, is or could be breaking the license by including possible binary blobs.
https://docs.dasharo.com/osf-trivia-list/introduction/
Here
https://en.wikipedia.org/wiki/Talk:Coreboot#Legality_of_reverse_engineering_this_software.
may also show more information about this question.
If no one enforced "copyright" "patents" "trademarks" or other licenses than the only question left could be...
https://en.wikipedia.org/wiki/Talk:Coreboot#Proprietary_blobs.
Is a program a proprietary program if it was in the public domain or under a license that does not require source code, such as a bsd like license, but still does not have source code?
Or is it only proprietary if under a license the does not let the end user to be able to
" Run the program as you wish, for any purpose. The freedom to study how the program works, and change it so it does your computing as you wish. The freedom to redistribute copies so you can help others. The freedom to distribute copies of your modified versions to others. "
I do not know if access to the source code is a precondition for making a program a non-proprietary program or not.
But till than I may need all source code and no binary blobs to even legally share/install a program like Libreboot, without me getting sued for breaking the GNU General Public License, version 3 that it is under.
Though than will those people also break GNU General Public License, version 3 seeing those people sharing Libreboot with it's binary blobs may be breaking copyright?
I do not wish to break the "copyright" of Coreboot and Libreboot developers, like for instance you, libreleah, by having binary blobs in Libreboot, if I use/distribute/fork it, as I than will likely be breaking even your "copyright" libreleah.
If Canoeboot is compliant with GNU Free System Distribution Guidelines should it steer people to use Libreboot as the README.md shows
Canoeboot is maintained in parallel with Libreboot, by the same developer.
You are strongly advised to use *Libreboot*, but a certain minority may
prefer Canoeboot, which is essentially a *censored* Libreboot (no binary
blobs allowed, so only few boards supported whereas Libreboot supports more
boards while minimising the number of blobs to zero when possible).
and
Canoeboot is inferior to Libreboot, in every way, and you should never use it.?
https://www.gnu.org/distros/free-system-distribution-guidelines.html
shows
A free system distribution must not steer users towards obtaining any nonfree information for practical use, or encourage them to do so. The system should have no repositories for nonfree software and no specific recipes for installation of particular nonfree programs. Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow. Programs in the system should not suggest installing nonfree plugins, documentation, and so on.
I think Canoeboot complies with the spirit and the letter of the law that is GNU. It has been audited directly by FSF Licensing and Compliance staff and confirmed to not contain binary blobs.
I've also engineered the Canoeboot build system to protect you further. For example, CONFIG_USE_BLOBS is not only disabled in configs, but the coreboot build system itself is modified so as to never honour it, instead only acting as if the option is disabled.
Ditto microcode; I modify coreboot to never add microcode, even if configs say to do so.
And I thoroughly check each new change in coreboot between revisions, making sure to remove any blobs I find. In practise, coreboto nowadays separates blobs to a 3rdparty repo that I skip downloading of, but sometimes some blobs do slip through, that I then have to delete from master (and I actually do contact the author of the commit that added it, to fix it).
So even if I and my website/docs do espouse views that you object to, the fact of the matter is that the software itself and what I distribute to users, is fully free. I'm giving you the option to use this blob-free coreboot, in the form of Canoeboot releases.
It would be so much easier for me to just maintain Libreboot and nothing else. Frankly, I think you owe a bit more respect than that.
But you do you. Canoeboot will continue to be maintained and give you fully free coreboot firmware.
Thank you for this information about Canoeboot, libreleah.
I'm glad you found ways to deblob upstream code as I did not wish to break the copyright of Coreboot or/and Libreboot developers by me infringing the licenses by having binary blobs in Libreboot or Coreboot if I tried to distribute/fork that software.
I think if I did try to distribute/fork Libreboot or Coreboot, but I did not remove the blobs I would be breaking copyright, as I would be breaking the licenses that the Libreboot and Coreboot developers chose that forbid binary blobs in their software.
I do not think the Libreboot or Coreboot developers are breaking copyright, as it is their writing, but not mine.
I also did not know if others are breaking Libreboot or Coreboot licenses by including binary blobs in Libreboot or Coreboot against the license, so that is why I was trying to ask about that as well as tell about dasharo, in-case that fork I saw on the wikipedia page of Coreboot was breaking the licenses.
I was not trying to be rude, I just did not wish to break your chosen license, libreleah, as it, I think, forbids binary blobs for me to combined into one program or distribute that code combined with blobs in software I may distribute/fork/use.
I hope information about others making forks could help, as well as to help others comply with Libreboot or Coreboot developers wishes to keep binary blobs out of those programs, as the license shows, so I can be in compliance with with the chosen licenses of the developers.
Unless the Libreboot or Coreboot developers put in the license an exemption allowing binary blobs for people other than the developers to also include binary blobs.
Than it will not be against copyright if anyone other than the developers include binary blobs.
Fair enough, and I apologise for my initial reaction; you were simply asking a technical question, which I will attempt to answer now:
Regarding licenses: Coreboot ROM images consist of several binaries inside a file system called CBFS (coreboot filesystem).
Such binaries include, for example: the bootblock, CAR / cache as RAM, postcar, ramstage romstage... a lot of moving parts. Where possible, I ensure that these are built from free/libre source code.
Sometimes coreboot requires that some or all of these be binary blobs. Actually, on all currently supported Libreboot platforms except Broadwell* are blob-free, at least within coreboot.
On Intel-based systems, the flash is further divided into "regions", e.g. IFD, GBE, ME, BIOS. IFD/GBE are config (not software). ME is Intel ME, BIOS is coreboot.
IFD/GBE aren't considered software blobs, because they're not software.
Anyway, cutting straight to the point:
Whether it's legal to mix code depends on the licensing, but coreboot's design makes this much easier. Since all the initialisation stages are broken up into separate binaries within CBFS, it's trivial to mix and match. It's the same as if you had say, an ext4 file system containing a GNU+Linux system but you wanted to install Nvidia drivers(binary ones). Same thing. In that case, you are not directly mixing code together.
So, generally speaking, the presence of blobs in coreboot images is legal, albeit ethically dubious (I'm still against blobs, and I remove them whenever possible).
*Broadwell: the current only supported Broadwell board is HP EliteBook 820 G2, it needs MRC.bin (blob) for raminit, but work is being done by Angel Pons on Haswell raminit (libreboot now provides fully free raminit on Haswell), and that means Broadwell isn't far off.
On all machines except Broadwell machines, Libreboot currently provides one of the following setups, as regards binary blobs:
* Only blob is microcode, and it's optional(you can remove it, with all the consequences that entails, but it should boot)
* Newer Intel platforms up to Haswell: Intel ME (neutered using me_cleaner), and microcode
* Broadwell only: Intel ME (neutered), microcode and MRC
* No blobs whatsoever: this would be the ARM platforms (gru_bob and gru_kevin), which do not use microcode at all
I hope this helps!
Of course, the above pertains to *Libreboot*; Canoeboot is *always* blob-free no matter what (which means that the systems that need neutered ME can't be supported).
Also: Libreboot doesn't directly include blobs in ROM images other than microcode. A script is executed on release ROMs, that pulls the blobs from the internet. This circumvents any remaining legal concerns regarding the distribution of certain blobs, because it's not direct distribution on our part.
Though than will those people also break GNU General Public License, version 3 seeing those people sharing Libreboot with it's binary blobs may be breaking copyright?
If you believe GPL's copyleft would impose constraints on the distribution of a separate firmware blob, I am pretty sure you are wrong. The blob is not a derived from the GPLed code: https://copyleft.org/guide/comprehensive-gpl-guidech5.html
More generally, I do think a license can constrain merely shipping separate works together with the copyrighted one.
https://www.gnu.org/licenses/gpl-faq.html#combining
shows information about linking to things to other things under the GPLed code.
I do not know yet what may be linked to what.
https://www.gnu.org/licenses/gpl-faq.html#NonfreeDriverKernelLinux
shows
Does distributing a nonfree driver meant to link with the kernel Linux violate the GPL? (#NonfreeDriverKernelLinux)
Linux (the kernel in the GNU/Linux operating system) is distributed under GNU GPL version 2. Does distributing a nonfree driver meant to link with Linux violate the GPL?
Yes, this is a violation, because effectively this makes a larger combined work. The fact that the user is expected to put the pieces together does not really change anything.
Each contributor to Linux who holds copyright on a substantial part of the code can enforce the GPL and we encourage each of them to take action against those distributing nonfree Linux-drivers.
Though maybe I can also look more at this page and the GPL to see how things link together.
https://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF
Or what things are placed in a program by GPLed compilers, as the GPLed compiler may place parts of itself in the compiled program.
https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
shows
If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL)
Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL. See also: What does it mean to say a license is “compatible with the GPL”?
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
shows
What is the difference between an “aggregate” and other kinds of “modified versions”? (#MereAggregation)
An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are nonfree or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
I do not know how some things link together yet, or if the compiler puts it's GPLed code into the end binary.
That FAQ entry applies to the kernel named Linux. Different programs operate in different ways potentially resulting in different answers.
Thank you for that information, Magic Banana and jxself.
I did not know if these blobs were a compiler putting it's code into the binary so as to make a derivative of the GPLed compiler.
Or if the blobs were in some way linked to the BIOS, thus linking to a GPLed program.
hi, look at the reply i gave earlier in this thread. i followed up with a full answer to your question, but here's the short version: no linkage. generally speaking, blobs in coreboot are placed inside cbfs (coreboot file system) alongside other executables/payloads within the rom image. they can be called into from coreboot. my answer above goes into more depth.
Thank you for all the information, libreleah, Magic Banana and jxself, and anyone else I may have not seen who also helped.
I see Gnu Boot and Canoeboot development may try very hard to make sure all blobs are removed.
https://directory.fsf.org/wiki/GNU_Boot
https://git.savannah.gnu.org/git/gnuboot.git
https://canoeboot.org/news/canoeboot20240504.html
https://directory.fsf.org/wiki/Canoeboot
I also saw clean room design may be a a defense against copyright infringement.
https://en.wikipedia.org/wiki/Clean_room_design
And as
Apple also challenged VTech's Laser 128 in court. The Laser 128 was an enhanced clone of the Apple IIc first released in 1984. This suit proved less fruitful for Apple, because VTech had reverse-engineered the Monitor ROM rather than copying it and had licensed Applesoft BASIC from its creator, Microsoft.
https://en.wikipedia.org/wiki/Apple_II_clones
If any clean room design was needed between the upstream (I think) Coreboot, Libreboot, and the more downstream (I think) Gnu Boot and Canoeboot, I was mostly looking for ways Coreboot, Libreboot, Gnu Boot and Canoeboot could support more computers without by mistake having other source code/binaries from Intel or other non-free licensed companies put in the freely licensed programs repositories.
I did not know that On Intel-based systems, the flash is further divided into "regions", e.g. IFD, GBE, ME, BIOS. IFD/GBE are config (not software). ME is Intel ME, BIOS is coreboot.
I thought there was at first computer hardware to use the BIOS, than the operating system being turn on by the BIOS.
So I thought changing the BIOS could be the last step in getting fully free licensed software on a computer, except perhaps some internal wifi or bluetooth, as these I thought the operating system turned on, maybe with the BIOS.
I also saw how people may sue for many things, so that is why I was trying to look for the best ways to not see non-freely licensed binaries when also trying to remove/replace the non-free things.
I'm glad that there are people working on removing non-free licensed things on computers, so end users do not get sued for "infringement" by companies for just trying to use their computers in ways they wish to justly use them, if the company does not like the type of use, as non-free terms of use may prevent some uses.
Or having their own computers be used by some companies or others in ways that also may be "Malware" or other ways the end user thinks is unjust.
https://www.gnu.org/proprietary/proprietary.html
I see "If you do not like the control that proprietary UEFI vendors have over you, then Gnu Boot or Canoeboot is may work well with you."
Both Gnu Boot
We believe computer users deserve to control all the software they run. This belief is the key principle of the Free Software Movement, and was the motive for developing the GNU operating system and starting the Free Software Foundation. We believe computer user freedom is a crucial human rights.
and Canoeboot
Unlike the hardware vendors, Canoeboot does not see you as a security threat; we regard the ability to use, study, modify and redistribute software freely to be a human right that everyone must have, and the same is true of hardware. Your computer is your property to use as you wish. Free Software protects you, by ensuring that you always have control of the machine.
are likely helping computer users get more control over the things they use.
- Login o registrati per inviare commenti