Problematic GPL enforcement at Verizon

I think that Alfresco's Matt Asay and I share some of the same concerns about the current spate of lawsuits that BusyBox and the Software Freedom Law Center (SFLC) have been busily filing. On the one hand, open-source developers have to protect their rights. However, as Matt notes:

My primary concern is that this (and the other two ongoing BusyBox lawsuits) will create more misunderstanding about the requirements the GPL imposes. It won't be helpful to have this result in less GPL-licensed software being adopted.

Put another way: if using GPL software comes to be seen as an invitation to get sued, fewer people will use GPL software. Whether individual enforcement actions can be justified isn't really the point. It's whether, collectively, copyleft-style licenses (including the GPL) start to look more legally risky than beneficial. CNET.com's Stephen Shankland took a look at SFLC's increasingly hard-line approach to license enforcement in "GPL defenders say: See you in court."

The latest BusyBox lawsuit against Verizon seems especially problematic.

Essentially, Verizon distributes Actiontec MI424WR routers to its customers for its Fios Internet service. It's unclear to me whether the device is sold or loaned or given away as part of the service; perhaps it's different by geographical location as I've heard conflicting experiences. In any case, the router is an integral part of Verizon's service. The routers use firmware that contains a variety of GPL software including BusyBox, a set of small versions of many common Unix utilities combined into a single executable.

The crux of the complaint is that Verizon allows its customers to download the router firmware from Verizon. Thus, although Actiontec apparently provides source code as required by the GPL on its own Web site, Verizon does not. It's also unclear whether the Verizon firmware is identical to Actiontec's and, if there are differences, whether they are relevant to the GPL or BusyBox. Regardless, the complaint focuses on the fact that Verizon offers firmware binaries for download without offering the corresponding source code; it makes no mention of Verizon distributing the binaries for a unique version of BusyBox.

Because Verizon is distributing firmware binaries without an offer of source code, this would, in fact, appear to be a violation of the GPL.

But it seems a rather picayune and hyper-technical one--especially if the Verizon firmware uses the same BusyBox code that is already available on the manufacturer's Web site.

It seems only a small step from this case to others that would raise some real concerns about using open source. I'm not a lawyer and draw no conclusion about whether these different sets of facts could trigger GPL violations or not. I merely note that they're close enough to the Verizon case that fine legal parsing would be needed to distinguish them.

• What if the entity distributing the routers was less clearly an OEM and more of a conventional retail outlet or electronics distributor? Presumably Best Buy doesn't today have to offer open-source source code for all the products that it sells, but what if it were to offer downloads to drivers and such as a convenience to customers? Could it run afoul of the GPL in the same way as Verizon?
• And why exactly does it matter whether the software binaries are being offered for download anyway? Even if they're just burned into flash inside the device, how is that different?
• OK, you say. So long as the hardware device comes with a piece of paper of whatever pointing the user to some source code download location at the original manufacturer's Web site, there's no problem. I guess that means that stores need to be careful about selling products in OEM packaging (i.e., not retail boxed). How would Micro Center even know whether some unboxed Seagate drive they're selling uses GPL code in its firmware or not?

To my non-lawyer (but reasonably open source-educated) eyes, these cases aren't clearly unique from that of Verizon. And, if they can't be clearly distinguished, they suggest scenarios that would be troubling to a lot of vendors making use of GPL software.

(Throughout this post, I've used the generic term "GPL." The new iteration of the license, GPLv3, includes some specific language related to end-user hardware devices that may or may not be relevant in this context. In any case, the reality is that the vast bulk of existing GPL software still uses the GPLv2 version.)