Hacker News Reader

Comment by dangrossman | Hacker News Reader

A related law-review article someone else on HN shared with me: http://web.bu.edu/law/central/jd/organizations/journals/bulr...

My interpretation is that the precedents in that article support this author's intepretations -- WordPress themes and plugins are not derivative works of WordPress. Merely calling simple interface functions is not enough to make a derivative work according to those cases.

Also, it may not be clear at first glance, but the author of this article and several of the commenters are lawyers.

View on HN

It depends on how you look at Wordpress. Are themes data that Wordpress processes, or are themes programs that use Wordpress as a library? In the first case, it is certain that the GPL does not apply. In the second case, it is certain that it does.

Personally, I see Wordpress as a library for implementing Wordpress themes, and it follows that Wordpress themes must be distributed under the terms of the GPL. (Wordpress could easily fix this problem by making themes data, not code. But they didn't implement it this way, which leads one to believe that the authors intended for the themes to be GPL'd.)

Also, it may not be clear at first glance, but the author of this article and several of the commenters are lawyers.

True, and their analysis of the law is very good (well, it sounds good to me, anyway). But their analysis of the software is not so good; I think they decided on my first scenario, even though the code does not support this.

Personally, I see Wordpress as a library for implementing Wordpress themes

By that tortured logic, the Linux kernel is a library for implementing programs and thus every closed source driver and every closed source program that run on Linux must be GPL'ed. It's pretty clear that the authors really want themes to be GPL'ed but their intent is not the deciding factor here.

There is specific wording in the GPL covering that case.

I am not trying to use "tortured logic" to make a point; I really think this is how Wordpress themes work. Without a theme, Wordpress does absolutely nothing. The theme makes calls into Wordpress to add data and display data. Each theme is its own piece of blogging software that uses Wordpress to abstract away common problems. That's a library.

Another "application" that is actually a library is xmonad. It's a library for writing a window manager that works in a certain way, and it's your "config file" that actually uses the library in such a way as to make a window manager. This is not "tortured logic", it is just good software design. (Although in the case of Wordpress, it's not the right design. Themes should not be applications, they should be data.)

There is specific wording in the GPL covering that case.

Which part of the GPL do you have in mind?

Each theme is its own piece of blogging software that uses Wordpress to abstract away common problems. That's a library.

That's a library under a tremendously contorted definition of library. As I said, if that's the criterion for something being a library, any program that loads and runs extensions is a library. Firefox is a library, Apache is a library, etc. It may be your preferred definition but it's at odds with both common sense and the way the Wordpress people describe their product.

http://wordpress.org/about/

The issue is direction. Themes call into Wordpress to get data. Mozilla plugins are called by Mozilla; if anything, Mozilla becomes GPL'd when it loads a GPL'd plugin. (Remember the whole "kernel taint" issue?)

Anyway, if you want me to dissect a Wordpress theme and show you why I think this, I will. But I think it's obvious if you look for yourself.

I don't think there is a case in which 'direction' figured in a copyright decision. The criteria are much more straightforward than that.

You never answered my question about what specific GPL language excludes the Linux kernel from the kinds of claims you are making about Wordpress. Or Mozilla (you claimed Mozilla loading a GPL'ed extension makes it GPL which is an interpretation that makes the GPL not 'viral' but an actual virus)

On the other hand, it's WordPress where execution begins, and it's WordPress that loads the theme into the interpreter.

This isn't necessarily true - it's quite possible that a Wordpress index template is the first thing run. The idea that copyright law hinges on who called whom first remains preposterous, though.

Possible, but exceedingly rare. For a theme to provide a top-level script, it would be referenced with a URL like mysite.com/wp-content/themes/mytheme/scriptname.php, which would be ugly, brittle, and contrary to the clean-URL style that WordPress promotes. It is nearly universal that WordPress's code responds to a request first, and then dispatches to the appropriate files in a theme depending on the type of request.

It's interesting that the structure of Wordpress affects whether the themes are derivative works. Maybe it's the PHP-soup style of HTML interspersed with PHP function calls that creates the situation you describe. The same system written so that the themes are stored as lists of colors and dimensions to be interpreted by the blog software would keep the themes as non-derivative works.

Definitely. XSLT is something that could work this way -- the blogging software generates an XML document with all the relevant information, and then the XML stylesheet is applied to make the XHTML (or Atom, etc.) result. Additional CSS and Javascript could of course be bundled.

In this case, there would be no question as to the legal status of the theme. It's just a program that transforms the output of another.

The existence of "hooks" further complicates things. WordPress themes are essentially collections of event handler scripts, and those scripts can register callbacks such that when core WordPress functions are called, those callbacks are executed. So, you have WordPress calling the theme calling WordPress calling the theme...

It is only "certain that it does" if all libraries or users of libraries are derivative works, but they're not. The law review article I linked lays out the case law for this, and the precedents are that merely using a library does not create a derivative work of that library. Cases that specifically said that including interface code from a GPL'd library is not a derivative work unless the interface is sufficiently complex -- which "the_title", "the_content" etc. that WordPress exposes is not.

As someone who generally likes the GPL, it's frightening that the line is so blurry. I have written and distributed libraries under the GPL because I think it's reasonable for me to insist that people who find bugs or make improvements give them back to me. But I don't think it's reasonable for me to insist that any user of the library release the rest of their application to me. In my mind at least, an application doesn't seem like a derivative work of a library.

You should learn more about the distinction between the GPL and the LGPL. Whether you make a library that is GPL and include it in a non GPL program, or you have a GPL program and want to include a non GPL library, both cases require all code to be released as GPL.

The GPL does not care about "library" verus anything else. The GPL is somewhat oriented around the constructs of C, but there have been clarifying guidelines from the FSF and in general its not hard to see how everything fits in for another language.

The LGPL, on the other hand, makes specific exceptions for libraries which are linked into an existing application. So long as a proprietary application is using the library in such a way that it could be removed and replaced for another compatible version, it is not considered a derivative work under the LGPL and is not subject to release.

(See boucher's comment for the difference in LGPL and GPL.)

The GPL also doesn't require them to "[fix] bugs or make improvements give them back to [you]".

It merely requires that if they do give the binaries to someone, including you, they have to also make available the modified source to those recipients.

I'm perfectly free to take your GPL code, modify it and run it in-house, including using it in a SaaS or web offering offering, and not give anyone access to the source modifications.

An excellent point. You are correct.

Reply on news.ycombinator.com