Re: [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 

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 

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

[Peter Stuge]

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 

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

[Werner Zeh]

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



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Lewis, Ian (Microstar Laboratories)]

Hello Werner,

> The way we decided to deal with the GPL-obligations is: 

Thank you for your detailed explanation of how you handle your GPL 
responsibilities. What you describe makes perfect sense to me. 

You have the advantage on us of having an output device on your system. And, 
since you run Linux your user base must be well aware of GPL. 

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. So, every user who ever had the device and 
had any ability to use it would have access to the About tab. 

Assuming this setup works for our responsibility, this also seems to free our 
customers from having to do anything to comply with GPL, though clearly we have 
to make them aware that our system contains GPL licensed code.

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, or do you consider the 
availability of all the required information built into your system (in the 
screen you describe) sufficient to meet your OEM's responsibilities as well as 
your own as long as they do not add any new GPL licensed code that you have not 
handled?

Ian

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Lewis, Ian (Microstar Laboratories)]

Hello Ron,

 

Thank you for the suggestion and the offer. The processor module is VEX-SOM 
from DMP/ICOP: 
http://www.icop.com.tw/en/product/System-On-Module-VEX-SOM/VEX-SOM.html, which 
runs a Vortex86EX processor. 

 

Your idea is a good one. However, I do not think it makes sense to separate the 
code yet.

 

First we need to figure out whether we are willing/able to move forward with a 
product that includes GPL licensed code at all. It really is not ideal for our 
customer base no matter how you look at it. But, VEX-SOM is very attractive for 
us for a low-end product, and maybe attractive enough to be able to make sense 
of placing the GPL requirement on at least some of our customers.

 

If you were willing, I would very much like to take advantage of your expertise 
to separate the relevant code if we do decide to move forward with a product.

 

Ian

 

From: ron minnich [mailto:rminn...@gmail.com] 
Sent: Friday, December 29, 2017 2:17 PM
To: Lewis, Ian (Microstar Laboratories)
Cc: Peter Stuge; coreboot@coreboot.org
Subject: Re: [coreboot] How to properly conform with GPLv2 for Coreboot and 
SeaBIOS on an embedded system

 

suggestion: you might want to figure out what subset of the source you actually 
use in your product, i.e. what files are used in your build, then create a 
subset of the coreboot source tree containing only this files, then lzma -9 
that file. 

 

I suspect it would be pretty small, but if you want to tell me what board this 
is I'm willing to give it a try.

 

ron

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Zoran Stojsavljevic]

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

For what I know about Werner (Zeh), the guy is pure Genius. It was all
My Pleasure to work together with Werner while I worked for INTEL
GmbH, supporting also Siemens Industrial (2011-2016).

Werner, thank you very much for all hard work and contribution you
brought and will continue to bring to Coreboot, and lessons/knowledge
you unselfishly gave to me/us here!

Zoran Stojsavljevic
___

On Mon, Jan 1, 2018 at 2:00 AM, David Hendricks
 wrote:
>
>
> On Sat, Dec 30, 2017 at 10:05 PM, Lewis, Ian (Microstar Laboratories)
>  wrote:
>>
>> 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.
>
>
> For their part, Siemens releases the code upstream:
> https://review.coreboot.org/cgit/coreboot.git/tree/src/mainboard/siemens
>
> As with your case the firmware for their products is basically invisible to
> the customer. Nevertheless if the customer wants to examine the code or make
> changes they can easily do so. Relevant license information is found in the
> header of each source code file as well as the COPYING file at the root of
> the coreboot directory.
>
> Werner (cc'd) might be able to share some more details about how they handle
> compliance matters.
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[David Hendricks]

On Sat, Dec 30, 2017 at 10:05 PM, Lewis, Ian (Microstar Laboratories) <
ile...@mstarlabs.com> wrote:

> 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.
>

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

As with your case the firmware for their products is basically invisible to
the customer. Nevertheless if the customer wants to examine the code or
make changes they can easily do so. Relevant license information is found
in the header of each source code file as well as the COPYING file at the
root of the coreboot directory.

Werner (cc'd) might be able to share some more details about how they
handle compliance matters.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Lewis, Ian (Microstar Laboratories)]

Hello Philipp,

Philipp Deppenwiese wrote:

> There is already an easy solution. Just tell your customers that you will 
> make the coreboot implementation open source (hw init). 
> They can load their own proprietary stuff afterwards as payload (binary) 
> without having issues with the GPLv2. 
> Sure if they use SeaBIOS it's a problem (GPLv3) but there are tons of 
> payloads out there.

Our customers will never load their own payload. Our systems always boot to our 
own OS, which manages the measurement hardware and data processing side of the 
customer application. Our customers send relatively simple scripts to our 
systems that tell them how to manage the real-time, control, and signal 
processing portions of the application, while they typically have a relatively 
complex application-specific human interface application that runs on the host 
OS, typically operating under Windows, but sometimes operating under Linux 
(these few customers operating under Linux, obviously, will not have any 
trouble with GPL). Most customers want our system to “just work”. They send our 
system a PID() command, say, and it runs a PID loop for them until they tell it 
to stop. They do not dig down into the boot process or load a different OS.

> coreboot makes things cost effective because we are all working together on 
> the platform support.
> Another good reason for not reinventing the wheel again :)

> Even Siemens uses coreboot + SeaBIOS -> 
> https://www.youtube.com/watch?v=tq4xSipCWEU 
> without having the "fear" of licensing issues. Sure they are not selling it 
> to end users.

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.

> If you want to make it easy for them. Upstream open source as much as 
> possible.
> If it is already there people will stop asking your customers for the source 
> code!
> Also if they use a custom payload without GPL code they don't need to open 
> source it!

