Why WordPress Themes are Derivative of WordPress | Hacker News Reader

Why WordPress Themes are Derivative of WordPress

markjaquith.wordpress.com

18 pointsicey20 comments

Could we please not have anymore "Why Wordpress themes do/don't fall under the GPL" posts from people who aren't lawyers?

It's an interesting topic, but it's been done to death over the past week in both the blogosphere and on HN. Pretty much every point made, or example given, can be debated in many ways. Until someone is doing so infront of a judge or jury, all of them are largely irrelevant and just noise.

That said, if you are a lawyer with experience in cases involving the GPL then post away. I'd love to hear your point of view :)

I thought this piece did a good job of summarizing the issues, and an especially good job diving into the technical details of this specific example. Those details are sadly lacking from much of the "noise" being made on the topic - the mixergy interview, for example. This post is signal.

The problem is that the technical details it dove into aren't particularly relevant to the underlying copyright question. They show that the user who choses to use a given theme is creating a derivative work, but no one has seriously questioned that. That derivative work is authorized by the copyright holders (GPL allows users to freely mix GPL and non-GPL code on their own systems).

Hence, the important legal question is whether or not the theme, AS DISTRIBUTED, is a derivative work of WordPress. This is a code authoring question, not a code execution flow question. There was little or no insight on that question in the article.

That is a really, really interesting question and there is actually some history behind that - the original developers of Clisp had used GNU readline to implement their REPL. Readline was (and still is) GPL, while Clisp was proprietary.

Anyhow RMS wrote to them and complained, so they asked an interesting question: what would happen if they simply had their software download and link Readline when it was installed on the customers computer?

RMS talked with a lawyer, and came to the conclusion that it would properly not be against the law. They made some sort of agreement and Clisp is GPL today.

While the GPL is a copyright license and a legal construct that is not the only lens with which it should be viewed. It is very much a social construct with a general understanding (i.e. agreement) that differs from the actual text. Do you have a changelog in the actual files? The GPL requires one, but many people do not and I've never heard of someone getting upset because someone did not include one.

This is an opportunity for other blogging platforms to tout that their themes are NOT considered derivative works. And if there are none, then that's an opportunity for someone to create one.

Themes are a major feature to a blogging platform. Stating up front that themes are not derivative of your platform will encourage others to create themes for it.

I have a bit of a question on this one. So I distribute a set of files under my license (pick any non-GPL compatible for arguments sake). None of these files have any GPL code, but when installed at the client, they call GPLed APIs. I do not distribute the actual GPL program (WordPress in this case).

I see in the Thesis case why they are in violation (they distributed GPL code), but in the general case, I am really not sure how you run afoul of a distribution-based license when you don't distribute the whole product.

If you have not copied GPL code into your files (and copying includes translating, adapting, or otherwise transforming the code before you use it), then your work standing alone is not a derivative work of the GPL work.

When the client combines your work with the GPL work, the resulting work on the client machine is a derivative work of both the GPL work and your work. The client must obey both licenses, if the client's combining and copying isn't excused by some exception to copyright law, such as fair use or the exception that allows copying to RAM to run a program.

If the client's production of this derivative work violates GPL, then it is possible that you could be liable for this infringement, as a contributory infringer.

However, the client's production of the derivative work by combining GPL and non-GPL code does NOT violate GPL. The GPL allows the client to take GPL code and non-GPL code and freely mix and use them for his own use. It is only if he wants to distribute the result that GPL requires that the whole work be distributed under GPL.

This lets you off the hook for contributory infringement--it is simply not possible to be liable for contributory infringement when there is no direct infringement for you to have contributed to.

What if the client DOES try to distribute the combined work? Then the client is a direct infringer. Could you now be on the hook for contributor infringement? I'd say you are still safe, because the bar to contributory infringement is pretty high. There must be no substantial non-infringing use possible with your work. Essentially it must only be useful as part of client infringements. That would not be the case, because your work would be useful in the way you intend--for clients to combine with the GPL work to run on their own systems. That's a non-infringing use, and its substantial.

To be safe, when writing add-on A to work with someone else's program P, I'd recommend the following.

1. If P is under an open source license and you wish to license A under a compatible open source license, there is not much to worry about. Write A using whatever means are most efficient, including copying code from P. Skip the rest of the items in this list.

