The Failure of the GPL
Date: Aug 31, 2009
Article is provided courtesy of Pearson.
In 1985, the Free Software Foundation (FSF) was formed to promote software freedom, as defined by these four freedoms:
The freedom to run the program, for any purpose.
The freedom to study how the program works, and adapt it to your needs.
The freedom to redistribute copies so you can help your neighbor.
The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.
One of the tools used to achieve this goal is the GNU General Public License (GPL). Looking back, has the GPL been a help, or a hindrance? And will it continue to be a help or hindrance in the future?
A GPL Success Story
The FSF website points out a specific instance of the GPL forcing a company to open its source. The company in this example was NeXT (now Apple), and the source code was the Objective-C front end for the GNU Compiler Collection (GCC). But what really happened?
When NeXT purchased the rights to Objective-C, it inherited two pieces of technology. One was a preprocessor—a fairly simple program that turned Objective-C into pure C. The other was a runtime library that handled all of the dynamic lookups, module loading, and other bits required for a complete Objective-C environment. The preprocessor approach had some limitations, not least of which was difficulty in debugging, so NeXT decided to move the preprocessor into the compiler.
The C compiler in use at the time was GCC, which was released under the GPL. To avoid the restrictions of this code, NeXT provided its front end as a library that end users would link against GCC, thereby avoiding the GPL (which only applies to distribution of the software, not how you use it). This little legal maneuver didn't work, however, so NeXT was forced to release the code.
Remember that an Objective-C implementation is in two parts: the compiler and the runtime library. NeXT was only required to release its compiler code, not its runtime library. As someone who has worked on an Objective-C compiler and two Objective-C runtime libraries, I can say with some certainty that NeXT didn't get the better end of this deal: For Objective-C dialects of that era, the runtime library is much more complex than the compiler.
Rather than admit that it had a worthless bit of code, the GNU Project wrote its own Objective-C runtime—and this is where things really started getting interesting. The GNU runtime wasn't quite a drop-in replacement for the NeXT runtime, so GNU needed to modify the compiler to support the new runtime. The modification involved a lot of #ifdef statements in the Objective-C support file. Of course, NeXT had no interest in supporting the GNU runtime, and therefore didn't bother to import these changes.
Periodically, NeXT would release a new version of its fork of GCC, and the mainline developers would try to backport their changes to the main branch. When Apple took over NeXT, the Apple developers continued to work on GCC, adding improvements such as better SIMD support to take advantage of the AltiVec units on the PowerPC chips that Apple was shipping. The developers also kept adding features to Objective-C. Because the Apple branch only had to support a single runtime library, there was no clear abstraction between the runtime-specific and runtime-agnostic bits, and so the GNU branch quickly fell behind.
The story doesn't quite end there, however. More recently, Apple wanted to integrate the compiler more closely with its IDE. One of the nice things about Visual Studio is that it uses the same parser and semantic analyzer for syntax highlighting and error reporting as it does for code generation, allowing for much better feedback than you get from editors that completely separate the two. Unfortunately for Apple, the GPL required either making XCode open source or rewriting GCC. Apple opted for the latter choice.
Fortunately, Apple didn't have to start from scratch, but instead was able to hire the lead developer of the LLVM Compiler Infrastructure Project, a BSD-licensed compiler infrastructure, and set him to work. The result was the creation of a new project, clang, to produce a new front end for LLVM that supported C, Objective-C, and C++. This front end currently supports the GNU runtime and the two Apple runtimes, and supports several features—such as fast enumeration and partial support for declared properties—that GCC doesn't, even when using the GNU runtime.
clang isn't the only Objective-C front end for LLVM, though; there's also one based on GCC. Unfortunately for people using non-Apple platforms, it's based on Apple's branch of GCC, and therefore only supports Objective-C on Darwin. This front end is covered by the GPL, whereas the one that has better support for the GNU runtime is covered by a BSD-style license.
What do we learn from this story?
First, we learn that you don't necessarily get good results from forcing people to do things. The NeXT Objective-C code was contributed to GCC reluctantly, and was never well maintained. The Apple code contributed to clang, in contrast, was written with a clean abstraction layer and allows new runtime libraries to be supported easily. This wasn't required by Apple, which started the project and therefore could do anything with it as desired. Because Apple willingly engaged the community, however, the end result is better for everyone.
The second thing to remember is that sometimes having someone else's code isn't actually a good thing. The Objective-C code in GCC is an unreadable, horrible mess. Objective-C is a small language, and the GCC team could probably have put together its own front end in a couple of weeks at most. If the team had done this, they probably would have designed it to support multiple runtime libraries from the start, and ended up with something a lot more maintainable at the end.
Google for Linux
For some time, Google has been the poster child of the Free Software community. The entire Google infrastructure is built around Free Software, and Google gives a lot back to Linux. That must count as a success for the GPL.
The elephant in this particular room is the Google filesystem, a highly scalable distributed filesystem used with Linux. Has Google released it? No. Surely the GPL requires that? After all, wasn't that the entire point—making people who benefit from Free Software and improve it share their improvements with the community?
Actually, no. As I mentioned earlier, the GPL is a distribution license, not a use license. It only comes into effect when you distribute the code. If you just use it internally, you don't need to distribute your changes to anyone.
Google has contributed a fair bit of code to Linux, though. Why? Because it's cheaper for the folks at Google to have that code maintained upstream than to keep an ever-growing local patch set for things that aren't core to their business. Every company that uses Free Software has to make this calculation. Keeping changes secret involves a cost (such as the extra maintenance work when someone makes some changes upstream that break your patches) and a benefit (the commercial advantage you get from being the only one with that feature). If the cost outweighs the benefit, then any well-managed company will release its code, whether or not the license requires it.
This explains why Yahoo! was employing people to work full-time on FreeBSD and contribute most of the those changes upstream. Yahoo! used FreeBSD internally, and needed certain features added and bugs fixed. Like the GPL, the BSD license applies only when distributing, but even if the folks at Yahoo! had distributed the code, they wouldn't have needed to release their changes. They just did it anyway, because it was good business sense.
Let's think about that for a moment. The latest estimates I saw showed that around 10% of developers were employed writing off-the-shelf software, while the remaining 90% were employed writing in-house software. None of these people are required to release changes from GPL'd code that they modify and use in-house. The community doesn't necessarily benefit from any of their work, but does the GPL cause any actual harm?
A few people in different companies have recently told me something that leads me to believe that the GPL actually does cause harm: These people have said that they'll use BSD or similarly licensed projects to base their internal systems, but will avoid the GPL because their legal team has decided that compliance is too difficult. If they use BSD-licensed code, they'll contribute improvements upstream, but keep their internal code private. (In most cases, no one would care if they released it anyway, because it's highly specialized.)
You're Either with Us or Against Us
The FSF makes two sets of Free Software licenses—one that's GPL-compatible, and one that's GPL-incompatible. This is an interesting spin, because most of the "GPL-incompatible" licenses are per-file, allowing you to combine them with code under any other license. The GPL places additional restrictions on the code, and therefore is incompatible. You can combine APSL, MPL, CDDL, Apache, and BSD-licensed code in the same project easily, but you can only combine one of these with GPLv2 code.
Even the Free Software Foundation can't manage to get it right. Version 3 of the LGPL, for example, is incompatible with version 2 of the GPL. This has caused a problem recently for a few GNU library projects that wanted to move to LGPLv3 but were used by other projects that were GPLv2-only.
The official stance is that projects shouldn't be v2-only, they should always be v2-or-later. I'll let you try to persuade Linux to switch. Oh, and good luck with PDF readers, too; the only open source PDF readers at the moment are based on xpdf, which is GPLv2-only. The FSF is frantically trying to write a new PDF library to get around this limitation, and licensing it as GPLv3-or-later.
This attitude is understandable. Richard Stallman believes that writing proprietary software is antisocial. Unfortunately, this mentality leads to lost opportunities. The GPL doesn't give you the choice of writing some proprietary software and contributing it to Free Software. If you want to use some GPL'd code, you have to GPL your entire project (which is sometimes impossible due to third-party requirements).
This is where the FSF and I have a fundamental philosophical disagreement. I believe that the community benefits when the amount of Free Software increases. The FSF believes that the community is harmed when the amount of proprietary software increases, and that making it easier to write a proprietary application is a bad thing, even when the side-effect is that the developers improve some Free Software.
I Feel Violated!
The GPL is several pages of legalese. I've read it several times, and still have to look up specific things, and I probably have a better knowledge of copyright law than the average developer. One of the major selling points of Free Software is that there's no cost in tracking licenses. Any piece of Free Software comes with the FSF's freedoms 0 and 2, meaning that you can use it and copy it as much as you want. This arrangement dramatically simplifies auditing, and is a huge win for big companies.
Because the GPL is a Free Software license, the same principle applies here, right? Yes, as long as you distribute with the source. There's a simple way of violating version 2 of the GPL, which I would imagine at least half of the readers of this article are guilty of doing. Grab the source code for your favorite GPLv2 project, compile it, and give a friend the binary. Oops—you've just committed copyright infringement. The GPLv2 requires you to provide either the source or an offer in writing (good for three years) to provide it (see clause 3).
It's generally considered helpful to compile software for your friends who aren't particularly computer-literate. They have no interest in the source, but the GPL requires you to give it to them (they'll thank you for it when they download the combined package over a pay-per-megabyte mobile connection), or give them a written offer for the source. If you choose the second option, you need to keep a copy of the source around for three years—and don't forget that it needs to be the exact version used to produce the binary.
This is only an individual concern, right? Well, not really. Imagine this conversation taking place between two employees of different companies:
"I can't open that file you sent me."
"Oh, sorry. I'll send you the program I used to make it—it's free."
"Great, thanks."
Sound reasonable? Variations of this same conversation are fairly common when the software in question is proprietary and it's illegal to provide copies of it, so for Free Software this conversation is likely to be even more common.
This helpful employee has now opened his or her company to legal liability. Note that in this example neither person modifies the source code at all, they both just use and share it. These are two of the conditions defined by the FSF as being vital, yet by exercising these freedoms, they have violated the license.
Of course, no reasonable developer would sue for this kind of GPL violation. Unfortunately, there's no trivial way of testing whether the developers of a particular program are reasonable.
Link, Pipe, Circumvent
The GPL makes a big deal about linking. If you want to avoid having to comply with the GPL, you need your code to run as a completely separate program. You can join two programs via pipes or sockets, as long as you do so via a reasonably generic interface, without either being considered a derived work of the other. Or, as NVIDIA discovered, you can provide a GPL'd modification to a GPL'd program that provides a generic interface, and then get end users to link it to some proprietary code.
If you have sufficient ingenuity, it's quite easy to work around the restrictions imposed by the GPL. With web services and web applications becoming increasingly common, you don't even need to try very hard. You can incorporate as much GPL'd code as you want into your proprietary web app or service, and no one can get at the code because you never distribute the binary—you just let people use it.
The Affero GPL attempted to address this problem by requiring you to leave in place any existing "download source" links. Of course, this requirement made the Affero GPL incompatible with GPLv2 (v3 has a special exemption). Because this requirement limits the modifications you're allowed to make to the code, it violates the four freedoms (although that didn't stop the FSF from recommending it).
If the GPL is easy to work around, why is it a problem? Anyone who needs to place additional restrictions on the code can do so—that is, anyone with enough money to spend on the extra developer effort or the legal advice, and therein lies the problem. The GPL fails to achieve its original objectives, and it also discourages people who don't want to employ a lawyer to read several pages of legalese and discover whether their intended use is likely to be allowed. It's easy to infringe accidentally; but if you really want to violate the spirit of the license, then it's still possible to comply with the letter of the license. With this situation in mind, it's easy to see why permissively licensed alternatives to GPL'd programs have recently started to see a lot more commercially sponsored development.