WordPress, themes, and derivative works
The WordPress community witnessed the end of a high-profile war of words last week when the distributor of a popular commercial theme for the blogging platform agreed to license some of his work under the GPL. Prior to last week, Chris Pearson had argued fiercely that WordPress themes are not derivative works of WordPress itself — as the project has long claimed — and thus he was free to sell his Thesis theme under his own restrictive licensing terms.
The stand-off between the projects erupted in a live argument on the Mixergy podcast between Pearson and WordPress founder Matt Mullenweg, one that ended with Pearson essentially challenging Mullenweg to bring a lawsuit against him. With Pearson's change of heart, the issue appears to be resolved. Pearson announced on his Twitter account that Thesis was now available under a "split" license, with the GPL applying to executable portions, and a separate license covering the images, CSS rules, and client-side JavaScript — the formula insisted upon by the WordPress project.
What's in a theme?
The disagreement hinged on a question that will sound familiar to free software enthusiasts: what constitutes a derivative work under the GPL? The WordPress project has long taken the position that both plugins and themes are derivatives of the WordPress application itself, and thus must inherit its license, the GPL v2.
Pearson disagreed, claiming that Thesis was his creation and that he could select a license for it at will. As he said during the interview:
Many commenters on the blog coverage of the fight seemed to be of the same mind, asserting that the WordPress license was irrelevant to "original work" written by a theme creator. Underlying that position, however, seems to be the belief that a WordPress theme is a layer "above" the WordPress application, which happens to call APIs exposed by WordPress.
[PULL QUOTE: Perhaps WordPress's use of the term theme is itself misleading, because it suggests something cosmetic. END QUOTE]Considering that belief, perhaps WordPress's use of the term theme is itself misleading, because it suggests something cosmetic, like a static template or a set of look-and-feel rules implemented in HTML and CSS. But that is not what WordPress themes are. Rather, themes in WordPress are a collection of PHP scripts that implement the entire outward-facing user interface of the site (the dashboard functionality is implemented elsewhere).
WordPress themes are executables that create all of the elements displayed in the browser: pulling the content of posts, comments, user information, category, tag, archive, and navigation links, even search functionality, all by calling WordPress functions. To put it another way, a WordPress theme is the interface component of the application; without a theme installed, WordPress does not serve up any pages, and when not installed in a WordPress site, a theme cannot even execute.
The debate over the GPL inheritance of themes and plugins has been around for several years, prompting Mullenweg to seek legal analysis. According to the Mixergy interview, he first consulted with Mozilla's attorney Heather Meeker, but it is the Software Freedom Law Center's (SFLC) official opinion that he refers to as conclusive proof.
The SFLC analysis states that "the PHP elements, taken together, are clearly derivative of WordPress code,
" citing the fact that they are loaded into the WordPress PHP application with include(), combined in memory with the rest of the WordPress code, and executed by PHP as part of a single executable program. On the other hand, SFLC noted, some elements of a theme, such as CSS rules, image files, and JavaScript, reside on the system only to be served by the web server as data delivered to the client. These elements could be distributed under the same license, but because they are not combined with WordPress itself, do not have to inherit the GPL.
This reading of the situation is essentially the same as the Free Software Foundation's (FSF) take on the licensing requirements for plugins. The GPL FAQ states:
The status of JavaScript components was not explicitly addressed in the SFLC's analysis. The lone discussion of JavaScript in the GPL FAQ deals with web page templates, by which it seems to mean static templates that "assemble" a page, in contrast to the executable definition of "plugin" explored above.
Code reuse and other considerations
During the Mixergy debate, Pearson referenced a 2009 blog post by Florida attorney Michael Wasylik, who asserted that WordPress themes did not inherit the GPL from the WordPress application, based largely on the "running on top of" WordPress argument. Mullenweg and others observed that Wasylik is a real estate, not a copyright, attorney, and that the court cases he references in his blog post are about hardware devices, not software.
But Wasylik also said that "actual incorporation of code
" makes
the work "probably derivative, and the GPL probably applies.
"
Drew Blas subsequently analyzed the Thesis source code and concluded
that the theme incorporates code lifted from WordPress itself.
Furthermore, WordPress core developer Mark Jaquith, in a longer analysis of the problem, observed that a former Thesis developer openly admitted that code from WordPress was copied into Thesis, and Andrew Nacin noted that the Thesis documentation commented on such inclusions: "This function is mostly copy pasta from WP (wp-includes/media.php), but with minor alteration to play more nicely with our styling.
"
Perhaps it was in the face of this evidence that Pearson changed his mind and switched over to a "split" license for Thesis — his only public comments on the decision have been made through his Twitter account.
Whatever the reasoning, Mullenweg seemed relieved to hear the news. During the podcast debate, Mullenweg repeatedly told Pearson that switching to the GPL would help, not hurt, his sales, observing that there are many other commercial theme developers who sell their works while complying with the requirements of WordPress's license. He said that, should Pearson come into compliance, he would add Thesis to the list of commercially-available themes promoted on the official WordPress site (although the addition does not appear to have happened yet).
It is always better for the community surrounding a free software project when disputes such as these reach an amicable solution. In another sense, though, Pearson's decision to relicense Thesis without comment leaves open — in some people's minds — the original question over when themes and plugins are rightfully considered derivative works.
WordPress is not alone in its position; the Drupal project also states that plugins and themes must inherit the GPL from Drupal. Joomla makes the same claim about Joomla extensions, although it admits that it may also be possible to create Joomla extensions that are not derivative works.
There may never be a simple black-and-white test to determine unambiguously when a theme is a derivative of the application that it themes. Fortunately, for the determined professional themer, it makes little difference. As the list maintained at the WordPress site demonstrates, there are quite few talented individuals who can make a living producing and selling GPL-licensed themes.
| Index entries for this article | |
|---|---|
| GuestArticles | Willis, Nathan |
Posted Jul 28, 2010 16:44 UTC (Wed)
by nye (subscriber, #51576)
[Link] (8 responses)
The way this is written seems to imply that the GPL has a say on what constitutes a derivative work. This may not be what the author intended, but it is a frequent misapprehension.
The correct way to say this would be 'what constitutes a derivative work under *copyright law*?' - the license in question is irrelevant.
Posted Jul 28, 2010 17:28 UTC (Wed)
by dwheeler (guest, #1216)
[Link] (6 responses)
"The correct way to say this would be 'what constitutes a derivative work under *copyright law*?' - the license in question is irrelevant."
Technically true, but in practice, what matters is both what copyright law says, and what the license says.
Fundamentally, copyright law defines the "upper bound", in this case, what can or can't be restricted by law.
But within this upper bound, a license can permit certain actions that the copyright law would allow to forbid.
And as a practical measure, laws are often fuzzy; the exact boundary of "derivative" is sometimes unclear, and few people are willing to go to court over such interpretations... so if there is a lack of clarity, a license will often have a practical effect.
There are lots of proprietary libraries that have run-time fees, and their legal theory about derivative works is exactly the same as the GPL's view about linking to libraries.
I don't know if a court case has ruled specifically on that point, but given the widespread practice, I believe a court is likely to accept the interpretation that an executable that links to a library is, in total, a derivative work of that library.
After all, many people have been making that assumption for decades.
Posted Jul 28, 2010 22:08 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (5 responses)
According to copyright law, only the copyright holder of a library (proprietary or free) is entitled to distribute the library code, so in the »proprietary case« the application author must pay the copyright holder a run-time fee to be allowed to pass a copy of the library along with their application. In this case, the question of whether the application is a »derivative work« of the library or not is immaterial, since the fee serves to compensate the (library) copyright holder for letting someone else (the application author) do something which would otherwise be the copyright holder's prerogative, namely making and distributing copies of the proprietary library.
The derivative-work issue only becomes a problem with the GPL, where there is already blanket permission in the license to pass copies of a library along with an application (albeit with strings attached concerning licensing and publication of source code, etc.). The question here is what combining an application with a GPLed library does to the licensing options for that application, not how the library copyright owner is to be compensated for the use of their actual code, which is what the run-time fees are about. I am not a lawyer in any way, shape, or form but would venture to guess that the legal theory covering this (such as there exists) is completely different from that dealing with run-time fees for libraries.
Posted Jul 29, 2010 22:53 UTC (Thu)
by giraffedata (guest, #1954)
[Link] (4 responses)
But who says the recipient doesn't get the library from someone else? The library author gives Mary a copy of his library, then the application author gives Mary a copy of the application.
It seems to me the derivative work issue is no more an issue with GPL-licensed stuff than with any other licensed stuff.
I agree with nye that people should keep clear in their minds what is copyright law and what is GPL. (Hint - if it stops you from doing something, it's not GPL. GPL only adds to what you can do). That prevents them from imagining that the author can control more than he really can.
Posted Jul 30, 2010 1:50 UTC (Fri)
by vonbrand (subscriber, #4458)
[Link]
True, but in the case of propietary stuff you pay for the permission to redistribute the library (and perhaps also for the right to create a derivative work to be distributed with it). In the GPL case the only point that matters is the second one, which is very much irrelevant in the propietary case.
Posted Jul 30, 2010 7:12 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
No, I don't. I said that according to copyright law only the copyright holder gets to distribute their code, and that vendors of proprietary libraries may charge run-time fees in order to allow others to do it too.
Application authors tend to take advantage of that sort of arrangement for the convenience of the users of their code. Whether that makes the application a "derived work" of the library is a non-issue in this case;
the library is presumably sold in order to be incorporated in applications, and end users typically don't get to redistribute the code in question to yet other people.
With a GPLed library, permission to distribute is already part of the library's license, and the authors of the GPL are jumping through hoops to try to enforce specific licensing conditions on the distribution of code that uses that library, which is an entirely different ball-game from the proprietary case.
Posted Jul 30, 2010 10:03 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (1 responses)
That's circumvention, it's forbidden by the DMCA.
Posted Jul 30, 2010 15:41 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
Posted Jul 29, 2010 10:39 UTC (Thu)
by hummassa (subscriber, #307)
[Link]
Now, if _the_ Pierce themes are derivative works of WP, that is one thing that I didn't analyse myself. They can be (especially if lots of non-trivial, can-be-done-differently-but-wasn't boilerplate code is involved). But I have a serious problem with the linking myth.
Posted Jul 28, 2010 20:06 UTC (Wed)
by ThinkRob (guest, #64513)
[Link]
Posted Jul 29, 2010 2:37 UTC (Thu)
by aigarius (subscriber, #7329)
[Link] (2 responses)
Posted Jul 29, 2010 16:21 UTC (Thu)
by njs (subscriber, #40338)
[Link]
Posted Jul 29, 2010 19:41 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link]
Posted Jul 29, 2010 7:51 UTC (Thu)
by rhertzog (subscriber, #4671)
[Link]
I doubt Thesis will end up listed on wordpress.org.
In this blog post, Mullenweg clearly said:
Posted Jul 29, 2010 18:40 UTC (Thu)
by butlerm (subscriber, #13312)
[Link] (29 responses)
This is some kind of joke, or rather the Software Freedom Law Center appears to be engaging in a combination of stupidity, opportunism, and wishful thinking. A derivative work becomes derivative by incorporating protected elements of another work. Whatever the end user does with a plugin has nothing to do with whether the plugin _itself_ is a derivative work. Not only that US law 17 USC 117(a) gives explicit permission for end users to create "adaptations" of copyrighted works as an essential step in running computer software "on a machine".
Those protected elements exclude technical interfaces of any kind, under the *scenes a faire* doctrine and the merger doctrine. The general purpose of an "include" file is to serve as reference material so that a compiler, etc. can be compatible with provided technical interfaces. No copyright violation, even if such things as structure names and elements are copied verbatim. See Bay State v. Bentley Systems (1996) and Gates Rubber v. Bando Chemical (1993).
So it would seem that the idea that a plugin that hasn't copied any technical interface unrelated code is a "derivative work" is entirely specious, fictional, and without any sort of legal foundation whatsoever. The SFLC website certainly contains no trace of an argument to the contrary. The common belief on this point is a combination of rumor and innuendo that such entities as the SFLC and the FSF propagate to an unwitting public, on no apparent basis other than pure opportunism.
Posted Jul 29, 2010 20:45 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (8 responses)
You write b.php .
Now someone gets a copy of my a.php and your b.php and runs a.php . In order to execute it, his system copies a.php into memory (this is a copy of my a.php) and then processes it to include b.php inside. That processed copy is derived from both a.php and b.php .
BTW: I really like your idea about adaptations. So if I have a printer whose drivers don't allow me to do silly things, is it within my right to adapt them? Distribute the resulting code? For profit?
Posted Jul 29, 2010 21:04 UTC (Thu)
by foom (subscriber, #14868)
[Link]
He cannot distribute that combination, of course, but in the Wordpress case, nobody is distributing such combined works.
Posted Jul 29, 2010 21:07 UTC (Thu)
by sfeam (subscriber, #2841)
[Link] (4 responses)
Maybe so, maybe no. The fact that both modules are loaded does not, by itself, make a.php a derived work of b.php. As to whether there now exists some third, separate work that is derived from both a and b, I'd say this is far from clear. Just having two executables running on your computer at the same time does not create a derived work, or so I would claim with some confidence. Is having two sets of php modules available at the same time a different case? I am dubious.
This is not to deny the possibility that a.php might indeed be a derived work for other reasons. But making use of other capabilities that may or may not be present on the system, be they other php modules or separately installed programs, is not a sufficient test for being derivative.
Posted Jul 29, 2010 22:05 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (3 responses)
The problem is that the combination of the licenses that cover a.php and b.php don't allow this derived work under either of them. This is very much not the case of two separate executables.
Posted Jul 29, 2010 22:36 UTC (Thu)
by butlerm (subscriber, #13312)
[Link]
The dubiousness of that proposition aside, any such combination by an end user would be explicitly legal under 17 USC 117(a). That includes _static_ linking if necessary.
"The problem is that the combination of the licenses that cover a.php and b.php don't allow this derived work under either of them."
It doesn't matter whether the licenses allow it or not. No one needs any kind of license to use something they have obtained a legitimate copy of. The only obvious way to defeat the fair use rights Congress clearly intended end users to have would be to have those who receive copies of open source software enter into valid contracts specifying otherwise.
Posted Jul 29, 2010 23:14 UTC (Thu)
by sfeam (subscriber, #2841)
[Link]
Similarly it is impossible to make practical use of a shared library without creating an executable that calls into it. But in neither case does this by itself create a derived work. I know that the FSF implies otherwise in justifying the existence of the LGPL, but that doesn't make them correct.
Posted Jul 29, 2010 23:56 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link]
Posted Jul 29, 2010 22:29 UTC (Thu)
by butlerm (subscriber, #13312)
[Link] (1 responses)
It helps if you actually read the law. The provision I quoted applies to end users. It also prohibits distribution of those adaptations:
"it is not an infringement for the owner of a copy of a computer program to make...another copy or adaptation of that computer program provided: (1) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine...or (2) that such new copy or adaptation is for archival purposes only and that all archival copies are destroyed in the event that continued possession of the computer program should cease to be rightful. (b)...Adaptations so prepared may be transferred only with the authorization of the copyright owner." (17 USC 117(a),(b))
Posted Jul 29, 2010 22:44 UTC (Thu)
by giraffedata (guest, #1954)
[Link]
Not only that, in the case of adapting out the silliness in the printer driver, the law doesn't help the end user either. It says you can make adaptations needed to run the program, and was intended to address the perverse interpretations of copyright law that once existed that loading (and relocating, etc.) a program required permission from the copyright owner. As long as you can use the printer driver to do the things it was intended to do, I don't think any court would say it's an essential step in using the driver to remove silly restrictions from it.
Posted Jul 29, 2010 23:13 UTC (Thu)
by giraffedata (guest, #1954)
[Link] (6 responses)
The explanation of why it's a derivative work seemed ridiculous to me, too -- traditional (e.g. books, films) copyright arguments don't talk about include() statements and memory, and I don't think there is a large body of tested law specifically about software plugins and such. But I have to pay some deference to SFLC simply because they should know (better than me, anyway) and have a reputation better than plain crackpots. So I wonder what's going on there.
Do you know if the derivative work definition has ever been tested in court with software that simply links (after distribution) with other software? Or code that calls other code? Or is it all pure speculation at this point?
With regard to the idea that software that links is a derivative work, I like to go back to first principles: the reason for copyright is to prevent someone from using an author's own work to compete against the author, which would make writing unprofitable, so there would be no writing. But plugins don't compete with the base code. If anything, they cause the base code author to get paid more.
So I don't see any reason the law would give Wordpress authors control over themes.
Posted Jul 29, 2010 23:53 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (5 responses)
Posted Jul 30, 2010 0:03 UTC (Fri)
by sfeam (subscriber, #2841)
[Link] (2 responses)
Neither the GPL nor the LGPL attempts to restrict what a calling program is used for.
Posted Jul 30, 2010 0:14 UTC (Fri)
by tzafrir (subscriber, #11501)
[Link] (1 responses)
But hey, it's impossible for a library to impose usage restrictions, right?
Posted Jul 30, 2010 0:26 UTC (Fri)
by sfeam (subscriber, #2841)
[Link]
But the GPL explicitly does not do this. Clause 0 says:
Posted Jul 30, 2010 0:13 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
I can't tell how that question relates to the post you replied to. Does it have something to do with the definition of derivative works? Or the purpose of copyright?
Taking the question by itself, though: I think it's possible to craft a copyright license for a library so people are restricted in how code they runs uses the library (to the extent you have to copy the library in order to use it, because you need permission from the author to copy it). It's not easy, since a condition on a copyright license must be met before the copying happens, but I think it's been done successfully.
Posted Jul 30, 2010 6:40 UTC (Fri)
by butlerm (subscriber, #13312)
[Link]
A library certainly can, under certain conditions. Notably a binding contract between the library developer and the end user. Forming that contract is a bit of a trick.
If you download a typical open source library from a web site somewhere, you typically have not clicked on a license agreement. If the web site provides you a legal copy of the software without requiring you to enter into a specific agreement, you now own that copy, and you are not bound by any use license.
The only reason why anyone actually needs to comply with the GPL is so that he/she can legally redistribute modified versions of the software. That requires a license because to do otherwise would violate the copyright of the original authors. No such license is required to use software in any manner that doesn't break copyright (or possibly patent) law, unless the software developer/distributors require you to enter into a licensing agreement before transferring a copy of the software to you.
Shrink wrap licenses are in legal limbo in many areas precisely because this does not happen at the point of purchase. A retail end user now _owns_ a copy of the software, and the First Sale doctrine means that the ability of the software developers to regulate further use has ceased, unless a shrinkwrap licensing agreement is counted as a valid contract between the end user and the original copyright holder no consideration.
If you _own_ a copy of software, or a book, or a CD, what legal principle requires you to enter into a further contract that takes away rights you already have by virtue of that ownership. That is the whole point of the First Sale doctrine, first established by the Supreme Court in 1908, and enshrined into statute in 1978. The software industry wants to take all that away with the pretense that opening shrinkwrap (or clicking yes on a post sale license agreement) constitutes entering into a valid contract. Where's the consideration?
The case for a typical open source license is worse. Where is the contract? A license is not a contract. A legitimate "license agreement" is a contract. A "license" grants you permission to do things you do not already have the right to do. It cannot take away rights you already have, which is why "use license" is an oxymoron.
Posted Jul 30, 2010 9:53 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (11 responses)
The plugin does nothing by itself, so you can argue that it is irrelevant as a piece of work and that only the whole thing matters.
> The general purpose of an "include" file is to serve as reference material so that a compiler, etc. can be compatible with provided technical interfaces. No copyright violation, even if such things as structure names and elements are copied verbatim.
Indeed it would look silly if #include "foo.h" was subject to different laws than "import foo", whatever these laws are. Laws and lawyers are never that inconsistent and always stick to some basic common sense. Look for instance at software patents. Oh, wait...
Posted Jul 31, 2010 0:03 UTC (Sat)
by butlerm (subscriber, #13312)
[Link] (10 responses)
You can, and get laughed out of court, unfortunately. Legal arguments actually have to have a legal basis, not just be an exercise in idle speculation.
"Indeed it would look silly if #include "foo.h" was subject to different laws than "import foo", whatever these laws are"
It depends on whether you are making a source or binary distribution. If you are making a source distribution, you don't have to distribute foo in either case. If you are making a binary distribution, it makes a _big_ difference whether protected elements of the include files are substantially included in the resulting binaries, or just referred to during the compilation process. This is not some new thing. The Supreme Court set the basic precedent in this matter more than 110 years ago.
Posted Jul 31, 2010 23:01 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (9 responses)
You meant: unfortunately *for the GPL*?
You are quite convincing about the theory. But in practice Justice is not as deterministic as a computers:
Even if you prove that the GPL has a poor legal basis, it is well-known that it is scaring many companies. So it would still serve its purpose anyway. Just like a number of other legal abuses (you do not fight guns with flowers)
> If you are making a binary distribution, it makes a _big_ difference whether protected elements of the include files are substantially included in the resulting binaries, or just referred to during the compilation process.
Whether this is the "right thing" or not, it sounds simple and consistent enough. Do you have examples of the former case?
> The Supreme Court set the basic precedent in this matter more than 110 years ago.
And whether 110-years old decisions all make sense for software is an interesting question.
Posted Aug 1, 2010 0:39 UTC (Sun)
by dlang (guest, #313)
[Link] (7 responses)
all the GPL enforcement court cases that I am aware of has involved clear copying of the work without including the source.
I am not aware of any GPL enforcement court actions where a library was under the GPL, proper source for that library was provided, and the enforcement action was that because the library was linked to another program, that other program had to be released under the GPL.
I know this is stated frequently as a requirement, and I fully believe that the threats around this may have forced some companies to GPL their software, but just because threats have worked doesn't mean it has a solid legal basis.
Yes, this does mean that I question if there is really an effective legal difference between the GPL and the LGPL.
the idea that software A could be considered derived from library B one day (because it only works with library B), and then the next day someone releases library C with the same interface as library B changing the status of Software A to no longer be considered a derivative work of library B (because it now works with both library B and library C) seems like nonsense to me. The status of software A as a derivative of some other piece of software needs to be based on what the developers A did while they were developing the software, not anything that anyone else does.
arguing that dynamic linking is Ok, but static linking makes something a derived work smacks of the same silliness as people claiming that because a computer copies a binary from the hard drive to ram (or from the ram to the CPU cache/registers) to execute it, copyright law now allows them to control the use of the software.
I also don't think that loosing these edge cases of derived would necessarily be a big deal for the community. I think more damage would be done by people no longer trusting the claims than by the loss of the license coverage.
Posted Aug 1, 2010 6:32 UTC (Sun)
by butlerm (subscriber, #13312)
[Link]
There is probably a pretty good argument that both static and dynamic linking create derivative works, either on disk or in memory. The difference is in part to avoid the silliness you describe with regard to copying software in memory, Congress has explicitly exempted the creation of adaptations and copies by end users that are necessary for them to use software on a machine, provided they do not transfer the adaptations to others, of course. See 17 USC 117.
The thing that irritates me the most about the specious idea that a plugin etc is a derivative work merely based on considerations such as utility and compatibility is if that were to become the case, the outcome would be _far_ worse than what little advantage it might gain in some circumstances.
Every Win32 program could require permission from Microsoft to be distributed for example. Or every program that reads files saved in a proprietary format, or supports proprietary network protocol extensions, and so on.
Posted Aug 1, 2010 11:51 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (5 responses)
Yes, sorry. In this context I was abusively using "GPL" instead of: "the GPL difference compared to the LGPL".
> the idea that software A could be considered derived from library B one day (because it only works with library B), and then the next day someone releases library C with the same interface as library B changing the status of Software A to no longer be considered a derivative work of library B (because it now works with both library B and library C) seems like nonsense to me.
Yes it would be nonsense.
What makes perfect sense however (whether it is legally correct or not) is that the status of software A in your example does not actually change. Because everything in your example is derived from library B, including library C since it is cloning B. I am not saying this is legally correct (I am not a lawyer). But it is simple, logical, consistent and makes sense.
(Note: this originated in http://lwn.net/Articles/394889/)
Posted Aug 1, 2010 21:22 UTC (Sun)
by dlang (guest, #313)
[Link] (4 responses)
this is what isn't logical, and as others point out, is a very dangerous precedence to set.
it would make all free software that was written for windows derived from windows (because that's the only OS it was written for), it would make linux derived from Intel's 386 chip (because that's what it was designed to run on), it would give apple exactly the control that they want over all software written for the iphone, etc
such results would be nonsense, but the same logic that you are claiming for the situation where there is no code copied from a library into an applications source code would lead to these conclusions as well.
I may have missed something, but I haven't seen any court cases that implied or stated that this is valid logic to follow, and there are court cases (like the recent 'jailbreaking a phone is ok' case) that point the other way.
as i said before, besides being a dangerous precedence to set, I don't think it's needed, in part because I haven't see anyone try to use it (in anything other than public threats)
Posted Aug 2, 2010 23:37 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (3 responses)
"Is there an alternative implementation?" is indeed not a rigorous way to express this "test". The real question is: "Is the API of library B an original, copyrighted creation of B?" (assuming that a copyright on just an API can be legal - but please let's not start over).
> this is what isn't logical, and as others point out, is a very dangerous precedence to set.
"Logical", "legal" and "dangerous" are different things. Please avoid mixing them in the very same sentence, otherwise it looks like your reasoning is not sheer but tainted by your agenda.
> it would make all free software that was written for windows derived from windows
Yes. But since Microsoft licenses are absolutely not using the concept of "derived work" like the GPL does, this would be a very different story. (about this difference see other posts above)
> (because that's the only OS it was written for)
Not really, but rather because: win32 and other MS APIs are original, copyrighted creations of Microsoft.
Posted Aug 3, 2010 1:25 UTC (Tue)
by dlang (guest, #313)
[Link] (2 responses)
all iphone apps are derivative works of the iphone OS as it created the API (This is something that Apple would love to have be the case, that way they could use copyright and the DMCA to ban anything from running on the iphone without their approval)
what's even worse is trying to say that using the API in one way (static linking) makes a derivative work, but in another way (dynamic linking) does not. Given that there is no difference in the creative work involved (writing the new program), only in the mechanical step of creating the binary.
The example of apple above is why I say that winning the definition war would be dangerous. It could get even worse than that example. Microsoft has now licensed the ARM core, so they may an ARM device that has a custom chip (in the ARM world you have the core and a bunch of things that can be combined together and manufactured as one chip), and then set the license for the chip API to exclude GPL code. They could even do it in an 'accidental' fashion like the Sun CDDL does.
some free software advocates are so eager to get legal tools in their hands to beat on proprietary software vendors that they don't stop to think how those same tools could be used against free software.
Posted Aug 5, 2010 10:07 UTC (Thu)
by rqosa (subscriber, #24136)
[Link] (1 responses)
> what's even worse is trying to say that using the API in one way (static linking) makes a derivative work, but in another way (dynamic linking) does not. Given that there is no difference in the creative work involved (writing the new program), only in the mechanical step of creating the binary. But there is a difference: the statically-linked binary includes (parts of) the library. If you distribute the binary, you're also distributing (parts of) the library. It's less clear whether the dynamically-linked binary contains any parts of the library; if there are things like inline functions or template functions in the .h files, it probably does, but otherwise… (However, PHP code is distributed in source form, and it seems pretty clear that source code that merely contains a call to "require_once()" isn't necessarily a derived work.)
Posted Aug 6, 2010 8:42 UTC (Fri)
by dlang (guest, #313)
[Link]
since linking is not a creative task, I don't see how it could create anything that's protectable by copyright.
Posted Aug 1, 2010 6:16 UTC (Sun)
by butlerm (subscriber, #13312)
[Link]
No, I mean unfortunately for the persons who find themselves in the situation of making an argument before a court that (1) runs contrary to dozens of precedents, (2) against the whole tenor of copyright law for at least a century, and (3) without at least a theory of why the law requires such a conclusion.
The GPL is just fine. The only issue is about where and when the difference between the GPL and the LGPL can actually be enforced. If there is joint distribution of both the GPL component and the proprietary component, the developers of the former have significant leverage that they do not have if there is not, because the distributors must comply with the license to have the legal right to distribute the GPL component. No specious theories about derivative works required.
"Do you have examples of the former case?"
No. But as far as I know there is no legal dispute about the proposition that including substantive creative material from another source into a resulting product, whether literally or by translation, and without technical necessity creates a legally restricted derivative work. C++ templates and inline functions are usually raised as an example, although to some degree the use of both might be allowed on the grounds of technical necessity, i.e. to the degree necessary to make a compatible interface. cf. Baystate v. Bentley Systems (1996).
"And whether 110-years old decisions all make sense for software is an interesting question."
That is an issue Congress would have to address. The situation with software patents is similar. The latter are probably a counterproductive drag on the economy and the progress of science and the useful arts, but courts aren't generally in the business of making such determinations. That is what legislatures are for.
Posted Aug 2, 2010 21:54 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link]
That's in C. But in PHP an include file contains the interface _and_ their implementations. A PHP include file is more akin to a shared object than to a .h file.
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
You're saying the derivative work issue is specific to GPL because without GPL the application author couldn't distribute his application without the permission of the library author anyway, because the application is no good without the library and he would need the permission of the library author to distribute the library.
WordPress, themes, and derivative works
WordPress, themes, and derivative works
It seems to me the derivative work issue is no more an issue with GPL-licensed stuff than with any other licensed stuff.
WordPress, themes, and derivative works
You're saying the derivative work issue is specific to GPL because without GPL the application author couldn't distribute his application without the permission of the library author anyway, because the application is no good without the library and he would need the permission of the library author to distribute the library.
WordPress, themes, and derivative works
Is it circumvention of an "effective technical measure"?
WordPress, themes, and derivative works
WordPress, themes, and derivative works
The misunderstanding that "linking" (mashing in the same address space) a derivative work does is widespread. But it is a misunderstanding anyway.
People who pay attention to my comments -- if they exist -- know that I am very pro-FSF but that specific piece "linking a derivative works does" of the GPL is bollocks. I have analysed it thoroughly.
WordPress, themes, and derivative works
[...] themes in WordPress are a collection of PHP scripts that implement the entire outward-facing user interface of the site [...]
Yes... well... that wouldn't be the first time that WordPress's distinctly pasta-ish architecture has caused problems...
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
So you go to, oh, cherry.py, and make your theme work.
Inevitably, there would need to be some python shimming to de-conflict your namespaces, make up for missing functionality, and the like.
The part of your work that runs the same everywhere is called the 'theme'.
WordPress, themes, and derivative works
Even though graphics and CSS arent required to be GPL legally, the lack thereof is pretty limiting. Can you imagine WordPress without any CSS or javascript? So as before, we will only promote and host things on WordPress.org that are 100% GPL or compatible. To celebrate a few folks creating 100% GPL themes and providing support and other services around them, we have a new page listing GPL commercially supported themes.
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
Now someone gets a copy of my a.php and your b.php and runs a.php . In order to execute it, his system copies a.php into memory (this is a copy of my a.php) and then processes it to include b.php inside. That processed copy is derived from both a.php and b.php .
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
it's impossible to make any practical use of b.php without creating a work that is derived from both a.php and b.phpWordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
So if I have a printer whose drivers don't allow me to do silly things, is it within my right to adapt them?
The provision I quoted applies to end users. It also prohibits distribution of those adaptations:
WordPress, themes, and derivative works
WordPress, themes, and derivative works
So a library can't have any licencing restrictions as to what the code that uses it will do?
WordPress, themes, and derivative works
WordPress, themes, and derivative works
You are confusing two things. It is certainly possible for a library to be licensed in such a way that its use is restricted. But this does not depend on the notion of a derived work. Use of the library itself is restricted, independent of what the calling code is used for.
WordPress, themes, and derivative works
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, [...]
WordPress, themes, and derivative works
So a library can't have any licensing restrictions as to what the code that uses it will do?
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
- judges are unreliable human beings with limited technical knowledge
- not everyone is rich and patient enough to actually go all the way to court
- US laws do not apply to the whole world
- etc.
For a (depressing) reality check look no further than software patents.
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works
WordPress, themes, and derivative works