We will definitely push any changes we make back to Coreboot or SeaBIOS to 
accept or reject.

Best Regards,
Ian


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Lewis, Ian (Microstar Laboratories)]

Hello David,

 

David Hendricks wrote:

Ø  Did you actually need to change coreboot or SeaBIOS? If so, how extensive 
were the changes? I am guessing that the boot firmware isn't considered to be 
part of the high-value IP of the product - that is presumably in your OS.

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. 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. 

 

Ø  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. 

 

Ø  Like you say, the goal here should be to make it so that downstream 
customers don't need to think about this stuff. The nice thing is that if you 
act consistently with the spirit of the open-source licenses then this should 
all be simple for them and for your company as well, and you get to spend more 
time engineering and collaborating and less time worrying.

Once I have an idea what I am talking about, I may spend less time worrying. 

 

Ø  Just my $0.02. Please make sure to consult your company's legal department 
before acting on anything you read in this thread (or elsewhere) :-)

:->

 

Ian

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[David Hendricks]

Hi Ian,
Did you actually need to change coreboot or SeaBIOS? If so, how extensive
were the changes? I am guessing that the boot firmware isn't considered to
be part of the high-value IP of the product - that is presumably in your OS.

If you can publish the coreboot and SeaBIOS code on your website (it could
be a zip file or something) then things should be reasonably simple. Even
better would be to add the mainboard support to upstream coreboot or fork
upstream coreboot on github and then add your patches on top. Then
downstream customers can then easily download the code and, if needed,
modify and commit their patches to the same codebase as to be in compliance
in the same manner as you.

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. You shouldn't need a clickthrough license or
anything (gnu.org has a FAQ that covers that topic:
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html). Also, the
"conspicuous" requirement should already be met with the license
information that exists in the header of each source code file and/or a
LICENSE or COPYING file. As Peter mentioned that is exactly how the
requirement is met for large companies who work with open source software.

Like you say, the goal here should be to make it so that downstream
customers don't need to think about this stuff. The nice thing is that if
you act consistently with the spirit of the open-source licenses then this
should all be simple for them and for your company as well, and you get to
spend more time engineering and collaborating and less time worrying.

Just my $0.02. Please make sure to consult your company's legal department
before acting on anything you read in this thread (or elsewhere) :-)


On Fri, Dec 29, 2017 at 6:21 PM, Lewis, Ian (Microstar Laboratories) <
ile...@mstarlabs.com> wrote:

> ron minnich wrote
> > how are you different in this case from Motorola, who had to put their
> linux source on a web site? companies resold motorola phones. Or the many
> switch vendors who sell network switches that run coreboot/linuxbios? or
> irobot, who use it still on the packbot?
> > Or how are you different from just about every vendor that sells
> embedded ARM boards that run u-boot?
> We are, because of the nature of our customers, very different from all of
> your example use cases, except perhaps the people who sell embedded ARM
> boards.
>
> Motorola phone: They sell their product to people (well, companies) who
> set out to make GPL licensed products, typically for a large market. The
> customer of Motorola makes no modifications to the Motorola phone, or at
> least no significant modifications. There is no difficulty for such a
> prospective reseller of such a product to comply with GPL. There are lots
> of sales to cover the initial costs. But, most importantly, the Motorola
> reseller is typically not making a new product. They are reselling the
> Motorola product, perhaps as a private label, to an end user who will
> receive Motorola's packaging and notifications (at first boot, perhaps - I
> do not actually know how).
>
> As far as I can see (well, guess), network switch purchasers are almost
> always end users (corporate or personal). And, it is my guess - after
> spending the past week and a half trying to understand GPL's implications -
> that there are many, many small resellers of network switches in complete
> systems that are out of compliance with GPL because they do not even think
> about the issue. As a side note, our customers are a bit like this kind of
> reseller of a complete system that happens to contain a network switch,
> though the analogy is not great because the network switch is in some sense
> a complete system, while what we make is not. Still, if I sell a network
> installation to a small shop, and I fail to give the recipient of my system
> that includes that switch the GPL license and a place to get the source
> code, I am in violation of GPL. I do not want this to happen to my
> customers.
>
> iRobot is making an end use product, not a product that someone else is
> going to take and build into something very different from the iRobot
> product. Again, a lot like Motorola and their phone. If NewEgg sells an
> iRobot product, they just pass through the iRobot package - with everything
> in it - so (I think, though I am not quite sure) they are in compliance as
> long as iRobot was. I suspect that NewEgg just assumes that iRobot got
> their licensing right. My reading of GPL is that NewEgg actually has their
> own obligation under GPL separate from iRobot's, but I would guess they do
> not worry about it much. They are not making anything. They are just
> reselling.
>
> ARM boards that run u-boot: The target customer base is aiming to take
> advantage of the ARM board to make a product at a low cost (typically), and
> most of them are well aware of GPL and 

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

[Lewis, Ian (Microstar Laboratories)]

ron minnich wrote
> how are you different in this case from Motorola, who had to put their linux 
> source on a web site? companies resold motorola phones. Or the many switch 
> vendors who sell network switches that run coreboot/linuxbios? or irobot, who 
> use it still on the packbot? 
> Or how are you different from just about every vendor that sells embedded ARM 
> boards that run u-boot? 
We are, because of the nature of our customers, very different from all of your 
example use cases, except perhaps the people who sell embedded ARM boards.

