people

practices

    Notice: Trying to get property of non-object in /var/www/brownrudnick.com/htdocs/blog/wp-content/themes/bro/header.php on line 192 Warning: Invalid argument supplied for foreach() in /var/www/brownrudnick.com/htdocs/blog/wp-content/themes/bro/header.php on line 192
expand all collapse all
fast finder
Brown Rudnick PROFESSIONALS

News/Resources: Blog

Emerging Technologies BLOG

Is BusyBox Too Dangerous To Use?

Posted on Friday, Feb 3, 2012

BY Edward J. Naughton

Rob Landley thinks so.  One of the principal developers of BusyBox, Landley was a lead plaintiff in some of the enforcement actions brought by the Software Freedom Law Center a few years ago.  He’s now leading up a project, called Toybox, to rewrite BusyBox and release it under a more permissive, non-GPL license.  And for doing that, Landley’s drawn a lot of fire from free software advocates.

I wrote about the BusyBox lawsuits a few months ago.  BusyBox itself is a lightweight set of utilities licensed under GPLv2 that is widely used in embedded Linux devices.  It’s been a vital tool in a GPL enforcement campaign by the Software Freedom Law Center (SFLC) and Software Freedom Conservancy (SFC).

Those enforcement demands and lawsuits generally involved consumer devices such as BluRay/DVD players, DVRs, and wireless routers.  The devices included Busybox, but the manufacturers or distributors of the devices (including Cisco, Verizon, Best Buy, and others) allegedly failed to provide the corresponding source code for Busybox.

Landley and his colleague Erik Andersen, represented by the SFLC/SFC, took the position that the failure to provide source code as required by GPLv2 (a) automatically terminated the licensees’ right to distribute GPLv2 code, and (b) could not be cured simply by providing the corresponding source after the fact, but required the licensees to obtain the express permission of the relevant copyright holders.  The SFLC/SFC and the copyright holders apparently demanded many concessions from the licensees before agreeing to reinstate the license, including the release of source code for a number of proprietary libraries and programs, as well as the right to review all of the code for new products prior to their release to ensure GPL compliance.

Busybox was critical to the SFLC/SFC’s strategy.  First, it was found in many consumer devices. Second, in many cases the companies targeted by the SFLC/SFC had simply manufactured or distributed products that included chips on which the BusyBox code had been embedded.  The targeted companies, therefore, had to obtain the corresponding BusyBox source code from their upstream chip supplier.  As a practical matter, it was generally difficult for these companies to obtain the right version of the code.  Taken together, these factors gave the SFLC/SFC tremendous leverage.

This is exactly why Landley says that “GPLv2 BusyBox is legally speaking one of the most _dangerous_ pieces of software you can ship.”  According to Landley, he initially became involved in the BusyBox lawsuits because he thought that they would improve the software:

when I thought that hooking up with a lawfirm to launch BusyBox license enforcement lawsuits would result in any code added to the BusyBox repository, THAT was naive. Zealots grabbed that and used it to inflict completely unrelated crap like “license compliance officers” sending reports to the Free Software Foundation (which WAS NOT INVOLVED, yet somehow managed to hijack this to further their own agenda).

Landley now believes that the lawsuits were a bad idea:

The BusyBox lawsuits are something I personally started.  They were a bad idea, they have done more harm than good (I have personal, firsthand experience with this), and it’s my responsibility to stop them.

On an engineering note, they never contributed a single line of code to BusyBox.  NOT ONE.  I thought they would, but they didn’t, so I stopped pursuing them.

Instead they were picked up by zealots to pursue a wider agenda that had NOTHING TO DO WITH MAKING BUSYBOX A BETTER PIECE OF SOFTWARE.  You yourself admit that this is what happened, and the idea of STOPPING this is exactly what you are objecting to.

I’m an engineer.  I respond to problems by writing code.

