Looking for BusyBox equivalent

On 23/11/2010 23:18, Nobody wrote:
> 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 depends on the kind of project.  If you expect that people will 
actually ask for the source code, then you should put up a web server 
hosting the software yourself.  You can also take advantage of the open 
source development community - put forums, wikis, etc., on the server 
and maybe someone out there will help improve your product for you.  On 
the other hand, if your product "just works", and it's unrealistic to 
expect people to want the source, it's not worth the effort putting up 
servers.  You also have to decide if you want to fully embrace open 
source development and encourage a development community around your 
product, or just follow the minimum legal requirements of the 
license(s), or somewhere in between.

You always need to provide the written offer of sending the files, if 
you don't distribute the source with the product.  It's perhaps the 
least user-friendly method of providing the source, but it's the letter 
of the license.

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

The other big reason for not linking to upstream sites is to avoid 
people mistaking the upstream site, author, forums, mailing lists, etc., 
as being directly involved in the project "Dear Mr. BusyBox author, the 
light on my woozit keeps blinking.  The woozit website says you wrote 
the software.  I demand that you fix the blinking light immediately!".

On 23/11/2010 22:46, Like2Learn 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? 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!
>
>

Others have suggested contacting a lawyer for a real legal answer.  But 
I'd first suggest emailing the SFLC - I think they are likely to give 
you a simple non-legal non-lawyer answer to a simple question.  Their 
main aim is to have people follow the spirit of the GPL (and other FOSS 
licenses) - they only resort to the letter of the law when that fails.

My personal understanding of the situation is that if you don't follow 
the terms of the GPL (or other relevant license - this applies to /all/ 
licenses, even if it is not explicitly stated), then you don't have the 
rights offered by the license.  So if you don't provide the source of 
the GPL'ed software, you are not allowed to distribute it.  If you /do/ 
provide the source, then you /are/ allowed to distribute it.  I believe 
it's that simple (but IANAL), and is in fact somewhat independent of the 
law suit.

By that reading, the SFLC is not revoking anyone's rights - the company 
in question never had the rights to distribute the software, since they 
did not follow the terms of the GPL.

It is also not the SFLC that enforces the GPL - the SFLC, on behalf of 
the copyright owner, is asking the courts to enforce the license.

Am 23.11.2010 22:46, schrieb Like2Learn:

Well, I'm not a lawyer, and it depends on the jurisdiction you are 
located in and where you are going to sell.

The best way to avoid this is simply not to use GPL software at all. The 
BSD license is much more suited to your needs, and NetBSD runs on 26? 
30? architectures. BSD as an embedded system is less known, but the 
source code quality seems to be of much higher quality, especially with 
OpenBSD, which is one of the must secure Unixes.

-- 
Mit freundlichen Gr��en

Frank-Christian Kr�gel

On 2010-11-24, Frank-Christian Kr?gel <dontmailme@news.invalid> wrote:

> Well, I'm not a lawyer, and it depends on the jurisdiction you are 
> located in and where you are going to sell.
>
> The best way to avoid this is simply not to use GPL software at all.
> The BSD license is much more suited to your needs, and NetBSD runs on
> 26?  30? architectures.

And NetBSD provides a "Busybox" replacement single executable
multi-tool program?

> BSD as an embedded system is less known, but
> the source code quality seems to be of much higher quality,
> especially with OpenBSD, which is one of the must secure Unixes.

He wasn't asking for a Unix OS replacement.  He was asking for a
Busybox replacement.

-- 
Grant Edwards               grant.b.edwards        Yow! My mind is a potato
                                  at               field ...
                              gmail.com            

What I heard from the customer: under clause 4 of the GPLv2, SFLC revoked their license to use BusyBox, which means they won't be able to distribute it for any case, no matter they decide to open the source codes or not. Is it fair? 

On Nov 24, 6:18=A0pm, like2learn <u...@compgroups.net/> wrote:
> What I heard from the customer: under clause 4 of the GPLv2, SFLC revoked=
 their license to use BusyBox, which means they won't be able to distribute=
 it for any case, no matter they decide to open the source codes or not. Is=
 it fair?

I think you can only ask "is it fair" if you somehow start from the
flawed premise that the code is public domain or that the copyright
owner is obligated to license something to you.

With few exceptions they aren't - if they chose to offer a license to
most people out of community mindedness, and your customer in the past
declined that license and instead simply pirated their software...
then yeah, it sounds fair for them to decide that they won't offer
that license to your customer.

That said, it might be worthwhile for your customer to approach the
copyright holders and ask if there is something they can do in the way
of "community service" such as contributing to a development or
advocacy fund and "responsiveness" such as appointing a compliance /
contact officer, to rehabilitate their reputation to the point where
they'd be considered "good guys" perhaps worth licensing to.

Or they can use some other solution - original, from a proprietary
vendor, or with a BSD or Apache style license (such as Android's
toolbox).