On Wed, May 7, 2014 at 11:30 PM, Patrick Georgi <[email protected]>wrote:
> One more advantage open source brings is that it provides standardized > licensing (and this issue is more important to commercial integrators that > want to sell their work than to private developers): Mainstream open source > licenses are well-known, battle-tested in courts around the world, and > companies tend to have (simple) policies on using code under open source > terms in products. > > I was recently told that the FSP license is different from the > click-through license on www.intel.com/fsp (the one shown when trying to > download the files). > > So here's how I understand the FSP license situation: There's the > click-through license on the web site, the FSP license (shown by the > self-extracting archive), the intersection of both that actually applies to > me when using FSP, and the application of these resulting terms in > jurisdictions world-wide. And every single-letter change to the license in > future releases restarts the license evaluation process from scratch. > > This may not be a problem for Intel - it's huge so these things don't > matter much, but please keep in mind that Intel's legal department alone is > probably larger than many of the companies that integrate Intel's chips. > > So custom licensing is certainly a great scheme to keep lots of lawyers > employed. But it's not so great if you're just trying to get chipset > initialization code (and by extension: chipsets) into the hands of > integrators. Yes - Simplicity, harmonization, and freedom in licensing is huge deal and impacts processes at many levels. I personally rank this as equal to the collaboration aspect of FOSS licensing. The need to "deal with partners" rather than to actually "work with partners" is both frustrating and a colossal waste of time and resources for both sides. > ARM has a Boot ROM inside their SOC, should the code inside the Boot >> ROM be open? or does it matter? >> > Those tend to be small, in the 4-8kb range, and focused on a single > purpose: getting the next stage into iRAM. > For the Allwinner CPU we support, one developer in our community checked > that the signed binary-only part (that we can't replace) is harmless. > > This isn't so easy with a multi-100kb binary affecting pretty much > everything across multiple chips. > > > I know this view point is not going to be popular, but Intel is trying >> hard to open as much code as possible (tianocore.org [1], Linux >> >> drivers, and Quark firmware are a few examples; I am sure more will >> come in the future). >> > I'm certainly looking forward to that! They have been getting better as Jiming points out. But going back to the process, how would one actually use this for a third-party project such as coreboot? Once everything is up on tianocore.org, can the necessary components be copied over to coreboot.org so that a user can build a working image by selecting the right options and running "make"? Or does the user need to visit >= external site, download something, pick apart bits and pieces that are needed, and plop them into a coreboot image built separately? How could the latter process even work if one were to attempt to automate this for large-scale development? You get the idea. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
