By now, just about anyone in the high-tech world knows something about Linux. Even my father, a very non-techie, knows enough to pronounce it correctly and vaguely understands what it’s for. Most know that Linux is gaining market share, and poses a major threat to Microsoft. Few, however, understand why it’s growing or why Microsoft cares. Deeply.

The answer to both questions is the GPL, or 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. Following is an attempt to explain the GPL and how it relates to traditional copyright law, and 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 U.S. 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. (Red Hat may be the exception to the rule, as they’ve managed to establish a brand that some people will pay for.) And, given that there’s no money to be earned, there’s no reason for Novell or Financial Fusion or other local companies to bother with it, right?

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 U.S. 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 U.S. 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 pre-existing 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.

U.S. 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 mind her constant probing of the identity 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 (and wouldn’t create a derivative work), so, too, with software that dynamically links to GPL code (including Linux)—it should be safe from the GPL’s “contamination.”

This view makes sense. Linus Torvalds, creator of the Linux kernel, supports this view. And, 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 year.

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 should not be considered to create a derivative work. 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.

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 as 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 Word Perfect, 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.

While managing Lineo’s Residential Gateways business, an embedded Linux software startup based in Utah, Matt Asay studied software licensing and innovation (specifically the GNU General Public License) at Stanford Law School. Matt is also one of Digital iQ's Open Source Bloggers. His ongoing comments can be seen in the blog section of the website.