[coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

Peter Stuge peter at stuge.se
Wed Jan 3 15:17:33 CET 2018


Lewis, Ian (Microstar Laboratories) wrote:
> Peter Stuge wrote:
> > If you can handle the cost then you could design a (read-only, e.g.
> > USB- attached flash memory appearing as a CD-ROM) medium *into* your
> > hardware, which stores the source code corresponding to the object code
> > which is in boot flash. I find that ideal.
> 
> What you suggest is very much what I was thinking when I originally
> considered a microSD to house the source. My thought was to attach the
> microSD permanently to our system in such a way that our OS could read
> it (not the host PC OS). Then, from our Windows Control Panel
> application for our device, on an About tab, say, a user could click a
> button and get the source for the actual image used to boot the system,
> which of course would include the license and all other content needed
> to satisfy GPL. This would completely protect the microSD from write
> because we would not allow any means to write to it (though, we would
> probably allow removal for advanced users who really wanted to get
> directly to the drive - and GPLv3 might even require us to allow this).

Consider Section 3 a) "on a medium customarily used for software
interchange" - a Control Panel snap-in arguably isn't such a medium.

What specific interface to use for delivery of source code probably
depends on how your product works, and what you want to enable your
customers to offer.


> Your specific suggestion of a USB connected Flash drive setup is also
> possible, and probably a bit less work for us - we would just need a
> built-in USB to USB hub or PCIe to USB host controller to allow for our
> device and the Flash drive to coexist on the same cable, but most flash
> USB drives are too physically big to work for us (resolvable, but
> probably not without adding more engineering effort - the USB connector
> alone is almost too big, and that means we might need to go to a
> board-mount drive - one more complication). And, there is a bit of a
> mess here under Windows because the Flash drive, if not controlled by
> our software, would just show up in Windows as a drive every time
> someone plugged in our device.

Sorry, I wasn't clear enough. I meant to refer to flash memory which
is *somehow* accessible via USB - but not neccessarily in the form of a
"removable drive". A much better "look" would be a virtual CD-ROM,
which are per definition read-only.


> But, at the least, this could be a real nuisance for users. And, it
> seems like it could also be quite confusing (I plugged in a measurement
> device and now I have a new drive. Where did that come from?). 

