Busybox replacement project
Write a non-GPL replacement for Busybox
Busybox is a widely used program which implements several Linux command line
utilities in a single, multi-tool binary. It is provided under the GPL license.
Due to its utility and ubiquity, it has been used in a very large number of embedded
devices. This includes use by companies who are not as diligent about their GPL
commitments as they should be.
Busybox is arguably the most litigated piece of GPL software in the world. Unfortunately,
it is unclear what the remedy should be when a GPL violation occurs with busybox.
Litigants have sometimes requested remedies outside the scope of busybox itself,
such as review authority over unrelated products, or right of refusal over non-busybox
modules. This causes concern among chip vendors and suppliers.
The purpose of this project is to produce a program that is as capable and useful
as busybox for a large majority of embedded Linux projects, such that busybox is
easy to replace in existing products and can be supplanted as the default choice
for a multi-tool program in most new projects.
It is expected that the first major milestone release (version 1.0) of the busybox
replacement program will include the following commands: [See the project page.]
The scope of the project is dependent on the target use cases that are envisioned
for the replacement tool. Busybox is currently used in a very large number of places,
and it is impractical to replace it's full functionality in a short time. However,
busybox as it currently stands includes very many non-essential programs and features.
The overall goal would be to provide essential busybox functionality (e.g. with
that contained in busybox version 1.0).
One additional area of commands which is outside the traditional busybox coverage
area, is Android tools provided by toolbox. Toolbox is a non-GPL multi-tool program
provided as part of the Android Open Source Project, and used in Android devices.
It is limited in functionality, however, compared to busybox, and so many developers
install busybox in their Android devices to supplement the command set. Google has
a goal of reducing the amount of GPL software in user-space for Android devices.
A busybox replacement that implemented the toolbox commands could useful to avoid
having Android developer adopt busybox by default. But more importantly, a replacement
that just focused on the weaknesses of toolbox could serve this tool supplementation
role that busybox fills, with very little effort.
It is expected that it will require about 6 months of part-time developer work
to achieve the first major milestone for the project.
This project will very likely start with a base of non-GPL software which is
already available, and has been scrutinized to be free from GPL legal encumbrances,
from the Toybox project
Information about the status and management of this project are at:Busybox replacement
[ http://www.elinux.org/Busybox_replacement ]
-  Busybox - http://busybox.net/
-  Toybox - http://www.landley.net/toybox/about.html
People interested in supporting this project can do one of several things:
- If you are an embedded Linux developer, you can start working on the ToyBox
code, adding commands or features to it.
- If you are a company interested in sponsoring or donating engineering resources
to this project, please contact Tim Bird at tim dot bird at am dot sony dot
This project is still Under Construction.
This project is in the proposal and fact-gathering stage, and is still under
construction. Please be advised that multiple aspects of this project are still
being defined and under consideration. We have not 100% committed to using ToyBox
as the replacement, although this seems very likely at this point. When the proposal
is launched, it will likely be announced with more firm details about the roadmap,
governance, license and schedule.
- Q. Simply providing the source, as the licence requires, would avoid litigation.
Isn't that easier than re-writing busybox?
- A. It is true that providing the source would avoid litigation. In most
cases, this *is* easier than re-writing busybox. However, in some cases - especially
when dealing with a naive or defunct supplier, it can be difficult or impossible
to find the 'correct' source for busybox. It would be better not to get into
a situation where the lack of correct source from a 3rd party supplier resulted
in extreme remedies being required. This project aims to make a useful alternative
to busybox which completely eliminates any possibility of infringement, wrongdoing,
and risk of litigation for this particular piece of software.
- Q. Isn't this a lot of work to avoid a relatively small effort (publishing
the source to busybox)?
- A. It will be some work, but it will likely only have to be done once, and
the burden and/or cost of the work can be distributed throughout the industry.
The cost to a single company to support this project is very small in comparison
to the legal liability and costs should some problem occur with busybox compliance.
- Q. Is this being done to prevent the SFC from asking for the source to the
- A. No, although it would have that effect. As part of their request to remedy
a busybox GPL violation, the SFC does ask for source code unrelated to busybox.
Personally, I believe this is improper. However, my main reason for proposing
this project is to avoid having the SFC gain review authority over unrelated
products produced by a company. The larger the set of Linux-based products that
are produced by a company, the greater exposure there is for a possible mistake,
and the greater potential costs that would incur in the event of litigation
- Q. Wouldn't it be morally better to help companies fulfill their GPL obligations,
than to have them avoid GPL software?
- A. There are multiple people who provide consulting services to help people
fulfill their GPL obligations. This is a good thing and it should be encouraged.
Helping companies avoid infringing the license of software they use is good.
Also good is providing software for companies that helps them avoid legal entanglements
at all. Arguments beyond this get into BSD vs. GPL license wars, which I don't
think are productive to engage in here.
- Q. Tim Bird, the proposer of this project, works for Sony. Is this a Sony
- A. No. Although Tim is employed by Sony, he spends a portion of his employed
time working on behalf of the embedded industry to improve Linux and encourage
GPL compliance. As of February 2, 2012, Sony has not endorsed or agreed to support
this project. This wiki page is for gathering information and project description
information, to present to various companies to solicit support and resources
for the project.
- Q. Can Tim's creation of this proposal be used to infer anything about Sony's
compliance record, future compliance intent, or other business practices?
- A. Tim has only recently informed his management about this proposal, and
Sony has not yet (as of 2/2/12) agreed to support it. So, "no, not really".
Sony has a good compliance record, and has strong compliance policies in place.
It has never been contacted by the SFC and has no expectation of being contacted
by the SFC about any license violation of GPL software. Tim is doing this as
part of his (paid for by Sony) role in the industry to address issues which
inhibit the adoption of Linux in consumer electronics.
- Q. If it doesn't affect Sony, why are you doing this? How does the busybox
litigation and the remedy terms requested by the SFC inhibit the adoption of
Linux in consumer electronics?
- A. It is not expected to affect Sony directly, because Sony has good compliance
practices. However, any company can make a mistake. There are instances where
this litigation and the terms requested by the SFC have resulted in companies
dropping their embedded Linux projects. It has also caused even compliant companies
to re-evaluate their adoption of Linux. This has a net negative effect (in my
opinion) on the adoption of Linux and ultimate amount of GPL software produced.
Tim (and Sony) view the production of GPL software as a good thing. It does
sound strange that this is the goal when the proposed project exists to replace
a piece of GPL software with a non-GPL piece of software, but the overall desired
affect of this project is to encourage more companies to adopt GPL software
(particularly the Linux kernel), and to comply with the obligations of the GPL
Copyright 2012 http://www.elinux.org/Busybox_replacement_project