Complying with GPLv2 for BusyBox.

[Rob Landley]

On Monday 13 October 2008 21:54:03 Alain M. wrote:
> I have followed this thread and nowhere I have seen two important points:
>
> 1) a GPLed software like Busybox can be used in a proprietary product,
> as long as not linked at all with the proprietary part. Even in an
> embedded it can be used.

As long as you abide by the license terms, which means providing source code.  
And before you say "but the source is already available elsewhere", read on, 
I'll get to that.

The text of the license obliges you to provide source code for binaries you 
distribute, and gives you exactly three options for providing source code.  
These options are spelled out in section 3 of the LICENSE file in the busybox 
source tarball:

A) bundle the complete corresponding source with the binary

B) bundle a written offer good for three years to provide source upon request 
(these days this is often a URL).

C) point you users at the upstream source (I.E. pass along somebody else's 3B 
offer).

Now section 3C is what most open source people use, and it's so lenient lots 
of developers don't even think about it.  Technically 3C is also full of 
restrictions (it's "allowed only for noncommercial distribution", and it only 
applies if you're redistributing a binary you didn't build yourself) intended 
to push people to use 3A or 3B, but the busybox project has generally let 
those restrictions slide (as has most of the rest of the open source world) 
when dealing with people who are acting in good faith.

So if you built an unmodified busybox release and you point people at the URL 
to the _SPECIFIC_ source tarball on busybox.net you built it from and 
truthfully say "that's it, no patches", we've accepted that as compliance 
even from commercial companies.  (We're not really interested in forcing 
random strangers to mirror stuff we've already got.  OSUOSL provides very 
nice high bandwidth hosting for us, and if they didn't there's always 
sourceforge and savannah and ibiblio and kernel.org and...)

The word "specifc" above is very important.  If you don't even _identify_ the
source that comes with your binary, there's no way you can say your
distribution complied with the license terms.  This means that even if you
didn't modify it (and thus the source code in question is already widely
available) you still need to _tell_ us what source code this binary comes 
from.  (Yes, busybox prints out a version number but are you distributing a 
release, or a nightly snapshot, or what?)  That's an obligation you have 
under GPLv2 when you distribute a binary: show us the code.

Secondly, even if you didn't modify it, if you don't explicitly _tell_ us you 
didn't modify it how are we to know?  I could spend weeks combing through an 
assembly dump of your binary, or trying to find the exact cross-compiler 
version you used to produce a byte-for-byte identical file, but the license 
says I shouldn't have to.  Proving a negative is a lot of work, and making me 
do this work is again shirking your obligations under GPLv2.

Why am I harping on "specific" so much?  Imagine somebody takes a release 
version and backports a half-dozen patches out of svn.  I can say from 
personal experience that trying to figure out what version _that_ is gives 
you a real headache.  (Giving us a tarball of the source code you built is 
indeed one way to comply, and I'm not saying you _shouldn't_ do that if it's 
what you have lying around, but on more than one occasion just telling 
us "We're using version blah plus backports of SVN# blah, blah, blah, blah, 
and blah" would have saved me personally several hours determining that there 
wasn't actually anything _new_ in it.  And yes, even though we theoretically 
have all this code already, the way you put it together is kind of unique and 
not necessarily trivial to reproduce.  Or, for that matter, untangle.)

The above is a fairly lenient interpretation of GPLv2 that works a bit like 
the BSD license's "advertising clause": that one required you to thank the 
university of california, this one requires you to identify the specific 
source code of the GPL binaries you distributed.  The GPL actually allows us 
to be more draconian than this (for starters, clause 3C doesn't have to apply 
to commercial companies at all), but as long as everybody's acting in good 
faith most projects seem happy with just identifying the specific source for 
binaries built from an unmodified upstream version.

Obviously if you did modify the source to the binary you distributed, and you 
don't think you need to at least provide us a _patch_, you've missed the 
point of GPLv2 entirely.  This is another incentive to get your patch merged, 
so you can ship a vanilla upstream version and not have to host your patch on 
your own website for 3 years after you _stop_ distributing your product.

The next paragraph right after 3C essentially says you're supposed to give us 
your .config file as well, and sometimes we've asked for that as long as 
we're contacting people anyway.  But to be honest, if we don't need to 
contact you to get the other stuff anyway, we seldom bother.  (We can 
generally figure that one out for ourselves.  I note that Linux 
kernel .configs are harder to reverse engineer, for that you'll probably need 
to provide a .config for to make the developers happy, but they put in 
a /proc/config.gz option to make it easy. :)

Now the above is what happens when people are acting in good faith.  I note 
that the GPL imposes upon you the obligation to provide source code 
_when_you_distribute_.  Whether you're using 3A, 3B, or 3C, they all 
start "Accompany it with", meaning source goes with binary at time of 
distribution.  So if we get the binary from you and there's no _mention_ of 
source code, your distribution of that binary didn't comply with the terms of 
the license.  At that point, you're already in breach of the license terms, 
and it's now about _fixing_ it.  So if we have to approach you after the fact 
to get this information, we have the option to be really nasty about it.

