On Mon, Jul 26, 2010 at 02:22, Tim Starling tstarling@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-derivat...
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-G...)
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.