The GPL License Mixing

Question

From the understanding that I am gradually gathering about the GPL it is not possible to mix licenses unless both have a special clause added to allow so. So how are the following possible?

Let's use Joomla as the basis of this example:

• People develop plugin scripts that have to invoke library functionality from the Joomla core in order to function. This surely means that the plugin has to be GPL.

• Said people then decide to sell the plugin scripts which I gather is fine as they are essentially selling a distribution/support service. But once purchased the end-user has every right to resell or do with it whatever they like (provided it falls under GPL terms).

Q1. So, how can people sell non-GPL licensed plugins for Joomla?

Q2. How is it acceptable to add some sort of activation system that limits use of the GPL source? Is this not going against the very goal of GPL?

Q3. How can a non-GPL licensed plugin for Joomla be restricted to non-commercial use?

Here is a response that I recently received from a non-GPL Joomla plugin vendor. They offer two varieties, non-commercial and commercial (but neither are GPL).

GPL does not mean that all associated or used software needs to be GPL. It regulates its use. We also would call "Joomla" not a product, it is open-source software under the GPL license.

Our extensions are open-source software under our own specific license terms,

In case you want to resell sites that use our extensions or the extension itself, that is not covered with our license. In case you want to use it on your own site, or sites which you create as designer for your customers, that is covered in our license.

I will not make reference to the plugin vendor at any point in this question because I do not want to make any false allegations. I am simply confused. In my experience of Joomla I have seen this situation over and over again and I have received similar responses.

I am sure that I am simply misunderstanding a fundamental aspect of the GPL, but I really want to understand it.

Added: Please note, my intent is not to sue or anything like that. I want to understand so that I can avoid the same from happening to a project that I will be releasing as open source later in the year. I just want to understand each angle.

Answer 1

The Joomla situation is pretty ugly and arose due to a lack of understanding of the license by it's developers. The Joomla team were initially supportive of people releasing proprietary extensions, so many got the impression that "it's OK."

It isn't OK though. Joomla itself was forked from another project, Mambo, which was also GPL. This makes Joomla require the GPL license, and they can't simply relicense it to allow proprietary extensions, without getting an alternative license from Miro (or now, the Mambo Foundation. But it was was obviously not in their spirit to allow that.)

AFAIK, Joomla have removed all non-GPL extensions from their listings since.

With little doubt, all proprietary extensions which invoke Joomla code are in violation of the GPL. It's clear that Joomla have no interest in chasing violations though, but The Mambo Foundation could still do so (unless Joomla has been since rewritten to remove it's dependency on Mambo, which I doubt).

It's quite clear that those extension developers do not understand the license either. I see lots of complaining about the decision to remove non-GPL extensions - the developers don't understand that it's not by choice of Joomla to do so, but they are forced to do so because of the license.

So to answer your questions

Q1: They can't really. Their distribution is a direct violation of the GPL, and they get away with it because Joomla aren't chasing them. However, if you decided to redistribute one of these works, the author doesn't stand a great chance in court since he is violating the GPL, so you can probably take your chances.

Q2: This is also a violation of the GPL, and you're within your rights to circumvent any restriction.

Q3: They can't. Same as other answers really. Those are the claims of the authors, but they really have little legal standing.

As for your response from an extension author, it's full of shit. The GPL does require that all linked works are also GPL licensed. (Not just GPL compatible, but GPL).

But as above replies have mentioned, what constitutes as "linking" is the legal boundary. Those extensions which simply rely on a service not linked into Joomla are OK.

If you're contemplating releasing code under the GPL, I would recommend it, but make sure you don't let violations get out of hand to the point of no return, as has happened with Joomla. It's a great license, shame they've defiled it so much.

Answer 2

People develop plugin scripts that have to invoke library functionality from the Joomla core in order to function. This surely means that the plugin has to be GPL.

Not necessarily, it would depend on how they are linked and ultimately the interpretation of the court. If you are working purely from published interfaces and your code will work with alternate builds of Joomla you could make a reasonable case that it isn't a derived work. Any more than using the Java runtime makes your code subject to Oracle's license.

But once purchased the end-user has every right to resell or do with it whatever they like (provided it falls under GPL terms).

If the code falls under the GPL, either because they chose to make it so - or because it was deemed to be a derived work

Q1. So, how can people sell non-GPL licensed plugins for Joomla?

If they can make a claim that it isn't a derived work.

Q2. How is it acceptable to add some sort of activation system that limits use of the GPL >source? Is this not going against the very goal of GPL?

You can't - the point of a license is to grant rights, the rights set out by the GPL are very clear

Q3. How can a non-GPL licensed plugin for Joomla be restricted to non-commercial use?

If you own it then just write 'not for commercial use'. Enforcing it is a different matter.

Answer 3

A plugin to a specific platform, depending on that platform, would "inherit" GPL from it. It is a derived work. If Joomla was LGPL, it wouldn't be a problem.

Still, if the plugin is generic - can be used with Joomla or some non-GPL platform, it can be proprietary, it does not depend on the free part. To give you example in the other direction (proprietary preventing GPL), Debian refused to include GameBoy emulator, because it wouldn't perform its intended function without proprietary ROMs. Then a fan-made Gameboy game was released under GPL and suddenly the emulator ceased to be dependent strictly on non-free components, and could be licensed as GPL.

Even then,

• only Joomla authors can sue them. They violated license on Joomla, which depends on copyright owned by Joomla authors.
• they can release their plugins as GPL and still sell them. GPL does not prohibit sales, it just makes a damn inconvenient loophole that any of your customers may freely release a recompile of your product.
• GPL gives you two options of releasing the source: 1. Bundle the source with the product, hand out to customers, 2. Provide the source to anyone on request. If you choose option 1, and sell the software, you don't have to give sources to anyone who didn't pay.

But in the end, if the author of the GPL'd piece is not interested in pursuing violators, there's nothing to stop them. Essentially, if blatantly derivative parts are licensed under arbitrary non-GPL licenses, this violates GPL but has no effect whatsoever until the author of the program that wrote the GPLd part sues the authors of the proprietary parts. (even worse if that's the same person).

There are caveats if the GPL'd work isn't original but derived from other GPL'd works - then the lawsuit could originate from higher above. Still, no lawsuit = do as you will.

Answer 4

WordPress asked time ago a similar problem to SFLC. A extract of the response:

On the basis of that version of WordPress, and considering those themes as if they had been added to WordPress by a third party, it is our opinion that the themes presented, and any that are substantially similar, contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works. Specifically, the CSS files and material contained in the images directory of the “default” theme are works separate from the WordPress code. On the other hand, the PHP and HTML code that is intermingled with and operated on by PHP the code derives from the WordPress code.

[...]

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.

Main article: http://wordpress.org/news/2009/07/themes-are-gpl-too/.