On Fri, Jul 23, 2010 at 7:23 PM, Platonides Platonides@gmail.com wrote:

I think that's because they are more liberal licenses, like MIT*. Do we have any code that isn't GPL-compatible?

*To which extent they can do that is debatable. Maybe they can only license under that license *some* pieces of their code.

There are at least some pages on mediawiki.org for extensions that are not under any open-source license at all. I remember at least one case where an extension there was only available as commercial software, and other developers in #mediawiki disagreed with my opinion that it should be deleted.

I consider that completely unrelated. PHP is a platform, similarly as how you can use a non-GPL program on a GPL kernel. Or write a document on a GPL text editor without it being automatically open source.

Insofar as PHP is just a program that processes input files, yes. But it also includes a standard library. If the PHP standard library implementation were licensed under the GPL, then at least according to the FSF's interpretation, it would be forbidden to write non-GPL programs for it. That's why OpenJDK (at the advice of the FSF) is GPL with a special linking exemption -- without the exemption, all programs written for it might have to be GPL. Likewise the GNU C standard library is licensed under the LGPL, not GPL.

Of course, in some of these cases there are non-GPL implementations too, and if you write it to be compatible with multiple implementations, I don't think anyone argues that it's a derivative work of any of them . . . I'm still not clear on this point. But in any event, I don't see why there'd be a difference between a library that happens to be shipped with a programming language implementation, and one that's not.

It wouldn't need to be under GPL. AFAIK, the case for that is that kernel drivers usually copy code from the GPL ones. Also note that since some version, they have apis not available for closed drivers.

I think there are some interesting discussions about this on lkml archives.

Linus Torvalds, at least, thinks that some drivers intrinsically need to be GPL:

http://lkml.indiana.edu/hypermail/linux/kernel/0312.0/0670.html

I don't know whether his view is correct, but it's certainly prevalent in the Linux kernel community, from what I've seen.

On Mon, Jul 26, 2010 at 4:22 AM, Tim Starling tstarling@wikimedia.org wrote:

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.

I think that is disingenuous. If one considers a skin or extension to be a derived work, that is not because it uses function and class names from the original product, but because they do not have any meaning without the original code. The product, people would argue, is not "extension" but "mediawiki+extension", which clearly _is_ a derivative of mediawiki.

Line numbers are even less creative than function or class names, but if someone took a series of instructions like

* Take Mediawiki version 11.0 * In such-and-such-file replace lines so-and-so to so-and-so by (my own code) * same with several other files/lines

I would argue that what you have is a derived work from MediaWiki. Whether the same holds for extensions and skins, I would not argue from either side, not knowing enough about either the code or the legal side of the matter, but I think your rejection is too easy.

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.)

On Mon, Jul 26, 2010 at 7:54 PM, Tim Starling tstarling@wikimedia.org wrote:

The law does have a preference for the literal.

Except that it doesn't say that a derivative work must contain parts of the base work, or even be similar to it. It says that a derivative work is just "a work based upon one or more preexisting works". It goes on to say, "A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'."

Would you say that a set of patches (in any form) is not "a work consisting of editorial revisions . . . or other modifications which, as a whole, represent an original work of authorship"?

I don't think that argument is particularly convincing. A review of a movie is completely dependent on the creative content of the movie, that doesn't mean the copyright holders of the movie have the right to restrict the distribution of the review.

Reviews might be derivative works, but if so, they're permitted under fair use. Indeed, reviews are one of the standard examples of fair use (although the standard application is when they actually copy parts of the work they're reviewing).

The FSF and SFLC have agendas. They make implausible arguments and justify them by the ends they achieve. I'll believe their interpretation when it's upheld in court.

The interpretation of a lawyer with an agenda is unreliable, but not so unreliable that laymen can second-guess them. At most, a layman can suspend judgment in the absence of unbiased expert opinion, not draw his own conclusions.

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.

On 26 July 2010 18:47, Robert Rohde rarohde@gmail.com wrote:

If there is a decision to be made (and I'm not sure there is), I would personally argue that we should take steps to make sure that authors are informed about the FSF position on the GPL, but not try to enforce it ourselves (except possibly for the extensions and skins actually deployed by Wikimedia).  I don't see much benefit for Wikimedia in taking a hard line with third-party software contributors over the licensing of their extensions.

There isn't really.

One, it would probably take Automattic actually attempting to enforce their copyright on WordPress as they view it, and winning - or achieving a quick settlement and GPL release of the theme code the second a real lawyer reads the GPL, as has happened in every GPL enforcement case to date. Perhaps PHP will be treated differently to C. But until that occurs, if it occurs, no answer exists and one cannot be discussed into existence, or Slashdot would have solved all problems by now.

Two, each developer holds the copyright on their small piece of the code and can enforce it without asking anyone else - as has been reasonably well tested by every GPL enforcement case to date - and Tim's opinion or wikitech-l consensus doesn't actually stop them.

You could ostracise developers who go against the group interpretation of what the GPL should mean, of course, if you feel that's appropriate.

- d.