And the "FSF's own interpretation" disagrees with the Copyright Act and applicable copyright case law. Thus, the "FSF's own interpretation" is not legally enforceable.

For reference, see Computer Associates v Altai, Sega v Accolade, Sony v Connectix, and Galoob v Nintendo.

PHP include/require versus exec/system makes no difference whatsoever in determining whether or not a work is derivative of another work. In order to be derivative, a work must incorporate, in some concrete form, copyrightable content of a protected work. (See the Altai decision.)

The GPL is a copyright license. Therefore, it cannot extend the definition of "derivative work" beyond the definition from the Copyright Act and applicable case law. So, if what the GPL states is inconsistent with the Act and case law, it is unenforceable.

And that interpretation by the FSF just doesn't coincide with the Copyright Act and applicable copyright case law. Guess which interpretation would win in court?

"Derivative Work" and "Public Performance" are two entirely separate things under the Copyright Act. The GPL explicitly states that anything not involving distribution of a copied or modified work is outside the scope of the GPL. Thus, "public performance", not being an act of distribution, is, as stated in the GPL, outside its scope. The GPL FAQ on this point will simply not withstand a legal challenge.

"The claim of WordPress authors" does not define "derivative work". Only the Copyright Act and applicable copyright case law define "derivative work". So, if what Matt Mullenweg, the FSF, and the SFLC *claim* is a derivative work differs from what the Act and the courts consider to be a derivative work, the Act and the courts will prevail, *not* Matt Mullenweg et al.

It would be completely irrelevant. Intent of the licensor is defined wholly by the license. Otherwise, FSF could write whatever editorial content they want on that site. There is no guarantee that either a) that editorial content was on the web site at the time that the Theme developer developed his Theme, or b) that the Theme developer ever even read that website (since the license itself is distributed with the code).

The statement you quoted is not part of the actual terms and conditions of the license. It is editorial only.

Further, this statement from the actual terms of the license trumps the above statement:

The end-user is free to do whatever he wants with GPL code - include link it to non-GPL code. Unless that combined work is distributed, the GPL simply does not apply.

First of all, it's not *fraudulent*, it's potentially *infringing*. Second, Thesis' plagiarism of WordPress core code is an entirely separate issue from the question of whether or not Themes are inherently derivative of WordPress.

A Theme developer has absolutely nothing to do with the PHP interpreter. If any WordPress-Theme combination takes place, it is the *end user* who combines the two, at run-time, on his own server. The Theme developer makes, much less actually *distributes*, no such a combination.

I just want to point out that, if there are any "pricks" in the WordPress/Theme derivative work debate, Mark Jaquith isn't one of them. I believe he misunderstands the Copyright Act applicable copyright case law, but he - of anyone - is the most willing to discuss the matter respectfully.

The "nature of PHP" is entirely irrelevant. With respect to the Copyright Act and relevant case law, the only germane question is whether or not a Theme incorporates copyrightable code from WordPress core. That a Theme is dependent upon WordPress (and technically, it's not. Someone could write an underlying application that defines the same function calls and hooks) does not render it derivative of WordPress. It doesn't matter how the two interoperate or link. The only thing that matters is whether or not a Theme incorporates copyrightable WordPress core code. And, as the previous commenter pointed out: any WordPress/Theme combination happens at run time, *by the end user*.

No WordPress theme *requires* WordPress core code in order to function. Rather, Themes require only function calls and filter/action hooks, which constitute non-copyrightable methods of operation per applicable copyright case law. The keys here are: 1) Under the Act and applicable case law, *dependent* != *derivative*. 2) Mere function calls do not constitute incorporation of core WordPress code.

The GPL doesn't define "derivative work", nor does the FSF's GPL FAQ; only the Copyright Act does. If the GPL's interpretation of "derivative work" differs from that of the language of the Copyright Act, or of applicable case law, then the GPL's interpretation will not withstand a court challenge. And in fact, the interpretation of FSF/SFLC/Matt Mullenweg/et al that WordPress Themes are inherently derivative of WordPress core, and therefore inherit GPL, runs exactly opposite to relevant copyright case law.