Complying with GPLv2 for BusyBox.
Rob Landley
rob at landley.net
Wed Oct 15 15:14:44 PDT 2008
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
More information about the busybox
mailing list