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

[(Anonymous)]

All of the questions you've asked have come up numerous times before, and they all have well-known answers (though apparently not well-known enough).

First of all, thinking of licenses (copyleft or otherwise) in terms of threats of lawsuits gets it entirely backward. Copyright itself puts you in that position. Copyright gives you a pile of exclusive rights over your code; licenses then grant those rights to others. FOSS licenses provide exceptions to copyright law, providing broad grants of permissions with some conditions attached. You start with a copyrighted work, which normally would not permit copying, modification, or redistribution, and apply the GPL to it, which allows all of those things on the condition that any derived work must also allow all of those things. That seems like a pretty generous offer to me; perhaps not quite as generous as an all-permissive license, but I personally agree with the goals of copyleft, and I see nothing wrong with saying "share and enjoy but don't make it proprietary".

You don't have to use the GPL on your software just because you derive from GPLed code; you can use any GPL-compatible license, which includes all-permissive licenses. The GPL still applies to the overall derived work, but anyone can take your permissively licensed code out of that work and use it under that permissive license, if you want that. A GPLed project can require that you use a GPL-compatible license on your work when it derives from theirs, but they cannot require that you use the GPL itself for that work.

The GPL says absolutely nothing about linking. The GPLv2 talks about derived works, a term defined in copyright law. The GPLv3 uses its own terminology ("propagate"), carefully defined in the license, but it effectively amounts to "anything which would have been covered by copyright law": 'To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.'

While linking often creates a derived work, it doesn't necessarily do so in all cases, and conversely a derived work may exist even in the absence of linking.

A Python program that imports pyskein probably represents a derived work of pyskein. Since pyskein appears to use the GPL, that would then require that the Python program derived from pyskein use a GPL-compatible FOSS license. On the other hand, a program configurable to use umpteen different hashes through a standardized interface does not become a derived work of pyskein simply because pyskein provides that standardized interface.

Similarly, Python's use of readline does not require you to use a GPL-compatible license on your Python programs, unless your Python programs actually use readline.

The "system library" exemption in the GPL (both v2 and v3) has a very narrow definition, which seems fairly self-evident just by reading the license. If a proprietary (non-GPL-compatible) library normally ships with the platform your program builds for, and you don't ship that library with your program, you can link to it even from GPLed code. This allows people to ship GPLed software for Windows and OS X, even though the standard libraries for those platforms do not use GPL-compatible licenses (and don't ship with source code).

"Preferred form for modification" has a similarly straightforward definition; apply your common sense as a programmer. Compressing the source code (reversibly) rather obviously doesn't affect this; source code in an archive does not magically become object code. (Of course, using an archive format nobody else has an un-archiver for does not work, but common sense should tell you that.)

If you as the programmer write a work entirely in machine code, you could certainly make a convincing argument that the machine code represents the preferred form for modification. (That would make your work hard to maintain, but not proprietary.) However, that argument won't fly when you started out with a pile of someone else's GPLed source code, modified it, compiled it, and then threw away the source.

If you give me a binary built from someone else's GPLed code, and don't give me access to the source code as required by the GPL, you've violated the license; the copyright holders can't compel you to distribute source, but they can compel you to stop violating their copyright, and since nothing other than the GPL gives you a license to distribute, you'd need to stop distributing and possibly provide other remedies. (Distributing source code generally represents the least painful option, hence why most GPL enforcement leads to that result.) On the other hand, if you have sole authorship of the code, then you can do whatever you like (since you have all the necessary rights already without needing the license), but in doing so you've created something unredistributable.

Either way, once I have a binary without corresponding source, I can't distribute it to anyone else because in doing so *I* would violate the GPL. I can't compel you to give me the source code, but that doesn't excuse me from my own obligations. To quote the GPLv3 (v2 has an equivalent provision): 'If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all.'

(Also, whether the GPL works as a license or a contract depends on jurisdiction, but the difference doesn't really matter.)

So, again, all of the questions you've asked have come up many times before, and they have well-known answers. The GPL does not represent some wild west of licensing uncertainty and open questions; using it puts you on well-trodden ground. And most importantly, the GPL and other FOSS licenses don't represent threats of lawsuits, but grants of permission that you wouldn't otherwise have.

You're wrong

[(Anonymous)]

Thinking of licenses in terms of threats of lawsuits is exactly right.

The purpose of legal counsel before the fact is to be professionally risk averse, and so the only measure of success or failure is gong to be in terms of ability to mitigate risk.

Personally, if I were in Sony's position, I'd do exactly the same thing, especially if my parts supplier were Qualcomm and I was contractually obligated to not reveal the contents of the hypervisor on the Snapdragon ARM processor I used (and in fact could not, because only Qualcomm had it in the first place), or if my supplier were nVidia, and I couldn't reveal the signing keys needed to allow you to comply with the ability to run your own kernel because, frankly, again, only nVidia has them.

Both of these derive from governmental obligations these companies face when these chips are used in mobile phones, and unless those go away, you have a chain of risk that leads to needing to rewrite to get out from under the GPL.