Motorola phone: They sell their product to people (well, companies) who set out 
to make GPL licensed products, typically for a large market. The customer of 
Motorola makes no modifications to the Motorola phone, or at least no 
significant modifications. There is no difficulty for such a prospective 
reseller of such a product to comply with GPL. There are lots of sales to cover 
the initial costs. But, most importantly, the Motorola reseller is typically 
not making a new product. They are reselling the Motorola product, perhaps as a 
private label, to an end user who will receive Motorola's packaging and 
notifications (at first boot, perhaps - I do not actually know how).

As far as I can see (well, guess), network switch purchasers are almost always 
end users (corporate or personal). And, it is my guess - after spending the 
past week and a half trying to understand GPL's implications - that there are 
many, many small resellers of network switches in complete systems that are out 
of compliance with GPL because they do not even think about the issue. As a 
side note, our customers are a bit like this kind of reseller of a complete 
system that happens to contain a network switch, though the analogy is not 
great because the network switch is in some sense a complete system, while what 
we make is not. Still, if I sell a network installation to a small shop, and I 
fail to give the recipient of my system that includes that switch the GPL 
license and a place to get the source code, I am in violation of GPL. I do not 
want this to happen to my customers.

iRobot is making an end use product, not a product that someone else is going 
to take and build into something very different from the iRobot product. Again, 
a lot like Motorola and their phone. If NewEgg sells an iRobot product, they 
just pass through the iRobot package - with everything in it - so (I think, 
though I am not quite sure) they are in compliance as long as iRobot was. I 
suspect that NewEgg just assumes that iRobot got their licensing right. My 
reading of GPL is that NewEgg actually has their own obligation under GPL 
separate from iRobot's, but I would guess they do not worry about it much. They 
are not making anything. They are just reselling.

ARM boards that run u-boot: The target customer base is aiming to take 
advantage of the ARM board to make a product at a low cost (typically), and 
most of them are well aware of GPL and its implications. This is somewhat like 
us. Some of the uses have very small markets - as most of our customers do. 
But, we do not have a customer base that is aware of GPL and intend to use it 
from the beginning.

A typical customer of ours might sell 50 systems in a year and consider that a 
very good year. They sell each system for a lot of money (typically) and they 
are not spending a lot of time thinking about licensing. Most (a guess) 
probably do not even have an in-house counsel, let alone a license management 
department.

Asking them to take on new licensing obligations is an impediment to adoption 
of our product. How many of our customers already easily deal with GPL, I do 
not know, but I doubt it is a big fraction. You may not see that as a big 
issue, and if you were our customer it would not be a big issue for you. But, 
many of our customers hardly even formally license their own products to their 
customers; they go install them. My point is that our market is not an end use 
market where the licensing almost does not matter once the end user has the 
product in hand. And, it is not a big OEM market where the licensing is a 
triviality. And, our market is not Makers, say, who know - and want to be - 
buying GPL licensed products so that they can hack around in them.

Our market is for small OEMs - or OEMs who work inside big companies, but with 
small customer bases, which is even worse because here there is a legal 
department, but our customer has next to no chance of getting their attention - 
who make low volume specialized products - an industrial turbine monitoring 
system, say - that typically sell infrequently for relatively high prices and 
they want our part of the system to just work with as little thought as 
possible. Their focus is on their application area. If we can help them without 
getting in their way, they may use us. If we look like a nuisance, they will go 
elsewhere (maybe to an ARM board and building their own 

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

[ron minnich]

On Fri, Dec 29, 2017 at 5:20 PM Lewis, Ian (Microstar Laboratories) <
ile...@mstarlabs.com> wrote:

>
>
> The real problem comes with our potential OEM and VAR customers - the most
> valuable customers for our potential product from a turnover perspective.
> If we attempt to sell them a GPL licensed product, we oblige them to
> conform with GPL licensing to be able to sell their systems to their
> customers. I am about certain that, unless we make it trivially easy to
> conform, this will put off a good fraction of our prospective customers.
> Even if we make it trivially easy to conform, unless it is almost
> automatic, I am concerned that it may still put off too many potential
> OEM/VAR customers. And, our customers would not be behaving in an
> nonsensical way. Many of them employ no firmware engineers who they could
> use to determine whether they were actually in compliance with GPL, even if
> they did not mind the added licensing on their product.
>

how are you different in this case from Motorola, who had to put their
linux source on a web site? companies resold motorola phones. Or the many
switch vendors who sell network switches that run coreboot/linuxbios? or
irobot, who use it still on the packbot?

Or how are you different from just about every vendor that sells embedded
ARM boards that run u-boot?

Also, why do you mention GPL V3? Coreboot is 2 or later.

What about the many systems that run all kinds of GPL V2 embedded software?
What's different between you and them?

What I'm trying to say is that problem seems to have been solved. I get the
feeling you are new to dealing with this question, and are trying to solve
it yourself, without talking to people who have already solved it?

thanks

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Lewis, Ian (Microstar Laboratories)]

ron minnich wrote:
>> First we need to figure out whether we are willing/able to move forward with 
>> a product that includes GPL licensed code at all.
> this part I do not understand. There are so many embedded systems out there 
> with GPL code in firmware, what is the unique property of your product that 
> makes it impractical? 

The issue for us is that most of our customers are not end users. Well, 
actually, we have many, many more end use customers than reseller customers, 
but end use customers represent a small fraction of our product sales. The bulk 
of our products sales are to OEM (Original Equipment Manufacturer) or VAR 
(Value Added Reseller - that is, consultant) customers who resell a system of 
their own that contains our product as a component.

