Arguments In favor of GPL Inheritance of WordPress Themes and Plugins
First, I would like to summarize the various arguments in favor of GPL inheritance of WordPress Themes and Plugins.
The Free Software Foundation (FSF), as authors of the GPL, offer their interpretation of what constitutes a derivative work with respect to the combination of two or more works. 1 Last year, Matt Mullenweg solicited the opinion of the Software Freedom Law Center (SFLC) regarding GPL inheritance of WordPress Themes. 2 Here is a recent post by Mark Jaquith, a WordPress lead developer, attempting to explain and clarify the matter. 3 Also, a recent post by Ryan Boren, another WordPress lead developer, addresses the issue. 4 Here, Andy Peatling, Automattic employee, adds another consideration, regarding extending core WordPress code. 5
Summarizing The Arguments
- WordPress core, with a third-party Theme installed, constitutes a derivative work.
- A Theme, on its own, that incorporates core WordPress code, constitutes a derivative work.
- A Theme, on its own, that extends core WordPress code, constitutes a derivative work.
- A Theme, on its own, constitutes a derivative work, for the following reasons:
- A Theme is analogous to a Linux Kernel Module, which many interpret the GPL to consider as a derivative work.
- A Theme is designed to work together with WordPress core, in the same address space, is loaded using the PHP include() function, and its contents are combined with WordPress core in memory, to be compiled as a single functional unit by the PHP parser.
- A Theme's PHP consists of calls to WordPress core functions and action/filter hooks, which determine entirely the output of the PHP.
- A Theme interacts with WordPress in exactly the same way that WordPress interacts with itself.
- A Theme is wholly dependent upon WordPress, and on its own does not constitute an original work.
- A Theme, even if not derivative of WordPress core, is almost certainly derivative of pre-existing WordPress themes.
Arguments Opposed to GPL Inheritance of WordPress Themes and Plugins
I'll begin with two posts by attorney Michael Wasylik, to whom Matt Mullenweg affectionately and incessantly refers as a real estate attorney, from rural Florida. 6 Wasylik first argues that Themes are not derivative of WordPress code. 7, and then argues that, even if they were, their distribution would fall squarely within a fair-use defense against infringement (which is mostly out of the scope of this post, though I link to it for further reference). Ruby On Rails developer Drew Blas, in his introduction to a blog post discussing the Thesis theme's incorporation of core WordPress code, explains why he doesn't believe Themes to be inherently derivative of WordPress. 8 PHP consultant and co-founder of php|architect magazine Marco Tabini offers his argument against WordPress themes being derivative. 9
General GPL Derivative-Work Arguments
Another attorney, Lawrence Rosen, former general counsel for the Open Source Initiative (OSI) who specializes in "intellectual property protection, licensing and business transactions for technology companies", offers a fairly strong general argument that, when applied to WordPress plugins and themes, would seem to refute the argument that they are derivative. 10. He restates similar arguments in this OpenMag article (article reprint at SitePoint). 11 Here, Novell weighs in on the meaning of derivative works in the context of GPL. 12 The University of Washington Law Center provides an incredibly in-depth look at several use-case scenarios with respect to GPL and derivative works 13, coming to the apparent conclusion that mere linking, without incorporation, does not cause a work to be considered a derivative.
Summarizing The Arguments
- WordPress is non-compiled code; therefore by definition, no static linking exists between WordPress core and Themes.
- A Theme is generally distributed as a standalone product, and not bundled, aggregated, or in any way combined with WordPress; therefore, in order to be derivative, a Theme must, on its own, constitute a derivative of WordPress. A Theme, on its own, does not constitute a derivative of WordPress, for the following reasons:
- A Theme that uses only function/global variable calls and action/filter hooks does not modify core WordPress code in any manner.
- A Theme merely interacts with WordPress core using mechanisms of interaction in the manner intended by WordPress developers.
- A Theme interacts with WordPress and modifies WordPress data structures in a transitory, rather than permanent, manner.
- A Theme modifies the presentation of user data, but WordPress core does not own copyright for user data; thus, any modification of presentation of user data does not cause a Theme to be derivative of WordPress core.
Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them.
What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
When WordPress is started, it executes various routines that prepare information for use by themes. In normal use, control is then transferred via PHP’s include() function to HTML and PHP templates found in theme package files. The PHP code in those template files relies on the earlier-prepared information to fill the templates for serving to the client.
On the basis of that version of WordPress, and considering those themes as if they had been added to WordPress by a third party, it is our opinion that the themes presented, and any that are substantially similar, contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works. Specifically, the CSS files and material contained in the images directory of the “default” theme are works separate from the WordPress code. On the other hand, the PHP and HTML code that is intermingled with and operated on by PHP the code derives from the WordPress code.
The PHP elements, taken together, are clearly derivative of WordPress code. The template is loaded via the include() function. Its contents are combined with the WordPress code in memory to be processed by PHP along with (and completely indistinguishable from) the rest of WordPress. The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called. They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combined with WordPress into a larger work.
Mark Jaquith gives the most thorough and straightforward technical argument for WordPress Themes being derivative of WordPress:
Is a theme separate from WordPress?
There is a tendency to think that there are two things: WordPress, and the active theme. But they do not run separately. They run as one cohesive unit. They don’t even run in a sequential order. WordPress starts up, WordPress tells the theme to run its functions and register its hooks and filters, then WordPress runs some queries, then WordPress calls the appropriate theme PHP file, and then the theme hooks into the queried WordPress data and uses WordPress functions to display it, and then WordPress shuts down and finishes the request. On that simple view, it looks like a multi-layered sandwich. But the integration is even more amalgamated than the sandwich analogy suggests.
Here is one important takeaway: themes interact with WordPress (and WordPress with themes) the exact same way that WordPress interacts with itself. Give that a second read, and then we’ll digest.
The same core WordPress functions that themes use are used by WordPress itself. The same action/filter hook system that themes use is used by WordPress itself. Themes can thus disable core WordPress functionality, or modify WordPress core data. Not just take WordPress’ ultimate output and change it, but actually reach into the internals of WordPress and change those values before WordPress is finished working with them. If you were thinking that theme code is a separate work because it is contained in a separate file, also consider that many core WordPress files work the same way. They define functions, they use the WordPress hook system to insert themselves at various places in the code, they perform various functions on their own but also interact with the rest of WordPress, etc. No one would argue that these core files don’t have to be licensed under the GPL — but they operate in the same way that themes do!
It isn’t correct to think of WordPress and a theme as separate entities. As far as the code is concerned, they form one functional unit. The theme code doesn’t sit “on top of” WordPress. It is within it, in multiple different places, with multiple interdependencies. This forms a web of shared data structures and code all contained within a shared memory space. If you followed the code execution for Thesis as it jumped between WordPress core code and Thesis-specific code, you’d get a headache, because you’d be jumping back and forth literally hundreds of times. But that is an artificial distinction that you’d only be aware of based on which file contained a particular function. To the PHP parser, it is all one and the same. There isn’t WordPress core code and theme code. There is merely the resulting product, which parses as one code entity.
But it’s still in separate files!
I don’t think that matters. Linux Kernel Modules likewise are in separate files, but they’re considered by most to be derivative. If that argument doesn’t convince you, then note that the vast majority of themes derive from the original WordPress core themes. How they load different PHP subfiles, loop through posts, and get and interact with WordPress data is all covered by the original WordPress core themes, which are explicitly GPL. But I don’t think we need to resort to that argument, because of the way that themes combine with WordPress to form a modified work.
WordPress has many external APIs that spit out data. Interacting with these APIs does not put your code on the same level as core WordPress code. These APIs include Atom, RSS, AtomPub, and XML-RPC. Something that interacts with these APIs sits entirely outside of WordPress. Google Reader doesn’t become part of WordPress by accessing your feed, and MarsEdit doesn’t become part of WordPress when you use it to publish a post on your WordPress blog. These are separate applications, running separately, on separate codebases. All they are doing is communicating. Applications that interact with WordPress this way are separate works, and the author can license them in any way they have authority to do so.
This is a wholly different model of interaction than with themes. Themes are not standalone applications. They are scripts that become part of WordPress itself, and interact with WordPress on the same level that WordPress interacts with itself.
The fact that themes don’t come bundled with WordPress is merely a result of WordPress’ flexible plugin/theme architecture and how non-compiled scripting languages like PHP work. The PHP opcode is compiled on the fly, so you can distribute portions of a WP+Plugins+Theme application piece by piece, and they’ll dynamically combine into one application.
Theme code combines with WordPress code in a way that makes them one functional unit. This is what makes WordPress themes so powerful and flexible. Themes cannot stand by themselves, and are dependent on deeply integrating their code with WordPress core code in order to function at all. They cannot reasonably be considered original works. As such, theme PHP code (and any CSS/JS code that is derived from GPL’d code) must be licensed under the GPL if it is distributed.
Drew Blas has a thoughtful post where he compares WP themes to Linux applications and likens declaring themes as derivative the equivalent of declaring Linux applications as derivative. I left a few comments on his post noting that a more apt comparison is with Linux Kernel Modules (LKMs) rather than applications running on top of Linux. Linux applications are more comparable to XML-RPC clients that use WP’s XML-RPC API. Neither Linux applications nor XML-RPC clients are considered derivative. LKMs, however, are considered by many Linux developers to be derivative works. LKMs load directly into the running kernel and have direct access to internal data structures and APIs. WP themes are the same way. They load directly into WP and have access to WP internals. The distinction between the different classes of interactions is important when discussing the letter of the GPL as well as the general spirit in which many authors of open source software regard modules, themes, and plugins that extend their works.
I’ve not followed Linux kernel development closely for the past few years, but as far as I know the debate over LKMs never definitively resolved itself. A system was put in place where LKMs could declare their license using a MODULE_LICENSE macro. Licenses that are not GPL-compatible “taint” the kernel. Many Linux developers will not assist with tainted kernels. I doubt we would do something similar with WordPress. Many WP developers already refuse to help with proprietary themes. Adding some API doesn’t help clarify anything. Unfortunately, the only thing that would is a lawsuit that goes the distance.
The thesis_comment class extends upon WordPress code and provides additional functionality. It is not just calling WordPress functions. That in my opinion makes it derivative work, not simply dependent work, and therefore violates the GPL.
- If I may address - and dispense with - the salience of that attempt to discredit Wasylik's opinion: Wasylik spends 5% of his time on copyright infringement - which I daresay is infinitely more than the amount of time spent by Matt in any form of litigation, copyright or otherwise. Also, what Wasylik living in "rural Florida" has anything to do with the credibility of his opinion, I haven't the slightest clue. But Wasylik was raised in Tampa, FL; has a bachelor's degree in Political Science from Northwestern University and a Juris Doctor from Florida State University; has done legislative work for the U.S. House and Senate; and has worked for law firms in Washington, D.C. and Virginia. ↩
But is it enough to say that a theme calls to WordPress functions or that it is somehow “combined with WordPress code in memory”? Does that make it a derivative, and therefore covered, work under the law and the GPL?
There are plenty of reasons to disagree with the expansive GPL view expressed above. First and foremost, it’s just not enough to say that themes running on top of, and using function calls from, a piece of software are “derivative” of that software. If that were the case, then any software application would be a derivative work of the operating system it runs on – such as Windows, Linux, or OS X – which in turn would be a derivative work of the software hard-coded into the chips running the computer. For that is the way all software works, down to the bare iron – it sits on top of, and makes function calls to, the software layer beneath it, until to get down to the silicon pathways in the chip itself. No software could run without those lower layers, and nothing is truly independent of them. But “dependent” and “derivative” are not the same thing.
Instead, copyright law takes a very pragmatic approach to determine what constitutes a derivative work.
The alleged derivative must “physically incorporate a portion of a copyrighted work… [or] supplant demand for a component of that work.”
In the case of Lewis Galoob Toys, Inc. v. Nintendo of America, Inc., 964 F. 2d 965 (9th Cir. 1992), a federal appellate court considered that very issue. Galoob manufactured a “cheater” cartridge that plugged into Nintendo games, between the game cartridge and the game unit itself, and allowed the player to change the game’s parameters – for example, players could give themselves unlimited lives using Galoob’s device. Nintendo sued Galoob, claiming that the devices violated Nintendo’s copyright in the games as a derivative work of the games.
The Galoob court rejected Nintendo’s argument. In order to be considered a derivative work, the alleged derivative must “physically incorporate a portion of a copyrighted work… [or] supplant demand for a component of that work.” Galoob at 969. Finding that Galoob’s device did neither, the court determined that there was no derivative work.
An important part of the court’s analysis was that “technology often advances by improvement rather than replacement.” Id. The court also noted that software often depends on other software to function:
Some time ago, for example, computer companies began marketing spell-checkers that operate within existing word processors by signalling the writer when a word is misspelled. These applications, as well as countless others, could not be produced and marketed if courts were to conclude that the word processor and spell-checker combination is a derivative work based on the word processor alone.
Id. Applying that theory to the Galoob device, the court concluded:
The Game Genie is useless by itself, it can only enhance, and cannot duplicate or recaste, [sic] a Nintendo game’s output. It does not contain or produce a Nintendo game’s output in some concrete or permanent form, nor does it supplant demand for Nintendo game cartridges. Such innovations rarely will constitute infringing derivative works under the Copyright Act.
Using that rationale, the question of whether WordPress themes are “derivative” of WordPress itself becomes more clear.
- Does a theme, rather than simply calling a WP function, incorporate actual code from WordPress?
- Does it somehow supplant the demand for the WordPress software itself?
If the answer to either of those questions is “yes,” then the work is probably derivative, and the GPL probably applies. If not, then even a theme or plugin that entirely dependens on WordPress to run at all, or simply improves WordPress in some way, would not be a derivative work and the GPL would not apply. For the vast majority of themes I’ve seen, the GPL would not apply because the theme is not, in my opinion, a derivative work. (In fact, if any one thing “incorporates” another, it’s most likely WordPress incorporating the theme, by use of the PHP include() call, rather than the other way around.)
The long and short is that SFLC’s opinion could be applied to any software that runs on Linux. Meaning you could never have a closed-source software product running on the linux kernel (“Oh, your code calls fork()? GPL!”). It is commonly accepted that simply integrating with an existing product does not produce a derivative work. If your code is totally your own, the GPL has no say over how you license it. This is actually an argument about fair-use far outside just the GPL and has been settled on many different topics including OEM car parts, Nintendo, iPod connectors and other questions of being allowed to build something that interoperates with someone else’s product. Per the GPL itself a derivative work is: “a work containing the Program or a portion of it, either verbatim or with modifications” so you must copy actual lines of code from their source to be a derivative work. Simply calling WordPress functions doesn’t cut it.
Personally, I find the SFLC’s argument very weak from a technical standpoint—particularly in the citation of the use of include (which is not a function) as justification for their claim that themes are derivative works. Includes are designed specifically to create interoperability between different programs—in the world of PHP, where there is no concept of “binary,” they are the equivalent of dynamic linking.
One would have to physically copy code between projects, or physically include files from another project in a new work, in order to create a derivative work in this context, and to claim that themes do this is simply ridiculous because WordPress is designed to be expanded in precisely the way that themes are developed. To impose the GPL on themes—unlike, say, imposing it on a fork of WP itself, which would be perfectly logical—is to restrict a developer’s ability to interact with a particular piece of software and this would constitute an artificial limitation on a developer’s ability to interact with WordPress, which could give grounds to a fair-use claim.
Does it matter what technical form of linking you use? Or is that analysis (e.g., static linking, dynamic linking, passing data through an API, as an object contained within a larger object, etc.) a technical morass that obscures the fundamental issue? How can the law of derivative works keep up with technological change in the world of software engineering?
These questions are important because some licenses require you to publish the source code of your portion of the resulting derivative work program, a burden you may not want to accept. Here's how I would decide in the cases described above.
- The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work.
- The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.
- Derivative works are not going to encompass plugins and device drivers that are designed to be linked from off-the-shelf, unmodified, programs. If a GPL-covered program is designed to accept separately designed plugin programs, you don't create a derivative work by merely running such a plugin under it, even if you have to look at the source code to learn how.
- In most cases we shouldn't care how the linkage between separate programs was technically done, unless that fact helps determine whether the creators of the programs designed them with some apparent common understanding of what a derivative work would look like. We should consider subtle market-based factors as indicators of intent, such as whether the resulting program is being sold as an “enhanced” version of the original, or whether the original was designed and advertised to be improvable “like a library”.
(Emphasis in original)
Simply combining a copyrighted work with another work does not create a derivative work. The original copyrighted work must be modified in some way. The resulting derivative work must itself “represent an original work of authorship.” So if the licensee does not modify the original GPL-licensed program, but merely runs it, he is not creating a derivative work.
Consider the scenario where the Linux operating system, a GPL-licensed program, loads and executes a proprietary program. The Linux program is not modified; it is merely used for the purpose for which it was designed. The proprietary program does not “contain” nor is it “derived from” Linux. Linux does not infect the proprietary program, and the proprietary program does not become subject to the GPL.
Software experts distinguish among various forms of program linking to create a combined program. Static linking requires a modification to the code of one program to allow it to link to another program. Such a modification, since it requires changes to the source code of the linking program, arguably creates a derivative work. If the linking program is licensed under the GPL, then the derivative work also becomes subject to the GPL.
Dynamic linking, on the other hand, is a transitory relationship between two programs for which they are each predesigned. The linking program need not be modified to implement the linkage. For example, a printer driver for a new printer can be installed in a program without modifying the source code of the original program. Such linkage does not constitute the creation of a derivative work.
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."
To quote everything of value would require quoting the entire article. Selections are below, but this one is a must-read, in its entirety.
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'.
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.
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.