[development] Modules that integrate non-GPL PHP apps violate the GPL.

Laura Scott laura at pingv.com
Fri Aug 31 13:50:30 UTC 2007


On Aug 31, 2007, at 6:05 AM, Thomas Barregren wrote:

> The issue original brought up by Jeff Eaton was about the fact that  
> it is not permissible to write modules that bridge software with a  
> license not compatible with GPL.

This interpretation is tragic for GPL applications, imho. It makes  
GPL toxic to other non-GPL applications out there. IANAL. I speak  
only to my perception of how such reasoning can effect the adoption  
of GPL throughout the world.

>>
>> This reasoning seems to employ arguments made by the RIAA and  
>> MPAA, except to opposite effect.
>
> That might be due to the fact that both FSF/GNU and RIAA/MPAA use  
> the same copyright law. :-)

Law is open to interpretation, and the legal tactics of the RIAA and  
MPAA are hardly universally viewed as being consistent with copyright  
law.

Not to mention how they are attacking their own customers in the  
process and undermining their own markets. I believe the cliche is  
"to cut off ones nose to spite ones face."

>
>> I write this as a GPL advocate and a big believer in open source.  
>> GPL open source software is greatly advantaged to dominate the  
>> software world eventually, but trying to force that through legal  
>> ownership assertions strikes me as a great way to undermine the  
>> whole movement.
>
> The beauty of GPL is that is doesn't fight the copyright laws.  
> Quite the opposite! GPL leverage on the copyright laws to protect  
> your freedom to
>
>    * to run the program for any purpose.

--except to integrate with any non-GPL application.

>    * to study and modify the program.

--unless, of course, you want to bridge it with a non-GPL  
application, apparently.

>    * to copy the program so you can help your neighbor.

--unless, of course, you want to help your neighbor integrate a GPL  
application into his non-GPL universe.

>    * to improve the program, and release your improvements to the  
> public, so that the whole community benefits.

--unless, of course, you software doesn't, in effect, ignore the non- 
GPL world.

Suddenly there are caveats in there.

>
> GPL allows you to use both GPL:ed and non-GPL:ed API:s to bridge  
> different applications. GPL also allows you to distribute the  
> derivative work which emerges thereby. But to make sure that *you*  
> don't deny the receiver the same rights as you got, GPL requires  
> you to distributed the derivative work under GPL. Therefore I think  
> this reciprocity of GPL (a.k.a. "copyleft") is something very good.
>
> The reciprocity prevents *distribution* of works derived partly  
> from a third-party software with a license which is not compatible  
> with GPL. Normally, this is also something good. As is said on the  
> GPL FAQ:
>
>    "If we permitted company A to make a proprietary file, and  
> company B
>    to distribute GPL-covered software linked with that file, the  
> effect
>    would be to make a hole in the GPL big enough to drive a truck
>    through. This would be carte blanche for withholding the source  
> code
>    for all sorts of modifications and extensions to GPL-covered  
> software."
>
>    See
>    http://www.gnu.org/licenses/old-licenses/gpl-2.0- 
> faq.html#TOCMoneyGuzzlerInc
>
>
> But, as this discussion is about, this can also pose a hindrance  
> for situations where it can seem reasonable to include software  
> with license not compatible with GPL.
>
> For an example, imagine someone who has put in a lot of effort to  
> write code that integrates a popular but proprietary software with  
> Drupal. So far it is okay under GPL. But now he wants to share his  
> effort with the community. Since the integration code calls  
> functions and share data structures with both the proprietary  
> software and Drupal, it is not allowed.

That's the problem, isn't it? Suddenly "free" does not mean what it  
means. That also seems to mean that proprietary systems need not try  
to integrate with Drupal, even if they want to offer such integration  
to the community under GPL. According to the reasoning at the top of  
this thread, GPL prevents them from doing that. That is a shame  
because it could seriously hinder or prevent the adoption of Drupal  
and other GPL software throughout the business world (where I argue  
it could do a lot of good).

>
> Fortunately, there is a solution. As long as you don't revoke any  
> rights granted by GPL, you can add your own terms and conditions.  
> This can be used to allow integration with software under a license  
> incompatible with GPL. Two examples on this:
>
>  * http://www.gnu.org/licenses/old-licenses/gpl-2.0- 
> faq.html#GPLIncompatibleLibs
>  * http://www.gnu.org/licenses/old-licenses/gpl-2.0- 
> faq.html#LinkingOverControlledInterface
>
> So, to solve the problem that the licensing of Drupal currently  
> force us to "dumbing down" or "bypassing of established application  
> methodologies", I suggest that the Drupal licensing is supplemented  
> with an exception for module developers linking through hooks.

All we need to do is track down everyone who has contributed code to  
the Drupal project and get their okay, right?


>> Laura (who's still wondering what was wrong with GPLv2)
>
> Pardon???
>
> All what had been said applies to GPL v2 as well as v3. So you  
> concerns must consequently also apply to GPL v2 which is used by  
> Drupal. Correct?

That signoff followed  "Time to stop developing software and start  
developing new licenses and lawsuits!" It was deliberately snarky,  
and as such perhaps confusing to some. My apologies.

Laura




More information about the development mailing list