Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
Hi Ian.
First of all I want to clarify some things so that all of us have the same understanding:
1. On our current coreboot-based products we just use coreboot itself with no other payload (e.g. SeaBIOS). We use instead a Linux as a payload which is self-tailored for every dedicated mainboard. 2. The vast majority of our products is sold to OEMs. 3. We provide the OS to the OEM which remains the one and only OS in the system. The OEMs uses our OS and it's provided interfaces to build his own applications on top of it. 4. Every mainboard/hardware belongs to a complete system which will in any case have a way to show informations to the end-customer (it might be a LCD-panel, a VNC-connection or a dedicated engineering system which is able to communicate with the devices).
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.
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). 2. Provide a screen (very similar to your About-Screen) on the system where every one who is interested in can see all the needed informations (version, licenses, ...). The information is gathered in a text file which is located in the CBFS on the flash. Therefore this information is bound to the hardware itself. We do provide a built-in text-viewer so that one can see all the information when ever there is a need for it.
So if there is someone out there who wants to run its own copy of coreboot on our hardware: Go to coreboot.org, get the latest tree, select the matching mainboard and...make! Beside the fact that you will loose the warranty if you install your own firmware (which was not verified by Siemens) on our hardware you are free to go!
Do I oversee something?
Werner
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:
- 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
-
Peter Stuge -
Werner Zeh