WordPress Creator GPL Says WP Template Must Be GPL'd

An anonymous reader writes "Matt Mullenweg (the creator of open source blog software WordPress), after review by various legal experts, is sticking to his guns that themes and plugins that 'extend' WordPress violate the GPL if they are not themselves distributed under the GPL. Matt has gone so far as to post this on Twitter. According to Matt, the premium template called Thesis should be under the GPL and the owner is not happy about it. WordPress is willing to sue the maker of Thesis theme for not following GPL licensing. The webmasters and Thesis owners are also confused with new development. Mark Jaquith wrote an excellent technical analysis of why WordPress themes inherit the GPL. This is why even if Thesis hadn't copy-and-pasted large swathes of code from WordPress (and GPL plugins) its PHP would still need to be under the GPL."

Comments

And this folks...

[DarkKnightRadick]

...is why I don't do any work creating anything for WordPress. CopyFree is the way to go.

Re:And this folks...

[cgenman]

...is why lots of businesses won't touch open source software. It is stuff like this that gives ammunition to the FUD.

Re:And this folks...

[MightyMartian]

What FUD? GPL is pretty clear. The developer in this case was an idiot. If you don't want to be bound by any particular license's restrictions, open source or otherwise, don't use stuff licensed using it, or at the very least don't release it publicly.

Re:And this folks...

[Sloppy]

If that's why, then they're idiots. The WordPress guys are not talking about their license or even WordPress itself; they are issuing an opinion about what Congress and the court's inconveniently undefined implied definition of derived work is. Their opinion would apply just as well to proprietary software as it does to Free software. If you write a Microsoft Windows program that calls Windows and is also called by Windows in the same way that Windows calls itself, like say, an installable filesystem or a device driver or perhaps even an MSIE plugin, then these guys would say that your program is a derived work of Microsoft's product. This flavor of FUD, much like software patents, is a threat to all software, not just Free software.

BTW, if you really want to fuck around with people who have this perverse view of what a derived work is, write a new system that is compatible with WordPress plugins. Then all WP plugins will automagically and retroactively become derived works of your program in addition to WordPress itself. License your program in a way that is incompatible with GPL and then you'll end up with a beautiful paradox. Their heads will explode, we can hose the mess away, and all will be well again.

Re:And this folks...

[tomhudson]

PHP is an interpreted language - "dropping a text file in the same folder" is actually adding code - creating a derivative work.

Absolutely not - otherwise, dropping a css file into a folder would also be creating a derivative work.

