On Sun, Jul 25, 2010 at 10:22 PM, Tim Starling tstarling@wikimedia.org wrote:
In my opinion, MediaWiki extensions are not derivative works unless they copy substantial portions of core MediaWiki code. If an extension merely uses the interface MediaWiki presents, then it is not a derivative work, and the authors of MediaWiki have no right to place conditions on its distribution.
Do you know of lawyers who agree with you, as far as American law goes? (I haven't heard anything either way about other legal systems.)
To adopt an interpretation of copyright law which claims that merely calling code constitutes a copyright violation of the code which is called would, in my opinion, be a terrible stance for a free software advocate to take. For instance, it would bring into question the legality of all open source code which runs on top of the Windows native API, such as 7-zip, not to mention Wine and Mono.
No one says that, though. They say that plugins or extensions are derivative works, not that ordinary programs that incidentally call the system libraries of their particular platform are derivative works. Something intimately tied to Windows, like a Windows shell extension or driver that doesn't make sense outside of a very Windows-specific context, might qualify as a derivative work according to this opinion, but not an ordinary program. A cross-platform program like 7-Zip even less so.
No one claims that reimplementing an API makes something a derivative work, either. The merger doctrine would prohibit that -- the API duplication in Wine/Mono is necessary for the purely functional purpose of compatibility with Windows/.NET code. Baystate v. Bentley is a district court case that rules on this issue explicitly, saying that a program that implemented support for a proprietary data format did not infringe copyright of the official program, because any API duplication was purely functional in nature: http://scholar.google.com/scholar_case?case=8753348956544433&hl=en&a...
The two legal theories which would allow the use of an interface are:
- A function name or class name are not creative enough or substantial
enough to be eligible for copyright.
As far as I know, everyone agrees with that.
- A function name or class name is a small excerpt from a work, used
for the purposes of precisely referring to a larger part of the work. Such reproduction of an excerpt is fair use. This is the same legal theory which allows us to reproduce things like chapter titles and character names in Wikipedia articles about copyright novels.
Fair use is never an absolute thing. It depends very much on the particulars of the case. I don't think it would be possible to argue that *all* plugins and extensions fall under fair use -- they might all win on the amount and substantiality criterion, and maybe nature of the copied work; but purpose and character, and effect on the work's value (the two most important criteria), would depend on the circumstances.
When I agree to the GPL, and when I consent to allow my work to be distributed under the GPL, I'm agreeing to the actual text of the license. I'm not agreeing to every piece of nonsense that has ever come out of Eben Moglen's mouth. I'm not even agreeing to the "How to Apply These Terms to Your New Programs" section, which is explicitly outside of the license itself.
There is no way the GPL can restrict code which is not licensed under the GPL, and is not derivative (in the sense of copyright law) of any GPL work.
The meaning of the GPL is uncontested here: it only restricts derivative works. In GPLv3 it uses clearer (more international) terminology, saying that it restricts only "modified versions", where "To 'modify' a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy."
The question is, under United States copyright law, does an extension or plugin constitute a derivative work? The professional opinion of the lawyers employed by the FSF and SFLC (and possibly others) is that some extensions and plugins are derivative works, depending on how tightly coupled they are with the underlying work. The SFLC did a detailed analysis of Wordpress themes, which I excerpt here:
""" . . .
The PHP elements, taken together, are clearly derivative of WordPress code. The template is loaded via the include() function. Its contents are combined with the WordPress code in memory to be processed by PHP along with (and completely indistinguishable from) the rest of WordPress. The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called. They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combined with WordPress into a larger work.
HTML elements are intermingled with PHP in the two themes presented. These snippets of HTML interspersed with PHP throughout the theme PHP files together form a work whose form is highly dependent on the PHP and thus derivative of it.
In conclusion, the WordPress themes supplied contain elements that are derivative of WordPress’s copyrighted code. These themes, being collections of distinct works (images, CSS files, PHP files), need not be GPL-licensed as a whole. Rather, the PHP files are subject to the requirements of the GPL while the images and CSS are not. Third-party developers of such themes may apply restrictive copyrights to these elements if they wish.
Finally, we note that it might be possible to design a valid WordPress theme that avoids the factors that subject it to WordPress’s copyright, but such a theme would have to forgo almost all the WordPress functionality that makes the software useful. """ http://wordpress.org/news/2009/07/themes-are-gpl-too/
- Section 5 applies only to derivative works, and as I said, it would
be a terrible thing for the free software movement if it were to attempt to apply this term to code which merely calls a copyrighted interface.
No one does, though. Something is only a derivative work in the view of the FSF/SFLC/etc. if it's an extension or plugin that's tightly coupled to the core program. Merely calling interfaces does not make something a derivative work according to anyone.
If section 5 did apply to function calls, then every GPL program would have to display prominent notices crediting the copyright holders of every GPL library which it called, due to sections 5(a) and 5(d).
This seems to be true, yes. Of course, there are few GPL libraries out there -- most are LGPL for this sort of reason.
On Mon, Jul 26, 2010 at 5:29 AM, Tim Starling tstarling@wikimedia.org wrote:
Those instructions do not contain any of the creative work that went into making MediaWiki. Thus the copyright holder has no right to restrict the distribution of those instructions.
If that were so, then you could evade the GPL completely by distributing modified source code in the form of the original unmodified source code plus a small program to patch it (not diff files, since those will contain the contents of removed lines). Along with an unmodified binary, together with a program to patch it just before runtime. Do you think this is correct? That would sure break the idea of copyleft to pieces.
Such a work might not "contain" any of the creative work that went into making the original software, if you construe "contain" in a very literal sense. But it is completely dependent on the original creativity. Without the creativity of the original author, the modified work could not meaningfully exist -- it is an extension of the original work, not something independent. This is what makes it a derivative work in the view of the lawyers employed by the FSF and SFLC, inter alia. (I wonder what Wikimedia's counsel thinks.)