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

[Thomas Barregren]

Laura Scott wrote:
> On Aug 31, 2007, at 2:56 PM, David Strauss wrote:
>
>> Jeff Eaton wrote:
>>> This is very true. It's also important to keep in mind that the FSF 
>>> gets
>>> annoyed when people distribute code that "Is GPL Compliant, Wink Wink
>>> Nudge Nudge" but doesn't actually do anything until you put it in the
>>> presence of non-GPL code.
>
> The no-distribution loophole seems to contradict what was quoted 
> earlier, but if true that's very reassuring. Thanks. The 
> not-permitted- even-if-not-distributed thing was what sounded so alarming.

You must have misunderstood this part. You are permitted to do what ever 
you want with a GPLed code as long as yo don't distribute it. But, if 
you distribute the code, with or without modifications, you must do that 
under GPL. It is as simple as that.

> It's a darned shame though that a GPL module that enhances a 
> free-standing GPL system (e.g., a module that bridges Drupal with an 
> outside system) is lumped together with a "GPL" widget that is wholly 
> dependent upon a proprietary system. The former is what I would 
> consider a powerful enhancement of another existing GPL system, while 
> the latter is clearly a licensing gimmick to get away with something. 
> And yet legally they should be considered the same? Ouch!
>
> Hypothetical: Could one argue that the GPL bridging module that 
> bridges, say, Drupal and ASP.NET does not depend upon the proprietary 
> system in order to be there and available for Drupal? I mean, if I 
> can, for example, see the module active and available in the Drupal 
> admin area, even if the ASP site is not connected, would not that 
> module be considered as not requiring a proprietary system to run?

Suppose you have a GPLed program A and another program B. The fact that 
A depends on B (or vice versa) is not enough to trigger the requirement 
that B also is GPLed. For an example it is perfect legal to let B be non 
GPLed if A use fork and exec and similar mechanisms to call B. A special 
case of this proviso is the "web service loophole". It is only if A uses 
a function, an object or some other internals of B, or vice versa, that 
B is required to be GPLed. Thus, for any construction where A and B can 
collaborate without knowing or assuming anything about each others 
internals, it is acceptable that B isn't GPLed.

So, if you want to build a module that can be used to integrate a 
software with a license incompatible with GPL, I *believe* that a 
solution is to build a GPLed Service Provider Interface (SPI) which 
makes no assumption about the internals of the service providers.

Regards,
Thomas