Difference between revisions of "Busybox replacement project"

From eLinux.org
Jump to: navigation, search
(FAQ about this project)
(FAQ about this project)
Line 18: Line 18:
  
 
* Q. Isn't this a lot of work to avoid a relatively small effort (publishing the source to busybox)?
 
* Q. Isn't this a lot of work to avoid a relatively small effort (publishing the source to busybox)?
* A. It will 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 should some problem occur with busybox compliance.
+
* 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 Linux kernel?
 
* Q. Is this being done to prevent the SFC from asking for the source to the Linux kernel?

Revision as of 14:12, 31 January 2012

Work on Tiny Linux Kernel

Summary
Write a non-GPL replacement for Busybox
Proposer
Tim Bird

Description

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.

FAQ about this project

  • 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 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.
  • 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 Linux kernel?
  • 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, the main reason for 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 damages 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 choose to 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.

Supported Commands

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

Scope

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

Project Management

Information about the status and management of this project are at: Busybox replacement

Contractor Candidates

Rob Landley

Related work

Comments