Toybox reaches version 0.5

Rob Landley recently released version 0.5 of Toybox, his minimalist Linux command-line utility tool. Toybox is frequently described as a "BusyBox replacement," and its history places it in the middle of a number of ongoing, often contentious debates—from GPL-versus-BSD license arguments to disputes between Linux kernel developers and the Free Software Foundation (FSF). Despite such controversies, the project has continued to soldier on, with this new release implementing multiple new commands and other improvements.

New toys

Toybox, like BusyBox and other similar efforts, is an attempt to reimplement the core functionality of basic command-line Unix programs in a single executable. Filesystem and file-management tools like grep, tar, and mount are the most common examples, but the included tools frequently incorporate user-space process management, network utilities, and text manipulation as well. Not every option of the original programs may be implemented; the goal is to provide those functions necessary for general-purpose maintenance and administrative tasks (especially those features expected by utility scripts) in a compact form suitable for embedded systems.

Landley started Toybox in 2006 under the GPLv2 license, but development tapered off. He relaunched the project in late 2011 under a two-clause BSD license, with the stated goal of making Toybox a replacement for Android's Toolbox multi-function utility. A steady series of releases has continued over the subsequent years, with Toybox adding support for more and more basic CLI tools. In mid-2013, Toybox releases started separating commands into two categories: fully supported and pending. Users could configure support for pending commands at build time if they wished to get a taste of up-and-coming (if perhaps less stable) new features.

The 0.5 release includes 150 supported commands, with another 59 in the pending category. New in this release are factor, find, install, and mount; in addition, the blockdev, inotifyd, and lspci commands graduated from pending to supported status. Quite a few additions were also made to the pending category, including several more-or-less standard programs like fsck, plus some more unusual offerings like mix, which adjusts sound volume through the Open Sound System (OSS) API.

There are also some changes in the build system incorporated in the new release. Builds now automatically take advantage of multi-processor systems, and there is broader support for the option to build commands as standalone binary executables. Not every supported command can be built standalone, however: chown, egrep, fgrep, fstype, halt, mv, nc, poweroff, unix2dos, and whoami are known not to work.

It is also interesting to measure Toybox's status against the utilities it seeks to replace. While BusyBox primarily focuses on implementing the GNU utilities, Toybox actively tracks its progress against several different command collections: the POSIX 2008 specification, the Linux Standard Base, and (as mentioned earlier) Android's Toolbox. There are still quite a few to-do list entries under the Toolbox category (around 30 at the moment), but that number can be misleading if taken out of context. Toolbox, after all, also implements a large number of features also addressed in POSIX and other collections.

Still, it does seem like those looking for a drop-in Toolbox replacement will have a bit more waiting ahead of them. One of the stated goals of the project is to reimplement Toolbox's functionality, but in a manner that avoids duplication of effort and integrates better with the other utilities.

As one would expect, the new release also incorporates a number of important bugfixes and improves on the included test suite.

Getting busy

Naturally, though, regardless of the program's feature set, for quite a few people the principal distinction of Toybox remains its license. Prior to starting Toybox, Landley was the BusyBox maintainer; he departed in 2006 with a public expression of his frustration with (among other things) the fact that BusyBox was frequently the focus of GPL enforcement actions—particularly in the embedded-product space. Landley was a plaintiff in several of the early actions, though, which may have contributed to others' negative reaction to the news that he no longer supported more recent enforcement actions.

Toybox's initial license was the GPLv2—which, of course, would likely have had the same effect in attracting enforcement actions as BusyBox if used in an embedded product. But the 2011 relaunch changed the equation; if Toybox was able to serve as a BSD-licensed drop-in replacement for BusyBox, then a manufacturer might adopt it in hopes of avoiding a GPL enforcement action. In 2012, Sony developer Tim Bird proposed just that, calling for the creation of a permissively licensed BusyBox replacement on the eLinux wiki, with Toybox as the recommended starting point.

Bird's proposal drew harsh criticism from (among others) Matthew Garrett, who called for kernel developers interested in GPL enforcement of the kernel itself to get in touch with the Software Freedom Conservancy (SFC) and offer their assistance. In the ensuing discussion, Garrett clarified this position somewhat. His argument was that BusyBox infringement suits were primarily used as an means to obtaining full GPL compliance from projects that were also violating the Linux kernel's licensing.

Thus, he said, a BusyBox replacement was of interest primarily to embedded device makers who do not wish to comply with the GPL's requirements on kernel code. These manufacturers' additions to BusyBox were minimal at best, but by skirting GPL compliance on the kernel, they were keeping important hardware-enablement information from the community.

And, indeed, it was precisely this chain of recurring events that bothered Landley so much as BusyBox maintainer. In his view, the SFC, FSF, and others who used BusyBox compliance as a means to enforce GPL compliance of non-BusyBox code were overstepping their authority.

A brief read-through of the comments on Garrett's blog post or of the discussion thread on our own news item will probably make it clear that neither side of this debate finds much common ground with the other, and is not likely to change positions any time soon. Thus, for the foreseeable future, Toybox and BusyBox seem likely to exist as competitors in the marketplace.

Landley's goal of replacing Android's Toolbox is a difficult one to handicap, but there are certainly other embedded Linux projects keen on adopting Toybox. As recently as October 1, for example, Intel's Xavier Roche expressed "deep interest" in using Toybox in Tizen. Notably, Roche's message did not cite the licensing difference as the reason for his interest in Toybox—but it is clearly a selling point in many quarters.