Busybox seems to be sort stumbling block for vendors that want little embedded linux. There are even lawsuits regarding Busybox.

Are there more liberally licensed (BSD, MIT or at least LGPL) analogue of Busybox for developers of closed systems?

closed as off-topic by bwDraco, random Jan 23 '15 at 3:37

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking product, service, or learning material recommendations are off-topic because they become outdated quickly and attract opinion-based answers. Instead, describe your situation and the specific problem you're trying to solve. Share your research. Here are a few suggestions on how to properly ask this type of question." – bwDraco, random
If this question can be reworded to fit the rules in the help center, please edit the question.

  • (unsure if it does belong to here, to SE or to programmers.se.com) – Vi. Jul 22 '11 at 15:52
  • @Vi This being about how to use computer software, and not how to program computer software, fits perfectly on SuperUser :) – Darth Android Jul 22 '11 at 15:54
  • 6
    Busybox isn't a problem unless you want to (1) modify it and (2) not give the changes back. If busybox meets your needs right now (or if you are willing to see any changes put back into the commons), using it doesn't expose you to any risk at all. The lawsuits involved entities in breach of the license. – dmckee Jul 22 '11 at 16:07
  • @dmckee, But certain customers "Linux? Busybox? GPL?! No... No! Remove it!", but at the same time are satisfied if it is LGPL. I heart that GPL states that the in the end the court decides if it is "same program" (even if separate processes etc.) or "separate programs". They already know that kernel vs program is OK and using {uC,g}libc is OK, and also heart about Busybox lawsuits. – Vi. Jul 22 '11 at 16:48

Disclaimer: I am not a lawyer. This answer really needs legal expertise, I've given my best effort to present the information, but it's not legal advice. Get a lawyer who understands software licensing and IP issues.

TL;DR version. The risk to closed systems is in the kernel, not busybox, because the kernel reveals hardware interfaces. Busybox reveals almost nothing because it tends to be used in a stock, or almost stock form.

They have the same stumbling blocks with the kernel itself, so it shouldn't be an issue. GPL isn't hard to comply with - if you distribute binaries, you have to distribute corresponding source, or offer to do the same, and make good on that offer. You don't however have to distribute all your work - typically, you won't make changes to busybox itself, so it's as simple as putting up a copy of the tarball you built busybox from on your site.

The Linux kernel is much more of an issue, since that's where your drivers go - the act of linking closed drivers to it theoretically either makes those drivers covered by GPL (if you own the copyright), or makes you completely in violation of GPL and unable to distribute your work legally if you don't. That means that you are probably going to have to give up key hardware details with any embedded linux implementation.

The rest of your "secret sauce" should be safe - the standard userspace programs are a non-issue, they end up being basically the same everywhere. Your custom applications to make your product work end up being entirely your creation, linked against libraries that permit linking closed source code.

  • The main issue is inadequate customers. We know that it is OK in particular use case (just use stock kernel and stock busybox and only proprietary bash scripts and/or some C programs), but "Busybox's => GPL => FAIL => Lawsuit" and it does not get confirmed. – Vi. Jul 22 '11 at 17:01
  • 2
    Still boils down to understanding the license and its implications properly. With busybox, it's important to know that whatever modifications you make to busybox itself are going to have to be redistributed. That's not an issue, because you shouldn't be hard-coding your proprietary software into busybox in the first place. At most, you have whatever code changes are needed to compile, and whatever code changes are needed to fix any bugs you find (which you should share anyway to be a good corporate citizen - it shouldn't hurt you to do so and it keeps software you depend on improving.) – Stephanie Jul 22 '11 at 22:33
  • Learned a little bit from @deadhead's answer below which warrants some clarification. The GPL's so called "death-penalty" is sometimes invoked in the case of license violations with respect to other GPL-covered works, such as the Linux kernel in order to compel GPL compliance. This still shouldn't be an issue for Busybox itself, but if there are other GPL violations in your product, like linking proprietary drivers with the Linux kernel (which is a violation of the kernel's license), you risk losing the right to use Busybox as well. – Stephanie Jun 16 '12 at 9:34

I think you'll find very interesting the work of an ex busybox devel :





BeastieBox is an attempt to bring a Busybox-like tool to the BSD world. Much of its work comes from NetBSD.

Not the answer you're looking for? Browse other questions tagged or ask your own question.