GPL creates no particular problem for us when we sell to a university - one of 
our main sources of end-use customers - that will use our device to perform 
specific experiments in their own lab. We would need no more than a piece of 
paper in the box plus a medium to carry the source code that corresponds to the 
firmware (or a website, for that matter). Since our end user in this case would 
build their setup and run it themselves and never distribute it, there would be 
next to no issue once we met our obligations under GPL. Though, even here I 
have a bit of a concern because I read GPLv3 to obligate us to provide our 
customer a way to replace the firmware, not just provide the source for it, and 
currently we do not have an external means to allow this on any of our 
products. Still, this is more of a technical issue than a legal or marketing 
one. We would most likely not lose a single end use customer sale because our 
product included a GPL license for a portion of the system. 

The real problem comes with our potential OEM and VAR customers - the most 
valuable customers for our potential product from a turnover perspective. If we 
attempt to sell them a GPL licensed product, we oblige them to conform with GPL 
licensing to be able to sell their systems to their customers. I am about 
certain that, unless we make it trivially easy to conform, this will put off a 
good fraction of our prospective customers. Even if we make it trivially easy 
to conform, unless it is almost automatic, I am concerned that it may still put 
off too many potential OEM/VAR customers. And, our customers would not be 
behaving in an nonsensical way. Many of them employ no firmware engineers who 
they could use to determine whether they were actually in compliance with GPL, 
even if they did not mind the added licensing on their product.

So, the root issue here is that - because of the nature of our customers - we 
are not just putting ourselves under GPL. We are putting our prospective 
customers under GPL too, and that will - I guarantee it - put off some fraction 
of our potential best customers. What I do not know is what fraction that would 
be and whether we want to find out. 

Ian

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[ron minnich]

On Fri, Dec 29, 2017 at 3:55 PM Lewis, Ian (Microstar Laboratories) <
ile...@mstarlabs.com> wrote:

>
>
>
> First we need to figure out whether we are willing/able to move forward
> with a product that includes GPL licensed code at all.
>

this part I do not understand. There are so many embedded systems out there
with GPL code in firmware, what is the unique property of your product that
makes it impractical?
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[ron minnich]

suggestion: you might want to figure out what subset of the source you
actually use in your product, i.e. what files are used in your build, then
create a subset of the coreboot source tree containing only this files,
then lzma -9 that file.

I suspect it would be pretty small, but if you want to tell me what board
this is I'm willing to give it a try.

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Lewis, Ian (Microstar Laboratories)]

Hello Peter,

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).

This is definitely doable, but, after some review of what we would need
to do to make this work, it is more engineering work that I would really
like to put into this, at least for a first-cut product. Still, this may
be the only way we can move forward. Even with this, I am a bit
concerned about whether this really meets the requirements of the
license, but it seems very close. My main concern is about whether this
kind of setup really meet the "conspicuous" requirement on presenting
the license. You seem to think it would, which is encouraging. But, I
remain a bit worried about the issue.

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. This is fine from the point of view of
meeting GPL requirements. 

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?). 

In any case, thank you for all of your suggestions and taking the time
to reply to my query in detail. I need to spend some time on the
technical issues of this kind of solution, and talk with some people
here to see whether we can make sense of this kind of arrangement from
the point of view of our customers. If that works, then I get to see
whether I can convince legal that, what we intend to do technically,
actually works to meet our interpretation of our legal obligations under
the license.

Ian



-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Peter Stuge]

A thought:

Peter Stuge wrote:
> > and our product always included the full license and source on
> > microSD, that would not be good enough to cover the obligations of
> > our distributor/customer?
> 
> As long as your customer passes the medium along to *their* customer,
> I would consider them compliant. They have to actually do that
> however.
> 
> It is helpful to state that they are non-compliant and risk a lawsuit
> should they fail to accompany the object code (in your hardware, which
> they ship) with the source code that they can acquire or have received
> from you.

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.

If that medium is in the spirit of the license text "a medium customarily
used for software interchange" then I think that is an utmost elegant way
to not only ensure your own and your customer's compliance (as long as they
do not destroy that medium!) but also compliance for everyone who might
re-sell your customer's product, or even your module, should your customer's
product at some point be stripped apart and bits of it sold e.g. as spare
parts.

I think that's a truly valuable offer for you to propose. GPL compliance
built-in, so to speak. :)


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Peter Stuge]

Hi Ian,

Ian Lewis wrote:
> Thank you for your detailed reply.  Of course, I understand that you cannot
> provide legal advice.  But, for now, I need to understand the practicalities
> of how to comply, more than I need to understand the law of compliance.
> And, in any case, that will probably be someone else's problem if we reach
> that point.
> 
> Since I wrote to this group, I found another page from SFLC
> https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html.
>  
> I know that Sam said that SFLC may have issues, but their write up still
> seems useful.

Cool!


> On the issue of notice, I am referring to section 1. of the license.
> 
> 1. You may copy and distribute verbatim copies of the Program's source code
> as you receive it, in any medium, provided that you conspicuously and
> appropriately publish on each copy an appropriate copyright notice and
> disclaimer of warranty; keep intact all the notices that refer to this
> License and to the absence of any warranty; and give any other recipients
> of the Program a copy of this License along with the Program.

Ah! Thanks for clarifying.

Note that this Section covers "verbatim copies of the Program's source code"
and says "on each copy" and "keep intact all the notices that refer to this
License".


> This seems to me to require some kind of clear notice to the recipient of
> their GPL rights.  A microSD attached to our product may provide the
> necessary source and license agreements.  But, it sure does not satisfy
> "conspicuously ", at least in my opinion.

I believe that the purpose of this section is to ensure that recipients
"after" you have exactly the same freedoms and possibilities with this
program as you had.

Thus it is important to communicate to those recipients which copyright and
licensing terms apply - conspicuously and appropriately "on each copy"
"of the Program's source code."

