Some people insist that since WordPress is released under the GNU Public Licence (GPL), its plugins must be also be licensed under the GPL since they are “derivative works”. I think this is not true, and represents a wish rather than a fact. In this post, I explain why you’re not required to release your WordPress plugin under the GPL if you don’t want to.
Let’s start from the top. The WordPress license page says:
There is some legal grey area regarding what is considered a derivative work, but we feel strongly that plugins and themes are derivative work and thus inherit the GPL license.
WordPress founder Matt Mullenweg is claiming in a video interview:
The GPL has a clause which basically says that if you build something on top of a GPL product, it must also be GPL. So the freedoms are maintained, even in derivatives, or things that might be built on top of it. That’s why all the plugins and themes for WordPress are also GPL. This engenders an incredible amount of creativity, because it allows things to build on what came before. […] So the key—the reason why plugins are GPL— is because they hook into the core WordPress hooks and filters and functions. They use the database class, they use everything like that. So by sort of linking core WordPress GPL code, they inherit some of what’s called the virality of the GNU Public License. And the idea from that is it’s a license which was created so that everything built on top of the product will protect the freedoms just like the product itself has. The same thing with themes.
That’s not true. Later on, I’ll show you why. But first still some of the points of view from the all-GPL claiming side. Mullenweg asked an opinion from the Software Freedom Law Center about WordPress themes, and got a reply that included this:
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.
The above seems to repeat the claim of the Free Software Foundation, the organization behind the GPL license, who say in their GPL FAQ:
If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
I don’t agree with any of the above.
WordPress is a system that is designed to be extended by means of plugins that make calls to WordPress functions. Implementing such functionality does not modify the base system in any way and thus does not create a “derivative work”, something that would be necessary for the GPL inheritance to occur. Mullenweg’s statement about plugins “inheriting” the WordPress GPL is not a valid legal interpretation.
(It should be mentioned here that “derivative work” is a United States copyright law concept that doesn’t exist as such in Europe, for example.)
First of all, the technical details of “shared address space”, “include() function” or “dynamic linking” as mentioned by the Software Freedom Law Center and the Free Software Foundation are, at least in this case, just technical mumbo-jumbo that obscures the real valid copyright issue. The authors of the Software Pluralism minisite (at the University of Washington School of Law) in their text Derivative Works make it clear that basing the copyright issue on the technical method of linking to a plugin results in “absurdity” and is in fact “misleading”:
The following thought experiment demonstrates the absurdity of the GPL approach. Imagine taking the Firefox source code and modifying it in such a way that it is encapsulated in a plugin, called Fireplug. Common sense and the law tell us that Fireplug is a derivative work of Firefox, based simply on the fact that Fireplug incorporates all or most of the Firefox codebase. Now, when we plug Fireplug into Firefox, we essentially have a Firefox browser running within a Firefox browser. And depending on the Firefox plugin architecture, the GPL drives us to incompatible results. If plugins are dynamically linked, Fireplug is a derivative work. This is the right result, but the reasoning is exactly wrong. Fireplug is a derivative work because it incorporates and is substantially similar to Firefox, not because of a decision made by the designer of the Firefox plugin architecture. On the other hand, if plugins are launched as separate programs, then Fireplug suddenly is not a derivative work, even though this result is counter the common sense result above. Clearly, the mechanism of a given plugin architecture are analytically unhelpful and misleading in answering the derivative work question.
So what is the relevant criteria, then? Remember, we’re looking to know if a WordPress plugin is a “derivative work” of WordPress or just an “aggregate”. I am not a lawyer, but Lawrence Rosen is. Let’s have a look at his article “Derivative Works” in the Linux Journal for an answer:
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 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.
Law professor Lothar Determann explains in his article “Dangerous Liaisons – Software Combinations as Derivative Works?” (Berkeley Technology Law Journal Vol 21:4 , 1422-1497):
[A] combination of code with a GPLed program constitutes a derivative work of the GPLed program only if the combination (i) is sufficiently permanent, (ii) contains significant and creative portions of the GPLed program, (iii) is creative in its own right, and (iv) involves significant and creative internal changes to the GPLed program.
Obviously a WordPress plugin will not satisfy parts 2 and 4 of the above.
The same Lawrence Rosen elaborates in his article “The Unreasonable Fear of Infection”:
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 doesn’t 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.
Some people are really trying to obscure this point. And as a consequence, they make little sense trying to explain why plugins are necessary derived works of the GPL’d WordPress, but other apps using other methods are not. For example, Mark Jaquith writes:
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 another untenable attempt to define the reaches of the GPL license with WordPress. To make the absurdity obvious: Let’s say I package all WordPress functions in my own API, let’s call it “FooAPI”, and then I modify my plugin to only call the FooAPI. What’s the difference? None at all. Let’s be clear: The WordPress offers a set of PHP functions, actions and hooks to do things, most of them specifically documented to say they are for plugin use. These functions, actions and hooks are “an API” in themselves. Using these from your plugin directly is no different to, say, calling the XML-RPC API. (Or would I get around the license requirement, then, by using the XML-RPC API to do the same things I can do directly with WordPress functions?)
The interpretation offered by Tom J Nowell is stricter than Mark Jaquith’s:
By referring to and using the WordPress API, your code is linking/binding with the WordPress code. As a result, if the answer to the big question about GPL and linking is yes, then your codebase must be GPL compatible if it’s to be publicly distributed for use with WordPress.
This is again an attempt to define the legal status of your code by technical methods. I think it’s understandable for coders to fall back to such an easily understandable and definable categorization, but it really isn’t a valid definition of the scope of copyright and actually just obscures the fundamental question: Who has the ownership of the work? The question of methods of referring to another work is a little bit like, say, claiming that the way you format your footnotes in an academical thesis determines if your work is “derived on” your source literature. Obviously, the answer lies in the content.
Also, Tom J Nowell’s and Mark Jaquith’s stance is begging the question: What is the WordPress API for, then, if not for using it? One must also remember that at least under U.S. copyright laws, methods and interfaces are not copyrightable.
Indeed, Malcolm Bain’s article “Software Interactions and the GNU General Public License” (IFOSS L. Rev, 2(2), pp 165 – 180) states:
[W]riting code to use a library (and then executing the library at runtime) could be considered merely “using” the library in the intended manner covered by forms of “fair use”, as well as specifically excluded from the GPLv2 license conditions when it says: “the act of running the Program is not restricted” – thus requiring merely a consent to reproduce (but not modify) and redistribute the artefact.
Let’s think about this for a moment. Malcolm Bain above talks specifically about a GPL’d library, but we can apply the same thinking to WordPress as a platform. A plugin that uses WordPress’s published functions and methods to get information and to manipulate it is actually using the system as it was intended.
Chip Bennett dissected the extant U.S. case law on the matter and concluded the same (he talks about themes here, but the same can be applied to plugins):
Extant case law involving copyright infringement – and especially, software copyright infringement – does not view linking to and interaction with a protected work to constitute a derivative work, and if anything, actively supports such interaction due to the promotion of innovation, and therefore benefit to the public and to the marketplace for the protected work. In order to be considered a derivative work, based on the past twenty years of copyright case law, a work must somehow incorporate copyrightable, creative expression of a protected work into itself.
Another thing to mention here: Under the U.S. copyright law, there is such a thing as “fair use”. If using the WordPress Plugin API and the relevant functions in a plugin is not “fair use”, I don’t know what is.
An important criterion for analyzing “fair use” is that a non-fair use diminishes the market share for the original work. For example, quoting all the passages containing new information from a scientific book would not be “fair use” since no one would need to buy the original book anymore. In the case of WordPress plugins, their existence does quite the contrary: they provide more demand for WordPress. This aspect has been analyzed by Michael Wasylik, who concludes (again, talking about themes but the same can be applied to plugins):
[The] development and distribution of WordPress themes, to the extent they engage in any “copying” or derivation from WordPress code, are resoundingly fair use of that code.
Coming back to where we started: The status of WordPress plugins has been called “a grey area”, even by the WordPress official site, as we saw in the beginning of this post. I’ve been trying to point out that there are valid reasons for not believing this to be the case. But even accepting ambiguity in this area, is there some juridical backbone to taking a negative stance to the all-GPL interpretation? The answer is yes.
Andrew Katz in his article “GPL – the Linking Debate” reminds us about a judicial rule called contra proferentem, which fundamentally says that ambiguous language must be interpreted against the provider of that language:
Note also that where an ambiguity exists, the contra proferentem rule would traditionally require the court to resolve the ambiguity against the licensor and in favour of the licensee.
So, the plugin developer, having obtained a license (the GPL) to WordPress with ambiguity about his rights, may resort to interpreting this ambiguity in his favour.
I understand that the WordPress developer community (“we” in the first citation) want plugins to be GPL. They think, or at least Matt Mullenweg thinks, that this ” engenders an incredible amount of creativity”. I don’t agree. When I want to contribute to an open source project, I will do it – and I have done it. But fundamentally, as a coder, I expect an income for my work. Giving away the right to freely redistribute my work to anyone that might have purchased a copy is an immoral idea. I won’t do it, out of self-respect. You shouldn’t either. If you want to release your WordPress plugin under the GPL, that’s fine – but if you don’t, you’re really not obliged to.