[git commit master 1/1] Much enlarged license.html
Denys Vlasenko
vda.linux at googlemail.com
Sat Aug 7 03:19:58 UTC 2010
commit: http://git.busybox.net/busybox-website/commit/?id=8ab0ffdccf6c429c8ddbaf21fce4f206859ab6f8
branch: http://git.busybox.net/busybox-website/commit/?id=refs/heads/master
Signed-off-by: Denys Vlasenko <vda.linux at googlemail.com>
---
license.html | 290 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 276 insertions(+), 14 deletions(-)
diff --git a/license.html b/license.html
index c29460b..336f963 100644
--- a/license.html
+++ b/license.html
@@ -3,8 +3,8 @@
<p>
<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 gpl at busybox.net), 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
-lawyers.)</p>
+lawyers.</p>
<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
+source tarball:
+
+<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
+offer).
+
+<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
+steps.
+
+<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
+not quite.
+
+<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, 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 <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
<a href="http://www.linksysbycisco.com/gpl">
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" -->
--
1.7.1
More information about the busybox-cvs
mailing list