The Failure of the GPL

• By David Chisnall
• Aug 31, 2009
• Article is provided courtesy of Prentice Hall

From the author of
Definitive Guide to the Xen Hypervisor, The

In 1985, the Free Software Foundation (FSF) was formed to promote software freedom, as defined by these four freedoms:

0. The freedom to run the program, for any purpose.

1. The freedom to study how the program works, and adapt it to your needs.

2. The freedom to redistribute copies so you can help your neighbor.

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