One of the problems is that the developers are taking the position that "because they don't work in separate processes, they're one program." This is absolutely false. Back in the single-process DOS (and pre-DOS) days, all programs "worked in the same process space", yet they were still copyrighted. Clearest case in point is a TSR (Terminate and Stay Resident - for you young'uns).

The argument that calling the APIs is not sufficient isolation is totally bogus. Calling an API does not make your code part of that code, any more than calling, say, the Windows API means that your program suddenly is merged with Windows and licensed by Microsoft.

When the guy argues in response to this question

So the Plugins API is actually not an API?
Why is it called Plugins API then?

Strictly speaking, no, it isn't an API. It's how WordPress itself is written! "X API" in this sense loosely means "WordPress core functions for purpose X."

It is not "an interface implemented by a software program which enables it to interact with other software." It's just functions. The use of API in this case is technically incorrect, but it's become common parlance, at least in the WordPress community. The incorrect label doesn't change my view of how plugins, themes and WordPress core form a single application, as explained above.

I'll give those links a read.

That's just idiotic. Even a c API is "just functions".

This whole thing is dumb.

Is the php code linked in, in any way, even at runtime? No. They both get run by a separate process, the php interpreter.

I'm in favour of the GPL, but this is beyond stupid.

Re:And this folks...

[yakovlev]

This is why (particularly for things like interpreted languages, but even for things like the Linux kernel) the correct thing to do is to label various interfaces as internal or external. Internal interfaces are those that, if called, make your work a derivative work. External interfaces are those that are considered "using" your work, and thus do not create a derivative work.

As a rule, internal interfaces are specific to HOW your implementation works, whereas external interfaces are more general to WHAT your software does. As such, internal interfaces are more subject to change. There are of course exceptions.

This kind of distinction is particularly important for applications that offer a plug-in or theming API.

Some cases are cut-and-dry:
If you modify GPL source code, your modification becomes GPL.
Most GPL libraries are pretty explicit that EVERYTHING is an internal interface and referencing it make a derivative work. Data is the only thing that doesn't.
For LGPL libraries, linking and calling pretty much any function exported by the original work fails to create a LGPL derivative work.

Other cases are tougher:
A plug-in may operate in the same process space as the main application, but may be considered a separate work if it only calls documented plug-in APIs.
Certain Linux kernel drivers are considered okay (graphics drivers) but others are considered too tightly tied to the original work.

Consider this: If a minor modification to the function call implementation (think remote function call) causes the answer on whether or not it's a derivative work to change, then the line wasn't clearly drawn.

This smells like one of those cases. If PHP scripts were called in a different process space, that would seem to change the result of the analysis, which means we're definitely in dangerous territory.

Without really understanding all the details, it sounds like the developers have made what was generally treated as a public API into an internal one. If it was clearly (READ: In the API documentation) stated as being an internal API that creates a derivative work, then you're okay. If, after the fact, you're saying "no, that API that we treated as public/external really wasn't" then you're in hot water. If this goes to court, you better believe that the documentation and the early mailing list/forum posts by the primary developers will be presented as evidence. If it looks like they EVER implied that you were free to use those without creating a derivative work, then the argument for NOT derivative has a pretty strong case.

NOTE: As was conceded in the comments of the analysis, simply running in the same PHP process without calling WordPress (WP) code isn't enough to create a derivative work. Also conceded in the main article was that using the WP RSS APIs (presumably outside PHP) also do not create a derivative work. In that sense, it seems pretty clear that he considers the RSS APIs to be external while the theming APIs are internal.

The question becomes: Was this ALWAYS clear? If not, you can't go changing the rules just because you don't like what somebody is doing with your work. If it was just ambiguous, then it's a toss up as to who wins. If you were lenient earlier and are now trying to tighten your grip saying that they were wrong all along then you are likely to lose, at least with a jury.

Consider, for comparison, a GPL C library, where there's pretty good agreement on what the rules are. The C library is released as an incomplete "part of a program" where a program that derives from that part must become GPL. It's generally fair game to make that a simple but useful program (think cat/grep) and release to code for that. Then that GPL program can be called by a more complicated program that then does not become GPL. It gets ambiguous but generally not allowed when you make a program that basically exposes the internal APIs without doing anything useful beyond exposing those APIs, and then write a separate non-G

Re:Implications for plugins

[Hatta]

No. It exposes a huge amount of authors of proprietary code to a copyright infringement lawsuit. How they settle this is up to them, but they can't be forced to open their code. In any case, they'll get off a lot easier than if they had misappropriated proprietary code.

That ain't the GPL's responsibility.

[Chris Burke]

Well, what is a derivative work? Guess what? The GPL itself doesn't define that term.

Of course it doesn't, since that term is defined by the legal code regarding copyright in your jurisdiction. Because the GPL is not anything else but a copyright license, it cannot apply to anything which is not a derivative work by the definition of the relevant legal code, because anything not a derivative work is not restricted by copyright law. So if the GPL did give a definition it would be irrelevant, and if it happened to differ from the legal definition at your current location in space-time, it would be wrong. How's an irrelevant and wrong definition going to reduce confusion, exactly?

But then you go and look at the legal code and see that, what do you know, the real definition of derivative work is vague. This is an issue that applies to all of copyright, and sparks many debates (and lawsuits), and has nothing specifically to do with the GPL. The lack of a clear definition is not something the GPL can fix.

It's trivially easy to comply with, but it's VERY hard to make a clear determination if the restrictions extend to you or not. So most people "just take the easy way out" and license GPL.

It's a fair point, that people license their own code GPL just because it's the only way to be sure they aren't violating the GPL of some other code they are using.

However the same issue of confusion applies in any situation where it matters whether you're creating a derivative work or not. With proprietary software, that means people "take the easy way out" and avoid doing anything with the software that could possibly be derivative. The only time the issue doesn't matter is when the license is so liberal it doesn't matter if your work is derivative or not because you can just repackage it with whatever license you want anyway.

And while BSD-style licenses are great for those who want to give away code, I don't think it's worth abandoning the advantages of Copyleft just to avoid the stick issue of what exactly constitutes a derivative work.