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

Ian Lewis ilewis at mstarlabs.com
Mon Dec 25 03:06:04 CET 2017


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 at 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 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<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
      <td style="width: 55px; padding-top: 18px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"
target="_blank"><img
src="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;"
/></a></td>
<td style="width: 470px; padding-top: 17px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Без вирусов. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"
target="_blank" style="color: #4453ea;">www.avast.ru</a> </td>
</tr>
</table>
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>

2017-12-24 9:46 GMT+03:00 Lewis, Ian (Microstar Laboratories)
<ilewis at mstarlabs.com>:
> 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 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.
>
>
>
> 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 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. 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.
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> 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 - would
> be if we distribute a copy of the exact source code used to build the
> module’s Coreboot/SeaBIOS configuration as an integral part of our product.
> If there is any way to do it, we would actually rather not develop the
> expertise to set up such a build, but I see no way around being able to
> build our own version of the system image if we are to comply with GPLv2. My
> understanding is that we have to know exactly how to build the exact binary
> we distribute and we have to be able to tell a technically competent
> recipient of the binary how to do that build themselves, as well as how to
> incorporate the new build into our product. We do not have to support any
> changes whatsoever, but we do have to support the initial process of
> re-configuring our product with a newly built binary that came from the
> sources we supply as long as there are no changes made to those sources.
>
>
>
> One idea I had is to put the source on a microSD drive and semi-permanently
> attach that drive to the product. That way the Coreboot/SeaBIOS code would
> go along for the ride any time our product changed hands (as long as no one
> lost it). The microSD would not be  part of our product. So, an owner of our
> product (and so a recipient of the binary distribution of Coreboot/SeaBIOS)
> would have the code on the microSD, but we have no easy way to provide them
> access to its content. But, they could remove the microSD from the product
> and read it from any machine that can read a microSD. That means almost any
> machine.
>
>
>
> That seems to me like it might cover the source distribution requirement of
> GPLv2, though I am not quite certain it is good enough.
>
>
>
> However, so far, it looks impossible to me to meet the GPLv2 notification
> requirements. And, I do not understand at all how the likes of network
> routers that use GPL licensed code can possibly comply either.
>
>
>
> I can imagine fitting a URL, such as www.mstarlabs.com/GPL (not a real URL)
> on to the product to point any owner of the product to an explanation of
> where to find the license text and source for Coreboot/SeaBIOS. The microSD
> would have everything needed to comply on it, but I do not think that comes
> close to meeting the notice requirements of GPL.
>
>
>
> Under Windows, where we sell the vast majority of our systems, we do have a
> control panel application that every user could potentially get to. And, it
> could include a screen that explains the owner’s GPL rights and where to
> find the source microSD on the product. But, we have no means to force the
> user to look at the control panel application, and most users would never
> have any reason to do so.
>
>
>
> Do you have any written guidelines that explain how to properly – and
> legally - distribute a commercial hardware product that incorporates
> Coreboot/SeaBIOS? In particular, how can we meet the notification
> requirements when the user never even physically handles the product, sees
> any output from the device, or installs any software on it? I am having a
> hard time figuring out how to do this, if it is possible at all.
>
>
>
> 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.
>
>
>
> Ian Lewis
>
> www.mstarlabs.com
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot 




More information about the coreboot mailing list