[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
learning curve for free and open source.


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

This is one way to comply; the "Source Alongside Binary" option.


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

GPL requirements aside, being able to build yourself what you deliver
to customers is never a bad thing. It takes some R&D yes, but nothing
comparable to full R&D for an inhouse replacement, and in my experience
quite many open source and free software projects are far simpler to
use than proprietary products.


> My understanding is that we have to know exactly how to build the
> exact binary we distribute

I don't think the GPL requires this explicitly, but I think you should
do this regardless, if you distribute anything at all.


Let's look at my layman understanding of the GPLv2 sections:

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 section gives you the freedom to distribute the source code, and
sets out the conditions for compliance should you want or need to do so.


2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program ...

This section gives you the freedom to modify the code. It doesn't seem
that you want to do so. Your case is a typical one where you would
benefit the most from getting your shipped configuration included
into the upstream repository, and as long as you take ownership of
that configuration (in the end probably just a few files) then that
is also very much welcomed and desired by the project!


3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

So this is an important section, becase you want to distribute object code.
Let's look at a) and b). (c) we'll ignore, because it's only for noncommercial
distribution.

a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,

Something like the memory card you described could be used to achieve
compliance with the above section. It is important to note, that every
downstream distributor must also comply with the license. But you can
make it easy for them. If all they need to do is ship that memory card
along to their customers, then that's not a high cost for compliance,
and on the flip side they of course save cost through your competitive
pricing that was enabled by you reusing coreboot and SeaBIOS.


b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,

Because paper costs less than storage medium this mini-book or booklet
method is used by many consumer electronics vendors. I've personally
received such a "compliance booklet" from Philips with a TV set, from
Samsung with a TV set and with a phone, and from several wireless
router vendors.

Personally I am less fond of this method. Yes, the cost at time of
shipment is less per unit, but on the other hand you must set up a
process to fulfill the offer, and you must keep it running for a
minimum of three years after your distribute the very last unit!
This is fairly risky; because this process will not be exercised
very frequently it is also much more prone to fail, and fail
silently, and then you are suddenly no longer compliant without being
aware, so if a request then comes in but the offer is not fulfilled
then the (usually simple) operational issue immediately becomes a
legal liability.

Most importantly, if the process breaks you are unable to satisfy
your customer's request for the source code.


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

Neither of those are in GPLv2, but indeed in GPLv3. Certainly the
GPLv3 has more requirements, and that may be a reason to use
coreboot, but not SeaBIOS. Other bootloaders exist, such as FILO.

Since you are booting your own OS anyway, that may even be preferable
over hanging on to obsolete BIOS services and data structures.


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

For GPLv3, yes.


> One idea I had is to put the source on a microSD drive
..
> 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.

It could be argued that a memory card qualifies as
"a medium customarily used for software interchange".


> That seems to me like it might cover the source distribution requirement
> of GPLv2, though I am not quite certain it is good enough.

I think it is one feasible way for *you* to comply. But as part of
your product, maybe in some documentation or training, you should
probably also make sure that your customers understand why they must
*also* ensure that *they* comply, and that part of the value of your
particular product is that you have already prepared this medium to
assist them with that. For GPLv2 I think the rest is a matter of
documentation that they supply with their products. (Like a booklet.)


> However, so far, it looks impossible to me to meet the GPLv2
> notification requirements.

Sorry, what are you refering to here? Neither "notification", "Notification",
"notify" nor "Notify" appears in my copy of the GPLv2 license text.


> And, I do not understand at all how the likes of network routers
> that use GPL licensed code can possibly comply either.

Many ship a compliance booklet which refers to a distribution service
where recipients of a binary copy can obtain the source code in
compliance with the license requirements.

Once set up, and firmly established within a company, that is probably
by far the most cost-effective. It's a longer commitment than shipping
a physical storage medium - that's a one-time thing for you.

GPLv3 is explicit about who can operate network servers, but:

"Regardless of what server hosts the Corresponding Source, you remain
obligated to ensure that it is available for as long as needed to
satisfy these requirements."


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

Maybe you refer to the 3b) "written offer" option for Section 3 of GPLv2?

Whether a mere URL constitues "a written offer ..." I don't know.
Personally I find that a very weak offer. A booklet or even a single
sheet of peper is significantly more obvious.

Note that Section 3 requires only "one of the following" options, not
all.


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

I personally find GPLv2 Section 3a) and 3b) to be pretty clear and
comprehensible. 3a) says accompanying object code with complete
corresponding machine-readable source code on a medium. 3b) says
accompanying object code with a written offer.

Note that however source code is distributed, Sections 1 and 2 must
also be complied with.


> 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


Hope this helps, and happy holidays to everyone! :)

//Peter