The debate over enforcement of the GPL took an interesting turn this week, after one developer’s call for more projects to begin enforcement proceedings against alleged GPL violators of the Linux kernel.
Red Hat kernel developer Matthew Garrett, who has long railed against downstream Android vendors who are very likely violating the GNU Public License, has turned the spotlight on a recent move by Sony’s eLinux team to begin work on a replacement for BusyBox, which Garrett alleges is purely a move to sidestep the GPL’ed BusyBox project and enable embedded vendors like Sony to gain BusyBox functionality without the need to comply with the GPL.
From one standpoint, this is all very kosher: as long as the BusyBox replacement doesn’t violate copyrighted code found in BusyBox, then this is a perfectly legal option. But Garrett is arguing that this is not being done for any technical reasons, but rather to eliminate a perceived headache for embedded Linux vendors: the ongoing GPL enforcement of BusyBox.
BusyBox is arguably the most “famous” GPL violation legal cases, started when BusyBox developers Erik Andersen and Rob Landley took Monsoon Multimedia, High Gain Antennas, LLC, Xteresys Corporation, and Best Buy to court over violations of the use of their all-in-one embedded tools utility. All of these cases were settled out of court. While the terms of the settlement were never officially disclosed, the Software Freedom Law Center (SFLC) and later the Software Freedom Conservancy (SFC), who assisted the BusyBox team, insisted that the goal of the legal actions were to obtain compliance–not to keep the defendants from every releasing the software again, or obtaining huge damages.
But Landley is now very much against the actions of the SFLC and SFC, citing that they went too far in their enforcement of BusyBox’s GPL.
“Since I’m not the only copyright holder of busybox, I can’t STOP the SFLC suing people over it. I added affirmative defenses to the BusyBox license page,” Landley wrote in a heated discourse on Garrett’s blog. “But that didn’t stop them from creating a self-funding legal machine where they never found any actual useful code that should have gone upstream, but they still demanded $15k or so in legal fees each time so they could go sue the next company.”
Landley also took exception to Garrett’s accusation that the eLinux/BusyBox replacement, which would be licensed under a BSD-style license, was part of a move by Sony to evade the GPL. In his blog entry, Garrett pointed to a wiki page on Sony’s eLinux wiki that he feels is evidence of Sony’s wrongdoings:
“It’s written by an engineer at Sony, and it’s calling for contributions to rewriting Busybox. This would be entirely reasonable if it were for technical reasons, but it’s not – it’s explicitly stated that companies are afraid that Busybox copyright holders may force them to comply with the licenses of software they ship. If you ship this Busybox replacement instead of the original Busyox you’ll be safe from the SFC. You’ll be able to violate licenses with impunity.”
I have to argue for a correction here, because Garrett’s last point is unnecessary hyperbole: if you use a clean-replacement product like ToyBox, there is no license violation. If you stop using BusyBox, how can you violate its license? Garrett’s point is only valid if ToyBox were to have code within it that was violating another pre-existing license, and to date there is no evidence of that.
[Author’s note: A bit of self-correction here. A conversation I had with Simon Phipps on Google+ this afternoon set me straight. “Garrett’s point is more subtle than that. The GPL applies to the combined shipped work. Thus, BusyBox provides a vector for SFC to pursue copyright violations against the Linux kernel, since when it is shipped together with Linux, SFC is a party to the overall violation,” Phipps wrote. In this context, then, Garrett’s statement makes more sense, and I withdraw the previous paragraph.]
For his part, Landley insists that he was the originator of the Toybox project referred to on the eLinux wiki, and that Tim Bird, the eLinux engineer from Sony who posted the page on the eLinux site was actually trying to recruit developers to Landley’s ongoing project–a project that is totally independent of Sony. Landley’s response was sharp:
“Dude, pay attention. Tim isn’t behind it, I am.
“I’m the ex-busybox maintainer who hooked them up with the SFLC in the first place. The guy who wrote little things like the non-stub versions of sed, sort, mount, bunzip2 before becoming the project’s maintainer. The guy who lamented that the busybox lawsuits had never produced a single line of usable code added to the busybox repository (unless you count our copyright notice announcement when you run the multiplexer), who tried to stop the self-financing legal machine the [Free Software Foundation] hijacked to force Cisco/Linksys to shut down all their Linux development and reassign the developers to work on Windows?”
Landley’s objections are long and detailed, and all center on a common theme: that his efforts on Toybox are his own, and not part of a conspiracy theory masterminded by Sony. He also objects to the actions of the SFLC and SFC for taking what he sees are too many liberties in the pursuit of GPL enforcement.
Landley also is highly disillusioned by the fact that GPL enforcement of BusyBox never garnered, from his perspective, the expected amount of new code contributions for BusyBox from developers who were allowed to see the source code.
“This is why I’m trying to stop busybox from being used as a bludgeon against the world at large. The SFLC sued an awful lot of companies that never got source from their upstream vendor, and couldn’t do so five years later (and a lot of cases were pretty old since they were grinding through the ‘hall of shame’ backlog), but the SFLC never once sued that upstream vendor (generally some taiwanese company that half-assed a board support package for the hardware they shipped). Instead the SFLC went after the local companies for enough money to sue the next one, and when we did get code drops they were obsolete worthless things with nothing we didn’t already have. (Generally some random SVN snapshot, or a release version with a couple backports from source control. The ‘local modifications’ were debug printfs, commented out lines, and the occasional hardwired global variable from people who didn’t know how to use the config system properly.)
“So tell me: where’s all this great code we got out of the lawsuits? In the entire time the SFLC or Conservancy have had the right to sue people over BusyBox, where is one line of code it resulted in? I honestly want to know, because I can’t name any, and I was a plaintiff!”
Garrett maintained in the comments dialog with Landley and Bird that there was indeed much code that came away from previous GPL lawsuits, including a lot of kernel code.
The crux of the arguments seems to be not that the GPL is being enforced, but the zealousness in which enforcement is being performed. Obtaining BusyBox source code is all well and good, critics argue, but when the SFLC and SFC move to seek compliance on unrelated software projects, there’s a problem.
“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 undesirable. It represents a business risk that is beyond the value that busybox provides,” Bird replied in the blog comments.
For its part, the Conservancy seems to be trying to push the debate into a more constructive look at GPL enforcement. The SFC’s Bradley Kuhn maintained on the BusyBox mailing list that the characterizations of GPL enforcement may have some inaccuracies:
“I’d like to point out that many of the “stories on the other side” are second-hand accounts. Obviously, as the person who directly handles most of the GPL enforcement for BusyBox, I can confirm there is no one with first-hand experience on the “other side” commenting on the LWN thread, nor on Matthew’s blog post.
“I think the community needs other projects to stand with us to enforce the GPL, and I’m working on coordinating that. BusyBox has become a ‘poster child’–unfairly–because for the last few years, BusyBox was the only project actively enforcing the GPL.”
Kuhn is correct that a reexamination of GPL enforcement may be a good idea, since there seems to be a lot of mis-interpretation about said enforcement. But his comments put Garrett’s call for more kernel developers to stand up and seek GPL compliance in an interesting light: if the Linux kernel is being violated, why aren’t there more GPL violation actions out there?
Perhaps there are… after all, as Kuhn as long maintained, most GPL violations never even get near legal action. But Garrett also points to another part of the problem in his own comments, when he was confronted about why he wasn’t taking action on his own contributed Linux kernel code.
“Most of the past work I’ve done is in bits of the kernel that are rarely present in infringing devices, and most of my recent work is owned by my employer rather than me,” Garrett wrote.
Since many of the Linux kernel developers are indeed employed by corporations (save for the Fellows that are salaried by the Linux Foundation and unpaid volunteers), it raises the question: is there social pressure within the Linux kernel community to not undertake GPL compliance action?
This may not be nefarious: maybe people just would rather not bother with enforcing compliance. Better, they may argue, to just let the violation go and get on with developing better code.
Or, as Bird and Landley so forcibly pointed out, there may be a fear of involving the Free Software Foundation, SFLC, or SFC in a GPL enforcement action because of fundamental differences of opinion with the philosophies and actions of these organizations.
If this is indeed that case, it would be ironic indeed if the very organizations that work to protect the GPL might be causing many developers who are otherwise supportive of the license to shy away from enforcement.