Not on each copy in object code or executable form (that's Section 3) -
but on each verbatim copy of the Program's source code.

In my opinion, a COPYING or LICENSE file in the source code root directory
serves as such conspicuous and appropriate notice, and is one reason
why this file is sometimes required by legal departments. (See the
thread on this list by the codeaurora member, who requested that such
a file be added to the root directory of the depthcharge repo (one payload)
as the preferd method to satisfy the requirements of Qualcomm's legal
department.


> You say that it is not possible to absolve our customer from GPL
> responsibility.

Correct. Your customers are also distributing the (coreboot) Program
(in object form, as received from you) and they must of course do so
in compliance with the licensing terms.


> But, I had the impression that they would have met their obligations if
> we can keep the source with our product (that is, physically attached to
> it) and provide each recipient with the notice (as I called it - see above)
> somehow.  Do you read this as incorrect?

I think that's correct.

Their obligations to their customers are the same as your obligations
to them. But the important point is that *they* are always responsible
for *their* obligations, just as you are responsible for yours. They
can't legally depend on you for that. (They would risk non-compliance
due to factors out of their control. Bad risk!)

If you want to (and I think you should, to maximize the value of your
offer :) you can design your compliance (as permitted by the license)
such that your customers can re-use your effort in order to themselves
achieve compliance easily, in particular if you choose the option to
deliver source code accompanied with the object code.


> That is, even if we could get our notice in front of each recipient

The notice is to be "on each copy" "of the Program's source code."


> and our product always included the full license and source on
> microSD, that would not be good enough to cover the obligations of
> our distributor/customer?

As long as your customer passes the medium along to *their* customer,
I would consider them compliant. They have to actually do that
however.

It is helpful to state that they are non-compliant and risk a lawsuit
should they fail to accompany the object code (in your hardware, which
they ship) with the source code that they can acquire or have received
from you.


> PS. I did not get a direct copy of your message.

Sorry about that. I've Cc:ed you on this reply, I hope that helps.

It's often customary to reply only directly to lists, although some
lists (noticeably all Linux kernel-related lists) have an explicit
policy to always use reply-all.

Because many email programs group messages by using (invisible) email
threading headers regardless of how/where the message arrived, people
with such programs usually prefer not to receive two messages.  It
usually works very well to politely ask for any replies to list messages
to also be Cc:ed directly to you, if that 

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

[Ian Lewis]

Hello Peter,

Thank you for your detailed reply. Of course, I understand that you cannot provide legal advice. But, for now, I need to understand 
the practicalities of how to comply, more than I need to understand the law of compliance. And, in any case, that will probably be 
someone else's problem if we reach that point.


Since I wrote to this group, I found another page from SFLC 
https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html. I know that Sam said that SFLC may have 
issues, but their write up still seems useful.


On the issue of notice, I am referring to section 1. of the license.

1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you 
conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the 
notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this 
License along with the Program.


This seems to me to require some kind of clear notice to the recipient of their GPL rights. A microSD attached to our product may 
provide the necessary source and license agreements. But, it sure does not satisfy "conspicuously ", at least in my opinion.


You say that it is not possible to absolve our customer from GPL responsibility. But, I had the impression that they would have met 
their obligations if we can keep the source with our product (that is, physically attached to it) and provide each recipient with 
the notice (as I called it - see above) somehow. Do you read this as incorrect? That is, even if we could get our notice in front of 
each recipient and our product always included the full license and source on microSD, that would not be good enough to cover the 
obligations of our distributor/customer?


Thank you for the additional references. I will review them, though probably 
not until next week.

Happy Holidays to you as well.

Ian

PS. I did not get a direct copy of your message. So, I constructed the history 
below by hand.

Peter Stuge wrote:

Hi Ian,

Thank you for reaching out to the community with your very valid concerns!

You are asking exactly the right questions.

In the end, the community can't provide you with legal advice, but
what we can do is help with pointers to successful uses of GPL code,
and we can of course discuss personal understanding of the license text.
I'm a developer, not legal counsel. :)


Lewis, Ian (Microstar Laboratories) wrote:

We have never used GPL licensed code in our products before. And, I
am having a hard time seeing how we can do so and comply with GPLv2,
or GPLv3 for that matter.


In the end it may be that you actually can't, if you have non-technical
requirements which are incompatible with the GPL.

But several companies have done it, so it is in no way impossible per se!



I have read this page
https://www.softwarefreedom.org/resources/2008/compliance-guide.html
several times, a number of other sites, as well as reading the GPLv2
itself.


Thanks for the link, I hadn't seen that, and I think it's a good
commentary to read along the license text itself.



I do not want to impose a GPLv2 requirement on our customers if they use
our product. I want GPLv2 compliance to be fully our responsibility.


The license applies to the software wherever the software ends up,
whoever the distributors and recipients are. This is very different
from a proprietary license, where conditions usually end with the
first recipient, and usually amount to "do not ever distribute" or
"you paid us once, so distribute as much as you like", or anything
in between.

Think about what the GPL strives to achieve.

The conditions in the license want to ensure that every single
recipient of the software has the same possibilities that you,
the initial recipient, have.

This in turn means that GPL compliance is per definition required
from every single distributor, not only from you.



If we do have to impose a GPLv2 requirement on our customers to use a
Coreboot/SeaBIOS initialized platform, we probably cannot use such a
platform in any product, which would be quite unfortunate from my point
of view.


That's your decision to make. It is certainly possible, many
companies do so very successfully already, and I would argue that some
of their success can actually be attributed to the very fact that they
have decided to reuse (and perhaps contribute to!) existing GPL projects,
at the very small compliance cost.



A large fraction of our customers are OEMs or VARs and they make
products of their own that use our products as a part. Unless they pull
the system apart, the end-use customer often does not even know one of
our products is part of the system they buy, though our licensing to our
customer (OEM) does require that the reseller maintain our copyright
notice in their system documentation or 

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

[Ian Lewis]

Hello Sam,

Thank you for the information on the SFC. I had not yet found their materials. I will look at them, though probably not until next 
week.


Ian
-Original Message- 
From: Sam Kuper

Sent: Sunday, December 24, 2017 10:06 AM
To: Lewis, Ian (Microstar Laboratories)
Cc: coreboot@coreboot.org ; Peter Stuge
Subject: Re: [coreboot] How to properly conform with GPLv2 for Coreboot and 
SeaBIOS on an embedded system

Hi Ian,

On 24/12/2017, Lewis, Ian (Microstar Laboratories)  wrote:

I have read this page
https://www.softwarefreedom.org/resources/2008/compliance-guide.html
several times, a number of other sites, as well as reading the GPLv2
itself.


I want to echo Peter Stuge on these points...

On 24/12/2017, Peter Stuge  wrote:

Thank you for reaching out to the community with your very valid concerns!

You are asking exactly the right questions.

In the end, the community can't provide you with legal advice


.. and to add a caveat to these points from Peter:


If this is the wrong forum for this kind of question, I apologies. And,
I would appreciate if someone could point me to an appropriate forum.


I think SFLC is a good point of contact, and FSF Europe also have a
strong focus on applied use of free software code.

http://fsfe.org/activities/ftf/documentation.en.html
http://fsfe.org/activities/ftf/services.html
http://gpl-violations.org/faq/vendor-faq/

And if you are interested to connect your legal counsel with experts on
the field of free software licensing, then this may be relevant:

http://fsfe.org/activities/ftf/ln.en.html


The caveat is that this is all good advice *except* that instead of
contacting the SFLC (i.e. the Software Freedom Law Centre, run by Eben
Moglen et al), it might be better for you to contact the SFC (the
Software Freedom Conservancy, run by Bradley Kuhn, Karen Sandler, et
al).

In my opinion, the SFLC was still giving decent advice in 2008, which
is when it published the post you linked to. But it has, sadly,
behaved rather confusingly of late. By contrast, the SFC has always,
as far as I know, taken a reasonable and consistent stance in its
work. For more about the SFLC's recent, unfortunate behaviour, see:

- https://mjg59.dreamwidth.org/49370.html

- http://www.rants.org/2017/11/conservancy_sflc_dispute/

- https://lwn.net/Articles/738046/

Wishing you a successful and GPL-compliant product!

Sam 



--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Ian Lewis]

