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

[Zeh, Werner]

Hi Ian.

> Ian Lewis wrote:
> I do have one question: You clearly have no issue for your compliance. But, do you tell your OEM customers that they need to provide the GPL license to their customers as part of their product packaging,

We do have a sticker on each component which tells that this component contains open source software and how to find the details on the component. Further we have a chapter in the end-user manual which describes all the details about open source software and the licenses. This manual will be handed over to the end-customer by the OEM.

> Peter Stuge wrote:
> Please consider the risk associated with offloading distribution of source code to a third party, be it upstream or anyone else.
Of course we keep the exact copy of the source code for every single release version internally. So we have any time the ability to provide the code by ourselves. And our customers are aware of this.
The upstream repo is just the first place to get the code from.

Werner



> Peter Stuge wrote:
> > 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.
> Peter Stuge wrote:
> > 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?
> Peter Stuge wrote:
> >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...
> 
> > Mh - again, I don't think that's cool.
> 
> Would you consider this true - for our compliance - if we put a piece of paper in the box that told you where to find the source code
> from your measurement device? If this point about the medium on which the user obtains the source code is critical, then this option is
> probably not a good solution for us. But, I am still curious whether you would consider us compliant if we had a piece of paper in the
> box that told the user that the source code for the Coreboot/SeaBIOS (if we use SeaBIOS) firmware in their measurement instrument is
> available by opening our Control Panel application, going to the About tab, and clicking the Get Firmware Source button (say).
> 
> I will note that it is impossible to use our device in any way unless our driver and server are installed, the basic version of which is
> available to anyone for download from our web site. And, the installation of these components always installs the Control Panel
> application. So, even if an OEM were to pre-configure a system with our hardware, the Control Panel application would always be
> available to all potential users of our device.
> 
> Peter Stuge wrote:
> > 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.
> 
> I fully understood what you said in your original message. My point remains: if we provide a virtual CD-ROM - which I still consider a
> "removable drive" even if it is read only - then plugging in our device, which has nothing to do with a drive of any kind, you suddenly
> have a new drive letter taken under Windows for no obvious reason (for most users). Taking up a drive letter can really mess things up
> for a user if they assume that letter is free for use, for example to attach to a network share when they log into a network.
> 
> Of course, you do gain the nice feature that Windows will pop up a box on first use telling you the new drive showed up. And, that
> would give you something that lets a user know something is going on that might need their attention. And, as you say, a CD-ROM is
> clearly a " medium customarily used for software interchange".
> 
> Peter Stuge wrote:
> > This is actually quite common with USB cellphone network modems and with some other USB-connected devices as well.
> 
> Yes. We know how to do this, though I am not overly enthusiastic about implementing it. I do not know much about USB cellphone
> modems, but it seems like the drive might make some sense to the user in this case. It certainly does when you plug in a cell phone
> since the cell phone has storage you want to be able to access. With our device, it would just be a spurious drive in most real
> installations. Of course, a user could disable the drive. But, because of the way Windows manages USB devices, it would most likely
> keep popping back up from time to time when you plugged it into a different slot.
> 
> Peter Stuge wrote:
> > 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.
> 
> We will almost certainly try to do this, though for initial development - all in house, so no GPL issues, we are going to work with
> SeaBIOS because we already have loader code that knows how to talk with a legacy BIOS. Once we have that fully functional, we can
> look at direct loading from Coreboot. Currently we boot our systems either directly from the first instruction the processor executes,
> when using our own processor designs, or from a legacy BIOS or UEFI for processor modules. I suspect it will be pretty easy for us to
> add one more boot mechanism to load directly as a payload of Coreboot. We make very little demand on the initial boot load
> environment.
> 
> Peter Stuge wrote:
> > You really should learn how to build the boot image yourself, because it is quite risky to rely on third parties.
> 
> Yes. I think this is completely correct. I do not think we would be in a good position at all if we claimed we had the correct source for a
> binary we did not build ourselves. This would be especially true if we have to comply with GPLv3 where we probably have to provide
> the instructions on how to go about replacing the firmware.
> 
> Peter Stuge wrote:
> > Ian Lewis wrote:
> >> 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.
> 
> Understood. But, since we plan to distribute a product, we have to make any changes public. So, we might as well make them
> available to the original project. And, we usually do that even when we make changes to an open source project only for internal use, if
> the changes seem to have any general value.
> 
> Peter Stuge wrote:
> > 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.
> 
> Right. I understood this. I did not mean to imply that Siemens had done anything wrong. I just meant that I could not tell how they
> handled GPL compliance. So, I could not use their practices to learn anything about what we should do.
> 
> Peter Stuge wrote:
> >>> If it is already there people will stop asking your customers for
> >>> the source code!
> > No - please avoid that reasoning.
> Peter Stuge wrote:
> > Upstream *can never* ensure your compliance!
> 
> Understood. The license itself seems very clear on this point.
> 
> 
> I very much appreciate the effort you - and everyone else on this group - have taken to help me understand our obligations under GPL
> and how to use your product in that context.
> 
> Ian
> 
> --
> coreboot mailing list: coreboot at coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot