Looking for BusyBox equivalent

I am developing an embedded linux system, and I would like a "Swiss-Army-Knife" tools utility like BusyBox in place. I am using Wind River Linux 4.0, and to protect our business, some of our source codes won't be open, at least for now. However, the developers of BusyBox is sueing around to collect money, so I am looking for an equivalent. Any information will be highly appreciated. Thank you for sharing!

On 2010-11-23, like2learn <user@compgroups.net/> wrote:

> I am developing an embedded linux system, and I would like a
> "Swiss-Army-Knife" tools utility like BusyBox in place. I am using
> Wind River Linux 4.0, and to protect our business, some of our source
> codes won't be open, at least for now. However, the developers of
> BusyBox is sueing around to collect money, so I am looking for an
> equivalent.

I don't understand why busybox doesn't suit your needs.

Whether or not _your_ source code is open or not has nothing to do
with busybox. What you're not allowed to do is ship busybox in your
product and then not provide sources for _busybox_.

-- 
Grant Edwards               grant.b.edwards        Yow! Remember, in 2039,
                                  at               MOUSSE & PASTA will
                              gmail.com            be available ONLY by
                                                   prescription!!

On 23/11/10 20:39, Grant Edwards wrote:
> On 2010-11-23, like2learn<user@compgroups.net/>  wrote:
>
>> I am developing an embedded linux system, and I would like a
>> "Swiss-Army-Knife" tools utility like BusyBox in place. I am using
>> Wind River Linux 4.0, and to protect our business, some of our source
>> codes won't be open, at least for now. However, the developers of
>> BusyBox is sueing around to collect money, so I am looking for an
>> equivalent.
>
> I don't understand why busybox doesn't suit your needs.
>
> Whether or not _your_ source code is open or not has nothing to do
> with busybox. What you're not allowed to do is ship busybox in your
> product and then not provide sources for _busybox_.
>

Also note that the same applies to the Linux kernel, and most of the 
utilities, libraries, bootloaders and other pieces of software you'll 
have on the system.

The GPL is quite simple and clear in this manner - if you distribute the 
binaries along with your product, you also need to make the source code 
available, including the source of any changes you have made.

So if you want to make your own changes to BusyBox, you have to provide 
those changes.

Your own applications on the system can use whatever license you want 
(unless you complicate things by linking to GPL'ed libraries or 
otherwise mixing in code with other licenses).  The license for BusyBox 
is irrelevant for /your/ applications.

And note that the developer (singular, I believe) of BusyBox is not 
"suing around to collect money" - he is taking legal action to force 
systems distributors to follow the license terms of the software they 
are getting for free.  He has spent a great deal of time and effort 
developing BusyBox.  He is very happy for people and companies to make 
money selling products that use his code.  All he asks in return is that 
companies respect his wishes and his choice of license, and make it 
clear to end users that the source code is available.  It's a small 
thing to ask, yet some companies think that "zero cost" means they can 
do what they like with the code.  He therefore sued a couple of 
companies in court to enforce the license.  The settlements were 
undisclosed, but the cases were never about earning money.


To my knowledge, there is nothing else like BusyBox.  If you only need a 
few utilities, you could use the standard gnu tools - they are much more 
powerful than the BusyBox versions, but much larger.  And they come with 
the same license and the same obligations.  I'd recommend you simply do 
the same thing here as you will no doubt do with the Linux kernel, and 
with any software you have licensed from Wind River - use the software 
and follow the obligations of the license.

Sorry about the comments about "the developers of BusyBox is sueing around to collect money". I checked with the person who told me and other information sources, and it simply was not true. So yes, they are taking legal action to force systems distributors to follow the license terms of the software they are getting for free.

I got one more question. If one company is currently at lawsuit with the Software Freedom Law Center (SFLC) about the BusyBox copyright, is it possible for the company to lose the rights to use BusyBox as stated at GPLv2? In other word, does SFLC has the right to forfeit the rights, which they have promised to the public as GPLv2, from a specific customer due to its past bad behaviors?
I have a potential customer who once violates the rights of BusyBox, and was in lawsuit. Rumors said they were forfeited the rights to use BusyBox, even for now they actually followed GPLv2. Is it possible?
Thanks!

On 2010-11-23, like2learn <user@compgroups.net/> wrote:

