|author||Denys Vlasenko <firstname.lastname@example.org>||2010-08-07 03:19:58 (GMT)|
|committer||Denys Vlasenko <email@example.com>||2010-08-07 03:19:58 (GMT)|
Much enlarged license.html
Signed-off-by: Denys Vlasenko <firstname.lastname@example.org>
1 files changed, 276 insertions, 14 deletions
diff --git a/license.html b/license.html
index c29460b..336f963 100644
@@ -3,8 +3,8 @@
<h3><a name="license">BusyBox is licensed under the GNU General Public License, version 2</a></h3>
-<p>BusyBox is licensed under <a href="http://www.gnu.org/licenses/gpl.html#SEC1">the
-GNU General Public License</a> version 2, which is often abbreviated as GPLv2.
+<p>BusyBox is licensed under <a href="http://www.gnu.org/licenses/old-licenses/gpl-2.0.html">
+the GNU General Public License version 2</a>, which is often abbreviated as GPLv2.
(This is the same license the Linux kernel is under, so you may be somewhat
familiar with it by now.)</p>
@@ -13,17 +13,17 @@ the BusyBox source code.</p>
<p><a href="products.html">Anyone thinking of shipping BusyBox as part of a
product</a> should be familiar with the licensing terms under which they are
-allowed to use and distribute BusyBox. Read the full test of the GPL (either
-through the above link, or in the file LICENSE in the busybox tarball), and
+allowed to use and distribute BusyBox. Read the full text of the GPL (either
+through the above link, or in the file LICENSE in the BusyBox tarball), and
also read the <a href="http://www.gnu.org/licenses/gpl-faq.html">Frequently
Asked Questions about the GPL</a>.</p>
-<p>Basically, if you distribute GPL software the license requires that you also
-distribute the source code to that GPL-licensed software. So if you distribute
+<p>If you distribute GPL-licensed software the license requires that you also
+distribute the source code to that GPL-licensed software. If you distribute
BusyBox without making the source code to the version you distribute available,
you violate the license terms, and thus infringe on the copyrights of BusyBox.
-(This requirement applies whether or not you modified BusyBox; either way the
-license terms still apply to you.) Read the license text for the details.</p>
+This requirement applies whether or not you modified BusyBox; either way the
+license terms still apply to you.</p>
<h3><a name="version">A note on GPL versions</a></h3>
@@ -63,18 +63,17 @@ want to use. New development is all GPLv2.</p>
<h3><a name="enforce">License enforcement</a></h3>
-<p>BusyBox's copyrights are enforced by the <a
-href="http://www.softwarefreedom.org/">Software Freedom Law Center</a>
+<p>BusyBox's copyrights are enforced by the <a href="http://www.softwarefreedom.org/">Software Freedom Law Center</a>
(you can contact them at email@example.com), which
"accepts primary responsibility for enforcement of US copyrights on the
software... and coordinates international copyright enforcement efforts for
such works as necessary." If you distribute BusyBox in a way that doesn't
comply with the terms of the license BusyBox is distributed under, expect to
hear from these guys. Their entire reason for existing is to do pro-bono
-legal work for free/open source software projects. (We used to list people who
+legal work for free/open source software projects. We used to list people who
violate the BusyBox license in <a href="shame.html">The Hall of Shame</a>,
but these days we find it much more effective to hand them over to the
<p>Our enforcement efforts are aimed at bringing people into compliance with
the BusyBox license. Open source software is under a different license from
@@ -84,6 +83,244 @@ don't want monetary awards, injunctions, or to generate bad PR for a company,
unless that's the only way to get somebody that repeatedly ignores us to comply
with the license on our code.</p>
+<h3>My company wants to include BusyBox into a product.
+What do we need to do in order to comply with BusyBox's license?</h3>
+<p>First: DON'T PANIC. Complying with BusyBox's license is easy.
+Complying with BusyBox's license doesn't cost any money.
+If, after reading the license and this document something is not clear
+to you, please send emails with your questions to the BusyBox mailing lists.
+We will expand this document to cover them.
+<p>If you are distributing the BusyBox binary, you also have to distribute
+the corresponding source code. If you modified the source, you have to
+distribute the modified source.
+<p>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
+<p>A) bundle the complete corresponding source with the binary.
+<p>B) bundle a written offer good for three years to provide source upon request
+(these days this is often a URL).
+<p>C) point you users at the upstream source (I.E. pass along somebody else's 3B
+<p>Using option 3A, that is, putting exact BusyBox source and .config file
+you used to build the binary on the same medium which you use to ship
+the binary, is the most bullet-proof approach to license compliance.
+If you do that, you can stop reading, your license obligations
+have been satisfied.
+<p>Option 3B makes sense if you do not distribute BusyBox binaries on a medium
+like CD-ROM, but instead ship them in a device's firmware.
+Storing the source there might be an unacceptable waste of space.
+In this case, add a note to the device's documentation that it uses
+open-source components and that their source can be downloaded
+from the company's website. Give exact URL to the page where it can be downloaded.
+<p>Regardless of whether you use option 3A or 3B, please make sure
+you distribute the <em>exact</em> same source tree you used to build the binary.
+It doesn't have to be a single archive. Indeed, most people distribute modified
+sources in the form of unmodified BusyBox-N.N.N.tar.bz2 archive
+and a set of patches which add features or fix problems.
+<p>If you added an applet, or an option to one of the applets in BusyBox,
+or fixed a bug, and the source tree lacks this addition or fix,
+then you are not fulfilling GPLv2 requirements.
+<p>You can avoid having to distribute source by taking option 3C.
+However, option 3C has some restrictions, and if your company wants to be
+paranoid and be 100% sure everything is crystal clear about complying with
+the license, perhaps it should use options 3A or 3B.
+<h3>Option 3C: using unmodified source</h3>
+<p>Option 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.
+<p>Using option 3C means identifying the specific version of the public source
+you used, where to get it from, and confirming that your binary was built from
+unmodified "vanilla" sources.
+<p>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...)
+<p>Note that you must do all three parts: what version did you use, where can we
+get it from, and explicitly state that you did not modify it. Don't skip
+<p>If you don't specify your version, we can't tell if you used some random git
+snapshot out of the development branch that was close to a release version but
+<p>If you don't explicitly say you didn't modify it, we 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 we shouldn't have to. Proving a negative is a lot of work, and
+making us do this work would be shirking your obligations under GPLv2.
+<p>Even if you just backported changes out of the development branch, that's not
+a vanilla unmodified release. The component parts may already be public, but
+you have to give us enough information to understand what you did, and the
+opportunity to produce an equivalent binary from that source, or you're not
+complying with 3C.
+<p>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.
+<p>Most open source developers are lenient in this way because we actually prefer
+a good 3C compliance to a bad 3A compliance. We've all received tarballs of
+who knows what old version, with who knows what changes, and wasted an
+afternoon proving that "this is basically source control commit number BLAH,
+plus backports of commits blah, blah, blah, blah, and blah, plus they
+commented out these five lines, changed two default values that they could have
+overridden from the command line anyway, and added some debug statements."
+I.E. we just wasted three hours confirming there's nothing remotely interesting
+here that we didn't already know.
+<p>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 <em>patch</em>, 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.
+<p>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. :)
+<h3>My company was distributing BusyBox binary without the source.
+We are contacted by users asking for the source, and we don't have it.
+Are we in trouble?</h3>
+<p>Not yet. But please stop doing that, and start distributing the source.
+<p>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
+<em>when you distribute</em>. 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 <em>mention</em> 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 <em>fixing</em> 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.
+<p>We're not <em>required</em> 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.
+<p>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.
+<h3>My company was distributing BusyBox binary without the source.
+We are contacted by <em>your lawyers</em>. Are we in trouble?</h3>
+<p>Yes, but it is not too bad yet. Stop being disorganized and fix
+your licensing situation before it gets really nasty.
+As I already mentioned, DON'T PANIC. Complying with BusyBox's license is easy.
+Get your act together, fight with internal inertia inside your company
+and it will be okay.
+If you do not understand something, please send emails with your
+questions to the BusyBox mailing lists, or privately to maintainers
+if you want to keed it private. We will expand this document to cover them.
+<p>However, you really cannot afford to be careless about complying with
+the license anymore.
+<p>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 <em>impolite</em> requests to, asking
+for far more than the original request did back when they were being nice.
+<p>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
+<em>really</em> 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 <em>needed</em> to once.
+<p>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 <em>back</em>. 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.)
+<p>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 <em>you</em>, and
+you have an obligation to provide this information. If you don't even know
+what it <em>is</em> when we ask, something is <em>wrong</em>. 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 <em>your</em> responsibility? Fixing this is not <em>our</em>
+job. "We ask, you answer" is us being <em>lenient</em>, 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 <em>responsibility</em>. Don't make me
+look up how to spell "fiduciary". (And delegating it to <em>nobody</em> really
+isn't as solution. Asking us to track down an ex-employee of a defunct
+Taiwanese company where nobody spoke English just <em>doesn't go over well</em>...)
+<p>Sorry about that. Scars from the "hall of shame" days. We have lawyers now.
+They're very nice. Where was I?
+<p>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, firstname.lastname@example.org) 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 <em>anyway</em>.
<h3><a name="good">A Good Example</a></h3>
<p>These days, <a href="http://www.linksys.com/">Linksys</a> is
@@ -94,7 +331,32 @@ check out what they do with
distributing the firmware for their WRT54G Router.</a>
Following their example would be a fine way to ensure that you
-have also fulfilled your licensing obligations.</p>
+have also fulfilled your licensing obligations.
-<!--#include file="footer.html" -->
+<p>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 <em>us</em> is something like:
+<p>A) a description of the product (including the build environment: processor
+type, libc version, kernel version).
+<p>B) identify the specific version of BusyBox it uses.
+<p>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).
+<p>D) attach the BusyBox .config file you used to build the thing.
+<p>E) A link to your website, so we can add it to our products page.
+<p>This is the "being nice to the developers" approach, which acts as a sort of
+free advertising within the developer community.
+<p>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. :)
+<!--#include file="footer.html" -->