On Sun, Jul 25, 2010 at 10:22 PM, Tim Starling <tstarling(a)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&…
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(a)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.)