I saw an intriguing post the other day by Jennifer Schiffer on WordPress, themes and the GPL. She linked to a video of Matt Mullenweg (one of WordPress’ lead developers) who was talking about why WordPress was a GPL product (short answer: they didn’t really have a choice because WP is based on b2, which was GPL) and, more specifically, was talking about why themes and plugins are also then GPL.
The truth of the matter is that the GPLv3 is a very restrictive license, in as much as it’s also a harbinger of freedom. The GPL was written in a way to specifically retain the freedoms it grants through successive iterations of a particular product, or its add-ons. This means that if you like a GPL product, develop a derivative work, a modification, a plug-in or any other type of add-on, the resulting work is also going to be covered by the GPL (you do not have a choice in this).
“You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.” – Section 10 of the GPL
This means that unless the WordPress GPL (yes, they’re specific by product… you can ADD restrictions if you want… so no 2 GPL’d products are necessarily identically licensed – we’ll talk about this in a minute) allowed for a theme developer to restrict the distribution of a theme, a theme developer isn’t allowed to add that restriction on their own. Your development on a GPL product inherits the license of the original product.
Inheritance is a powerful concept because it creates license congruity, ad infinitum, for all downstream works of the original code. It would be extremely difficult to manage license compliance if WordPress had one license, but a plug-in had a different one.
But there’s apparently a wonderful new theme available for WordPress called Thesis. Its developer sells two several different versions of the theme (selling under the GPL is fine). The problem comes to light when you look at the options:
- Personal: one site only; footer link must remain intact; can’t re-sell theme or modifications
- Developer: can create multiple sites and must pay Thesis developer for each site deployed; can remove footer link; can’t re-sell theme or modifications
And these options are problematic because they violate the GPL v2 under which WordPress is licensed. Specifically, Section 2, which states, in part:
“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.”
and Section 6:
“Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.”
(Note that v2 and v3 of the GPL are vastly different animals… and v2 was actually more in the realm of “free as in free beer” than v3, which touts freedom as “free as in free speech, not free beer”.)
So, in fact, the Thesis theme, as a WordPress derivative work, is bound to the GPLv2 license that WordPress is licensed under. As such, even the sale of the theme is a problem, as are the one-site-only restrictions and the “can’t re-sell” restrictions. Note: the footer link restriction is probably fine, as it could qualify as the attribution allowed under the GPL. Additionally, it could be argued that the fee charged is for the “physical act of transferring a copy” as allowed by Section 1 of GPLv2, but even then, the remainder of the unauthorized restrictions are still problematic.
But who is going to do anything about this violation? Who has the right to enforce the license? WordPress? The folks at b2 (WordPress’ predecessor)? Any particular end user? Technically, it’s the folks at WordPress who have the right to enforce their license upon theme and plug-in developers. They have the ability to potentially even sue to prevent a rogue developer from violating their license with WordPress [though I’m guessing that a theme developer is going to try to argue that a theme isn’t a derivative work or a modification]. But this is inherently difficult. So instead, WordPress is taking a slightly different tack. They’re going to create a Theme Page on the main WordPress website which only lists themes that follow the GPL (by the way, all derivatives have to be GPLv2 licensed, as the WordPress license doesn’t allow for newer versions of the GPL to apply). I’m guessing that Thesis won’t be listed.
LicensingHandbook Archive 
Where in the GPL (pick a version) is it stated that it shall also apply to a “plug-in or any other type of add-on, the resulting work is also going to be covered by the GPL (you do not have a choice in this).”? It is generally accepted that statically linking a program to GPLed code will transfer the license, but this is not the case with themes. It is highly debatable whether mere function calls from interpreted code into the api of GPLed software transfers the GPL to the calling software.
Thanks for the comments, Martin. I would call a theme or plug-in a derivative work. They can’t really exist (you can’t run them as software) without WordPress under them. Derivative works are covered by all versions of the GPL.
Update: Seems that the WordPress folks actually asked the Software Freedom Law Center for an actual legal opinion. Granted, the title of the Center is even biased, and everyone also knows the saying about opinions. But anyways, they agree with my assessment: http://wordpress.org/development/2009/07/themes-are-gpl-too/
The SFLC is – as you point out – clearly biased in this matter. I am merely pointing out that a legitimate debate exists around what constitutes a derivative work in this context. Themes do not incorporate (as I understand it) any part of WP, they merely reference the API provided by WP. Whether a theme is meaningful without WP isn’t as I see it a relevant factor, just as a it is not a relevant factor in determining if a reading guide for a book is a derivative of the book. Furthermore a theme would be useful with any software implementing the WP API.
Agreed on all fronts – the question is whether a theme/plug-in constitutes a derivative work. Notwithstanding SFLC’s bias, I think they still have a point. If you take a look at the files that comprise a WP theme, there are 2 potential types: PHP and CSS (HTML isn’t really a type, it’s a language used in both types of file). As a theme developer myself, I’ve spent many hours buried in the coding of each type of file. So I can say with experience that the PHP files are almost 100% full of calls to WP functions. There’s virtually nothing else in them. For example, the following is the PHP code that generates the bulk of the page you’re looking at right now:
<!–
<?php/*Template Name: Page Template*/?>
<?php get_header(); ?>
<div id=”content”>
<div id=”contentleft”>
<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
<h1><a href=”<?php the_permalink() ?>” rel=”bookmark”><?php the_title(); ?></a></h1>
<?php the_content(__(‘Read more’));?><div style=”clear:both;”></div>
<!– <?php trackback_rdf(); ?> –>
<?php endwhile; else: ?>
<p><?php _e(‘Sorry, no posts matched your criteria.’); ?></p><?php endif; ?>
<?php posts_nav_link(‘ — ‘, __(‘« go back’), __(‘keep looking »’)); ?>
</div>
<?php get_sidebar();?>
</div>
<!– The main column ends –>
<?php get_footer(); ?> –>
As argued by the SFLC, each one of these PHP calls that references a WP function is merely implementing what WP has already provided in their code. There’s nothing in this file that’s even original content, save for the specific order of each function’s appearance. Additionally, there’s nothing that these PHP files can do without WP behind it, answering each function’s call.
CSS, on the other hand, is a little more complicated. As it’s more generic and can be used for more than just WP pages, and, in fact, is telling the BROWSER how to appear, not WP how to function, I can see a brighter argument for not classifying the CSS as a derivative work on its own. Works presented as a whole aren’t divided in this way for evaluation of whether they’re derivative or not (ie: you don’t disassemble it into its component parts and parse it out). So 1 CSS file combined with a potentially infinite number of PHP files (mine has about 12), IMHO, would be a derivative work, because the theme is ALMOST entirely WP-function calls, and, as a whole, could not operate without WP behind it.
To address your issue of the WP API, while I’m not sure that your description is functionally accurate, I’m also not sure that it matters given my reasoning.
Now, I didn’t do a whole lot of digging into current case law (and it seems that even as of 1/1/2008, folks were still waiting for a test case), but I did find that the various Circuits are still at odds over how to test for derivative works. The general rule of them seems to be a comparison test (the AFC test) to check for the amount of originality in a work. Interestingly enough, there are just as many arguments that say that the AFC test only tests for copyright-ability, not derivative work status. But since there aren’t any cases that I can find on software derivatives, I think we’re still in a gray area. As such, I still hold firm to my logic above.
What part of my argument regarding the WP API does not make sense? What prevents another piece of PHP based blog software from implementing the same API?
As to CSS I don’t see a reason why this is different from the API calls in the theme. The CSS targets the classes defined by the HTML produced by the themes, the theme targets the functions defined by WP.
For a different, but I think interesting, take on the same matter see http://thread.gmane.org/gmane.linux.kernel/475654/focus=476049 where Linus outlines the irony of GPL fundamentalists being copyright fanatics.
As a follow-up on my previous Reply please see section 36 of Eben Moglen’s affidavit in the Progress Software v. MySQL case (http://www.gnu.org/press/mysql-affidavit.html). Interestingly none of Moglen’s arguments apply to a WP theme. There is no compilation taking place and there is no joint machine language copy on disc.
FSF’s analysis of the derivative nature of WP themes (http://wordpress.org/development/2009/07/themes-are-gpl-too/) on the other hand seem to imply that the GPL “spreads” to any code that calls functions in GPL’ed code. The core of the argument seems to be that: “They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call.”, which to the extent it is true would apply to any use of any API. One can only call a function in an API if it exists and only call it with the parameters that it will accept. Again I return to the analogy of a reading guide for a book. The content of a reading guide is also in large part determined by the book it serves to guide the reader through. It can only reference chapters and sections that exists in the book. It cannot meaningfully change “parameters” in the content of the book, like the age of characters, without becomming “incompatible” with the book. In a sense such a guide is tied even closer to the book than a WP theme is to WP. It is hard to imagine a reading guide that is meaningful when read with with another book (without that book violating the copyright of the original), whereas a WP theme would be potentially useful with any blogging engine that implements the parts of WP API used by the theme. I think most would agree that a reading guide that otherwise respetcs the copyright of the original (e.g. quotes the original in compliance with applicable copyright law) would not consitute a derivative work. It seems to me that many the arguments for a theme (specifically the PHP parts) being a derivative work of WP proper ,ignore that GPL is a license based on copyright which does not protect ideas or functionality, only the specific expression of these. This is especially true when the analysis relies on a comparision between the amounts program logic inhenrent in the WP API calls and the rest of the program logic in the theme as does the FSF letter “ruling”.
So, I’m not sure that the analogy to a reading guide applies. Practically speaking, a reading guide is used to critique and evaluate portions (or the entirety) of a literary work – not put the work into practice. In other words, a reading guide would be authorized under the fair use exception of the Copyright Act because it meets the four-part test of the exception. But this isn’t what Themes are doing. They don’t critique, don’t evaluate, don’t review.
WP Themes use specific PHP calls (which, btw, might qualify for copyright protection in terms of how they’re written, but I’m not going to rely on that here). These calls have to be implemented by code that is “listening” for those calls. So I don’t know that it matters whether someone else can write something that is listening – the mere fact that they’re writing them to be listened TO indicates the derivative nature of the work.
The literary comparison in this case would be the individual who takes the characters of a particular work and writes a subsequent work using those characters – such as Harry Potter, or, as has been done, the Wicked Witch from the Frank Baum classic, The Wonderful Wizard of Oz. So Wicked, for example, is a derivative work (and it’s allowed even without permission because the copyright to Baum’s book already expired).
Let’s go back, however, to an alternate theory, though – that the WP PHP code itself is worthy of copyright (which it is) and that the function calls themselves would also qualify on their own (which they might, I haven’t seen a court rule on this yet). This would mean that the actual PHP code used to invoke a function, such as: <!– <?php get_header(); ?><br /> –> when used in a Theme, is an authorized derivative work. It’s copying, but it’s permissible under the terms of the license – which means that the license applies to its use and thus the Theme must, by default, be licensed under the GPL.
I guess I just think of it more plainly, though. Would a WP Theme be functional if WP wasn’t (and had never been) around? Of course not… they’d be calls to thin air. Someone would have to “invent” a way for those calls to be read. Seems a little backwards to me. Instead, WP came first and created the language (not PHP, but the specific calls) that Themes are written in. Writing in that language requires an interpreter (WordPress). Without the interpreter, the Theme doesn’t matter.
This, btw, is also the reason why documents you create with MS-Word, WordPerfect, OpenOffice or any other word processor AREN’T derivatives. They don’t use anything OF the creator beyond the creation process. Individual documents don’t take from the code of the creation app and they don’t require (but can use) the creator to be read.