
Why WordPress Themes are Derivative of WordPress - icey
http://markjaquith.wordpress.com/2010/07/17/why-wordpress-themes-are-derivative-of-wordpress/
======
ajg1977
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 :)

~~~
andrewpbrett
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.

~~~
tzs
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.

~~~
tomjen3
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.

------
richrd
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.

------
protomyth
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.

~~~
tzs
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".

~~~
mukyu
MDY v. Blizzard is basically the situation you describe.

They were found liable for contributory copyright infringement.

~~~
rprasad
_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.

~~~
mukyu
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.

------
sbierwagen

        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.

~~~
nohat
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.

~~~
tomjen3
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.

------
pkaler
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.

~~~
earl
"Wordpress gets to define what is derivative."

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

------
jasonlbaptiste
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?"

------
antidaily
_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.

