The GPL: Understanding the License that Governs Linux
Novell Cool Solutions: Feature
By Matt Asay
Digg This -
Posted: 16 Jan 2004
Editor's Note: This is the first in a three-part series in which Matt explores the GPL (GNU General Public License). This piece originally appeared in Wasatch Digital iQ.
The answer to both questions is the GPL, or GNU General Public License, the software license that governs the Linux kernel and other open-source software. Despite the critical role the GPL plays in the advance of Linux, not many people understand its terms. I'll attempt to explain the GPL and how it relates to traditional copyright law, as well as explain how commercial software developers can legally benefit from this exceptional license.
What Is the GPL?
Put bluntly, the GPL is a software license that attempts to turn copyright law on its head. Article I, Section 8, Clause 8 of the US Constitution creates limited monopolies for authors and inventors to ensure sufficient incentive for them to invest time in their writings or works. The GPL, by contrast, assumes that writers of software need no such incentive, preferring instead to write and share software for purely utilitarian and compassionate reasons. If something breaks, better fix it, and not horde that "fix" to yourself.
What the GPL Says
Dubbed by proponents as a "copyleft" license (and by opponents as "un-American"), the GPL allows licensees to copy, modify, and distribute GPL-licensed code, provided that the user then license the derivative work under the same terms. That is, the licensee can do whatever she wants with GPL software, provided that she license her derivative works under the GPL. This effectively means that the creator of the derivative must give away her work for free, as will be shown. Depending on how one looks at it, this is either a virtuous circle of sharing or a severe limitation on the use and utility of Linux and other GPL code.
As stated, joining the Linux camp more-or-less relegates a developer to poverty status. Software vendors like Microsoft make money because they provide a product that no one else can: access to the "secret sauce" (Microsoft's "source code") is difficult to come by, and replication or derivation thereof is forbidden. Linux vendors, governed as they are by the GPL, do not have this luxury. The GPL requires that licensees:
- Not establish proprietary rights in the software (Once you write it, everyone gets to enjoy it);
- Provide the source code (or access to the source code) along with the object code. (Basically, requires you to reveal or "open source" exactly how you make the software do what it does);
- Include in the software notice that the code is subject to the GPL (So that everyone downstream can be warned); and
- Accept the GPL code without warranties of any kind (You got it for free, so you cannot complain if it does not work).
Since everyone can copy, use, and distribute your code, it becomes difficult or impossible to charge for it, though charging for associated services (including a warranty) and software is permissible. (There are exceptions - brand continues to help some open source companies earn revenues on otherwise free software.) And, given that there's no money to be earned, there's no reason for Novell or IBM or anyone else to bother with it, right?
The GPL and Derivative Works
Not necessarily. While it's true that it's challenging to charge for your derivatives of GPL software, the real question is: what constitutes a GPL-derivative? That is, are you going to run afoul of the GPL and abandon your IP by writing applications to run on Linux or that somehow interoperate with GPL code? By way of response, the first section of the GPL's "Terms and Conditions" looks to US copyright law to provide a definition of derivative works, then defers final judgment on whether or not a derivative has been created to a case-by-case analysis of how the GPL software interacts with independent code. Let's take a closer look.
In US copyright law, a copyright owner of an original work is the only one with the right to make or license derivative works based upon a previously copyrighted work. A derivative work is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. US copyright law stipulates that a work will only be considered an infringing derivative work if it is substantially similar to the copyrighted work, and if the copyright holder did not authorize the derivative. Courts generally consider a work a derivative if it contains a substantial amount of material from a preexisting work. I, therefore, cannot legally publish a different ending to The Grapes of Wrath, or create a work substantially similar to it (substituting plundering communists for rapacious capitalists, for example), or write a musical based on the novel. Only Steinbeck and his estate can do this, or license me the right to do so. Reasonably clear, right?
The courts have not, however, done much to relate this concept of derivatives to software law, where software routinely "links" to other software in order to create one "meta-program." Linking brings together different modules (and submodules) from different files that are designed to work together, and merges them into one executable program, as depicted here. So, likening this to authorship of a novel, linking allows me to create my own novel - let's call it The Grapes of Matt - which makes "calls" out to various other works to furnish details on my characters. Maybe I reference Scout Finch, a character from To Kill a Mockingbird, without going through the effort of providing a physical description or biography of her - just referencing her reminds you of all her attributes, and you go on with my book. All of the potential for infringement - copying, modification, and the resultant substantial similarity between the two bodies of code - is there. What isn't there, however, is the literal copying of the text, which introduces the best way to resolve this potential pitfall: analysis of how software links with other software.
There are two common methods for linking code: static and dynamic. Static linking is the original method used to combine an application program with the parts of various library routines it uses. The linker is given the user's compiled code, containing many unresolved references to library routines. It also gets archive libraries containing each library routine as a separate module. The linker keeps working until there are no more unresolved references and writes out a single file that combines the user's code and a jumbled mixture of modules containing parts of several libraries. The library routines make system calls directly, so a statically linked application is built to work with the kernel's system call interface. The crucial thing to remember is that a static link outputs a combined file from the compiled code and the libraries. This executable would almost certainly be considered a derivative work of the GPL code. It's as if instead of just referencing Scout Finch, I wholesale copy all of Harper Lee's rich description into my text, so that a substantial body of my work is Ms. Lee's.
Dynamic linking, on the other hand, does not copy the code into an executable. When the linker builds a dynamically-linked application, it resolves all the references to library routines without copying the code into the executable. You therefore end up with two separate bodies of code that talk to each other only as needed, which would seem to eliminate any question of there being a derivative created. This is similar to simply referencing Scout Finch - perhaps I mention that my character has all the curiosity of Scout Finch, which calls to your mind her constant probing of the identify of Boo Radley. I don't actually copy any of the text from To Kill a Mockingbird, but simply reference it at 'run-time.' Just as this would be acceptable in literature (and wouldn't create a derivative work), so, too, it seems reasonable to believe that software that dynamically links to GPL code (including Linux) should be safe from the GPL's so-called "contamination."
This view makes sense, but it's by no means settled law. Nor is it as clear-cut as I've tried to make it appear in this article. Intelligent minds will disagree. In fact, no less than Linus Torvalds (not a lawyer himself, but open source begs for every developer to have at least some familiarity with copyright law) has spoken out both in favor of and in rejection of proprietary kernel loadable modules dynamically linking to GPL code.
Still, as Jerry Epplin notes, kernel developers have consistently supported such an open interpretation by accepting the presence of proprietary hardware drivers. This essentially means that the core of the system is off-limits (for tampering without sharing), but that the core is open as an acceptable platform to build upon by creating programs that leverage its functionality without stealing that functionality and calling it one's own. This reading of the GPL has become overwhelmingly prevalent in the past few years.
Why Microsoft Is Scared, and You Should Be Cheering
In sum, users of the GPL code are empowered to do pretty much whatever they want with GPL code, provided that they assert no proprietary rights to the original code and open source any derivative works. Untangling the question of what constitutes a derivative work is the thorniest issue the GPL raises, and was by far the biggest roadblock to Linux adoption by the world. However, as noted, dynamic linking to GPL code is generally not considered to create a derivative work. This is *not* to say that this is the "Right" legal outcome - no one can know the definitive answer on that matter until a court settles it - but it is to argue that general industry practice has come to view dynamic linking as acceptable. This opens up a huge realm of options to the commercial software developer to leverage the power of Linux, while retaining the ability to make money from one's own software that interoperates with Linux. Even so, you should seek professional legal advice before you link to open source code.
Commercial software developers need not fear Linux and the GPL that governs it. Instead, such companies should embrace Linux as an exceptional development platform, one that is free as water (and much more stable). Commercial hardware vendors and services firms like IBM have figured out how to make money on Linux - you should, too.
This, quite frankly, is what Microsoft fears. Microsoft can beat up on a Novell, or a WordPerfect, or name-your-favorite-computer-company. Microsoft cannot, however, beat up on a global, faceless army of developers who "hack" 24/7. Now, life is bad enough for Microsoft when Linux encroaches upon its platform space (the Windows OS family). Microsoft will lose the OS war. More interestingly, as commercial software developers wake up to their rights to leverage the Linux platform and other GPL code, no computing device will be a safe-haven for Microsoft, including the desktop.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com