We're not _required_ to be nasty, and we prefer not to.  An honest mistake 
that a company is willing to fix is understandable, and as far as I know 
we've always started out with "excuse me, could you fix this please" and not 
made a fuss.  Most of the time, it doesn't go beyond that, we get back an 
email "oh, sorry, it's version blah, and here's the three line patch we used 
to change a default value", and we're happy.  (We keep meaning to start 
a "hall of fame" with the _positive_ compliance information we've got...)

And some companies are disorganized but honest about it, and go "um, we lost 
track of this information and the guy who did it left the company, can you 
give us some time to dig it out of the archives?"  And if they're making an 
honest effort, we're polite about that too.

But the "hall of shame" proved that being polite wasn't always enough. Some 
companies ignore the polite requests entirely, and go all deer in the 
headlights on us, or maybe hope that if they ignore us long enough we'll go 
away.  Those are the ones that the SFLC sends _impolite_ requests to, asking 
for far more than the original request did back when they were being nice.

For starters, if the SFLC has to actually sue someone to get their attention, 
they bill them for expenses.  (They have an office in New York City, you 
_really_ don't want to go there.  Also, they usually make the company appoint 
an "open source compliance officer" and deliver quarterly reports.  And make 
them try to contact the old customers they shipped product to without source 
and let them know where the source is.  All this is the lawyerly equivalent 
of "raising your voice to be heard".  I've only seem them take the gloves off 
once.  They've only _needed_ to once.)

A lot of companies get in trouble because although they use an upstream 
vanilla source tarball, they don't say what version it was, or they don't 
explicitly say it wasn't modified.  Then when we approach them for more 
information, they don't understand what we could possibly want, and panic.  
(Panicing bad.  Please don't panic, this is actually pretty easy to get 
right.  Ignoring repeated polite requests is not going to end well.  Please 
be polite _back_.  Ask for clarification if you don't understand something, 
it's not an admission of weakness.  If you ignore us until we stop knocking, 
these days it may mean we're getting the battering ram.  This is not an 
improvement for anyone concerned.)

Another common failure mode is companies that redistribute some vendor board 
support package they bought, and when we ask them they brush us off with "we 
got it from a vendor, go bug our vendor, not our problem".  Dude, you're 
copying and distributing GPL code too.  If the license is the only thing that 
gives you permission to do that, then that license applies to you too.  
Really.  If your vendor complied with the license terms but you didn't, 
you're not off the hook.  This is not a scavenger hunt, nor is it the episode 
of M*A*S*H about getting tomato juice to Colonel Potter.  We asked _you_, and 
you have an obligation to provide this information.  If you don't even know 
what it _is_ when we ask, something is _wrong_.  If you'd reprinted somebody 
else's documentation and stripped out BSD advertising clause notices, do you 
think you could then say "but the original PDF we got from our vendor had the 
notice in it, so we're ok, don't bother us"?  Or would going "oops, here's 
one with the right data" be _your_ responsibility?  Fixing this is not _our_ 
job.  "We ask, you answer" is us being _lenient_, the license technically 
says we shouldn't have had to ask in the first place, you were supposed to 
provide this info when you shipped.  And even if we're letting you delegate 
the implementation, you can't delegate the _responsibility_.  Don't make me 
look up how to spell "fiduciary".  (And delegating it to _nobody_ really 
isn't as solution.  Asking us to track down an ex-employee of a defunct 
Taiwanese company where nobody spoke English just _doesn't_go_over_well_...)

Sorry about that.  Scars from the "hall of shame" days.  We have lawyers now.  
They're very nice.  Where was I?

A company that wants to be legally paranoid will make a source CD for the GPL 
portions of their entire product (build scripts, cross compiler toolchains, 
and all), and either include the CD in the box with the product (clause 3A) 
or put the ISO up on the web and mention the URL to it in their product's 
documentation (clause 3B).  They don't need our say-so to be satisfied with 
that, even a strict reading of GPLv2 says that complies with the license 
terms.  (You can probably even email the SFLC guys about what exactly should 
go on the CD, gpl at busybox.net.)  This is the "make it go away" preemptive 
nuclear strike approach, and probably a good idea for Fortune 500 companies 
that have their own legal department to do _anyway_.

Ideally, what the busybox developers really want is for people who develop a 
product using BusyBox to post a message to the busybox mailing list when 
their product ships.  What's most useful to _us_ is something like:

A) a description of the product (including the build environment: processor 
type, libc version, kernel version)
B) identify the specific version of busybox it uses
C) identify any modifications made to that version (either by linking to a 
nicely broken up series of "diff -u" patches on the web, or attaching the 
patches to the message, or explicitly saying it isn't modified)
D) attaching the busybox .config file you used to build the thing.

This is the "being nice to the developers" approach, which acts as a sort of 
free advertising within the developer community, and would let us put your 
project in a "hall of fame" page on busybox.net if we ever get around to 
doing that.  (Heck, if traffic of these messages got high enough we could 
create a list just for them.  Such problems we should have.)

You really can't go wrong with either approach: you can obey the letter of the 
license according to a strict reading, or you can make the developers as 
happy as possible so they not only have no reason to make trouble, but 
actually like you.  (Heck, we won't complain if you do both. :)

Rob