On Mon, Jul 26, 2010 at 02:22, Tim Starling <tstarling(a)wikimedia.org> wrote:
On 23/07/10 10:57, Andrew Fitzgerald wrote:
Saw an article mentioned on Slashdot about
Wordpress themes and plugins
being required to be disributed under the GPL because they are derivative of
Wordpress. Is this also true for Mediawiki extensions and skins? It seems
like the arguements for why Wordpress themes and plugins also apply to MW.
Article:
http://markjaquith.wordpress.com/2010/07/17/why-wordpress-themes-are-deriva…
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.
That's contrary to the FSF's opinion, as mentioned by citing their FAQ
in a previous posting. The Why-CLISP-is-under-GPL document is also
very informative in this regard (hosted at
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-…)
It's also very analogous to MediaWiki's situation since CLISP was only
using the GNU readline *optionally*, and as anyone who's used a
readline C API can tell you that must have been a very miniscule part
and disposable part of CLISP, which isn't the case with MediaWiki
extensions.
The opinion of the FSF's legal team in that case was that explicitly
coding for a GPL'd API (as all MediaWiki extensions do) means that
your program must be under the GPL too. Here's the main gist of the
discussion:
The FSF position would be that this is still one program, which has
only been disguised as two. The reason it is still one program is
that the one part clearly shows the intention for incorporation of the
other part.
I say this based on discussions I had with our lawyer long ago. The
issue first arose when NeXT proposed to distribute a modified GCC in
two parts and let the user link them. Jobs asked me whether this was
lawful. It seemed to me at the time that it was, following reasoning
like what you are using; but since the result was very undesirable for
free software, I said I would have to ask the lawyer.
What the lawyer said surprised me; he said that judges would consider
such schemes to be "subterfuges" and would be very harsh toward
them. He said a judge would ask whether it is "really" one program,
rather than how it is labeled.
So I went back to Jobs and said we believed his plan was not allowed
by the GPL.
The direct result of this is that we now have an Objective C front
end. They had wanted to distribute the Objective C parser as a
separate proprietary package to link with the GCC back end, but since
I didn't agree this was allowed, they made it free.
So I don't think the GPL actually requires a correction for this.
But perhaps it would be a good idea to add a note explaining this.
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.
Opinions differ on that, but that stance has pretty much been what the
GPL was all about from day 1. Whether that's bad is up for debate, GPL
advocates would dispute that, saying that the end result is a lot more
free software from parties that just release their software under the
GPL so that they can take advantage of GPL libraries and programs.
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.
That's different, for the reasons Aryeh Gregor explains.
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.
* 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.
Aryeh Gregor wrote:
The FSF's position on the issue is that
plugins, extensions, and
things like that, which link to/call code from a GPL program, must
themselves be licensed GPL-compatibly:
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.
[...]
Nobody's saying that you have to agree with the FSF, but they're the
preeminent authority on how the GPL applies in practice. Having spent
untold resources and laywer time examining case law in writing the
licenses, and continuing to defend the GPL in court (most of those
cases end in settlement).
Thus they have a lot of insights on how the GPL applies in practice,
which aren't readily gleamed from just reading the license text.
But as I said, I never agreed to that and I don't
intend to start now.
It comes after the words "END OF TERMS AND CONDITIONS".
Whether you agree to that or not doesn't matter. That text is just a
list of best practices on how the license should be appliet to source
code. It doesn't carry any legal meaning, and MediaWiki following it
or not following it doesn't change the responsibility of downstream
distributors. Only the GPL itself matters.