The ongoing fight against GPL enforcement

[mjg59]

GPL enforcement is a surprisingly difficult task. It's not just a matter of identifying an infringement - you need to make sure you have a copyright holder on your side, spend some money sending letters asking people to come into compliance, spend more money initiating a suit, spend even more money encouraging people to settle, spend yet more money actually taking them to court and then maybe, at the end, you have some source code. One of the (tiny) number of groups involved in doing this is the Software Freedom Conservancy, a non-profit organisation that offers various services to free software projects. One of their notable activities is enforcing the license of Busybox, a GPLed multi-purpose application that's used in many embedded Linux environments. And this is where things get interesting

GPLv2 (the license covering the relevant code) contains the following as part of section 4:

Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.

There's some argument over what this means, precisely, but GPLv3 adds the following paragraph:

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation

which tends to support the assertion that, under V2, once the license is terminated you've lost it forever. That gives the SFC a lever. If a vendor is shipping products using Busybox, and is found to be in violation, this interpretation of GPLv2 means that they have no license to ship Busybox again until the copyright holders (or their agents) grant them another. This is a bit of a problem if your entire stock consists of devices running Busybox. The SFC will grant a new license, but on one condition - not only must you provide the source code to Busybox, you must provide the source code to all other works on the device that require source distribution.

The outcome of this is that we've gained access to large bodies of source code that would otherwise have been kept by companies. The SFC have successfully used Busybox to force the source release of many vendor kernels, ensuring that users have the freedoms that the copyright holders granted to them. Everybody wins, with the exception of the violators. And it seems that they're unenthusiastic about that.

A couple of weeks ago, this page appeared on the elinux.org wiki. 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 Busybox you'll be safe from the SFC. You'll be able to violate licenses with impunity.

What can we do? The real problem here is that the SFC's reliance on Busybox means that they're only able to target infringers who use that Busybox code. No significant kernel copyright holders have so far offered to allow the SFC to enforce their copyrights, with the result that enforcement action will grind to a halt as vendors move over to this Busybox replacement. So, if you hold copyright over any part of the Linux kernel, I'd urge you to get in touch with them. The alternative is a strangely ironic world where Sony are simultaneously funding lobbying for copyright enforcement against individuals and tools to help large corporations infringe at will. I'm not enthusiastic about that.

Comments

[mjg59]

The page explicitly says that 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).

[landley.livejournal.com]

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

[mjg59]

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.

[landley.livejournal.com]

That's not the reason, and I know because I'M THE ONE WHO DID IT.

I'm the one who connected busybox with SFLC, because when I became BusyBox maintainer I inherited Erik Anderson's "hall of shame" page, and couldn't maintain that part of the project. So I went "if this is really an issue, let's deal with it properly", and asked around about pro-bono legal representation, and Pamela Jones of Groklaw gave me contact info for the SFLC.

I started this process, and Erik went along with _me_. And the objective was to shake these guys down for THEIR BUSYBOX CODE. Not for other projects' code, and not for money (although money is how you get their attention). I continued for a year, and at the end of that year we had not gotten a single line of busybox code added to the repository because of all this.

I note that gpl-violations.org already existed at that point, with Harald Welte suing over kernel stuff before the SFLC was founded. We felt no need to handle that because somebody else was already doing it.

The lawyers had a larger agenda, but the engineers didn't. But their main agenda was to get paid: the SFLC made sure that everybody they contacted paid them $20k for legal fees, so they could afford to keep doing it. Whatever the outcome code-wise, the SFLC got paid, so of course they kept filing suits. The first I _heard_ of most of these companies was when the SFLC informed me we were suing them. (Presumably Erik had lots of complaints he'd never acted upon, and then there was the gpl@busybox address.)

The SFLC never asked "what code do we get out of this". They got their $20k. Whatever happened, the lawyers got paid, bring on the next lawsuit!

This self-perpetuating lawsuit machine is what the FSF hijacked to stop all internal Linux development at Cisco. that had the potential of producing some great code, they were ALREADY planning to release it, and the FSF got those engineers reassigned and the division dissolved. (I was there when it happened, as was mirell.org.)

From an engineering perspective, destroying Linksys was a BAD THING.

You're complaining about the loss of side effects you like. I'm pissed about A) the complete failure of the original purpose, B) massively counterproductive side effects that would have made the original purpose not worth it anyway.

[(Anonymous)]

From an engineering perspective, numerous bits of useful Linux code have become available because of lawsuits that originated with Busybox, making it possible for people to hack on their own devices in ways they otherwise couldn't. Most usefully, GPL enforcement also gets vendors to release the exact version of the Linux kernel they use, including patches, configurations, and drivers.

I'd also point out that the WRT54G/WRT54GL remains the most wildly successful Linux router of all time, and it spawned numerous communities around it that have expanded to cover a large number of other devices; that never would have happened if Linksys hadn't been forced to release the GPLed source for the original WRT54G.

I agree with you that sometimes pursuing GPL enforcement has the effect of discouraging companies from using Linux (just as, for that matter, the use of the GPL rather than an all-permissive license discourages some companies from using Linux). I also agree strongly that all GPL enforcement requires a careful approach, and the case you mentioned of having a lawsuit filed against a company you were already actively working with towards compliance sounds astonishingly counterproductive. I don't think that screwup negates the need to continue to enforce the GPL; it just serves as a reminder that doing so requires more care.

[(Anonymous)]

Also, in most cases I'd assume you didn't get useful Busybox code out of the process because nobody ever needed to modify it. (As opposed to the Linux kernel, where vendors frequently add drivers or other patches to customize it to their hardware.) Even in such cases, the GPL still obligates vendors to distribute their code, which at least includes the Busybox .config the vendor used, to help people who want to create modified firmware images.

That said, I wonder sometimes if some projects should take the approach used by the UPX license: GPL, but if you make absolutely no modifications and just compile and ship the thing, you don't have to provide source. On the other hand, that would make it extremely difficult to tell the difference between someone using an unmodified version and taking advantage of that provision, and someone shipping a modified version in violation of the license. Better to just require source in all cases; it honestly shouldn't burden a vendor that much to stick a tarball somewhere and point to it.