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!
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!!
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!
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
If the company isn't complying with the license terms then then they don't _have_ the right to use the software.
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?
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!!
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.
He may be thinking of this clause of the GPLv2:
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.
"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.
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.
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!".
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
And NetBSD provides a "Busybox" replacement single executable multi-tool program?
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?
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).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.