2. If you plan to use a license that is not compatible with P's license, examine P's license to see if there is anything in it that would prohibit P's users from using unapproved add-ons. If there is, you may have to worry about contributory infringement. If that is the case, I'd say give up, unless A will have some use outside of being an add-on for P. Most open source licenses do allow users to do anything they want on their own systems, so if P is under an open source license continue on to item 3.

3. If you plan to use a license that is not compatible with P's license, do not copy any code from P. Ideally do not even look at any code from P. If you need to call functions in P that are not part of a publicly documented API, get the call information from someone else, and don't get code from them--get them to provide a formal specification of the interface but no sample implementation.

The idea here is that you want to be able to say and prove that you wrote A without looking at P's code or any copyrightable elements of P. If you can maintain that, you can't have produced a derivative work. If you haven't produced a derivative work, you don't need permission from P's copyright owner. If you don't need permission from P's copyright holder, you don't care what P's license says.

Note that this is very similar to the procedure you would use when developing an unauthorized add-on to a commercial program whose developer is hostile to unauthorized add-ons. The only real difference is that the open source program defines unauthorized as "not using the license we like" whereas the commercial developer probably defines it as "didn't pay me big bucks to join my developer program".

MDY v. Blizzard is basically the situation you describe.

They were found liable for contributory copyright infringement.

Basically, but not exactly, or even all that similar. With the law, it's the little details that matter the most.

The reason most lawyers on HN have refrained from arguing the parent issue is that it can go both ways. Copyright law is intentionally ambiguous, and court rulings are all over the place. There's really no knowing how the court will rule until it actually does.

I am not ignorant of how laws work. I have spent a lot of time understanding copyright law and in particular copyright licenses.

In my post, I did not even comment on the wordpress issue at hand or even put forth an argument regarding it. I was only commenting on tzs's proposed scenario trying to fill in what I saw as a gap.

It was that kind of case I was thinking of when I put in step 2, make sure the license of P allows the user to combined P with other works.

Blizzard has a EULA that prohibits the WoW user from using software such as MDY's, so step 2 of my advice would tell MDY to give up.

    To the PHP parser, it is all one and the same. There 
    isn’t WordPress core code and theme code. There is merely 
    the resulting product, which parses as one code entity.

Oh please. This is like saying anything compiled in GCC is automatically GPLed.

There is a specific exception to this in the gpl. Actually I'm pretty sure he's even being too lax in his explanation of what gpl requires. If you distribute the theme (or any gpl connected code) you must make the source available, and anyone who gets the theme can also distribute it all they want.

It is PHP, you don't have much choice in making the source available :)

But if you meant that any visitor to your site had the right to get the source code, then the answer is no - that is not how how the GPL works, and you would need the AGPL for that.

The makers of things are the makers of rules.

Wordpress gets to decide what license to use. Wordpress gets to define what is derivative. It's their project they get to do whatever they like.

There is no point in arguing what is derivative or not derivate. The project owner gets to decide that.

Wordpress decided that themes and plugins are derivative. They decided JS, CSS, images/resources, XML-RPC, RSS are NOT derivative.

Them's the rules. Don't like them then pick another platform.

"Wordpress gets to define what is derivative."

No. The combination of US law and wp's license decide what is derivative.

WordPress doesn't get to unilaterally decide what is derivative. Project owners do not get to decide that. They do get to decide what license to use, and what the terms of the license are. A court will decide whether themes are derivative.

If themes are derivative works that the copyright owner can control, then the same expansive reasoning would mean that movie studios can decide whether you can make copies of that BR movie you just bought, game companies could bar you from trading saves, and publishers/authors could bar you from talking about that novel you just read.

Copyright law doesn't change just because open source gets involved, and we shouldn't change copyright law just b/c an open source project is on a power trip.

I agree with this, but here's the question I haven't seen answered. It seems thesis and others want to make their themes non-gpl so they have recourse if someone redistributes it illegally. The question is: "How many people have they ACTUALLY taken recourse against?"

Themes cannot stand by themselves

Yes, they can. Sorta. It wouldn't be very difficult to extract the design for use elsewhere, especially a static website. Most designers start designing with tools like Photoshop and HTML/CSS, not PHP and Wordpress code.

Reply on news.ycombinator.com