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
WordPress-Specific Arguments
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.
Notes:
-
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.
On APIs
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.
...
Conclusion
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.
WordPress Themes, GPL, and Copyright Case Law – http://www.chipbennett.net/2010/07/wordp…
@chip_bennett well written chip, I enjoy it and you made it clear 🙂
@chip_bennett well written chip, I enjoy it and you made it clear 🙂
@ryanriatno thanks! I appreciate that. And thanks for the RT.
RT @chip_bennett: WordPress Themes, GPL, and Copyright Case Law – http://www.chipbennett.net/2010/07/wordp…
@chip_bennett Following your Midway argument, a theme *is* a physical replacement for a core component — the default theme.
@nacin a theme is transitory, not permanent. So, I don’t see it being analogous to a physical-replacement circuit board.
@chip_bennett I don’t see the distinction. Guess I’ll have to look it over again.
@nacin consider, especially, Sega and Sony, where both an emulator and third-party games were both considered to be not infringing.
@nacin p.s. how do you like Simple Footnotes in action there?
@chip_bennett Me likey, though I think you’re pushing their limits a bit 😉 I like how WP enables them to effortlessly work across pages.
@nacin that was one of the things I wanted to test – but is there a way to make the notes display *below* the pagination links?
@chip_bennett Not easily. It simply hooks into the_content. Can’t detect page links as they typically occur later. One option is a…
@chip_bennett … is a simple option that allows you to have them wait until after page links. Also considering an option for markup etc.
@nacin are there any hooks around wp_page_links?
@chip_bennett Yeah, I can filter the after arg.
@chip_bennett Yeah, I can filter the after arg.
@chip_bennett Yeah, I can filter the after arg.
@chip_bennett Yeah, I can filter the after arg.
@chip_bennett Got a beta version for you. The zip hasn’t refreshed yet, but http://plugins.trac.wordpress.org/browse… (there’s a download link at the bottom)
@nacin awesome! I will test it tomorrow. Way past my bedtime.
@nacin awesome! I will test it tomorrow. Way past my bedtime.
@chip_bennett Look under Settings/Reading. Also, it’s smart enough to still display footnotes when there is only one page (& thus no links).
@nacin oh, that’s slick! Just perfect. I’ve implemented it, and think it works much better. Take a look.
@chip_bennett incredible article! http://www.chipbennett.net/2010/07/wordp…
RT @chip_bennett: WordPress Themes, GPL, and Copyright Case Law – http://www.chipbennett.net/2010/07/wordp…
@chip_bennett Good post Chip, you are quite the researcher. Should be interesting if it goes to court. #wordcase #wordcourt
RT @chip_bennett: WordPress Themes, GPL, and Copyright Case Law – http://www.chipbennett.net/2010/07/wordp…
RT @chip_bennett: WordPress Themes, GPL, and Copyright Case Law – http://www.chipbennett.net/2010/07/wordp…
RT @chip_bennett: WordPress Themes, GPL, and Copyright Case Law – http://www.chipbennett.net/2010/07/wordp…
RT @chip_bennett: WordPress Themes, GPL, and Copyright Case Law – http://www.chipbennett.net/2010/07/wordp…
Like I said earlier. Excellent just excellent. or was it awesome? =)
You are an excellent writer I must say.
This really is how one must approach this subject. Find case law, talk about how things interact and why different cases is pro or against a certain interpretation.
Now I’m awaiting an as detailed response from the themes/plugins are GPL camp. They really need to step up since none of the themes are GPL articles/posts comes even close to the depth of this article.
From what I’ve understood the WP core crew are going to present their view on things on WP.org. I hope their pro-GPL article is as well researched as this one and includes references etc to cases that is in favour of their interpretation. Given that the only source of their arguments for at the moment is an biased response from SFLC the really need more unbiased sources.
I’d absolute describe a WordPress code extensions (themes or plugins), as “elaborations, or other modifications.” Themes necessarily have WordPress code in them. They necessarily use code from the original (and GPL’d) WordPress themes. Plugins and themes absolutely “transform” and “recast” the WordPress application. That’s what makes them so great!
In the end, neither of us are lawyers, and even if we were, this is new legal territory. Actually, it’s rather exciting to be involved in a passionate debate over something new like this that could have such broad-reaching implications, wouldn’t you say?
I regard a WordPress extension, as an “elaboration” of WordPress code. You may consider it to be a separate work that is not at all “based upon” WordPress. It doesn’t sound like either of is coming closer to changing the other’s mind. We’ll see how it shakes out, I guess!
P.S. how is this post shorter than the comments you left on mine? 😉 I kid, I kid.
P.P.S. No website left because your OpenID functionality was just hanging when I tried.
Totally missed the other pages. I take back my comment about brevity!
Mark,
Thanks for stopping by and taking the time to read and comment. I agree that it is indeed exciting to be involved in such a passionate debate – though I appreciate that we can discuss such controversial and potentially incendiary topics as dispassionately as possible.
As I said up front: I have no problems with the GPL, and appreciate the benefits it has provided to me. But, I also see a community benefit to discovering the truth, which I believe will cut through the emotional and sometimes propagandistic rhetoric (from both sides of the debate), so that it can cease being a source of division for the community.
What I specifically wanted to look at with this post is not the logical or common-sense arguments, but what the courts have had to say on the matter. With something like copyright, in a common-law jurisdiction like the U.S., the law is written fairly open-ended, and the specifics are defined by court decisions. So, we can debate the logical and common-sense arguments into eternity, but what really matters is the reasoning behind the various court decisions involving copyright – and especially those involving software copyright.
And, as I said in the post: I don’t see copyright case law supporting the argument that themes are derivative of WordPress because they are “elaborations” or “modifications” of WordPress. I’d love to hear another interpretation of this or other copyright case law, that would support such an argument.
I agree that neither of us is a lawyer, and I would certainly welcome a lawyer explaining how I am misinterpreting the cases I’ve cited (or, for that matter, backing me up on that interpretation!). Regardless, I find it interesting – and instructive – for us to discuss these decisions, even as laymen.
(And I do apologize for getting overly wordy in my post and in my comments.) 😉
p.s. thanks for the OpenID heads-up. I’ve not checked in on it for a while. I’ll go do some investigation, and figure out what’s wrong.
@Mark:
Are the footnotes obscuring the pagination? I’m still experimenting with both.
Hell of an article Chip!
Can’t wait to see if there’s an outcome on this topic from the potentially upcoming Matt vs Chris legal battle.
Chip:
As I said on Twitter — well done.
While I, too, am sympathetic to the GPL side of things, the more I read, the less convinced I am that the Foundation, Matt, et al. would prevail if they take Chris up on his request to be sued. There are simply too many factors, including the necessity of a technically-competent jury, to declare a potential suit as an easy win and the substantive downsides to a loss are indeed severe.
Trying my comment again, now that I’ve seen pages 2 through 4.
I’d absolute describe a WordPress code extensions (themes or plugins), as “elaborations, or other modifications.” Themes necessarily have WordPress code in them. They necessarily use code from the original (and GPL’d) WordPress themes. Plugins and themes absolutely “transform” and “recast” the WordPress application. That’s what makes them so great!
Why the distinction on static linking? PHP is compiled into bytecode on the fly (or, not on the fly in the case of using a PHP opcode cache). PHP code can also be compiled. Why should that make a difference? I don’t think the compiled or non-compiled nature of the code, or the file in which code is contained, makes it any more or less separate, as they all are all one as one application. Not WordPress and a Theme communicating or interoperating, but running together as one functional unit (etc, you’ve read my post).
The add-on was separate hardware that allowed the user to change three 6- or 8-byte values. It’s hardly on the level of a theme or a plugin which can change entire swaths of code, add new functionality, or disable existing functionality. In terms of modification, the Game Genie was about the equivalent of an air horn and “timing codes” so social conservatives can bleep out or distort swears in songs. And it’d only work three times a song, so it’d be useless against Kid Rock (ZING).
It was a 24 byte one-way filter, completely external to the game. It didn’t even have the ability to add or remove code — only flip one of 192 light switches into a different position. It’s a far more subtle form of modification than WordPress extensions have.
From what I can tell, Accolade did not substantially incorporate that code into their work. Sega was saying that Accolade privately converting decompiling their code was infringement, even though they never distributed it (at least, not substantially). That’s not what we’re saying.
To be clear, expression means code, in this case. The implementation of an idea. So the idea of filters is not copyrightable. WordPress’ filter implementation is.
I think Thesis would fail this test (that is, it would bear substantial similarity). There may be a gray area where themes that don’t do much in their code and just display a list of posts have less similarity than themes which integrate themselves more tightly into WordPress code. We’d have to see how it went in court.
This is the crux of our disagreement. I do not consider them mechanisms of interoperability. They are mechanisms of changing WordPress. They are WordPress itself! WordPress has external APIs for interoperability. RSS, Atom, AtomPub, XML-RPC. If you want to look at the Sega case, having someone look at WordPress source code in order to figure how to interoperate with those APIs wouldn’t violate the WordPress copyright.
The HTML is a distraction. That’s not really the issue. It’s the PHP code.
Again, there may be gray area here where “basic PHP” is evaluated by courts differently than something like Thesis. Coincidentally, and tangentially, the integration with WordPress is roughly proportional to the benefit that would come from it being freely licensed, and as well proportional to the extent to which an anti-GPL theme developer might feel inclined to give a restrictive user license. No one would sue because of a
foreachloop. 🙂Anyway, thanks for writing this. It seems very much in the spirit of my post (the difference being that my post being more of a technical analysis, this being more of a legal exploration). It’ll take a court case to look at both technical and legal aspects and give us a conclusive answer. It was interesting reading all these other cases, but I think what they make most clear is that copyright in the digital age is complicated, and there is still a lot of legal ground yet to plow.
I really do have to disengage from this whole debate. I just got in trouble with the Mrs. for spending so much time on it! I’m going to go back to coding with WordPress and releasing everything I distribute under a non-restrictive license. It’s easy to forget that beneath the bickering and the mountain of legal and technical minutia, there’s an amazing and fun publishing platform that was downloaded 10 million times in the last month! 🙂
Great piece! Incredibly well researched and thought out.
I agree with you that Themes are not derivatives and are effectively a working example of “fair use”.
One thing I am struggling to get a grip on and your opinion would be interesting is, what exactly is WordPress protecting under the GPL? What is the copyrightable material?
For example, the functions and things to make database calls or do screen layouts are not necessarily able to be covered and the output content belongs to the users. Most of what WordPress does is to shunt data to and from a database or organise the user’s data for presentation.
So I ask, what exactly is covered?
I also think your analysis on “loss” is excellent. As I’ve said on Twitter, themes are additive in their impact to the product so there really can’t be “loss” and therefore no damages. Would you agree?
Excellent stuff.
@Doug Stewart:
I think, even more so now, that Thesis is a special case, due to the extent of copying of core WordPress code. (Note: I don’t know what that extent is alleged to be, fully.) Interestingly, the Altai decision certainly implies that Thesis can be held accountable for infringement for version X.Y, even while version X.Y+1, which presumably has all core WordPress “copy pasta” removed, is held not to be infringing.
But, I don’t think even Thesis would be a “slam dunk” case, because I don’t know what result the court would get from an Abstraction-Filtration-Comparison test. It is entirely conceivable that the court could rule either way (again: not knowing the full extent of what was copied from core into Thesis).
If Thesis were ruled to be infringing, I don’t think the ruling would have that much reach into other Themes. But, if Thesis were ruled not to be infringing, the results would be devastating for advocates of GPL inheritance.
@Mark Jaquith:
I appreciate your (as usual) thoughtful reply. I’ll incorporate your thoughts into the response it deserves, as free time, and its appropriate use, allow.
@Sean Kaye:
Note: I believe themes are not inherently derivative. Unless and until a court actually considers a specific Theme, it will be difficult to say anything more definitively.
Thesis is a good example: a court will have to determine if the “copy pasta” code constitutes infringement of copyrightable expression from WordPress core. I couldn’t even hazard a guess as to how that would turn out, because such a suit would be unprecedented, and because I’ve not seen the exact details.
Here’s one quick-and-dirty example that I thought up: Widgets.
The idea of Widgets isn’t copyrightable, and likely, WordPress’ specific means of implementation of Widgets isn’t, either. However, WordPress’ expression of Widgets – i.e. the specific Widgets defined in core – would likely be copyrightable.
Another example: Comments.
The idea of Comments isn’t copyrightable, and, likely, WordPress’ specific means of implementation of Comments isn’t, either. However, WordPress’ expression of Comments – i.e. the code defined by wp_list_comments() function call – would likely be copyrightable.
So, a court probably wouldn’t consider using WordPress’ defined mechanism of filtering wp_list_comments() to constitute a derivative work; however, a court very likely would consider the wholesale incorporation of wp_list_comments() to be derivative.
In the post, I didn’t get into any of the relief specified by copyright law. It is likely a topic for its own post (if necessary). But, in brief: relief in a copyright infringement case isn’t necessarily dependent upon loss or damage incurred by the owner of the infringed work. The Act specifies statutory damages based solely upon the severity of the infringement, and that can be awarded at the court’s discretion. So, Thesis could be subjected to statutory fines, regardless of any loss incurred (or not) by WPF.
And thanks for reading!
@MikeWas I referenced your WordPress Theme/GPL derivative analysis post here: http://www.chipbennett.net/2010/07/20/wo… (would love your input)
@chip_bennett has an outstanding, thorough, clear, and scholarly post on the GPL debate: http://www.chipbennett.net/2010/07/20/wo… #gpl
@MikeWas thanks for the retweet! I appreciate it.
Your “not a contract” claim is erroneous:
“It is important to understand that, because the GPL explicitly
defines any activity not involving distribution to be out of the
scope of the license, and since right of distribution is solely
derived from copyright law, that GPL derives its legal basis from
copyright law alone. This distinction separates the GPL from most
other traditional software licenses, which derive their basis for
usage and modification restrictions not from copyright law, but
from contract law.”
The principle that a license is a contract was established by the
Supreme Court in DE FOREST RADIO TEL. CO. V. UNITED STATES, 273 U.S.
236 (1927). http://supreme.justia.com/us/273/236/case.html
“No formal granting of a license is necessary in order to give it
effect. Any language used by the owner of the patent or any conduct
on his part exhibited to another, from which that other may properly
infer that the owner consents to his use of the patent in making or
using it, or selling it, upon which the other acts, constitutes a
license, and a defense to an action for a tort. Whether this constitutes
a gratuitous license or one for a reasonable compensation must, of
course, depend upon the circumstances; but the relation between the
parties thereafter in respect of any suit brought must be held to be
contractual, and not an unlawful invasion of the rights of the owner”
This contract principle applies specifically to copyright licenses:
“Although the United States Copyright Act, 17 U.S.C. 101 – 1332,
grants exclusive jurisdiction for infringement claims to the
federal courts, those courts construe copyrights as contracts and
turn to the relevant state law to interpret them.”; Automation by
Design, Inc. v. Raybestos Products Co., 463 F.3d 749, (United
States Court of Appeals for the Seventh Circuit 2006).
http://ftp.resource.org/courts.gov/c/F3/463/463.F3d.749.05-1172.html
No federal court in the past eighty-three years has ever ruled that a
copyright license is anything other than a contract. Eben Moglen’s
assertion that “licenses are not contracts” is simply untrue under U.S
law. A copyright license is either an enforceable contract or it’s not
a valid license.
@RJack,
I actually never said that the GPL isn’t a contract. To claim I made a “not a contract” claim is a mis-characterization of my point, which was that, in granting an implied license of unrestricted use (modifying, copying, et al) except in the case of distribution, the GPL eschews all protections granted by contract law outside of copyright law.
The GPL is basically a modified Public Domain license, that grants full usage rights to the end user, and only imposes the restriction that any distribution be released under the same license. Explicitly stating everything other than distribution as out of scope causes the GPL to derive its enforceability solely from copyright law, rather than contract law in general.
Hopefully that clears up the mis-conception.
WP extension does not elaborate or modify WordPress it self. Only the information created by the end user. No code is ever added, altered or removed from WP core.
Using code would mean for loops, if statements etc. They don’t necessarily use actual code from original themes. Then comes the question if traversing an array is copyrightable. Also ain’t there fair use principle. If the application is meant to be extended and you have to study its code to extend it sounds odd that use of the codelayout and function names would be enough to inherit GPL.
Thing here is that they don’t recast and transform WordPress application. They transform the information inputted by the end user. Themes/Plugins are also loaded by WP. Not the other way around.
Dynamic linking is considered by many to be allowed. Not by the biased FSF how ever.
GPL#Linking and derived works
It is a matter of when and how it happens. It is done by the end user, not by the developer/distributor. The end user is the one that creates a derivative work by your own admission but it is not distributed so the GPL does not come into effect.
Show me one piece of theme/plugin code that alters the actual WP core code and not what the functions return? Theme/plugins uses the turn on/off switches that is already in WP core code. They does not alter any code to make it work. If I remodel a keyboard to be an arcade control and then use that with a game meant for keyboards have I altered the game? If I change which keys the game should listen to through the interface the game provides have I altered the core code of the game?
Which theme/plugin adds and removes WP core code? By your own admission themes/plugins can turn off/on functions through the interface WP it self provides. No alteration of core code required.
Problem is the vague definition of an API and that you really have different definitions of it depending of the situation. In essence WP itself is a framework meant to be interacted with or a platform as Matt has called it.
If its a platform then the systems library exception could come into effect.
You’re attempting to create new copyright law. The “distribution” of a derivative work as a whole is a matter of contract law. 17 USC § 106(2) governs only “preparation” of derivative works. The Copyright Act is silent concerning the distribution of derivative works as a whole.
There are two distinct copyright owners in a newly created derivative work:
17 USC § 103. Subject matter of copyright: Compilations and derivative works
(b) The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material.
Absent a valid contractual agreement between the two distinct owners (preexisting and modifying) of their respective copyrights, no derivative work as a whole may be distributed.
The GPL cannot create a new right or scope restriction concerning distribution of derivative works as a whole — that is the sole province of Congress.
@RJack
I’m not disputing that GPL gains its validity under contract law. Clearly, it does.
Rather, I’m saying that the exclusive right to make and distribute a work, or a derivative of that work, derives from copyright law, and that any other protections otherwise afforded by contract law have been eschewed by the implied license granted by virtue of the GPL. (In fact, most of the exclusive rights protected by copyright law have been eschewed by this same implied license.)
Again: IANAL. I’m not understanding how we are saying vastly different things, or how the differences in what we are saying in any way impact the overall analysis?
“Show me one piece of theme/plugin code that alters the actual WP core code and not what the functions return?” ~ Andreas Nurbo
So code must modify the original program’s source code at runtime to be derivative? So I can copy code and modify it in my program as long as I don’t have the program write the changes back to the original source? Ridiculous. (And plugins have used preg replace for that)
By the way, WordPress “provides “the interface” “for turning off/on functions” for it’s own use. Derivatives are by definition WordPress. WordPress and it’s licensed derivatives are the only programs which can legally use the internal APIs and interfaces in a distribution.
@Ken Newman:
Clearly, if a Theme copies/pastes core WordPress code into itself, then it has incorporated code from WordPress. I don’t think Andreas is disputing that point at all. (But even then, the question for the courts would be one of whether or not the copied code constituted copyrightable expression.)
But, as for modifying “the original program’s source code at runtime”: WordPress Themes (and Plugins) do not modify WordPress core code. Do a checksum of core WordPress files, then intsall, activate, use, deactive, and uninstall a Theme – if you once again performed a checksum of core WordPress files, it would be identical to the previous checksum. Themes, by their very design, do not modify core WordPress code.
Agreed. And, as per the case law cited here, mere use of that interface – whether it is external, internal, or even if core needs to be decompiled to determine the mechanism – does not cause a work to be considered derivative. See Sega and especially Sony.
I’m not sure what you mean by this statement. Can you clarify? (And I’m not trying to be obtuse; I want to make sure I’m understanding what you’re trying to say.)
Not true. In fact, according to the cases cited, the courts will not permit, under copyright protection, artificial hurdles to be erected to prevent follow-on works from making use of another work’s mechanisms for interoperability.
I welcome any references to copyright case law that indicates otherwise; I couldn’t find it, though.
It is very refreshing to see the GPL Theme issue debated on an intellectual level without all the emotion. This article and Mark Jaquith’s are the best I’ve read for either side. I was strongly for the “themes are a derivative” side before reading this but now I am more on the fence and able to look at the whole issue with a broader perspective.
Whatever the outcome, it will be very exciting to see how this whole thing plays out. My only concern is that if WordPress and Thesis go to court we might not get a ruling on the derivative work issue since so much Thesis code was taken directly from WordPress core.
@Chip Bennett
I Think what you are saying is:
Copyright law says the rights to copy, modify, and distribute exclusively belong to the creator. You must have contracted permission to copy or create a derivative for distribution. The GPL grants contracted permission if you accept the terms.
I’m only confused by you writing “implied.” The default position (Copyright Law) is that you have no right to copy, modify, sublicense, or distribute the code. You can only gain permission through the license (Contract Law), so in order to gain that permission you must agree. It’s pretty explicit (fully and clearly expressed).
@Ken Newman
I think that’s a fair statement – with the qualifier that even copies do not fall under the scope of GPL unless distributed.
The implied license involves any activity outside of distribution (which both implies and includes copying) of the work or a derivative. In other words, the implied license involves any type of end-use activity. The license for end-use activity is implied, rather than express, because GPL explicitly states that such activity is outside its scope.
@Chris Olbekson
I lament the injection of emotional appeal into the discussion, as it doesn’t help the community find the truth, and come to a conclusion or compromise. So, I try to avoid emotional appeal whenever possible.
As for a potential lawsuit against Thesis: it depends on the approach of the suit. I see many similarities to Altai here, since presumably any plagiarized code in Thesis 1.7 (or whichever) will be removed in Thesis 1.8. So, the lawsuit could seek in infringement claim on the two versions individually – just as Computer Associates did against Altai.
In that case, the court would (hopefully) decide on the merits of each version (with plagiarized code, and without) separately – giving us some resolution on the question of whether or not Themes are inherently derivative of WordPress.
That’s a misread of the case law.
The Sega issue was, first, making a copy for testing, learning (fair use) and then second, whether a password was copyrightable or available for distribution. Doesn’t really aply well when you understand that a password file deliberately set up to block interoperability and an internal API aren’t even close with regard to this case.
As for Sony, “The court determined that the BIOS represented non-copyrightable tools necessary for implementation of creative expression, and that they cannot be used as artificial barriers or hurdles to fair use.” Again, it’s about fair use. (Creative expression is fair use) How is WordPress’s internal workings (like Sega’s password file) “artificial barrier to fair use”?
(A commercially distributed theme isn’t fair use. Using internal APIs outside of the license isn’t an example of fair use, because the license is permissive to fair use.)
Each of these cases deal with fair use, and intentional artificial barriers to fair use but Every fair use scenario is covered and allowed by the GPL. There is no barrier to fair use with GPL.
The case law you cite actually supports the opposite of what you presented.
@Ken Newman:
This conclusion isn’t supported by the facts – and decision – of the Sega case. Quoting again from Douglas Hass:
The parallels here should be clear. The application of copyright law here isn’t a matter of fair use, but of the right of developers to create compatible, follow-on works that interoperate with a protected work. It’s not a matter of fair use, because those compatible, follow-on works aren’t derivative.
@Ken Newman:
Look also at the wording of the decision itself. To wit (at 1523):
Here, the alleged infringement was the decompiling of the video game object code – which would not be an infringement under GPL. Nevertheless, consider the court’s reasoning: the “growth in creative expression” resulting from additional Sega-compatible video games, is “precisely” what “the Copyright Act was intended to promote.” The “creative expression” of additional video games is directly analogous to the “creative expression” of additional WordPress themes.
Further, with respect particularly to the PHP required to render a WordPress theme, consider this part of the decision (at 1524, citations omitted):
This reasoning, by my reading, refutes Mark Jaquith’s contention that the code itself is the “expression”. The code itself does not exist as a means unto itself, but rather as a means to carry out some function, purpose, or other creative expression. In order to determine what parts of WordPress’ core code are copyrightable as creative expression, it will first be necessary to define, at varying abstraction levels, the purpose of WordPress.
(I gave some examples above. See: Widgets, Comments.)
And finally (at 1527-1528):
If the “finished products” – i.e. Accolade’s Sega-compatible video games were derivative works, and therefore infringing on Sega’s copyright, why was this point not argued and decided upon the District Court’s remand of the decision? if Accolade’s Sega-compatible video games, that incorporated the functional requirements of Sega’s video games in order to achieve interoperability with the Sega console, were not derivative, then clearly, neither are WordPress themes.
Your initial premise,
“Since the copyright owner has [the] exclusive right to produce and to distribute derivative works based on the copyrighted work, the GPL intends to grant unlimited usage rights (to use, study, modify, etc.) to the end-user, while forcing follow-on developers of derivative works to release those works under the same license”
is simply untenable under U.S. law. As I previously stated, the GPL is a contract between a preexisting author and a modifying author. The “follow-on developers of derivative works” to which you refer are the “… all third
parties under the terms of this License” referred to in the GPL’s sec. 2(b).
You can’t “force” those third party developers to accept the GPL’s terms.
There is a fundamental principle of contract law prohibiting the parties to a contract from binding nonparties. See, e.g., EEOC v. Waffle House, Inc., 534 U.S. 279, 294 (2002) (“It goes without saying that a contract cannot bind a nonparty.”).
This lack of privity renders the GPL unenforceable. My point concerning the unenforceability of the GPL was pointed out to Eben Moglen by Professor Robert P. Merges of the Berkeley Law School in June of 2000:
********************************************************************
“Professor Robert P. Merges of the Berkeley Law School noted some of
the problems in his “The End of Friction? Property Rights and
Contract in the ‘Newtonian’ World of On-Line Commerce” (12 Berkeley
Tech. L.J. 115), in which he describes the GPL as “informal (i.e.,
not legally enforceable) restrictions on digital content.”
Not legally enforceable?
“By its own terms, the copyleft agreement is an unusual license; at
the most basic level consider the problem of determining damages
when the licensee frustrates the licensor’s expectation of zero
profits under the contract,” writes Merges. “But what is most
significant about the agreement is that it purports to restrict
subsequent transferees who receive software from a licensee,
presumably even if the licensee fails to attach a copy of the
agreement. As this new transferee is not in privity with the
original copyleft licensor, the stipulation seems unenforceable.”
This isn’t as complicated as it sounds. “Privity” simply means party
to the contract, and it works both ways: I can sign a contract with
you whereby you give me some money and I send flowers to your
mother. If I fail to send the flowers, you can sue me, but your
mother can’t, because she’s not a party to the contract. Likewise, I
might sign an agreement with you whereby I give you some money and
in return you agree that your mother will come to my house and, I
don’t know, bake a pie some Sunday afternoon. Your mother is not
obligated to live up to the terms of the agreement, because she’s
not party to it. If she doesn’t bake the pie, I can’t sue her but I
can sue you.) Merges’s point is that the GPL isn’t an enforceable
contract because it obligates parties who did not agree to it.”
******************************************************************
http://www.linuxplanet.com/linuxplanet/reports/2000/1/
Moglen’s answer was that a license was *not* a contract.
There’s an interesting paper on the Queensland University of Technology site about Legal Issues for the use of FOSS and in particular it goes into some of the legal risk elements of the GPL. Obviously this is based on Australian law, but it is an interesting read, especially page 15.
The paper also touches briefly (without going into too much depth) about how the GPL v2 may run afoul of the Trade Practices Act here in Australia. The paper talks about warranties a bit, but the TPA is much broader than that. If something like the GPL were to run aground in Australia, it would almost certainly be with the Trade Practices Act as opposed to even Copyright Law.
There’s also a decent explanation of derivative works (as it relates to software) in the paper which is worth reading.
Something that has confused me is that the GPL FAQ says you can take GPLed code and use it for private use (to modify/study/etc.) BUT says that code running a publicly available website is hardly ‘private use’ and therefore the code should be made public as well.
@Fill,
Simply running WordPress on a publicly accessible web site is not distribution. If anything, it is most analogous to public performance. Public performance is use, not distribution, as defined by the Copyright Act. Thus, by the wording of the GPL, it is outside the scope of the license.
If the FAQ says otherwise, it’s simply wrong.
I believe you’re referring to this part of the FAQ (emphasis added):
This statement contradicts the clear wording of the Copyright Act. Distribution (covered by the GPL) and public performance (outside the scope of GPL) are clearly defined as two separate actions in the Act. Such an argument, if used in court, would not withstand even the most basic scrutiny. Public performance is not distribution, and the GPL clearly states that anything outside of distributions of copies of modified or unmodified code or its derivatives is not covered by the license.
Yep, even the FAQ itself in the next sentence suggests the Affero GPL if you want that.
Kudos on a well-written conspectus of various applicable cases in law. Nonetheless, I respectfully disagree with your ultimate conclusions. In particular, the following claim:
The problem is with the conflation of “derivative work” with “infringing derivative work”. There are actually several ways a work could be categorized:
It is not derivative.
It is derivative but not infringing (original material unprotected by copyright).
It is derivative and would be infringing, but licensing provides authorization.
It is derivative and unauthorized, but the Fair Use doctrine applies.
It is derivative and unauthorized, and it is infringing.
Two of the three rulings which you cited as supporting your conclusion (Sony and Sega) were each based upon the Fair Use defense being successfully applied to the derivative work, not that the work was deemed non-derivative. In the third (Galoob), at issue was not whether the Game Genie device itself was a derivative work, but whether its output constituted a derivative work. Galoob, in particular, seems to have no bearing on any GPL-related questions of derivative work — though of all the cases cited, Galoob seems to provide the most comprehensive general analysis of derived works.
At best, the Sony and Sega rulings suggest that the fourth category (Fair Use) might apply to linking and interaction of plug-ins or modules. That, however, is quite distinct from not being a derivative work — in fact, to reach the point of Fair Use being addressed, the work has to be considered derivative.
But Fair Use is always a fact-based analysis of a particular situation and a Fair Use defense may well be viewed in a much different light if applied to the facts surrounding a GPL-licensed program than to more traditionally licensed copyrighted works. In the Sega case, the courts maintained that allowing Fair Use derivatives provided a public benefit, a growth in creative expression, and dissemination of other creative works. Likewise, in the Sony case it was decided that NOT permitting Fair Use derivative works would make it impossible for others to compete in the marketplace.
Considering that GPL licensing directly has as its goal to promote public benefit and the sharing of creative works, while still enabling others to compete, one wonders whether the courts would ever be able to justify a Fair Use defense against it. Quite frankly, the GPL does a better job of “promoting the Arts and Sciences” than does copyright law itself; and as Fair Use is a defense against copyright holders overextending their monopoly to the point of suppressing creativity and sharing, it is a fairly weak proposition when confronting the General Public License.
GPL licensing has encouraged millions of creative and inventive minds to share their expressive works freely with society. I for one would be extremely disappointed if the courts were to ever place the commercial interests of a single individual or company above that advancement.
Nonetheless, thank you for your well-written article and for providing a background to this discussion.
Regards.
It depends on who you ask actually. One goal is that software should be free as in beer. Another is to make all software free as in freedom. Etc. Its an ideologial license really. RMS calls it a social movement.
When it comes to copyright etc there seems to be monetary aspect also.
GPL will still be doing just fine even if it doesnt extend to plugins/themes. WP and other software will still be developed etc. They just cant benefit from the code of propriety extensions and those extensions can’t use the code of the GPL software. The GPL software it self is not hurt by propriety stuff and I don’t think people would stop licensing their stuff under the GPL just because they don’t have too.
@saulgoode:
I disagree with your assessment of Galoob. It is directly applicable to WordPress core and Themes. The Theme interjects itself between WordPress core and the person viewing the content managed/output by WordPress, in order to modify the appearance of that content. Just as the Game Genie did so in a manner that was determined by the court not to be derivative, so does a WordPress Theme.
Bear in mind that, with Sega, the alleged infringing took place in the intermediary copying of object code, not in the development of Sega-compatible games. It was this intermediary copying (of the entire work, both copyrightable and non-copyrightable content), in order to reverse-engineer the Sega game in order to define the methods of interoperability, that was deemed to be a fair use of a protected work.
In fact, the court differentiated between the copyrightable content (the elements of the video game itself) from the non-copyrightable content (the functional requirements of interoperability) of the protected work. The Sega court expressly stated that infringement occurred due to the copying of the copyrightable content of the object code, but that such copying was fair use since it was the only means of accessing the non-copyrightable content that was necessary for development of follow-on (and by definition, non-derivative) works.
The Sony court used much the same reasoning.
The most important point from both decisions, with respect to WordPress Themes, is that the courts determined that any part of the protected work incorporated into the follow-on work for the purpose of achieving interoperability was non-copyrightable method-of-operation content. Therefore, since such content was non-copyrightable, it by definition did not cause the follow-on work to be considered a derivative of the protected work.
This is a fascinating discussion.
However, I’m afraid that any Matt vs Chip court battle would be disappointing.
As I understand it, Chip’s themes incorporate code from GPL’d WordPress themes. As such, I suspect any court will rely on that simple and clear fact to rule against Chip.
Unfortunately, the court does not have to say anything in its decision about whether hooking a non GPL’d theme to the WordPress core is problematic.
What is really needed is a case where the WordPress theme is written entirely from scratch and incorporates no GPL’d code.
Dennis
@Dennis Steed:
I believe you mean Chris – as in Chris Pearson – not Chip – as in, me. 🙂
You are correct, I did mean to say “Chris” rather than “Chip”. Don’t know how to edit the original post though.
Dennis
Chip,
An excellent and thorough review of the case law and arguments on both sides. I’m going to bookmark this for reference.
Mike
I disagree with your definition; basing a work upon non-copyrightable content does not make it non-derivative, it would be derivative but non-infringing. If I produce a photo album of paintings by Leonardo daVinci, it is still a derivative work even though it doesn’t infringe upon any copyrights.
Semantics aside, I would point out that while the court in the Sega trial did address accessing non-copyrightable content of the object code, they did not actually delineate what that obtained, or why. As such, it is rather a stretch to conclude from that case that modules or plug-ins which inter-operate with programs don’t access copyrightable content; especially so since the “object code” under consideration was machine statements burned into ROM.
Given the construct of the machine and the development approach taken at the time, there was no function prototyping, no symbolic referencing, and no runtime linking information that could be gleaned from reverse engineering the Sega games’ object code. Aren’t these aspects of a program indicative of the creative and intellectual elements that the programmer has fixated in the software which make it copyrightable?
Isn’t that precisely what copyright is supposed to protect: the creative and intellectual choices made by an author, artist, or programmer that are distinct from the choices that would be made by somebody else? Certainly Ian Fleming shouldn’t be able to prevent others from writing stories about heroic government agents battling evil villains who are members of global terrorist organizations, but when those stories call their hero James Bond and he works for MI6 and is fighting Ernst Blofield of S.P.E.C.T.R.E. then it pretty well starts to fall under consideration as being a derivative work.
Likewise, I would argue, that copyright law as applied to computer programs does not preclude people from employing the algorithms and functionality from other programs, but once your program (or plug-in/module) starts calling a particular set of functions with a particular set of parameters in a particular sequence, you have entered the realm of creating a derivative work based on that other computer program*. If the creative and intellectual aspects of a computer program aren’t protectable by copyright then what exactly makes a program copyrightable?
* But not necessarily infringing.
@saulgoode:
Copyright only extends to that part of a work that is copyrightable. Content can be non-copyrightable for myriad reasons (public domain, copyrighted by others, merger, scenes a faire, etc.); but regardless of the reason particular content is deemed non-copyrightable, if content is determined to be non-copyrightable, then it by definition isn’t copyrighted. If it isn’t copyrighted, then it (again, by definition) isn’t derivative.
Assuming the paintings (or the photos thereof) are in the public domain, then you have created a compilation. Your copyright doesn’t extend to the photos themselves, but rather to the creative manner in which you compiled them. Such compilations have a very narrow scope in terms of copyright protection.
I could take those same photos and do pretty much anything with them – except for re-create your exact compilation – without violating your copyright.
I would argue that such differentiation is exactly what the Sega court performed. See Sega at 1523:
Clearly, the Sega court considered Accolade’s games themselves to be original, creative work (i.e. non-derivative), and considered the “functional requirements for compatibility” to be “not protected by copyright”. This differentiation is directly applicable to a WordPress Theme: the creative expression of the Theme is original, creative work, and the “functional requirements for compatibility” with WordPress (i.e. function calls, filter/action hooks, etc.) are not protected by copyright.
Even if your conclusions regarding the Sega decision are correct (and as I argue, they aren’t), this follow-on conclusion appears not to take Galoob into consideration. The Galoob Game Genie is exactly what you describe: a “[module] or [plug-in] which interoperate[s] with [a] program” – and the Galoob court determined that the Game Genie was not a derivative work.
No. Those are primarily “functional requirements for compatibility” and scenes a faire (see also: Altai).
And thus, you have nicely described scenes a faire – but, it seems, you have mis-applied the concept to WordPress. WordPress is a content management system used primarily as a blogging platform. To repeat two aspects I’ve referenced above: WordPress cannot claim copyright for Widgets and Comments (both are scenes a faire for a CMS/blogging platform). However, the creative expression contained in the code behind wp_list_comments() is copyrightable. Likewise, the actual Widgets included in core WordPress are copyrightable.
What is not copyrightable, however, is the use of the wp_list_comments() function call. It is merely a method of compatibility. Likewise, extending the WP_Widgets class to incorporate new Widgets is not copyrightable (nor are the new Widgets inherently derivative of WordPress).
Merely making function calls is not derivative, because doing so in no way incorporates copyrightable content of a protected work in a follow-on work. Making those function calls with a particular set of parameters in a particular sequence – if such parameters and sequence are required for interoperability with the program – is likewise not derivative, because such parameters and sequence are “methods of operation” and therefore non-copyrightable.
That depends entirely on the purpose of the program – and that is a question that, as the Altai court indicated, needs to be answered using a process of Abstraction, Filtration, and Comparison.
It seems that you are arguing for a Wheelan-level abstraction, which no court in the past 18 years has applied.
As happens with too many discussions concerning the GPL license,
there seems to be an automatic assumption that the GPL is an
enforceable license. Before launching into an analysis of what
constitutes a derivative work or what constitutes an infringing
derivative work, why not ask “is section 2 of the GPL license
legally enforceable?”
The Software Freedom Law Center has forever claimed that section 2(b)
is a “condition” on the permissions to copy, modify and distribute GPL
code. See for example the Best Buy Inc. litigation:
“23. Under the License, Mr. Andersen grants certain permissions to other
parties to copy, modify and redistribute BusyBox so long as those
parties satisfy certain conditions. In particular, Section 2(b) of the
License, addressing each Licensee, states: You must cause any work that
you distribute or publish, that in whole or in part contains or is
derived from the Program or any part thereof, to be licensed as a whole
at no charge to all third parties under the terms of this License. Thus,
if a Licensee redistributes a version of BusyBox, it may do so only
under the terms of the License. Distribution of BusyBox under any other
terms or conditions is not allowed.”
http://www.softwarefreedom.org/resources/2009/busybox-complaint-2009-12-14.pdf
The term “condition” in a legal complaint means a “condition precedent”.
We can rest assured that Judge Scheindlin who is hearing the Best Buy
Inc. case will interpret the term “condition” this way. See e.g.:
“n52 “Plaintiffs bring claims for “Contract Failure of Condition”
against each defendant. The Court is not familiar with this term. I
assume “Contract Failure of Condition” is a claim for breach of a
condition precedent.” Abu Dhabi Commercial Bank, et al. v. Morgan
Stanley & Co., et al., 1:2008cv07508, SDNY, (2008).–Judge Shira A.
Scheindlin. http://amlawdaily.typepad.com/AbuDhabi.pdf
So… what is a “condition precedent” in a contract?
“A condition is an event, not certain to occur, which must occur, unless
its non-occurrence is excused, before performance under a contract
becomes due.” Restatement (Second) of Contracts § 224 (1981).
“Conditions precedent are disfavored and will not be read into a
contract unless required by plain, unambiguous language.” Effects
Associates, 908 F.2d at 559 n.7.”; Jacob Maxwell, Inc. v. Veeck, 110
F.3d 749 (11th Cir. 1997).
http://ftp.resource.org/courts.gov/c/F3/110/110.F3d.749.96-2636.html
In the case of the GPL, the performance that is subject to the
conditioning events is in section 2: “You may modify your copy or copies
of the Program or any portion of it, thus forming a work based on the
Program, and copy and distribute such modifications…” One event
(condition precedent) which must be satisfied is section 2(b):
“You must cause any work that you distribute or publish, that in whole
or in part contains or is derived from the Program or any part thereof,
to be licensed as a whole at no charge to all third parties under the
terms of this License.”
The obvious question is how you do gain copyright permission to copy,
modify and redistribute the GPL’d code? You can’t *copy*, *modify* or
distribute any code unless you *first* satisfy the condition (event)
that any derivative work “you distribute or publish, that in whole or
in part contains or is derived from the Program or any part thereof,
to be licensed as a whole at no charge to all third parties under the
terms of this License”.
So… how do you distribute and license code that you have not yet
received permission to create (copy and modify)? In contract law this is
known as an impossible condition — the conditioning event depends on
performance of the contract and performance of the contract depends on
the conditioning event.
Impossible conditions occurring in a contract are strictly construed
against the drafter. The GPL is truly an unenforceable license.
@RJack,
I’m tracking you now. Thanks for clarifying and elaborating.
You bring up an interesting question regarding GPL – one that I’d not considered. As such, I’m not really in a position to comment on it. I think the point you bring up is fascinating, but largely irrelevant for the WordPress community at-large, which has generally accepted the validity of the GPL.
I’ll have to look into it some more.
Nice article.
Supported by: Dangerous Liaisons—Software Combinations as Derivative Works? Distribution, Installation, and Execution of Linked Programs Under Copyright Law, Commercial Licenses, and the GPL, By Lothar Determann
Keep up the good work of disspeling the GPL myths.
regards,
alexander.