The GPL and Themes/Plugins

HeckertThis is a continuation of the Blog Herald’s Guide to the GPL License series. You can read part one and part two here.

One of the more common misconceptions about the GPL is that it is “viral” in nature and can “infect” any software that touches it.

While it is true that the GPL does have a viral component, it is only to ensure that derivative works based upon GPLed code are also released to the GPL. It is possible, and even common, for GPL applications and proprietary ones to co-exist side by side. For example, there are many proprietary programs, including Skype and MyDropBox, that run on Linux, which is GPLed.

However, when one delves into plugins and and themes, something of a gray area begins to emerge. Though a WordPress theme, for example, might not be based upon a GPL theme, it relies upon a GPL application to function. As such, it has been widely held that they are GPL-licensed, even if they haven’t been explicitly licensed as such.

This has caused a major rift in the developer community and Automattic, the makers of WordPress, sought out the aid of the Software Freedom Law Center to determine the what the status of WordPress themes is.

However, in many ways the answer from the SFLC raised more questions than answers and may have created even more confusion.

The GPL and Themes

The reason GPL has been such an important question to the theme community is that is a large, and often controversial, market for commercial themes. Many companies have sprang up selling WordPress themes. Though many of these commercial themes are licensed under the GPL, most are not and are instead licensed under a proprietary license that forbids copying.

Though to the developers that license their themes accordingly, this is a legitimate practice. However, others consider it against the spirit of WordPress and many have wondered if it is against the GPL.

The SFLC, however, did not provide a simple answer. According to the SFLC, WordPress themes, “contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works.”

As the SFLC saw it, many of the files of the themes required WordPress to run. Familiar files such as the index.php, pages.php, etc. had “hooks” that fed into WordPress and that made those filed derivative works and, as such, should be licensed under the GPL as per WordPress’ GPL license.

However, there are several files typical to WordPress themes that are not covered by this including images, JavaScript files and CSS files. These files run independently without any WordPress code and are accessed directly by the Web browser with no processing by WordPress. As such, these files are not covered by the license.

This creates a problem as a single theme will likely contain dozens of elements, some which are GPL licensed via their derivative nature and some which are not. As Matt Mullenweg, the CEO and founder of Autommatic, said in his blog post, “Even though graphics and CSS aren’t required to be GPL legally, the lack thereof is pretty limiting. Can you imagine WordPress without any CSS or javascript? ”

However, themes aren’t the only add-ons affected by this issue, plugins are as well.

Plugins and the GPL

The same as themes have elements that rely upon WordPress to function and parts that do not, so do plugins. As plugins have become more sophisticated, they include images, JavaScript files and even stand-alone PHP scripts that do not require WordPress, or any other GPL software, to operate.

With a theme, it is fairly easy to determine which files are likely to be non-WordPress derivative. However, with plugins the challenge becomes much greater. Without going through the plugin file by file, perhaps even line by line, and seeing what relies upon WordPress and what does not, it is almost impossible to be certain unless the plugin is deliberately licensed under the GPL.

This means that many, if not all, of the questions that surround proprietary themes also surround proprietary plugins, including many WordPress “custom installations” that are for specific uses.

Obviously, this confusion is something that Automattic and much of the WordPress community would prefer to ignore and they have come up with a solution to at least minimize the potential issue.

The Directories

The best way to avoid these licensing issues would be for theme and plugin developers to license their works under the GPL. This way, the entire work would have one license. To encourage this, Automattic created both a theme directory and a plugin directory and have restricted access to these directories to only GPL-licensed works.

These directories are not only the official repositories for WordPress addons, but they are also available from within WordPress installs themselves, making them easier to install and, in the case of plugins, easier to update and maintain.

Though plugin and theme developers are free to license their works, or at least the non-derivative portions of their work, under any license they chose, not using the GPL carries with it a series of limitations that could make the extensions far less useful and far less used.

Even though some authors have decried this decision, given the potential nightmares for licensing themes and plugins, the decision seems understandable.

Bottom Line

Though this post has focused largely on WordPress, the same is true for any other GPL bogging platform or CMS. WordPress was used as an example since Automattic used it to test the waters of these issues.

In the end, whenever you create a plugin or other add-on for a blogging platform or a CMS, it is likely that large portions of it will need to be licensed under the GPL to be compliant with the original software’s license. However, it is also very possible that other portions will not.

Though this is not necessarily a flaw within the GPL, it does highlight a limitation and a gray area that it does create, though it is largely one created by copyright law itself and the difficult definition of a derivative work. In short, almost any license that attempts to make itself viral will have a similar issue.