Thank you for your rapid reply, Ivan.

We certainly can, and probably will, ship a mini-book with our product. But, as you say, that is likely to get lost long before the 
end user has the system, let alone any reselling of the product by the end-user.


Your ideas about displaying the booklet and notice about where to find the source at boot time are interesting. Unfortunately, we 
have no access to a screen of any type at boot time. Our product - a measurement system with built-in processing, largely used for 
control or signal processing - has no user I/O. It communicates with another computer (usually a PC) over a communication link that 
is - at root - either PCI, PCIe, or USB (2 or 3). Our PC-side driver can get to the Windows Event log, but it cannot interact 
directly with the user (well, actually, it could, but our customers would not appreciate that).


Still, if we ever do use Coreboot on a device that has a screen these seem like useful approaches to presenting the GPL license and 
information on where to find the source code.


Best Regards,
Ian Lewis
www.mstarlabs.com

-Original Message- 
From: Ivan Ivanov

Sent: Sunday, December 24, 2017 5:11 AM
To: Lewis, Ian (Microstar Laboratories) ; coreboot@coreboot.org
Subject: Re: [coreboot] How to properly conform with GPLv2 for Coreboot and 
SeaBIOS on an embedded system

Good day, Ian!

Perhaps it is a good idea to look what another responsible company did
at the same situation

The TP-Link company is using the GPLv2-licensed source code for the
firmware of their routers,
and they include a small paper printed mini-book ---> which contains
two major things:
1) the complete text of GNU GPLv2 license
2) an explanation that the complete firmware source code could be
obtained from TP-Link website:
http://www.tp-link.com/us/support/gpl-code-center

But it seems that in your situation you could not include such a mini-book,
because it could be lost before it reaches the eventual user of your device
and also - these are additional expenses to print such mini-books

However there are two excellent alternative solutions :

1ST SOLUTION :

1) Modify the SeaBIOS source code, so that - while booting - it will
print a two-line message
at the bottom of screen, something like "The source code of this BIOS
is GNU GPLv2 licensed,
for more info - press "ESC" and then a letter corresponding to
"FreeDOS with GNU GPLv2 texts" boot entry

2) Download a FreeDOS floppy, remove an installer from it (not
needed!) and add two text files to this image:
*) your "mini-book" in txt format with GNU GPLv2 license text and a
link to your sources
*) similar "mini-book" but for FreeDOS - with a license for FreeDOS
and a link to its sources

3) Add this virtual floppy to the completed coreboot+SeaBIOS build
while using the LZMA compression
using a simple command like this:

./coreboot/build/cbfstool ./coreboot/build/coreboot.rom add -f
./FreeDOS.img -n floppyimg/FreeDOS_with_GNU_GPLv2_texts.lzma -t raw -c
lzma

and then it will be shown as "FreeDOS with GNU GPLv2 texts" boot entry
at SeaBIOS boot menu.

Good thing is that even if the user makes some edits to license using
a text editor -
these changes will be temporary and will disappear after a user
reboots your device

When LZMA compression is used, FreeDOS floppy takes about 714 KB -
twice less than its original 1440 KB size

