How Do You Like Your Links?

Some of the thorniest concepts in the GNU General Public License (GPL) revolve around the engineering concept of linking. Here’s how and when the GPL applies to combinations of code.

Among its many conventions, the restrictive portion of the GPL, Section 2, is perhaps the license’s most famous (and infamous) stipulation. According to Section 2, given a work licensed under the GPL, both works based upon the original work and works combined with the original work to form a single work must also be licensed under the GPL. Yet “based upon” and “combined with” are two distinctly different concepts according to the copyright law of the United States.

A work that is based on another original work is a called a derivative work. Furthermore, for a work to be considered a derivative, the work from which it is derived must be protectable by copyright. The new portion of a derived work is entitled to an independent copyright, but the copyright holder of the new portion depends on the permission of the copyright holder of the original work to exercise his or her full range of rights under copyright. A derivative work establishes a largely one-to-one relationship between the two copyright holders, and the copyright holder of the original work is under no obligation to grant permissions to the copyright holder of the derivative work.

A work that is combined with other works to form a single, new work is called a collective work or a compilation. A collective work is formed by assembling a number of preexisting materials, each of which may be independently subject to copyright (or not subject to copyright at all), to form the new work. To the extent the collective work incorporates preexisting copyrighted works, the copyright holders of those preexisting works must grant permission to the copyright holder of the collective work to use the preexisting copyrighted works. Further, the copyright holder of the collective work only holds a copyright in that particular, specific combination of assembled preexisting works; the copyright holder in the collective work cannot claim any rights in the preexisting works.

So how does this play out in the context of the GPL? If you take source code licensed under the GPL and modify or extend it (perhaps even extensively), there is little question that you’ve created a derivative work, and pursuant to the GPL, that derivative work is subject to the GPL as well.

In the instance of a collective work, you assemble numerous pieces of component, preexisting code to form a new work (assuming for the moment that you didn’t have to write any new code to integrate the components). In this case, you must have the permission of the copyright holder of each component to include the component in you new collective work.

Collective works aren’t a problem under any OSI-certified open source license (see the rather expansive list of approved licenses at http://www.osi.org/). However, to the extent that any one component is licensed under the GPL, you must, under Section 2 of the GPL, to license the entire collective work under the GPL. This doesn’t change the license that specifically pertains to any of the components, only to the work as a whole, the collective work.

Cooking Up Some Links

Linking “imports” library subroutines so that features and functions don’t have to be written over and over again. Libraries make for more efficient software development.

When a program calls for a routine, the program searches for that routine among its available libraries and then incorporates it. If that incorporation takes place at the time the code is compiled and the routine is effectively copied from the library into the executable, that’s considered a static link. Or, if the incorporation doesn’t take place until the program runs and the routine is utilized but not literally copied, you have a dynamic link. Both static linking and dynamic linking are engineering concepts, not concepts literally defined anywhere in the law, whether in the copyright statutes or case law.

Because U.S. copyright law covers both source code and binary code, you must consider both source and binary when considering issues of derivation, compilation (in the copyright context, not the programming context), and infringement. The fact that a new work exists only in binary form is irrelevant, since that binary is still subject to copyright.

Thus, since static linking requires literal copying from a preexisting work into a new work, the new work is a collective work. Hence, if any portion of the collective work is licensed under the GPL, then the collective work as a whole must also be licensed under the GPL.

Conversely, because dynamic linking doesn’t require the literal copying of a work, a work that makes a dynamic function call generally escapes the reach of GPL.

Why “generally”? Keep in mind that the GPL not only reaches derivative works, it reaches collective works as well, and there is always the possibility that the calling work has been combined and distributed with the GPL’d work in the form of a collective work. In that instance, it isn’t the dynam linking that subjects the calling work to the GPL — it’s the distribution of the two independently created works as a single collective work.

Mark Webbink is the Deputy General Counsel of Red Hat, Inc. and Linux Magazine’s legal affairs correspondent.

Comments are closed.