I’m hoping that my boss Matt Mullenweg sharing the legal opinion on “Themes are GPL, too” will put the issue to rest for the majority of the community (emphasis mime):
“PHP in WordPress themes must be GPL, artwork and CSS may be but are not required.
…
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? So as before, we will only promote and host things on WordPress.org that are 100% GPL or compatible. To celebrate a few folks creating 100% GPL themes and providing support and other services around them, we have a new page listing GPL commercially supported themes.”
The legal opinion was provided by Software Freedom Law Center. Council James Vasile provided the findings and blogs at hackervisions.org . James also has posted about this on his own blog in the article “CMS Themes and the GPL“. As I commented there, my fear is:
“people read what they want to get out of it, and case law is the only thing that moves them.”
The legal finding and unchanged policy1 are consistent with the intentions of the WordPress developer community and what has been promoted for the four years I’ve been involved.
Talking about licensing really is the suck. Matt’s article became necessary lately as some commercial theme developers have been very aggressive to WordPress community members, who have shared theme code as allowed by WordPress’s viral GPL v2 license.
It frustrates me when I read commercial theme developers complaining about people “stealing” their themes after the thousands of hours they have worked. They make no mention of the hundreds of thousands of hours others have worked on WordPress (counting on the GPL protecting their freedoms ).
The incredibly exciting news is seeing the various commercially developed and supported themes embrace the GPL in the last 9 months. Theme collections like ThemeShaper (Thematic FrameWork), StudioPress (previously Revolution 2), and WooThemes are all 100% GPL — those are just the ones I’m familar with, be sure to check out the theme offerings of the other commercially supported GPL themes.
- Besides, only allowing GPL v2 compatible themes at wordpress.org/extend/themes/ is likely the only manageable solution. [↩]
Technically, those themes aren’t GPL unless the author releases them as GPL. The GPL is not self-executing in that manner. The difference is this: the penalty for not releasing code that is supposed to be GPL under the GPL is a) monetary, and b) revocation of their GPL rights for the underlying code. Their code doesn’t automatically become GPL. And it means they would have a hard time suing someone for copyright infringement and winning, which is their remedy for someone putting their code in the wild.
@King Rat, that is an interesting insight.
As you describe though, practically, they would have little recourse it someone distributes their theme’s code.
I still simply do not understandy why are themes written from scratch licenced under GPL. Because they are using wordpress functions? So if I’m writting a program using GPL programming language and using it’s functions, my programm is automaticaly GPL?
@Tomas, yes.
WordPress theme code is not written from scratch, it is derived from the WordPress program, therefore when distributing the theme’s code you are accepting the terms of the GPL license and licensing your code under the same terms.
@Tomas Kapler
Look at any themes code. If you see code like wp-bloginfo or something like that you are using wordpress code, which in turn is licensed under gpl
Pingback: GPL Isn’t a Good License for Proprietary Software < A Fool’s Wisdom
@Antonio,
You’d be hard pressed to prove that you can GPL a function name, and thus require the use of said function name falls under GPL inheritance.
Hard pressed, indeed.
@Nathan, I don’t think @Antonio said or suggested that. If the theme’s code is derived from WordPress code then it needs to be licensed under the GPL v2 or it’s in violation of WordPress’s license.
@Lloyd,
I would agree, but what evidence is there to suggest that theme code is derived from WP code? A typical theme consists of MOSTLY HTML and CSS, a little bit of custom PHP, with the sporadic use of a function call to pull in dynamic data. (Title, content, etc.), presumably, but not necessarily, from WordPress.
In what possible way could that be considered a derivative of the original work?
As Antonio accurately pointed out, what is being argued here is that the use of functions like bloginfo(), the_title(), the_content in a theme makes it inherit the GPL. Which, of course, is ridiculous. WordPress doesn’t own that function name, or any of the others that it uses.
As I’ve said elsewhere, I wholly encourage people to adopt the GPL for their themes and plugins, but I also wholly support those who maintain they have no legal obligation to do so.
@Andrei thanks for providing a link to an interesting legal opinion that argues that the GPL v2 interpretation of derivative is too broad and even misused. I found the article a bit disconjugate – I wish it had stayed focused on case law, even if from other domains, and stayed away from the GPL FAQ, stayed focused on the letter of the license. I would love what the analysis of v3 would be and too bad it has not been updated since 2006 (with new case law).
@Nathan, seems like a a decent position to have. No position is currently well supported by case law. Hopefully, that means that issues are being resolved agreeably outside of court.
It comes down to what is fair use and what is a derivative work. The legal opinion of the Software Freedom Law Center is WordPress themes are a derivative work.
Is it enforceable? I hope so. Should it ever be enforced? I can’t think of a current case, where it should be.
The following article gives a legal analysis of the “plugins must be GPL’d” claim:
http://www.law.washington.edu/lct/swp/Law/derivative.html
It’s a long article but it’s well worth the read.
I do not agree. When I did a theme, i wrote from scratch. I do not use default etc theme, i do not like their code.
Yes, i use 10 or 15 wordperss wordpress functions for generating loop etc. I’m using also PHP functions like IF, ECHO etc. So if PHP code is open source, than anything written in PHP is open source?
I do not care much, i do not sell my wordpress, but for me as a developer this means, that i cannot create any professional theme or plugin for someone for money and calculate it so that i would invoice e.g. only 1/10 of development and count that i could sell it to 10 people. I can’t because if everything for WP must be GPL then i have to sell it for 100%, because someone who would buy it could give it everyone other for free. And wait! I cannot even sell it, because it is against GPL, i have to offer it for free!
Nathan – You can’t GPL a function name but you can GPL the code that runs in that function of course.
The themes use that code which is why they’re described as derived.
The themes are obviously intended to run using the functions in WordPress, not the API of some proprietary application.
@ THOMAS KEPLER
[Quote]And wait! I cannot even sell it, because it is against GPL, i have to offer it for free![/Quote]
http://www.gnu.org/philosophy/selling.html
Pingback: Licensing is the vehicle, our users are the environment | Weblog Tools Collection
@Lloyd,
Case law would be beneficial, but licenses like the GPL are rarely enforceable enough to make it to court.
I definitely agree with you there. The opinion of the SFLC is about as beneficial to “closing the book” as an opinion in the opposite direction from the “You Can Always Copyright Software” Law Center
@Donncha,
Very true. But I’m not including “the code that runs in the function” in my theme.
“The themes use that code…”
That’s where I disagree. While it’s true that themes, in the right context, can use the code in the functions, they don’t necessarily have to. Which makes the issue grey, at the very least.
Whether or not the author intended the theme to run exclusively on WordPress is irrelevant to its licensing, unless the author decides to GPL the theme himself. The argument from the FSLC is that because themes require WordPress to run, they are considered derivative, and therefore inherit the GPL, regardless of the author’s own intentions for licensing. If, however, a proprietary system existed which would also run themes, licensing requirements go out the window, because the theme no longer needs WordPress in order to function. This is the same principle which caused the FSLC to admit that CSS and Images don’t automatically inherit the GPL … the exact same principle. Any code that does not require WordPress in order to operate is not subject to WordPress’s viral license.
Which is why the GPL is entirely inadequate to cover uncompiled web applications, or at the very least, plugins that run on web applications. There are simply too many exceptions to exploit.
PS – I’m curious, Matt mentioned a while back that he’d be checking with the FSF about this issue. Have they not gotten back to him?
@Nathan, what is your basis for your claim that the GPL is not enforceable enough to make it to court. There is case law that supports that for some scenarios GPL is strong in its copyright law foundation. I would imagine the issue of whether legal issues are pursued is more about calculating damages and cost.
I believe you are mistaken on what the principle is. It’s whether they form a single work, not how it was engineered. That is how the GPL protects against “clean room” work, and the basis for only GPL compatible parts to form the single work. On the other hand the GPL does not “protect” (affect) data or content.
I think it’s a safe bet that the FSF referred Matt to the SFLC.
[Editor: I"m assuming this is in response to @ THOMAS KEPLER]
Wait a minute here. Are we reading the same document?
The GNU “selling” document says unequivocally, bluntly, several times that you can sell GPL software and for any amount you decide. In fact, at one point that document *encourages selling it*. They are pretty particular about saying that you’re not selling proprietary software — which goes without saying — but are selling the “distribution” of that software. Then again, because software lacks physical goods, if you’re selling even a proprietary download, you’re doing the same thing. So why are folks afraid of this? In fact, it seems we need some people aggressively selling GPL-licensed stuff to prove that it can work.
I was under the impression that to use a documented api, and not modifying or coding to existing code, that the new code is separate, and not derivative. For example, writing an actionscript program that runs in the flash player. Or a program that runs on a desktop platform. These programs are not “infected” by whatever licenses. Wordpress is a platform with documentation. I’ve written code for themes (child themes) without reading the source code of either wordpress or the parent theme, only reading the documentation and examples on websites. Having said that, I don’t mind GPL as it simply means I distribute the code with the “program” but I do have some confusion about what “derivative works” means.
@Ken, the intentions of the WordPress community, the GPL license, and the legal opinion mentioned above, is that WordPress Theme code is GPL. @Andrei Belogortseff provides a link above to a legal opinion that deals with plugins, that argues the opposite.
An actionscript program in the flash player, I don’t think this is analogous, because the licensing there specifically allows that scenario. Similarly, Linux is a GPL program with an amendment to allow non-GPL v2 compatible kernel “plugins”.
Whether documentation, examples, reading the code, or how you figure out how to create a work using GPL’d software, you have to be careful to consider whether that creates a derivative work.
@Lloyd,
The only reason I mention it being hard to take to court (and perhaps that was poorly worded) is that, unlike with proprietary copyright infringement, violating the terms of a license like the GPL rarely affects any one person or company adversely, motivating someone to file a lawsuit. I’m not saying a lawsuit is an impossibility or anything, just that they’re a lot less likely to happen in Open Source than they are in the proprietary world.
WRT to your second paragraph, with all due respect, the goal posts keep moving here (at least, seemingly).
The GPL mentions derivative works, then Matt says that themes aren’t “derivative” but rather the “linking” makes it inherit the GPL (which, even that is debated in the OSS community, static vs. dynamic linking).
Now, it’s about being a “single work”. The qualification for inheritance needs to be identified before conversations like this can take place, because that’s what this is all about.
Assuming, however, that the qualification is the “single work” standard, I still don’t see how one could seriously make the claim that they are a single work.
Themes are WordPress-compatible modules. Neither the parent system, nor the modules, necessarily need each other to function. The reason this is true is because WordPress is built on a “parent system” of its own … PHP. And PHP simply makes it too easy to find loopholes. And yes, that’s exactly what this all comes down to … loopholes. Not gaping holes, just small ones that are easily exploited. Obviously, the WordPress developers intended for themes to inherit the GPL, and this I choose to honor that, but intentions aren’t enough to stand up legally, and the GPL simply isn’t equipped to legally impose its restrictions on themes. There are just too many ways to get around it.
@Nathan, thanks for the clarification. Overall, I think we are mostly on the same page.
Derivative work and single work are language for the same outcome. I find the 2nd a useful test in my thinking, but I can see how that could be confusing for others. 1st test for me: does it create a new version (derivative) of a single work. If that fails, then it it fails the derivative work test, and that seems to be the story for WordPress Themes. For example, if I thought my favorite book would be even better if it had a few new chapters or maybe just a different cover, whether distributing my creation by itself or with the original work, the result would be a single work, and I would have to consider copyright of the original work.
From the GPL v2:
The GPL is a copyright license, and Matt’s comment about linking seems a little off. The linking discussion in the FAQ is used to help establish that it is a derivative work (single work) or not. I haven’t seen case law that uses that aspect of the license, and the language in the GPL v2 at least doesn’t go there.
I don’t see how PHP can differ from other interpreted programming languages. You write that these loopholes are easily exploitable, but don’t provide any examples of how this has been born out in courts.
Going full circle, I think Matt’s article on wordpress.org and initiatives like commercial 100% GPL themes listed on WordPress.org will allow many people to move on, move forward. Thanks for your insights.
“Derivative work” is one of those things that is hard for programmers to define because there is no clear boundary. You cannot point to something and say “this is derivative and that is not”. There is no technical definition, because the question is not a technical one. The opinions that matter are the ones held by courts, and they consider it in a much broader sense.
The Copyright Act, says a derivative work is “a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, …, or any other form in which a work may be recast, transformed, or adapted. 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”.
Read that carefully. See how vague it really is? If you think about this carefully and with that in mind, you’ll come to the conclusion that a theme must be derivative, even when written from scratch. Why? Because it is going to be substantially similar to other themes which are also GPL (and two of which are included with WP itself). It might be possible to write a theme in a way that it was different to everything else that came before it, but really, what would such a theme look like? Strange indeed.
Plugins actually have somewhat less of a case. I have seen plugins which would not qualify as derivative works, IMO. The mere use of a function like add_filter() would not realistically be enough to trigger the GPL, IMO. However, the FSF and others stick to the theory that a “deep call” to a function is enough. It’s a very liberal use of the idea of what makes something derivative, and has not been tested in a court, AFAIK.
So yes, themes must be GPL. Plugins may not have to be. It would certainly be easily possible to write your way around the GPL in a plugin with a simple one-file PHP wrapper, even if you did subscribe to the deep-linking theory. I have seen plugins that use multiple types of wrappers to add compatibility with multiple types of blog systems (one that springs right to mind is the popular Bad Behavior plugin). Making the case that these are derivative is a sure-fire loser, IMO.
@Lloyd,
We could definitely go ’round and ’round about this, but I think we understand each other’s positions pretty well now.
We certainly agree that theme authors should license under the GPL, and that’s probably the point we should all take away from this.
Thanks for hashing all this out. I’ve enjoyed it.
Pingback: Breaking News: WordPress is GPL | alexking.org
Pingback: Wordpress GPL Arguments :: CMS Design Resource
Pingback: WordPress Themes are GPL and Chris Pearson still acting like a bully » Mark Finch Thoughts
I always wondered how these commercial theme creators got away with this. I’ve seen many lately putting spyware in the footer.php and then distributing them as well. Then they get all worked up if you modify it.