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." – DragonLord, random

(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 AndroidJul 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.
–
dmckeeJul 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

3 Answers
3

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.)
–
StephanieJul 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.
–
StephanieJun 16 '12 at 9:34