This is actually quite common with USB cellphone network modems and
with some other USB-connected devices as well. USB allows exposing
several different interfaces (that's a specific USB term), each with
different functionality, over one electrical (cable, onboard) connection.


Lewis, Ian (Microstar Laboratories) wrote:
> > Also, why do you mention GPL V3? Coreboot is 2 or later.
> 
> The module we are using uses both Coreboot (GPLv2) and SeaBIOS (GPLv3).

I would recommend to avoid SeaBIOS if you can. Not because it's bad, but
because you may not require it, and it would avoid dealing with GPLv3
compliance, which is a lot more involved.

SeaBIOS provides legacy compatibility for systems that really require a
BIOS, but since your board only ever boots your OS, maybe you can avoid
one.

If your operating system depends strongly on BIOS services and data
structures then you can consider using libpayload in your operating
system, instead of BIOS calls. libpayload has a BSD license.


Lewis, Ian (Microstar Laboratories) wrote:
> Ø  Did you actually need to change coreboot or SeaBIOS?
> 
> No.  We have made no changes.  At the moment we do not even know
> how to build the required modules for the system.  Personally, I
> would rather we did not have to know how to do a build, but I think
> we will need to so that we can validate that the source code
> matches the binary we distribute.

You really should learn how to build the boot image yourself, because
it is quite risky to rely on third parties. The good news is that it's
not very difficult; especially for the Vortex86EX it should be
straightforward, because coreboot has few if any external dependencies
there.


> Even once we do work out how to do a build, I very much doubt we
> will make any changes at all.  If we do change anything in coreboot
> or SeaBIOS – or any other GPL licensed project for that matter, we
> will definitely release our changes back to the relevant project to
> accept or reject.

You don't strictly have to just to be compliant, but it is certainly
in the spirit of the license, and it does *simplify* compliance,
because you do not have to maintain private patches.


> Ø  Your idea about using the "About" tab to inform the user about
> the licenses and where to find the code is good.  It should cover
> your company even if the customer never reads it.
> 
> If this is correct, and an About tab with all the relevant
> information about coreboot and SeaBIOS meets our – and our
> customer’s – licensing responsibility, then we clearly can do
> something that will work well for our purposes.  And, the issue
> becomes purely one of engineering work and administration in
> production.

Unlike David I'm not so sure about this. Requiring a special software
to access the source code IMO does not satisfy "medium customarily
used for software interchange" - while a virtual CD-ROM would, if
your product connects via USB in normal operation.

The Control Panel idea may be a good way to help your customers with
being compliant, but I don't think it's very good for your own
compliance, if that makes sense?


Lewis, Ian (Microstar Laboratories) wrote:
> On a quick look at the Siemens website for this product, this
> definitely looks like a good example of a product that matches what
> we do quite well, though I suspect they aim at much bigger
> customers than we do.  With a few minutes spent looking, it is not
> at all clear to me how Siemens handles their GPL responsibility and
> whether they attempt to provide compliance for their customers or
> not.

Keep in mind that compliance is required when copying and distributing
the Program in object code or executable form, meaning that marketing
material such as webpages don't come with requirements.

In particular, distributors of object code must be compliant *to the
recipient* of object code. There is no requirement for anyone to publish
anything to the whole world when you sell me a product which contains a
coreboot object code - but it is obviously appreciated, and it makes
things a lot easier for you and me both.

What *is* required however, is that you enable me to publish the
source code *should I choose to do so*, by making sure that I have or
can acquire that source code.

If yousimply use upstream coreboot there is obviously no point for me
to publish the code, but you are still responsible for providing me
a copy of the source code that corresponds to the object code which you
distributed to me.


> Philipp Deppenwiese wrote:
> > If you want to make it easy for them.  Upstream open source as
> > much as possible.

Agreed!


> > If it is already there people will stop asking your customers for
> > the source code!

No - please avoid that reasoning.


David Hendricks wrote:
> For their part, Siemens releases the code upstream:
> https://review.coreboot.org/cgit/coreboot.git/tree/src/mainboard/siemens

It is the responsibility of each distributor of object code (and noone else)
to provide the corresponding source code to each receiver of object code. If
you don't make sure to provide this source code yourself, then you risk sudden
non-compliance should the upstream repo become unavailable, which can happen
for any number of reasons, none of which are under your control!

Upstream *can never* ensure your compliance!


The benefit of pushing code upstream is another, actually twofold:

1. Your release management is significantly simpler - it becomes zero! :)

2. You add value to your product, because your customers can choose to
use a later version of the upstream code, if they want to take advantage
of some new functionality. (Maybe power saving, or something else.)
As Werner mentioned, this may void warranty. That's fine. It's still
an added value, because you provide your customer and their customers
with more possibilities.


Lewis, Ian (Microstar Laboratories) wrote:
> Still, the more I look at this, the more it sounds like we would
> meet our obligations if we provide an About tab in our control
> panel application, and from there present the license and provide a
> means to fetch the source code from our hardware, thus tying the
> source tightly with the firmware.  Every user must have that
> application installed to be able to run our hardware at all no
> matter how they got the hardware.

Mh - again, I don't think that's cool.


> Assuming this setup works for our responsibility, this also seems to
> free our customers from having to do anything to comply with GPL,

I agree completely that this should be the goal.


> though clearly we have to make them aware that our system contains
> GPL licensed code.

Yes.


Werner Zeh wrote:
> The way we decided to deal with the GPL-obligations is:
> 1. Make sure all our mainboards are on master! We always build the final
> image based on the latest master. Of course one version freezes the time
> it is released while master keeps going forward. But one can easily get
> the git-commit which was the latest once the version has been released
> (by looking at the console output for example).
..
> Do I oversee something?

Please consider the risk associated with offloading distribution of source
code to a third party, be it upstream or anyone else.

You can only do so under Section 3 b) - ie. if you accompany object
code with a written offer - and if your offer refers to infrastructure
outside of your control, then external factors can suddenly make you
non-compliant.


//Peter



More information about the coreboot mailing list