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

[Lewis, Ian (Microstar Laboratories)]

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