is a set of command-line
utilities developed with the goal of keeping its size as small as
possible. To that end, all unnecessary options and code are ruthlessly cut
out, and the entire command set is implemented by a single, multipurpose
executable. BusyBox is found in a number of embedded environments; chances
are it is running on your wireless router, for example. The command set
has reached a level of capability that the new BusyBox maintainer believes
that it is almost ready for use on
Yes, BusyBox has a new maintainer, as the result of another disagreement
over the draft revision of the GNU General Public License (GPLv3). This
episode is worth looking at, as it may be an omen of
disagreements that could come up in other projects as the GPLv3 process moves
Some projects reach 1.0 more quickly than others. BusyBox is one of the
others. It was started by Bruce Perens in 1995, and became part of the
Debian boot process. Bruce moved on to other interests shortly afterward,
leaving BusyBox in an idle state, where it remained for a few years. Under
the maintainership of Erik Andersen, BusyBox came back to life, and the
much-delayed 1.0 release happened almost exactly two years ago - in
October, 2004. Version numbers can be deceiving, however, as BusyBox had
been in production use for many years prior to 1.0.
In recent years, the BusyBox maintainer has been Rob Landley, an energetic
individual (at least, when sufficient caffeine is at hand) who has done a
lot to push the project forward. So the task of thinking about how BusyBox
and GPLv3 relate fell to him. Since BusyBox can be found in so many
embedded systems, it finds itself at the core of the GPLv3 anti-DRM
debate. A GPLv3-licensed BusyBox would create obvious difficulties for any
vendor wishing to incorporate it into a locked-down product.
BusyBox is not a GNU project, so the Free Software Foundation does not hold
its copyrights; instead, those copyrights are retained by the original
authors. As Rob looked over the code, he found many contributions with the
usual "or any later version" language which would allow a change to GPLv3.
Others, however, had the explicit "version 2 only" language. Some,
contributed by one Linus Torvalds, state that they "may be redistributed as
per the Linux copyright." Some other contributions carry a BSD license -
originally with the GPL-incompatible advertising clause. It was quite the
mixture of licenses.
Rob was especially concerned about the version-2-only licensing, since that
would obviously get in the way of any switch to GPLv3. And, in any case,
he was ambivalent at best about GPLv3; it seems that the BusyBox project
had developed a plan to dual-license its code under both GPL versions,
allowing it to continue to be used under either license. So his question with regard to the v2-only code was:
Anybody feel like auditing all those to make sure it was
unintentional and check to make sure that nobody that's contributed
to any of those files since is unwilling to also have their code
under v3, or should we just admit that the BusyBox license is GPLv2
only? (In which case we can take the hotplug patch...)
That led to the beginning of a long and unpleasant discussion about whether
BusyBox should move to GPLv3 or not - and it quickly became clear that Rob had no interest in such
a move. His reasoning is worth a read, as it includes a couple of new
concerns - including the fact that a dual-licensed GPLv2/GPLv3 code base
would be unable to accept contributions licensed under a single version
(either version) of the license.
Enter Bruce Perens, last seen in in BusyBox
circles about ten years ago. Bruce clearly feels that he still has some
rights over the code:
When I created Busybox, the policy was that it could be distributed
under the GPL. There was no restriction to prevent future versions
of the GPL. Over time, my work has been submerged in that of other
authors. But IMO it would be respectful of the original author to
continue to use those license terms.
What followed was a long discussion on whether DRM differs from simply
putting the code into ROM, whether the FSF is more worthy of trust than
IBM, whether a move to a GPLv2-only license was possible, how much of
Bruce's original contribution remains, and so on. Interested parties are
encouraged to go into the BusyBox list archives and spend considerable time
plowing through the postings; they do not always show the free software
community at its best. The real outcomes, however, are this:
- BusyBox will be GPLv2 only starting
with the next release. It is generally accepted that stripping out
the "or any later version" is legally defensible, and that the merging
of other GPLv2-only code will force that issue in any case.
- Bruce Perens wants his contributions to
keep the "any later version" language, and has requested ("and
required") that the
copyright notices reflect this wish. Accommodating a contributor's
wishes in this regard is normally done, but Rob Landley has refused to
go along; his reason, in the end,
boils down to "I'm mad at Bruce and don't want to."
To show that he meant it, Rob launched a project to find and
excise any remaining contributions to BusyBox from Bruce. In response,
Bruce has announced that he will be
creating a fork of BusyBox which will be more responsive to his wishes.
All of that may be moot, now that Rob has resigned from the project and handed the
maintainership over to Denis Vlasenko - who plans to pursue moving Busybox
onto the desktop.
All of this could be dismissed as yet another silly community soap opera -
and there is truth to that view. But this is a soap opera which is likely
to be rerun a number of times over the coming months. Any project which
(1) uses the GPL, and (2) allows contributors to retain their
copyrights is likely to have a discussion like this one. Avoiding such
discussions is, perhaps, why the FSF is so insistent on obtaining
copyrights for the projects it manages.
Version 2 of the GPL has brought together vast numbers of developers into a
single agreement on the terms under which their code could be distributed.
It may never have been possible to update the GPL without fracturing that
agreement; it seems increasingly clear that the GPLv3 draft has, so far,
failed in that regard. There are enough developers who see it as not being
"similar in spirit" to GPLv2 to ensure that the new license, in its current
form, will not be a simple drop-in replacement for its predecessor.
Regardless of how one feels about the new terms in the GPLv3 draft, it is
hard to see the potential for this sort of discord in the community as a
(Thanks to the several LWN readers who brought this to our attention).
to post comments)