⇥ WordPress, the GPL and cherries on top
The WordPress community is abuzz with news that the WP Foundation has essentially gone to war with the makers of the Thesis WP theme. The substance of the argument, as I understand it, is that the makers of WordPress claim that themes, since they rely on WP’s GPL’ed code to run, must be covered by the GPL as well because they are derivative works. Thesis, on the other hand, is distributed under a commercial license, therefore violating this tenet.
I have, in the past, expressed my dislike for the GPL, which, inevitably, colours my “legal” opinion on the matter—though, I assure you, this post is not about the GPL and I have absolutely no intention on engaging on a debate on the license. Write me or comment on the GPL and I will simply not care—you’ve been warned.
Legal opinions abound
As always when a legal matter is involved, everyone and their dog is giving an opinion. Matt went and asked the Software Freedom Law Center to officially render theirs, and they came through, true to their name, with a nine-paragraph letter that illustrates how themes are, in fact, derivative works covered the GPL.
Arguments on the other side of the fence typically focus on the fact that themes are not derivative works, or because of the fair-use doctrine1.
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 function2) 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.
Obviously, the SFLC probably believes that any form of linking or reliance of a piece of software upon another creates a derivative work, and they may well be right. Larry Rosen of the OSI believes that the determination of what constitutes a derivative work in the context of software should also take into account the element of intent—that is, whether the author of the work in question wrote their software in a specific way because they were aware of and attempted to circumvent the application of a license to derivative works. If he’s right, building a theme cannot possibly constitute the creation of a derivative work—again, WordPress is designed to be expanded, and it cannot taint downstream work that is not a direct derivation of itself, much like Linux cannot impose the GPL on commercial drivers or on commercial products built on it3).
Legal opinions are meaningless
Here’s the kicker: what I think is meaningless. What Matt thinks is equally meaningless. And what the SFLC means is most meaningless of all.
I am not a lawyer, and neither is Matt. The SFLC, which has an obvious bias towards the enforcement of the GPL4 is made up of lawyers and they, more than anyone else, should have made sure to cover their collective ass and Matt’s by explicitly pointing out that there is but one legal opinion that matters: that of a judge and jury.
Unless the WP Foundation ever takes the makers of Thesis to court, therefore, all these “legal opinions” have absolutely no legal value whatsoever. They are nothing more than a form of posturing and an exercise in public relations in the world of court opinion, to cite Adlai Stevenson.
And that is what puzzles me, because from a business and strategic perspective, the WP Foundation has nothing to gain from this exercise. Let’s look at the possible outcomes:
- The WPF could sue and lose, and look like idiots who spend their time litigating rather than innovating (which is what they should stick with).
- The WPF could sue and win—and still look like idiots because the implications of themes being covered by the GPL would have an enormously chilling effect on the professional WordPress community. More than that, they would have to sue every infringer, or risk looking like they are pursuing some secret Matt-centric agenda.
- The WPF could do nothing and look like warmongering zealots—belligerent only in words, all they would achieve is a polarization and eventual schism of the community between those who believe that software is free, and those who believe that GPL is about freedom.
The way I see it, there is no possible outcome of this diatribe that could benefit the WPF, which is why I am puzzled.
Incidentally, you may be wondering why I think that GPL’ing the themes will be problematic for the entire community. Well, what I am wondering is: how will it affect the thousands of freelancers who create custom one-off themes for clients?
This is a big problem, because the GPL does not attach itself to a derivative work until you distribute it—this is why, for example, you don’t need to release GPL code if you hold copyright and use it for your internal purposes. If you are a freelancer, however, you normally hold copyright on a theme you develop but don’t use it for your own purposes—you give it to a client under some sort of license… which is exactly what amounts to distribution.
Unless you assign the copyright in your work to the client (and why would you want to? You are a freelancer, not an employee, and giving up copyright in a particular work is tantamount to giving up your trade secrets), you are, effectively, distributing the theme you developed, which now becomes covered by the GPL. Should the theme somehow include code that is owned by the client—for example to interface to one of their internal systems—that code might well be covered by the GPL, too, thus opening a can of worms of elephantine proportions: the client has gone from ordering a bunch of templates for its website to having to open-source and distribute its own proprietary code. If I were said client, I’d probably be switching to another CMS right now.
Naturally, the WPF could say that it won’t pursue those cases, but they don’t get to choose what the GPL attaches itself to or not—remember, the GPL is not GPL’ed itself: you can’t modify it, you can only use it or not use it. And the GPL says that derivative works must also be released under the GPL period.
So, what the WPF thinks the GPL applies to and what it actually applies to could be two completely different things. Therefore, while you may not get sued by the WPF for writing a proprietary theme specifically for a client, the GPL may still apply to it and all the code that is part of it—which means that, if your theme uses a client’s proprietary code, you’re both in potentially big, big trouble.
So, what should the WPF do?
First, it should back off; this fight isn’t helping anyone—least of all the WPF itself.
Second, it should draw very clear lines in the sand:
- WP is released under the GPL, and so has to be any direct contribution to core or fork thereof.
- Themes and plugins are not derivative works and are not covered by the GPL and can be released under commercial licenses.
- Themes and plugins distributed by wp.org must be released under a GPL.
This creates a fair and balanced set of clear guidelines for everyone to follow: if you want the exposure of wp.org—for example to increase your reputation and credibility as a WP expert freelancer—you have to release your code under an open-source license. If you want to distribute your code commercially, the burden of promotion and public relations is on you since the community doesn’t benefit directly from your work.
Now, I anticipate that some will simply say that, under my proposal, nothing would prevent commercial vendors from circumventing the fact that core is GPL and simply using plugins to effectively fork WP without forking it. Well, nothing has prevented them from doing that until now5, so how would this be different, other than giving developers and freelancers the confidence that the WPF board isn’t going to wake up on the wrong side of the bed one day and start suing people left and right?
- I link here to two articles by the same author only because these seem to be the best-researched among those I’ve seen. There are plenty more to go around. ↩
- I am not splitting hairs: if you want to make a legally-valid argument, it needs to be based on a technically valid thesis, or you will be ripped to pieces by the opposing expert. Trust me—I’ve done the ripping myself. ↩
- Again, the distinction is fuzzy here, because there are no binaries and no static linking in PHP—but that doesn’t mean that a court of law could create an analogous framework for PHP applications based on whether code was copied, whether there is overlapping functionality and what the intent of the downstream developer is. ↩
- It’s the very reason of their existence, and there is nothing wrong with that. ↩
- Sure, maybe the WPF claims that themes and plug-ins are covered by the GPL, but that hasn’t stopped developers from building commercial products anyway. ↩
Comments
How about having two versions of any given commercially-released product like Thesis? Kind of like the app store, a free, “limited” version that is available for free under the GPL and a commercial, paid version that is available under another license? WP could then require all commercial add-ons to provide a free version with a decent ration of free features versus paid features and everyone would be happy… but then again, it’d require people to respect that too.
To me its clearly a derivative work as defined in the GPL license, so the WPF, having chosen the GPL, has every right to sue. Actually if they don’t sue, they might as well stop using the GPL, something which I would welcome.
Themes are “distributed” by nature and if a theme is affected by GPL that means I can copy the theme of any commercial website. Yea sure that may be your company logo but by putting it in a theme and distributing it its now GPL.
“If you are a freelancer, however, you normally hold copyright on a theme you develop but don’t use it for your own purposes—you give it to a client under some sort of license… which is exactly what amounts to distribution.”
That doesn’t hold up in every jurisdiction as far as I know. And if it’s a one of theme, it’s probably best to re-assign copyright anyway…
In any case, I do think that themes are derivatives as they *do* use code. Whether it’s dynamically or statically linked doesn’t really matter anyway as it uses APIs that are under the GPL (the APIs are code after all).
Most Freelance contracts I’ve encountered won’t let me use the theme I developed for client A, with Client B. But, my experiences could be abnormal..
Are you suggesting I could build a theme, use IonCube or Zend encoder, and distribute that binary under any license?
IANAL or smart.. so take all of this with a grain of salt.
I would argue that doing custom client work does not count as distribution. If you develop the custom code and deploy it only on the client’s server I don’t think you’re really distributing it. But I guess it depends on your definition.
Follow up to my previous comment.
This is taken from the GPL’s own FAQ:
“But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL.”
I think the key there is releasing it to the public. If you are contracted to do work for a private individual or company and deliver the code to them I don’t think it could really be argued that you are publicly distributing it.
You don’t transfer copyright to your clients? What are they paying for exactly?
Winning would not have a chilling effects because all of the non-Thesis major commercial themes are already GPL, and doing great. It works in practice, if not in theory.
Why? How many prominent non-GPL distributed WP themes are there? Thesis is one of the exceptions.
Seriously? You’d develop a theme for a company, and then maintain that you own that code? So if the company is sold, what, you get to be in on the negotiations, or they’d have to stop using the theme you built? Why would a company pay you to construct a rope that you’d use to bind them? That’s certainly contrary to every consulting relationship that I’ve had. It’s all work-for-hire, which means that it is not distribution. They own the code, and if they don’t distribute it, it is not distributed.
Many people have changed their mind in favor of our interpretation of the GPL. If you listen to the Mixergy interview, it certainly wasn’t Matt who came off as pugnacious or zealous. It seems that the more the issue is brought to light, the more favor swings towards WordPress. Many people have expressed that they were simply unaware of the licensing issues.
A better way would be to provide an alternate theming mechanism that doesn’t make the theme reliant on GPL code. For example through a 3rd party templating language (Twig, Smarty, etc). As much as I dislike using them, I can’t think of any other way to keep it at arms length from the GPL.
IANAL. Now, with that out-of-the-way…
Yes, and how exactly is this a problem? The theme goes under GPL as it is being distributed. If your client wants to distribute the theme, they also will need to do so under the GPL. The GPL only stipulates that if you distribute the software, you must also provide the source code at no more than the price of the software. Just because it’s GPL doesn’t mean that it needs to be released to the public.
Why would the theme touch proprietary code? Even if it does, why would the organisation have to open-source and distribute their code? GPL doesn’t require distribution. It just means that if the organisation were to distribute their proprietary code *together with the GPL theme*, it would then have to be under the GPL.
The real issue here is actually on your end, as you’d be the one distributing code that is incompatible with the GPL. The only way around it that I can think of is providing the theme under GPL, then provide a patch separately to inject the proprietary bits.
WordPress has several public APIs that spit data out of WordPress. When you interact with these APIs, you are not forming one intertwined codebase, like with a theme or a plugin. These APIs are Atom, RSS, AtomPub, and various XML-RPC APIs. You can use these APIs and be 100% outside of WordPress, with no code interdependencies. You can license the software that interfaces through those external APIs any way you like. But at that point, you’ve re-implemented a non-trivial portion of what makes WordPress WordPress. Thesis has hundreds of hook registrations and function calls and class extensions to WordPress. So it’s a lot of work to avoid the license. You’d be better off developing on another platform that doesn’t have a viral license, or just building your own platform (which I believe Chris has suggested he might do).
Maybe that’s the best solution. Chris believes that Thesis stands alone from WordPress. It doesn’t, clearly, but he could make it stand alone (assuming he gets rid of all the code that was taken from WordPress).
But if they were doing this, they would have an interest in improving the core to support new features and capabilities. Chances are high that they would be contributing to the core or at least testing and reporting bugs. If you want to do a lot of things with plugins, you’ll probably contribute to the core development of WordPress–even if it is just fixing the bugs that you notice.
I do custom design work and code my own themes for my clients. My understanding is that what I do for them falls under “work for hire,” and that they own copyright to the theme and no-need-to-GPL CSS/HTML/images. Because they prefer unique work and design, they have no incentive to distribute it to other people. They *can* turn around and use the design on another site of theirs, but thankfully they have not.
David’s comment also covers a common understanding between me and my clients. Even if the work for hire concept didn’t apply, I or my clients are under no compulsion to distribute the source code to anyone except those whom we choose. Nothing in the GPL gives anyone the right to demand I release my source code to them, only to the ones to whom I’m distributing it. It doesn’t grant the right for someone to be distributed to. And that’s my two cents.
I just wanted to say I couldn’t agree more with your points.
Wouldn’t this pretty much prohibit anyone distributing commercial software for linux as well?
[...] week, I posted an article that pretty much started with “this is not about a legal interpretation of the GPL.” Therefore, [...]
[...] Tabini (co-fondateur du magazine php|architect) indique qu’il n’aime pas la GPL, et l’opinion de chacun ne change rien, seul un tribunal [...]
[...] [...]
[...] Read the original article here: WordPress, the GPL and cherries on top | The Accidental Businessman [...]
[...] Tabini (co-fondateur du magazine php|architect) indique qu’il n’aime pas la GPL, et que l’opinion de chacun ne change rien, seul un [...]