Zealots respond to problems by telling OTHER people what they “should” do, and freaking out when they don’t do it.

Landley explains that he wants to rewrite BusyBox under a non-GPL permissive license to “stop BusyBox from being used as a bludgeon against the world at large.”

The BusyBox license enforcement lawsuits were a HORRIBLE IDEA, I regret having started that ball rolling, I couldn’t stop it.  I can only render it irrelevant with fresh development.

But others, particularly Matt Garrett, have excoriated Landley, because they believe that creating a non-GPL alternative to BusyBox will make it easier for others to violate the GPL:

the reason for writing this replacement isn’t to avoid infringing Busybox’s license, as such, but to avoid Busybox being used as a tool to enforce the license of other GPLed code (primarily the Linux kernel). . . .

The problem of vendors wilfully violating the GPL isn’t one that can be solved by writing code.  People who own the copyright to bodies of BusyBox have chosen to enforce that copyright as part of a larger overall strategy to force vendors to release the source code to other GPLed works that they’re infringing.  They have the right to do that.  You’re choosing to work on a replacement for BusyBox in order to make it easier for people to avoid enforcement actions.  You also have the right to do that.  I think your approach results in us seeing a larger number of wilful GPL violations than would otherwise be the case, but it’s absolutely your choice.

For his part, Landley has little good to say about the SFLC/SFC:

I wrote up fairly extensive guidelines about what I did and did not consider infringement:

http://lists.busybox.net/pipermail/busybox/2008-October/033327.html

I.E. using vanilla unmodified code is not infringing, we just want your IMPROVEMENTS.  I did’nt care about forcing you to mirror source tarballs like the FSF did to Mepis, or exploiting crazy loopholes.  If you honestly haven’t got any code we’d want, there’s nothing in it for us.

The SFLC/SFC didn’t work that way.  They wanted settlement money so they could afford to file the next suit, and they used BusyBox to sue over OTHER software packages which is disingenuous.

So from my point of view, “Is your code vanilla unmodified BusyBox” could be answered “yes”.  From the SFLC’s point of view, the answer had to be accompanied with a $20k check and the right to go through your refrigerator looking for expired mattress tags.

I’m aware that you care deeply about the mattress tags, but you’re being a slimy weasel exploiting other people’s loopholes to get your way, and you’re upset that the loophole is closing.  You find it an INJUSTICE that the loophole may no longer be leverageable for unrelated purposes.

Both Landley and Garrett are passionate advocates for FOSS, but it’s evident that they view the problem from diametrically opposite perspectives.  Garrett sees GPL non-compliance as a serious problem that will be made bigger by the loss of BusyBox as a tool for enforcement.  Landley believes that the BusyBox litigation hurt the adoption of Linux and other GPL’d code.  Landley’s collaborator Tim Bird sums it all up soberly and succinctly:

Matthew correctly points out that the busybox litigators use busybox as a leverage for asking for more than just the busybox source.  I believe they do not have this right (either legally or morally).  It is this aspect of the situation that some companies find undesireable.  It represents a business risk that is beyond the value that busybox provides.

The intent of this project is not to shield GPL violators.  It is intended to prevent violation in the first place.  I view the need for this project with some sadness, as I myself have worked hard for many years to encourage GPL compliance.  I will continue to do so.

I think that reducing the legal uncertainty involved with using GPL software increases the likelihood of adoption and compliance.  This is in stark contrast to the direction that the SFC has taken with their re-compliance requirements.

What Matthew argues here is that the ends justify the means, in terms of GPL enforcement. I respectfully disagree.

Landley and Bird have framed the problem well, but they can’t solve it simply by rewriting BusyBox.  In his response to Landley, Bradley Kuhn declares that “I’m here to enforce the GPL,” and Garrett himself urges Linux kernel copyright holders to step into the breach left by Landley.  “The mushroom cloud of legal uncertainty” surrounding the GPL and the Linux kernel will continue. Blogs