However, if thats still too large for you, instead of FreeDOS you
could use any other floppy based OS
which meets these two requirements:
*) Contains a text editor / text displayer as the means to show the
license texts to the user.
*) That OS is licensed by GNU GPLv2 or less restrictive license

So, if you don't like FreeDOS you could use something like MikeOS:
*) this floppy MikeOS is licensed by BSD-like license
*) it compresses significantly better than FreeDOS: to just 54 KB,
and even better if you remove some games/demos from it

2ND SOLUTION:

Similar to 1ST, but - instead of using a floppy based OS - you could
directly modify the SeaBIOS source code
to include a fake boot entry - which, when selected, instead of
booting any device will start showing
your mini-book page by page and its possible to scroll pages or move
back/forward between them

I wrote a patch to SeaBIOS which sadly didn't got accepted, you could
obtain it here:
https://mail.coreboot.org/pipermail/seabios/2017-June/011416.html
[SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and
possible pages

Without this patch the SeaBIOS supports just 9 or 10 boot entries,
but with this patch - 35 boot entries, and its possible to switch the pages
between the first 18 entries and last 17 entries

You can borrow this paging code and modify it to display the pages of
your mini-book
with license texts and explanation that sources are easily available
from your website

Actually it would be much better if you will be able to contribute the
sources for your device
to the official coreboot repositories:
1) it will be more 

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

[Sam Kuper]

Hi Ian,

On 24/12/2017, Lewis, Ian (Microstar Laboratories)  wrote:
> I have read this page
> https://www.softwarefreedom.org/resources/2008/compliance-guide.html
> several times, a number of other sites, as well as reading the GPLv2
> itself.

I want to echo Peter Stuge on these points...

On 24/12/2017, Peter Stuge  wrote:
> Thank you for reaching out to the community with your very valid concerns!
>
> You are asking exactly the right questions.
>
> In the end, the community can't provide you with legal advice

... and to add a caveat to these points from Peter:

>> If this is the wrong forum for this kind of question, I apologies. And,
>> I would appreciate if someone could point me to an appropriate forum.
>
> I think SFLC is a good point of contact, and FSF Europe also have a
> strong focus on applied use of free software code.
>
> http://fsfe.org/activities/ftf/documentation.en.html
> http://fsfe.org/activities/ftf/services.html
> http://gpl-violations.org/faq/vendor-faq/
>
> And if you are interested to connect your legal counsel with experts on
> the field of free software licensing, then this may be relevant:
>
> http://fsfe.org/activities/ftf/ln.en.html

The caveat is that this is all good advice *except* that instead of
contacting the SFLC (i.e. the Software Freedom Law Centre, run by Eben
Moglen et al), it might be better for you to contact the SFC (the
Software Freedom Conservancy, run by Bradley Kuhn, Karen Sandler, et
al).

In my opinion, the SFLC was still giving decent advice in 2008, which
is when it published the post you linked to. But it has, sadly,
behaved rather confusingly of late. By contrast, the SFC has always,
as far as I know, taken a reasonable and consistent stance in its
work. For more about the SFLC's recent, unfortunate behaviour, see:

- https://mjg59.dreamwidth.org/49370.html

- http://www.rants.org/2017/11/conservancy_sflc_dispute/

- https://lwn.net/Articles/738046/

Wishing you a successful and GPL-compliant product!

Sam

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Peter Stuge]

Hi Ian,

Thank you for reaching out to the community with your very valid concerns!

You are asking exactly the right questions.

In the end, the community can't provide you with legal advice, but
what we can do is help with pointers to successful uses of GPL code,
and we can of course discuss personal understanding of the license text.
I'm a developer, not legal counsel. :)


Lewis, Ian (Microstar Laboratories) wrote:
> We have never used GPL licensed code in our products before. And, I
> am having a hard time seeing how we can do so and comply with GPLv2,
> or GPLv3 for that matter.

In the end it may be that you actually can't, if you have non-technical
requirements which are incompatible with the GPL.

But several companies have done it, so it is in no way impossible per se!


> I have read this page
> https://www.softwarefreedom.org/resources/2008/compliance-guide.html
> several times, a number of other sites, as well as reading the GPLv2
> itself.

Thanks for the link, I hadn't seen that, and I think it's a good
commentary to read along the license text itself.


> I do not want to impose a GPLv2 requirement on our customers if they use
> our product. I want GPLv2 compliance to be fully our responsibility.

The license applies to the software wherever the software ends up,
whoever the distributors and recipients are. This is very different
from a proprietary license, where conditions usually end with the
first recipient, and usually amount to "do not ever distribute" or
"you paid us once, so distribute as much as you like", or anything
in between.

Think about what the GPL strives to achieve.

The conditions in the license want to ensure that every single
recipient of the software has the same possibilities that you,
the initial recipient, have.

This in turn means that GPL compliance is per definition required
from every single distributor, not only from you.


> If we do have to impose a GPLv2 requirement on our customers to use a
> Coreboot/SeaBIOS initialized platform, we probably cannot use such a
> platform in any product, which would be quite unfortunate from my point
> of view.

That's your decision to make. It is certainly possible, many
companies do so very successfully already, and I would argue that some
of their success can actually be attributed to the very fact that they
have decided to reuse (and perhaps contribute to!) existing GPL projects,
at the very small compliance cost.


