Hello Hannah, On 07.09.23 20:49, Williams, Hannah wrote:> Already there are binaries FSP, AGESA, PSP being used in Coreboot and> because of IP and licensing issues everything cannot be open sourced. > The uGOP is just a stripped down version of GOP that is already inside > FSP. This is the fastest method for this specific product and hence we > are asking for a waiver to the closed source binary rule (by the way > where is this stated in coreboot.org?).
Terms and conditions to use and modify/extend coreboot can be found here https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/COPYING The second sentence of the preamble already wraps the gist of it up, very well: "By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users." Changing software that comes in form of a blob is hard (and in case of FSP even denied by its license; nobody but Intel is allowed to even fix security issues). The technical mechanism to guarantee freedom lives in Section 3. The basic idea is that everybody who makes a product with coreboot has to share the source code of their whole coreboot under a compatible license. In a way, this means one has to pay to license coreboot for their products--not with money but with source code. Now with FSP, Intel presents their customers with an uncomfortable choice: Don't use Intel or go in debt (not being able to pay with source code). And now that Intel plunged everybody into debts for 10 years, you are asking for a waiver, so everybody can incur more debts? When should this end? When will Intel help to pay any of it back? Maybe, as a token of good faith, Intel could start publishing source code of this decade of FSP? All this "software freedom" may seem unnecessarily idealistic. But it often turns out that it actually helps with the every growing complexity of today's computer systems. And it helps to scale, it helps innovation. OTOH, the way I see it, Intel's approach seems to achieve less at much higher cost. As far as I understand, Intel's argument not to open source is usually a combination of: * There are a few lines that can't be open sourced because IP / NDA. * Intel supports only a single code base because of "convergence goals", (and that code base needs to be tainted by the lines mentioned above). I believe it's such convergence goals that keep Intel stuck 30 years in the past. Back then, there was little product diversity. Having a single, validated binary scaled well enough for a 386 SL/SX/DX (all in desktop like PCs). Toolchains weren't trusted, reproducibility probably wasn't a thing. Security updates were not a concern. I could imagine that source code wasn't even properly archived. IMO, the way Intel handles firmware today perfectly fits these times... In the 21st century, things look kind of the opposite: (security) updates every- where, huge product diversity (x86 on tablets, laptops, desktops, workstations, servers, all the IoT things--everything multiplied by consumer, embedded, server markets), and reproducible builds. A single validated binary probably scales so badly, I can't imagine the costs, and the horrors Intel employees have to go through. This also has bad effects on Intel's customers: there is absolutely no room for inno- vation. Let's imagine for a moment, everybody using coreboot for Meteor Lake would have to use a single coreboot build, a single binary, configured VBT-style. It seems virtually impossible to get that done in time. OTOH, it seems possible that supporting the coreboot code base and projects like libgfxinit directly--instead of trying to converge everybody's needs in a single binary--is actually cheaper for Intel. The SoL feature could be the perfect project to experiment with a community approach. Hannah, sorry if I digressed too much, but I really hope this helps to understand the bigger picture. Please help Intel to embrace diver- sity instead of trying to cook up single binaries. Actually, Pat Gelsinger seems to understand already[1]: "• And, as is core to the Intel values, we will be inclusive in our approach and support of communities’ efforts, while embracing diversity and our differences because they make us better." There are probably many levels inside Intel between you and him that need your help to understand it too, and to adapt Intel to the 21st century. Nico [1] https://www.linkedin.com/pulse/open-letter-ecosystem-pat-gelsinger _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