This, as it turns out, is part of the trade off of using a viral license, such as the GPL, versus a non-viral one, such as the BSD license.


  1. says

    Thanks for the informative read. Most GPL related blog posts are over-opinionated and unhelpful, yours was the opposite. Thank you very much.

  2. says

    Jonathan, thank you for a great series. I think I have commented on each of your posts, so it only fitting I comment on this one as well.

    When this whole topic flared up I was immediately consumed, as you were, by many people’s misperception and understanding of the GPL. Now, I might have a number of my own misconceptions I suppose, but I would like to think that over the years, endless consultations with lawyers on the subject and being the architect behind Movable Type and Melody’s open source strategy, that I have amassed a certain amount of my own [layman’s] expertise.

    First, the GPL governs distribution, thus it is really only invoked when code is bundled and distributed together in a way that forms a derivative work. In other words, a theme by itself is a completely separate, albeit worthless, piece of code from WordPress. In that form, it shares absolutely no code with WordPress. As such, themes are distributed independently from WordPress itself, or IOW users must first download the theme, and then install it into WordPress in order for it to function.

    We good so far? Excellent.

    Now, let’s establish a fact: the GPL specifically states that I am permitted to make modifications to any GPL software in my possession, and that I am even permitted NOT to make my changes public, provided that I do not re-distribute my changes. As long as my changes are private and mine alone, I can do whatever I want. This to me is one of the most liberating parts of the GPL.

    Still with me?

    So the question in my mind turns to this: if I were to install a theme into my private install, have I created a derivative work just by doing so? Perhaps, but the GPL is only enacted when I choose to redistribute this “derived work.” Let’s look at two scenarios:

    a) I want to create a version of WordPress that includes my own themes I have created. I (of course) am permitted to do this under the GPL, although trademark law would prevent me from calling it “WordPress.” Now, because my themes are distributed with WordPress, and because those themes when loaded by WordPress share the same memory space (a.k.a. dynamic linking), I have created a derivative work of WordPress. As such, in order to be in compliance with the GPL the themes I have choosen to redistribute alongside WordPress must also be GPL (or GPL compatible), even if those themes adhere to an API that keeps the code physically separate.

    b) In this next scenario, I make modifications to a GPL theme directly. I am under no obligation to share my modifications unless I choose to redistribute those changes to anyone. So even though I have created a derived work by making modifications directly to the theme, the GPL only comes into affect vis-a-vis my changes when I redistribute them.

    The point to underscore is the the GPL is only relevant and can only “infect” code when code is distributed. Now the GPLv3 attempts to provide greater clarity around what “redistribtion” means and attempts to define the process of making something available through a web site (e.g. a blog) as “distribution.” This is very controversial and one of the reasons I suspect that WordPress is still only licensed under GPLv2 where this definition of distribution is more ambiguous. If they adopted v3 of the GPL, then all of the proprietary code written by Automattic powering would also need to be made available under the GPL. Not something they are likely to want do IMHO.

    Back to the core issue and question: “if I were to install a theme into my private install, have I created a derivative work just by doing so?”

    I maintain that no, you have not. At least not as it relates to the GPL. The GPL gives me permission to install and modify my GPL software however I want without obligation of any kind. That includes installing themes and plugins.

    Let’s look at it this way:

    Pretend I am a large media company and I have just paid a design firm a handsome sum of money to design for me a web site powered by WordPress. I install the theme they gave me, and in so doing create a “derived work.” According to SFLC and the arguments currently being made, this company would now be compelled by the GPL to open source their code/theme. Implying that every theme ever made for WordPress must be GPL. This is utter nonesense. Seriously, is there anyone who believes this could possibly be true? It can’t be because no code is actually being distributed. It is being commissioned and is owned privately by someone. This it is shielded from the GPL.

    No, Byrne, you misunderstand, code commissioned and paid for privately is ok. What about the themes being sold through a store front?! Ok, sure, in this scenario code is being distributed. But the code being distributed is not a derived work in and of itself. It is only a derived work after it is installed and executed. My code would only be governed by the GPL if I redistributed WordPress with my theme pre-installed.

    This was a long comment. My apologies. But despite all that people have written on the GPL, and especially on this topic, it is still amazing to me how few people understand what the GPL actually governs.

    Thank you for your great series. I look forward to the next piece.

  3. says

    Sometimes it become very messy when people add a GPL with their theme and additionally add some of their personal conditions that conflicts with the GPL.

Leave a Reply

Your email address will not be published. Required fields are marked *