Software Pluralism

Software Pluralism

Derivative Works


This article discusses the treatment of derivative works under the GNU General Public License. It argues that the functioning of the GPL depends upon a definition of derivative work that is significantly more broad than that employed by the Copyright Act or the courts. This over-broad definition ultimately leads to nonsensical results in the face of many modern program development and distribution methodologies. This article visits a number of fact-patterns to help illuminate possible weaknesses and inconsistencies in the GPL definition of derivative work.

This article requires that readers have more than a passing familiarity with computer software system concepts, so readers who are not well-versed in those ideas are urged to first read the Technology Primer.

The GPL and Derivative Works

The following section describes some common program development scenarios and their treatment under one of the most commonly used open source licenses, the GNU General Public License (GPL). At a high level, the GPL allows the licensee to copy, modify, and distribute the licensed program under certain conditions. Copying, modification (or the creation of derivative works), and distribution are of course three of the exclusive rights granted to authors under the Copyright Act of 1976. 17 U.S.C. §106. The first GPL requirement is that software distributed under the terms of the GPL be accompanied by source code. The second condition requires that modifications of the original program be distributed under the same terms as the GPL itself. Section 2 of the GPL grants the licensee the right to "modify [their] copy ... of the Program, thus forming a work based on the Program, and copy and distribute such modifications or work" provided that the modified work is also licensed under the terms of the GPL. This latter requirement makes the GPL reciprocal (or viral, depending on the reader's political viewpoint) and guarantees - if it functions as intended - that subsequent versions of an initial code-base remain open or free, where openness here is used to refer to the availability of source code coupled with the right of end-users to make changes to that code. The critical observation is that the requirement that the GPL be applied to a new work is triggered when 1) a derivative work is created and 2) that derivative work is distributed. The efficacy of the GPL depends, therefore, on the breadth of the definition of derivative work. In the sections that follow we first survey the various definitions of derivative work as employed by the courts, and then analyze the GPL's effect in the face of a variety of commonly occurring software development patterns.


Under the Copyright Act, a derivative work is defined as "a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, ..., or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'." 17 U.S.C. §101. The courts have unfortunately been less than clear and in many cases inconsistent in their interpretation of this provision in the computer systems context. An exhaustive legal analysis of derivative works in the computer system context is beyond the scope of this article, but the three cases (all taken from the video game context) discussed below should provide a feel for the courts' struggles with the concept.

In Midway Mfg. Co. v. Artic International, Inc., the court confronted the derivative work question in the video game context. 704 F.2d 1009 (7th Cir. 1983). In this case, the defendant marketed a circuit board that could be installed to speed up the gameplay of an arcade game manufactured by the plaintiff. The court held, with minimal discussion, that the speeded-up video game was a derivative work of the original video game, and that the defendant infringed the plaintiff's derivative work right.

Almost a decade later, a different court, on very similar facts reached the opposite conclusion. In Lewis Galoob Toys, Inc. v. Nintendo of America, Inc., the defendant developed a hardware add-on module that enhanced the game play of a Nintendo video game system. 964 F.2d 965 (9th Cir. 1992). The court adopted a particularly narrow definition of derivative work: "[it] must incorporate a protected work in some concrete or permanent 'form'." Id. at 967. The court held that because the add-on module did not incorporate the protected work (here, the audiovisual video game displays) in any way, it did not infringe Nintendo's right to create derivative works.

The Nintendo court distinguished Midway by pointing out that the circuit board distributed in Midway substantially copied and replaced a portion of the original video game circuitry, whereas the Nintendo add-on did not actually incorporate any of Nintendo's protected expression. The court then buttressed this distinction with a market effects test, noting that the Nintendo add-on did not actually supplant demand for the Nintendo game console, whereas the plaintiffs in Midway were being deprived of potential additional profits reaped by licensees of the arcade video game. Finally, the court made a policy argument, noting that holding the add-on infringing would unduly chill the market for improving innovations, such as plug-in spell checkers for existing word-processing programs.

Finally, in Micro Star v. Formgen Inc., the court held that a distributor of new "levels" for a video game infringed the creator's derivative work right. 154 F.3d 1107 (9th Cir. 1998). At first glance, this case seems again similar to the above. The alleged infringer simply marketed add-on modules, that an end-user could employ to create variations on the original work. So why the different result? The court distinguished Nintendo because the levels distributed in this case actually described "sequels" to the original game, whereas the add-on module in Nintendo merely enhanced the gameplay. In Nintendo the gameplay was still generated by the Nintendo game console whereas in Formgen the new levels actually directed a new telling of the video game's story. The court focused especially on the architecture of the Formgen game system, which consists of a rendering engine, an image library, and one or more files ("MAP" files) that describe the game levels and their content. The MAP files, therefore, define the very metes and bounds of the video game's story. And since Formgen created the initial video game story with their original MAP files, any other MAP files must tell a related and derivative story—a sequel, in a sense—of the original.

Whether or not we find the analysis in these cases convincing, they do teach us something about the way courts address the derivative work problem. First, a derivative work must incorporate the protected work in some manner. Second, courts will fall back on an analysis that resembles the substantial similarity test familiar under the reproduction right. Third, courts will look at the market impact of the work. An alleged derivative that does not supplant demand for the original is less likely to be held infringing. Finally, courts recognize that an over-broad definition of derivative work may chill the market for follow-on innovations.


Modifying a source file

Example 1.0: Starting with the most simple case, suppose a programmer, X, has in their possession a copy of program G. G consists of a number of source files (physical modules) and is licensed to X under the GPL. Now suppose that X modifies program G by adding and/or deleting a number of lines of code to one or more of the source files that make up G. In doing so, X creates a new program G'. Given that G is licensed to X under the GPL, will the modified program, G', also be subject to the GPL?

Initially, the answer to this question must be in the negative. Recall that the GPL's demand that it be applied to a derivative work of the original program is only triggered upon the distribution of a work that is derivative of the original program. So even assuming for the moment that G' is a derivative work of G, X does not need to license the modified version in absence of distribution. The Frequently Asked Questions about the GNU GPL (hereinafter FAQ) confirms this analysis: "The GPL does not require you to release your modified version. You are free to make modifications and use them privately, without ever releasing them... But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL." Therefore, so long as X does not release - and thereby exercise the distribution right - G' need not be subjected to the terms of the GPL.

Example 1.1: Now, assume the same facts as above, but that X now wishes to distribute copies of G', as might a traditional software vendor. Since distribution is given, the analysis now turns on whether G' is a derivative of G. If so, G' must also be licensed under the GPL, meaning that X must provide copies of the source code along with any translation (executable) they may distribute.

This fact pattern is probably the canonical case envisioned by the drafters of the GPL. G' surely qualifies as a derivative of G under the legal framework described above. G' incorporates much if not all of the original work G. G' is certainly substantially similar, given that we are assuming only a small number of lines of code have been added. Finally, G' can be viewed as a replacement for G, thereby denying market share to the author of G. Hence, because X is distributing a derivative of G, X must license G' under the terms of the GPL.


Adding a file to a collection of files

Example 2.0: Suppose that X modifies the original program G by simply adding a new source file S. S contains some new functionality which X wishes to add to the existing functionality of G. Depending on the architecture and programming language used in G, it may be necessary for X to also make at least a small modification to one the source files in G, in order to invoke the functionality contained within S. In this case, it is useful to think of the resulting work as the sum of its constituent parts. First, S is just the new source file added by X. Second, G' is just the original code-base G, plus some (possibly minor) modification required to invoke functions located in S. Note that G' is similar in many ways to the simple example given above, except that the code added makes one or more external references to functions located in module S. The resulting work can be expressed as G' + S. In order to run their new program, X will need to compile all of the modules in G' + S and link them together to build an executable, E. We will use the notation C(x) to describe the object file that results from compiling a given source file x. For instance, C(S) is the object file that results from compiling source file S. Hence, E = C(S) + C(G').

Assume that E is statically linked, and suppose that X wishes to distribute E. Must E be licensed under the terms of the GPL? Again, if E can be considered derivative of G, then the answer must be yes. Recall that E = C(S) + C(G'). We know from the analysis above that G' is a derivative work of G. The copyright statute tells us that "translations" are considered derivatives of original works. 17 U.S.C. §101. Assuming that the process performed by the compiler qualifies as translation, then C(G') surely qualifies as a derivative work of G'. And finally, since E is statically linked, at the time of distribution it literally incorporates C(G'), which we have determined is derivative of the original work G. E therefore can be considered a derivative work of G and must be distributed under the terms of the GPL, meaning that source code G' and S must be provided.

Example 2.1: Now suppose that X wishes to license S (containing the bulk of the new functionality of G' + S) under different terms. In particular, X might want to distribute S under a license that does not entitle the licensee to view the source code in S. X might be able to do this by first distributing just the portion of E defined by E - C(S). In other words, X might choose to distribute just C(G'). This portion of E will likely not be a functioning program, and, under the above analysis it will be a work based on G, and therefore also subject to the GPL. And then suppose that X separately distributes the object module C(S). Is this module subject to the GPL? Must X provide the accompanying source code, S?

The GPL itself admits to the possibility that certain kinds of works, independently distributed, may not be subject to the terms of the GPL. Section 2 of the GPL states: "[The requirement that the modified work be licensed under the GPL] apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works." In our scenario, then, if S can be considered an independent work of G' and if S is distributed separately from G', then S need not be licensed under the terms of the GPL. Given that it is being independently distributed, the answer then depends on whether S can be considered an independent work of G'. Independence is nowhere defined in the GPL, but it seems reasonable to assume that the drafters meant the term to encompass the set of works that are not derivative of the original work.

The answer depends, then, on whether or not S can be considered a derivative G'. On the one hand, if we can make this case look like Formgen, then there might be a good argument for deciding that S is a derivative of G'. For example, suppose that G' is a digital signal processing program, consisting of an engine module that applies a variety of filters to a digital sample. Assume further that a collection of pre-existing filter modules already exists in G'. So the interesting thing about G' is not really its application engine, but its collection of filter modules—just as the interesting thing about the Formgen video game was the stories described by the MAP files. Arguably, now, a new filter provided by module S could be viewed as a derivative of at least some of the original filters provided by G'. And while S does not necessarily literally incorporate any portion of G', it is at least substantially similar to some of its components. Moreover, the combination of S and G' could certainly be viewed as a market substitute for G' alone. In this analysis then, S is arguably a derivative of G', and X would need to distribute it under the terms of the GPL.

Even here, however, there are features of copyright law that may stand in the way of this conclusion. The first is the bar on protection for processes and methods of operation in section 102(b). Recall that the MAP files in Formgen described the telling of the video game's story. And in holding that the story was protectable subject matter, other MAP files - that told variations on that story - were necessarily derivative works. A digital signal processing system, on the other hand, is at its core highly functional. And the filters themselves are written by highly efficient and arguably rote implementations of mathematical formulas. Therefore, under section 102(b) and its more rigorous manifestation in the Altai Abstraction-Filtration-Comparison test (Computer Associates International v. Altai, 982 F.2d 693, 23 U.S.P.Q.2d 1241 (2nd Cir. 1992)), it is doubtful that there is very much copyrightable subject matter in the original digital signal processing system as defined by G'. If G' contains only minimal copyrightable expression, then the argument that S is in some way a derivative becomes even harder to make. The lesson perhaps is that architectural similarities alone are insufficient to show derivation. Here, the question was not resolved by reference to the architectural similarities between the Formgen system and our system, but by reference to the strength of the copyrightable expression in the parent system.

The fair use limitation provides another counter-argument to a finding of infringement in this example. The fair use analysis is codified in section 107 of the act, and directs courts to look at four factors: the purpose and character of the use, nature of the copyrighted work, amount and substantiality of the portion used, and the market effect. The first factor weighs against X, assuming he intends to sell C(S), because commercial use typically works against an alleged infringer. The remaining factors, however, may work in X's favor. The second factor restates the principle discussed above, that creative works of authorship are entitled to higher degrees of protection. Here again, the analysis will turn on the substance and strength of copyrightable expression in G'. And if G' is seen as primarily functional, there again will be little copyrightable expression to infringe. The third factor focuses on the amount of the original work used in the allegedly infringing work. Here, assuming that modern software engineering principles are followed, the amount of literal copying of code in G' is surely minimal. The relationship between S and G' is just that S makes function calls into G'. Therefore, S makes use just of the function names defined by G', and doesn't actually copy any portions of the G's program text. Finally, the market effect analysis also works in X's favor, because S does not supplant the market for G. In fact, anyone who wishes to use S has to also download a copy of G'.

Of course, even if we decide that S is not a derivative of G' (or any portion of it), the original author may proceed under a contributory infringement theory. Since the executable E is a derivative work of G created by the end user, the owner of the copyright in G could claim that even if S alone is not a derivative work of G, that X is contributorily infringing their derivative work right because they are inducing, causing, or materially contributing to infringing conduct of another. Even assuming that X has the requisite knowledge of the infringing activity, there is a problem with this argument related to the grant of rights under the GPL. Because the GPL grants the end-user in this situation rights to make derivative works of G', the owner of the rights in G' cannot argue that the end-user is actually infringing their derivative work right. Without underlying infringement by the end-user, any claim to contributory infringement must fail.

To be sure, using such a strategy to circumvent the GPL seems clumsy. In order to obtain a functioning program, the end-user would first have to obtain C(G'). Then, they would have to separately obtain C(S), and link that module to C(G') to create an executable. The executable E, that is created by the end-user, is a derivative of G, as discussed above, but the critical distinction here is that X did not distribute that derivative work. X only distributed the building blocks required to build E. One of those building blocks, C(G'), is distributed under the terms of the GPL, as required. The other building block, C(S) may be distributed under another, more restrictive license, because if we believe the above analysis, C(S) is not necessarily a derivative work of G.

However, as times change we encounter new ways to build and distribute software. In particular, software systems are becoming increasingly modularized, supporting increasingly high levels of reuse and sharing. The distribution of software has also become increasingly fluid as networks become a dominant distribution medium. In many cases, the monolithic executable that lives in a single address space is being supplanted by networks of clients and servers, intercommunicating in order to provide a service for an end user. In this way, the architecture of programs begins to sprawl across machines and the networks that connect them, making the line drawing exercises demanded by a license such as the GPL increasingly difficult. Example 2.1 should therefore be viewed as more than an odd academic exercise, because the issues it raises will reappear in the real-world software scenarios we shall visit in the sections that follow.


Static or Dynamic Linking: Does it Matter?

Example 3.0: This example is the same as example 2.1 except that it takes place in a dynamically linked universe. The main difference is that the executable E only exists as a physical combination of modules when the program is being executed. Until the program is launched, there is only a collection of disparate object modules residing on disk. When the program is launched, these object modules are stitched together to form something that we would call an executable. So it should be clear that dynamic linking in some ways makes the potential weakness in the GPL noted above easier to exploit, because the vendor of software only ever ships unconnected object modules, and the "combining" of those modules does not take place until the end-user activates the program.

The results in this example seem to be the same as above. As long as module C(S) is not considered to be a work derived from G, then it is not within the scope of the GPL. If X can distribute C(S) separately from C(G'), and the combination of C(S) and C(G') is only made by the end-user, X should be free to license C(S) under whatever terms she chooses. And the distribution scheme seems a fraction less “kludgey” than the one employed in example 2, because the step of combination (linking) occurs transparently to the user of a dynamically linked system.

Much has been made of the issue of how dynamic linking bears upon the applicability of the GPL. Some commentators contend that a first module dynamically linked to a second, GPL'ed module is not necessarily subject to the GPL. (Lawrence Rosen, for example). The drafters of the GPL, on the other hand, argue that the first module in this instance would be subject to the GPL, regardless of whether the two modules were statically or dynamically linked. In the GPL FAQ they note, "If the modules are included in the same executable file [static linking], they are definitely combined in one program. If modules are designed to run linked together in a shared address space [dynamic linking], that almost surely means combining them into one program." They go on to say that if modules communicate with each other over networks, they are unlikely to be considered derivatives of each other. In a way, framing the question in this manner has been unfortunate, because it focuses the inquiry upon the mechanism of inter-module communication rather than on the more metaphysical - and legally significant - inquiry into whether one module is in fact a derivative of the other. And as we have seen above, courts answer this question not by reference to the technology underlying the work but by reference to qualities such as incorporation and substantial similarity, tempered by subject matter limitations, fair use defenses, and public policy rationales.

In short, the debate over static and dynamic linking simply misses the mark. As we shall see in our next example, using inter-module communication as the basis for a derivative work analysis will lead frequently to counter-intuitive and nonsensical results.


The Problem With Plugins

A plugin is a module of code that can be easily - from the end-user's perspective - installed and run within an existing application. A plugin generally expands or extends the functionality of the original program in some way. Many modern application programs contain some form of plugin architecture, so that third parties can write extensions for the underlying application. For example, the Mozilla Firefox browser has a plugin architecture. This allows, for instance, Adobe Systems to offer its Acrobat Reader as a plugin for Firefox. After installing the plugin, if a user loads a PDF document, Acrobat Reader will launch and appear within the browser window. Another example is the Flash Player, which allows users to view animations within their web browser. In this way, the designers of Firefox can enable (or rather, allow third parties to enable) the viewing of novel content types within the friendly confines of the browser, but without disturbing the core architecture and design of the browser itself.

Example 4.0: Program P, licensed under the GPL, contains a plugin architecture that allows users of P to dynamically download and run object modules that extend P's functionality. X writes a plugin by creating a source module S, compiling it, and advertising the resulting C(S) on his website. Does X have to license the plugin C(S) under the terms of the GPL?

This is yet another, but more naturally occurring example of the GPL's difficulty in dealing with distribution of related modules that are not assembled prior to distribution. In this way, the analysis here does not differ greatly from that of Examples 2 and 3, above. The primary difference is that X is not even distributing G', which recall was a slightly altered version of the original program G, modified so that S could be integrated into it. Here, the end-user has presumably obtained the analog of G' (P), from a third party. The vendor is only writing and distributing the plugin. The combined work, if there is one, does not come into existence until the plugin C(S) is installed and running on the end-user's machine. So the GPL need only be applied to S if S, standing alone, can be viewed as a derivative of P.

The GPL FAQ takes an explicit position on this particular scenario. It states that the result "depends on how the program invokes its plugin. If the program uses fork and exec to invoke plugins, then the plugins are separate programs, so the license for the main program makes no requirements for them." On the other hand, "If the program dynamically links the plug-in ... they form a single program, which must be treated as an extension of both the main program and the plugin." The terms fork and exec refer to UNIX system calls that a running program uses to launch another program. Every modern operating system provides some equivalent set of system calls. The GPL drafters therefore draw the boundary around components that are linked together, operate in the same address space, and have some intimate level of interaction and communication.

To understand the implications of this method of boundary drawing, consider for a moment the Acrobat Reader plugin for Firefox, and assume that the browser is licensed under the GPL. The plugin offers its own set of user interface buttons and is capable of rendering file formats that are exotic to Firefox. Does this seem like a derivative work of Firefox? Whatever our intuition may tell us, the answer depends - according to the GPL's drafters at least - on the particulars of the Firefox plugin architecture. If the plugin architecture launches plugins and runs them in separate address spaces as separate, running executables, then the GPL does not consider Acrobat Reader a derived work of Firefox. On the other hand, if the plugin is dynamically linked to Firefox, then the GPL urges the opposite characterization. This seems to fly in the face of common sense, which tells us that Acrobat Reader is not a work derived from Firefox.

The following thought experiment demonstrates the absurdity of the GPL approach. Imagine taking the Firefox source code and modifying it in such a way that it is encapsulated in a plugin, called Fireplug. Common sense and the law tell us that Fireplug is a derivative work of Firefox, based simply on the fact that Fireplug incorporates all or most of the Firefox codebase. Now, when we plug Fireplug into Firefox, we essentially have a Firefox browser running within a Firefox browser. And depending on the Firefox plugin architecture, the GPL drives us to incompatible results. If plugins are dynamically linked, Fireplug is a derivative work. This is the right result, but the reasoning is exactly wrong. Fireplug is a derivative work because it incorporates and is substantially similar to Firefox, not because of a decision made by the designer of the Firefox plugin architecture. On the other hand, if plugins are launched as separate programs, then Fireplug suddenly is not a derivative work, even though this result is counter the common sense result above. Clearly, the mechanism of a given plugin architecture are analytically unhelpful and misleading in answering the derivative work question.


Object Oriented Systems

Our next example concerns the GPL's applicability to object-oriented software systems. The central programming abstractions provided by object-oriented languages are those of objects and classes. Objects represent real, functioning program entities that contain data and can respond to certain messages. Classes are a means of defining and organizing a world of objects. A class defines the data and behaviors of a group of objects. For example, a programmer may wish to build a student database application for a university. In doing so, she may create a class called Student that defines the relevant characteristics of a student. These characteristics may include data such as name, student ID number, and GPA. They may also contain behaviors that students can perform. For instance, a student might know how to take exams, complain, and ask questions. Finally, classes may relate to each other by means of inheritance. In our example, our programmer might create a subclass of Student called GradStudent that specializes and/or extends the behaviors of Student in some manner. For instance, a GradStudent may prefer to complain about his or her advisor, whereas a generic Student may typically prefer to complain about grades. Inheritance allows the programmer to easily reuse much of the functionality of existing classes, by defining a subclass that overrides certain default behaviors of its superclass. (Some object-oriented languages, C++ for example, use the term base class for superclass and derived class for subclass. For obvious reasons, we shall avoid the use of those terms here.)

Example 5: Programmer X wishes to write a class D, that is a subclass of existing class B. Class B is subject to the terms of the GPL. If X distributes D, does it have to be licensed under the terms of the GPL?

The answer given in the GPL FAQ is short and to the point: "Subclassing is creating a derivative work." In our example, this makes D a work derived from B, and thereby makes D subject to the terms of the GPL upon distribution. This approach attempts to further broaden the reach of the GPL, but it again leads to counter-intuitive results.

Typical object oriented programming languages include a standard class hierarchy. This hierarchy provides a framework within which application developers can build their programs. The standard classes typically provide useful classes that represent user interface elements (e.g. windows, buttons, etc.), collection classes (for handling collections of data), and input-output abstractions (e.g. files and networking connections). In many object oriented languages, each class must be a subclass of exactly one superclass. And for this reason, the class hierarchies are rooted by a highly generic, standard class called Object. (The question of the superclass of Object is beyond the scope of this article.) The class Object describes only the most general properties and behaviors. For instance, in Java, the class Object only performs a handful of functions. In Java, every class is a subclass (directly or indirectly) of the Object class. Under the GPL approach, then, every program written in Java is a derived work of Object, because every program written in Java by definition consists of classes that inherit from the Object class.

Such a result certainly sounds extreme. The Object class in Java is extraordinarily generic and bears little relation to many of the classes that inherit from it. To be sure, all Java classes can perform the behaviors defined by Object, precisely because they are subclasses of Object, but this does not necessarily imply that those subclasses should be considered derived works under copyright law. It would be as if an author writes an incredibly generic, one-sentence long "story" along the lines of "There are some characters who do things and stuff happens to them" and then claims that just about every novel that follows is a work derivative of his story. From a naive perspective, almost every story (perhaps with the exception of Waiting for Godot) can be considered derivative of our short story because it borrows or incorporates the same essential plotline. Obviously, though, this is not the result that we obtain under the law. Principally, the reason is that the short story would not be considered copyrightable subject matter, either because it does not meet the minimum creative threshold, or because it is already in the public domain, or because the idea of the story has merged with its expression.

As usual, the answer in this example depends on questions of copyrightability, incorporation, substantial similarity, market demand, and public policy. As a general matter, in the case of inheritance in object oriented systems, a subclass trivially incorporates (and is substantially similar) to its superclass. The analysis should then turn, to a larger degree, on questions of copyrightability of the superclass, market demand, and public policy. For example, if the class B is highly generic (as in Java's Object class), it is unlikely that it would even be considered copyrightable subject matter under the 102(b) bar. On the other hand, if B is highly specialized—as are classes that we find on the fringes or leaves of a class hierarchy—there may be a stronger argument that they contain substantial copyrightable subject matter. This argues, then, for a finding that D is a derivative of B. Even here, though, a market demand analysis might argue against a finding of derivation. Class D will not supplant demand for class B, simply because it makes no sense to deploy D in the absence of B.


Networked Systems

Example 6: Software vendor V who distributes proprietary software wishes to add the ability to manipulate digital sound files. Being short on time, V finds a GPL'ed sound library, dresses it up as a server, and gives away the server under the GPL. Meanwhile, their core, proprietary application is modified to communicate with the "sound server" in order to perform sound processing tasks. End-users who wish to exploit the sound functions have to install the proprietary code alongside, or at least on the same network as, the GPL'ed sound server. Both of these items are "distributed" by the vendor.

Is the core, proprietary application now bound by the terms of the GPL? No, certainly not, even according to the GPL FAQ. The FAQ notes that "... sockets ... are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs." In many ways, this example does not seem controversial, but we bring it up to again emphasize the inadequacy of the reasoning by which the GPL drafters reaches their result. As with plugins and object-oriented systems, above, the GPL FAQ writers seem to reach this conclusion because of the way the two programs interact. Because the two works are two separate programs interacting over a network, they are somehow different from two modules interacting by means of function calls within an address space. As usual, this is not necessarily so. It is easy to construct an example where the work, viewed as a whole, is implemented by means of multiple servers intercommunicating over a network. And if an author comes along and adds an additional server that somehow extends the functionality of the existing community of servers, we might be inclined to say that the new server is a derivative of the original work, independent of the fact that it communicates with the original via a network.



In some ways, the apparent weaknesses in the GPL should come as no surprise, as the GPL was born of an era in which the central artifact of software development and distribution was the monolithic executable. In such a universe, software development proceeded principally by modifying the existing source text of programs, compiling source modules, linking the corresponding object files, and distributing the resulting executable. This model of software development and distribution has become increasingly fractured in an era characterized by highly dynamic, late binding, object- and network-based systems. The GPL, consequently, strains to cover these newly arising scenarios.

To effectuate the goals of the free software movement, the drafters of the GPL urge a generally expansive definition of derivative work. The great irony is, of course, that such an expansive definition would have second order consequences that are exactly counter to the goals of the proponents of Free Software. A broad definition of derivative would give code authors less freedom to create software that they can truly call their own and do with as they please. And if naive analytic approaches such as "subclassing equals derivation" reign, then proprietary vendors such as Microsoft could arguably stake claim to every program ever written in C#, because they authored the original class hierarchy. And since it seems unlikely that courts would employ different standards depending on the goals or ideological motivations of licensors, proponents of free software might want to be careful what they wish for: what's good for the GNU might not be good for the gander.


Related Articles