• About BusyBox
• BusyBox in VM
• Screenshot
• Announcements

• FAQ
• Command Help

• Download Source
• Download Binaries
• License
• Products

• Browse Source
• Source Control
• Mailing Lists
• Bug Tracking
• Use less RAM
• Contributing

Links

• Related Sites
• Tiny Utilities
• Sponsors

Developer Pages

• Rob
• Bernhard
• Denys
  - resume
  - kernel inlines
  - kernel size
  - mboot
  - linld
  - init must die
  - no ifup
  - unscd

BusyBox is licensed under the GNU General Public License, version 2

BusyBox is licensed under the GNU General Public License version 2, 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.)

A complete copy of the license text is included in the file LICENSE in the BusyBox source code.

Anyone thinking of shipping BusyBox as part of a product should be familiar with the licensing terms under which they are 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 Frequently Asked Questions about the GPL.

If you distribute GPL-licensed software the license requires that you also distribute the complete, corresponding source code (as defined by GPL) 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.

License enforcement

BusyBox's copyrights are enforced by Software Freedom Conservancy (you can contact them at <gpl@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 Conservancy. Their entire reason for existing is to advance the public's access to Free and Open Source Software projects, which includes ensuring that the GPL is upheld for projects that pick GPL as its license. We used to list people who violate the BusyBox license in The Hall of Shame, but these days we find it much more effective to hand them over to our enforcement agent.

Our enforcement efforts are aimed at bringing people into compliance with the BusyBox license. Open source software is under a different license from proprietary software, but if you violate that license you're still infringing copyright and the law gives the copyright holder the right to enforce our copyrights. We don't seek 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.

My company wants to include BusyBox into a product. What do we need to do in order to comply with BusyBox's license?

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 <gpl@busybox.net> We will try to expand this document to cover them.

If you are distributing the BusyBox binary, you also have to distribute the complete, corresponding source code. If you modified the source, you have to distribute the modified source.

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:

• 3(a) bundle the complete, corresponding source with the binary.
• 3(b) bundle a written offer good for three years to provide that source upon request. (These days this is often a URL).
• 3(c) pass along somebody else's 3(b) offer.

Using option 3(a), 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, plus the scripts used to control compilation and installation of the executable is the most bullet-proof approach to license compliance. If you do that, you can stop reading, your license obligations have likely been satisfied.

Option 3(b) 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 you'll provide sources upon request. Ideally, we like it when you offer the source for downloaded from the company's website, with an exact URL to the page where it can be downloaded

Regardless of whether you use option 3(a) or 3(b), please make sure you distribute the exact 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.

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.

You can avoid having to distribute source by taking option 3(c). However, option 3(c) has some restrictions, and can't be used if you distribute the software commercially. We recommend 3(c) only if you're an individual sharing your software with friends (something we encourage, BTW!)

Option 3(c): using unmodified source

Option 3(c) is what most open source people use, and it's so lenient lots of developers don't even think about it. Technically 3(c) 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 3(a) or 3(b), 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 non-commercially and are acting in good faith.

Most open source developers are lenient in this way because we actually prefer a good 3(c) compliance to a bad 3(a) compliance.

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.

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?

Not yet. But please stop doing that, and start distributing the source.

The above is what happens when people are acting in good faith. Note that the GPL imposes upon you the obligation to provide source code when you distribute. Whether you're using 3(a), 3(b), or 3(c), 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 we seek to work with you collaboratively to fix the problem.

My company was distributing BusyBox binary without the source. We are contacted by your lawyers. Are we in trouble?

Yes, but it is not too bad yet. Stop being disorganized and fix your licensing situation before it gets really nasty. As 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 and Conservancy if you want to keep it private. We will expand this document to cover them.

However, you really cannot afford to be careless about complying with the license anymore.

Some companies ignore the polite requests entirely, maybe hoping that if they ignore us long enough we'll go away. Those are the ones that Conservancy sends impolite requests to, asking for far more than the original request did back when they were being nice.

For starters, if the Conservancy has to actually open an enforcement action to get their attention, the demands will increase. Conservancy will usually require the company appoint an “open source compliance officer” and deliver quarterly reports. And require contact to the old customers who received the product without source and let them know where the source is.

Some 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, and they don't include “the scripts used to control compilation and installation of the executable”. Then when we approach them for more information, they don't understand what we could possibly want, and panic. Please don't panic; just work with us.

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. If your vendor complied with the license terms but you didn't, you're not off the hook. 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. 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.

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 3(a)) or put the ISO up on the web and mention the URL to it in their product's documentation (clause 3(b)). 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 Conservancy guys about what exactly should go on the CD via <gpl@busybox.net>.)

A Good Example

These days, Linksys is doing a good job at complying with the GPL, they get to be an example of how to do things right. Please take a moment and check out what they do with distributing the firmware for their WRT54G Router. Following their example would be a fine way to ensure that you have also fulfilled your licensing obligations.

Add yourself to the Products page

We (BusyBox developers) would be happy to add the information about your product which uses BusyBox to our Products page. In order to be added there, post a message to the BusyBox mailing list when the product ships. While at it, the following information would cover the GPL licensing questions about the product:

• 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) attach (or give URL to) the .config file you used to build the BusyBox binary.
• E) A link to your website.
• This is the "being nice to the developers" approach, which acts as a sort of free advertising within the developer community.

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

Developer's note: GPL versions

Version 2 of the GPL is the only version of the GPL which current versions of BusyBox may be distributed under. New code added to the tree is usually licensed GPL version 2, and the project's license is GPL version 2.

If you are a developer and you want to use a small part of BusyBox source code in your project, please check both the header comments and git logs of the source file(s) you are taking code from. Even though BusyBox code, as a whole, can only be used under GPL version 2, some individual files may have more permissive licenses: "GPL version 2 or later" — meaning that you can also reuse the code from this source file for a project which is distributed under GPLv3, and "Public domain" - the code in these files have no licensing restrictions whatsoever.

Historical details:

Older versions of BusyBox (versions 1.2.2 and earlier, up through about svn 16112) included variants of the recommended "GPL version 2 or (at your option) later versions" boilerplate permission grant. Ancient versions of BusyBox (before svn 49) did not specify any version at all, and section 9 of GPLv2 (the most recent version at that time) says those old versions may be redistributed under any version of GPL (including the obsolete V1). This was conceptually similar to a dual license, except that the different licenses were different versions of the GPL.

However, BusyBox has apparently always contained chunks of code that were licensed under GPL version 2 only. Examples include applets written by Linus Torvalds (util-linux/mkfs_minix.c and util_linux/mkswap.c) which stated they "may be redistributed as per the Linux copyright" (which Linus clarified in the 2.4.0-pre8 release announcement in 2000 was GPLv2 only), and Linux kernel code copied into libbb/loop.c (after Linus's announcement). There are probably more, because all we used to check was that the code was GPL, not which version. (Before the GPLv3 draft proceedings in 2006, it was a purely theoretical issue that didn't come up much.)

To summarize: every version of BusyBox may be distributed under the terms of GPL version 2. New versions (after 1.2.2), as a whole, may only be distributed under GPLv2, not under other versions of the GPL. Older versions of BusyBox might (or might not) be distributable under other versions of the GPL. If you want to use a GPL version other than 2, you should start with one of the old versions such as release 1.2.2 or svn 16112, and do your own homework to identify and remove any code that can't be licensed under the GPL version you want to use. New development is all GPLv2.