> A large fraction of our customers are OEMs or VARs and they make
> products of their own that use our products as a part. Unless they pull
> the system apart, the end-use customer often does not even know one of
> our products is part of the system they buy, though our licensing to our
> customer (OEM) does require that the reseller maintain our copyright
> notice in their system documentation or software copyright notice or
> they do not have a right to distribute our software. The copyright for
> the hardware is printed on the hardware itself, as is customary. The OEM
> who uses our product configures our product before it ships to the
> end-use customer, and they often build additional hardware of their own
> as part of the system. The OEM (our customer) almost always includes a
> PC and custom software of their own as part of the end-use system. The
> end use customer may later re-sell their system to yet another end-use
> customer or even pull our product out of the system and resell that
> separately (on eBay, say).

Cool. None of that is per se incompatible with the GPL, IMHO.


> If I have understood correctly, all of these owners of our product must
> have access to exactly the Coreboot/SeaBIOS source used to produce the
> binary in the copy of our product they own.

Yes, that is my understanding too.


> Based on my understanding so far (highly limited), the only way that
> looks like it might be possible to avoid propagating a GPLv2 requirement
> to our customers - and thus making the compliance fully our responsibility

No, absolving someone else of GPL requirements is simply not possible,
unless you are the sole copyright holder and you use a dual-licensing
scheme. (Enabling that is one purpose of copyright assignment.)

Every single distributor of GPL code must comply with the license, as is
the case with every other license.

The conditions of the GPL mean that distributors do have to spend some
effort on compliance. Instead, quite some NRE effort can be saved! In
the case of coreboot, I think the monetary advantage to GPL is super
obvious, but of course that doesn't help if you have strict requirements
to not require your customers to understand and implement GPL compliance.

So far that may sound quite scary, but:

GPLv2 compliance is not really difficult, just different from engineering,
but maybe more importantly it is very different from the adversarial
compliance that lawyers have trained for decades to deal with.

It's common for legal departments to need some time to climb the

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

[Ivan Ivanov]

Good day, Ian!

Perhaps it is a good idea to look what another responsible company did
at the same situation

The TP-Link company is using the GPLv2-licensed source code for the
firmware of their routers,
and they include a small paper printed mini-book ---> which contains
two major things:
1) the complete text of GNU GPLv2 license
2) an explanation that the complete firmware source code could be
obtained from TP-Link website:
http://www.tp-link.com/us/support/gpl-code-center

But it seems that in your situation you could not include such a mini-book,
because it could be lost before it reaches the eventual user of your device
and also - these are additional expenses to print such mini-books

However there are two excellent alternative solutions :

1ST SOLUTION :

1) Modify the SeaBIOS source code, so that - while booting - it will
print a two-line message
at the bottom of screen, something like "The source code of this BIOS
is GNU GPLv2 licensed,
for more info - press "ESC" and then a letter corresponding to
"FreeDOS with GNU GPLv2 texts" boot entry

2) Download a FreeDOS floppy, remove an installer from it (not
needed!) and add two text files to this image:
*) your "mini-book" in txt format with GNU GPLv2 license text and a
link to your sources
*) similar "mini-book" but for FreeDOS - with a license for FreeDOS
and a link to its sources

3) Add this virtual floppy to the completed coreboot+SeaBIOS build
while using the LZMA compression
using a simple command like this:

./coreboot/build/cbfstool ./coreboot/build/coreboot.rom add -f
./FreeDOS.img -n floppyimg/FreeDOS_with_GNU_GPLv2_texts.lzma -t raw -c
lzma

and then it will be shown as "FreeDOS with GNU GPLv2 texts" boot entry
at SeaBIOS boot menu.

Good thing is that even if the user makes some edits to license using
a text editor -
these changes will be temporary and will disappear after a user
reboots your device

When LZMA compression is used, FreeDOS floppy takes about 714 KB -
twice less than its original 1440 KB size

However, if thats still too large for you, instead of FreeDOS you
could use any other floppy based OS
which meets these two requirements:
*) Contains a text editor / text displayer as the means to show the
license texts to the user.
*) That OS is licensed by GNU GPLv2 or less restrictive license

So, if you don't like FreeDOS you could use something like MikeOS:
*) this floppy MikeOS is licensed by BSD-like license
*) it compresses significantly better than FreeDOS: to just 54 KB,
and even better if you remove some games/demos from it

2ND SOLUTION:

Similar to 1ST, but - instead of using a floppy based OS - you could
directly modify the SeaBIOS source code
to include a fake boot entry - which, when selected, instead of
booting any device will start showing
your mini-book page by page and its possible to scroll pages or move
back/forward between them

I wrote a patch to SeaBIOS which sadly didn't got accepted, you could
obtain it here:
https://mail.coreboot.org/pipermail/seabios/2017-June/011416.html
[SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and
possible pages

Without this patch the SeaBIOS supports just 9 or 10 boot entries,
but with this patch - 35 boot entries, and its possible to switch the pages
between the first 18 entries and last 17 entries

You can borrow this paging code and modify it to display the pages of
your mini-book
with license texts and explanation that sources are easily available
from your website

Actually it would be much better if you will be able to contribute the
sources for your device
to the official coreboot repositories:
1) it will be more convenient both for you and your users to have the
latest coreboot updates
2) other coreboot users will clearly see that your device is supported
and would want to get it

Please ask if any questions, we could come up with a lot of good ideas
of how it could be done.
Also it will be great to learn about your product once its released,
maybe some of coreboot developers
would want to get your device - and this could probably give some
additional support from community

Best regards,
Ivan Ivanov


  https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Без вирусов. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avast.ru




2017-12-24 9:46 GMT+03:00 Lewis, Ian (Microstar Laboratories)
:
> I am looking at using a processor module that initializes using Coreboot and
> SeaBIOS to make an embedded hardware product. Assuming we move forward,
> Coreboot/SeaBIOS will load our (proprietary) OS. Our OS contains no GPL
> licensed code.
>
>
>
> We have never used GPL licensed