[coreboot] New addendums to INTEL FSP family (ron minnich)

David Hendricks dhendrix at google.com
Fri May 9 23:29:40 CEST 2014


On Wed, May 7, 2014 at 11:30 PM, Patrick Georgi <patrick at georgi-clan.de>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140509/94ad3119/attachment.html>


More information about the coreboot mailing list