> Sorry about the comments about "the developers of BusyBox is sueing
> around to collect money". I checked with the person who told me and
> other information sources, and it simply was not true. So yes, they
> are taking legal action to force systems distributors to follow the
> license terms of the software they are getting for free.

And you've got to be pretty obtuse to actually get sued.

It's not at all difficult to comply with the GPL license: in my
experinece nobody ever really wants you to mail them a CD for
"reasonable cost of duplication".  In practice, putting the sources on
an FTP or 'web server is enough to make everybody happy.  If you're
using unmodified sources you can probably slide by with just linking
to the upstream download site (though I don't think that's quite
enough if somebody wants to get technical about it).

As always, YMMV.

-- 
Grant Edwards               grant.b.edwards        Yow! FEELINGS are cascading
                                  at               over me!!!
                              gmail.com            

On 2010-11-23, Like2Learn <user@compgroups.net/> wrote:

> I got one more question. If one company is currently at lawsuit with
> the Software Freedom Law Center (SFLC) about the BusyBox copyright,
> is it possible for the company to lose the rights to use BusyBox as
> stated at GPLv2?

If the company isn't complying with the license terms then then they
don't _have_ the right to use the software.

> In other word, does SFLC has the right to forfeit the rights, which
> they have promised to the public as GPLv2, from a specific customer
> due to its past bad behaviors?

I don't think "forfeit" is the word you wanted.  When you "forfiet"
something, you are giving up something (property, money, rights) that
you previosly had.

I think what you mean is "revoke" -- can the SFLC prohibit somebody
from, in the future, using GPL'ed software in an otherwise compliant
manner?

> I have a potential customer who once violates the rights of BusyBox,
> and was in lawsuit. Rumors said they were forfeited the rights to use
> BusyBox, even for now they actually followed GPLv2. Is it possible?

No, I don't think so.  Once a piece of software has been released
under GPLv2, I don't think it's possible to retroactively revoke the
rights of certain named people who are complying with the license
terms.

You (the holder of the copyright) could, in theory, release _future_
versions under a license that forbids use by certain people.  That
license would, however, not be the GPLv2.

But, if you have specific legal questions like that, you probably
ought to ask a real lawyer.

-- 
Grant Edwards               grant.b.edwards        Yow! Hello.  Just walk
                                  at               along and try NOT to think
                              gmail.com            about your INTESTINES being
                                                   almost FORTY YARDS LONG!!

On Tue, 23 Nov 2010 21:49:06 +0000, Grant Edwards wrote:

> If you're using unmodified sources you
> can probably slide by with just linking to the upstream download site
> (though I don't think that's quite enough if somebody wants to get
> technical about it).

It isn't enough to satisfy the terms of the licence, but it does make it
unlikely that anyone will ever actually ask you to send them a CD.

The main reason why linking to the upstream site isn't considered
sufficient is that you could end up with a huge multinational distributing
a million copies of the binary while pointing users to the author's
personal web space for the source code, which wouldn't really be fair to
the author.

On Tue, 23 Nov 2010 22:00:46 +0000, Grant Edwards wrote:

> No, I don't think so.  Once a piece of software has been released under
> GPLv2, I don't think it's possible to retroactively revoke the rights of
> certain named people who are complying with the license terms.

He may be thinking of this clause of the GPLv2:

  4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License.  Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.

If this actually applies to his customer, I'd suggest consulting a lawyer.

This isn't the kind of situation where a lay person could form an educated
opinion based upon prior judgements and a working knowledge of contract
law. In fact, the answer may not even be clear to a lawyer.

On Nov 23, 3:08=A0pm, David Brown
<david.br...@removethisbit.hesbynett.no> wrote:

> To my knowledge, there is nothing else like BusyBox. =A0

"toolbox" which ships with Android, is a lot like busybox, only more
limited, and Apache licensed, specifically to avoid GPL code in
userspace.  Presumably it could be built for other systems as well.
There's also the 'bionic' C library to go with it.

As others have mentioned, I'm not entirely convinced of the benefits
of non-GPL userspace on top of a GPL kernel though.  Once you have
anything GPL in your product, your organization has to have procedures
in place for creating, offering, (and at least if someone asks)
distributing source releases.  Doing it for busybox in addition to the
kernel, C libraries, and other common userspace bits doesn't seem like
much extra work.

Not surprisingly, a lot of the community android builds include a
version of busybox built to provide the tools which toolbox lacks.