WordPress Themes, GPL, and Copyright Case Law

Filed in Web DevelopmentTags: , , , , ,

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

  1. WordPress core, with a third-party Theme installed, constitutes a derivative work.
  2. A Theme, on its own, that incorporates core WordPress code, constitutes a derivative work.
  3. A Theme, on its own, that extends core WordPress code, constitutes a derivative work.
  4. A Theme, on its own, constitutes a derivative work, for the following reasons:
    1. A Theme is analogous to a Linux Kernel Module, which many interpret the GPL to consider as a derivative work.
    2. 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.
    3. A Theme's PHP consists of calls to WordPress core functions and action/filter hooks, which determine entirely the output of the PHP.
    4. A Theme interacts with WordPress in exactly the same way that WordPress interacts with itself.
    5. A Theme is wholly dependent upon WordPress, and on its own does not constitute an original work.
  5. 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

  1. WordPress is non-compiled code; therefore by definition, no static linking exists between WordPress core and Themes.
  2. 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:
    1. A Theme that uses only function/global variable calls and action/filter hooks does not modify core WordPress code in any manner.
    2. A Theme merely interacts with WordPress core using mechanisms of interaction in the manner intended by WordPress developers.
    3. A Theme interacts with WordPress and modifies WordPress data structures in a transitory, rather than permanent, manner.
    4. 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.


  1. 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.

  2. 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.

  3. 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.



    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.

  4. 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.

  5. 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.

  6. 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.
  7. 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.

    1. Does a theme, rather than simply calling a WP function, incorporate actual code from WordPress?
    2. 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.)

  8. 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.

  9. 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.

  10. 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.

    1. 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.
    2. 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.
    3. 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.
    4. 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”.

  11. (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.

  12. 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."

  13. 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.


Comments (Comments are closed)

77 Responses to “WordPress Themes, GPL, and Copyright Case Law”
  1. chip_bennett says:

    WordPress Themes, GPL, and Copyright Case Law – http://www.chipbennett.net/2010/07/wordp

  2. 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.

  3. Mark Jaquith says:

    A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”.

    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.

  4. Mark Jaquith says:

    Totally missed the other pages. I take back my comment about brevity!

  5. Chip Bennett says:


    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.

  6. Chip Bennett says:


    Totally missed the other pages.

    Are the footnotes obscuring the pagination? I’m still experimenting with both.

  7. Ryan says:

    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.

  8. Doug Stewart says:

    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.

  9. Mark Jaquith says:

    Trying my comment again, now that I’ve seen pages 2 through 4.

    A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”.

    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!

    WordPress is non-compiled code; therefore by definition, no static linking exists between WordPress core and Themes.

    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 Nintendo court distinguished Midway by pointing out that the circuit board distributed in Midway substantially copied and replaced a portion of the original video game circuitry, whereas the Nintendo add-on did not actually incorporate any of Nintendo’s protected expression.

    The 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).

    Also, Galoob appears to refute the argument that Themes are derivative of WordPress due to their dependence upon WordPress core, their design to interact with WordPress core in the same way that WordPress interacts with itself

    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.

    The Sega court held that a copyright owner could not erect barriers intended to prevent interoperability with follow-on works, and that copying of code required to accomplish that interoperability, in the expression of a separate, copyrightable expression, did not constitute copyright infringement.

    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.

    This incorporation must involve the actual creative expression of the protected work, not merely the mechanisms of interaction, which are non-copyrightable ideas.

    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.

    In order to be derivative, a work must bear substantial similarity to a protected work, based on an Abstraction-Filtration-Comparison test.

    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.

    Further, as Sega and Sony demonstrate, even a Theme’s use of WordPress core function/global variable calls and filter/action hooks merely constitutes incorporation of non-copyrightable mechanisms of interoperability.

    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.

    Theme PHP files generally describe a semantic HTML markup. This semantic markup on its own is likely not copyrightable, as it falls under merger and/or scenes a faire principles.

    The HTML is a distraction. That’s not really the issue. It’s the PHP code.

    Even the basic PHP in Themes very possibly constitutes non-copyrightable expression of ideas, processes, or methods of operation – and as such is not covered by copyright law.

    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 foreach loop. :-)

    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! :-)

  10. Sean Kaye says:

    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.

  11. Chip Bennett says:

    @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.

  12. Chip Bennett says:

    @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.

  13. Chip Bennett says:

    @Sean Kaye:

    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”.

    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.

    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?

    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.

    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?

    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.

    Excellent stuff.

    And thanks for reading!

  14. chip_bennett says:

    @MikeWas I referenced your WordPress Theme/GPL derivative analysis post here: http://www.chipbennett.net/2010/07/20/wo… (would love your input)

  15. RJack says:

    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).

    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.

  16. Chip Bennett says:


    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.

  17. I’d absolute describe a WordPress code extensions (themes or plugins), as “elaborations, or other modifications.”

    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.

    Themes necessarily have WordPress code in them. They necessarily use code from the original (and GPL’d) WordPress themes.

    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.

    Plugins and themes absolutely “transform” and “recast” the WordPress application. That’s what makes them so great!

    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.

    Why the distinction on static linking?

    Dynamic linking is considered by many to be allowed. Not by the biased FSF how ever.
    GPL#Linking and derived works

    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?

    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.

    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.

    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?

    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.

    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.

    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.

    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.

  18. RJack says:

    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.

  19. Chip Bennett says:


    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.

    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?


  1. Twitted by ericlbarnes