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

[Thomas Barregren]

David Metzler skrev:
>> f your code link to another code and call functions and share data 
>> structures with that other code, your code becomes a derived work of 
>> the other code.
>
> You keep insisting this, but I don't agree its that cut and dry.

I believe that legal issues never are cut and dry. GPL is no exception. 
It is always possible to construct circumventions to the intent of GPL. 
Tivoization is a good example.

> Current literature on the subject suggests otherwise when calling code 
> that is "designed as a library".  Regardless as to whether it is 
> statically linked or otherwise.  Creating a derivative work is not a 
> technical definition, it's a legal one.  Most of the reading I've done 
> outside of the GPL FAQ agrees with this.

I agree that code that links to a library, which were *designed* and 
*intended* to be used as a library, not necessarily makes the code a 
derived work of the library, but just a collective work. But as I 
understand it, that is not the subject matter. We are talking about 
modules that bridge Drupal with third-party software. Let me elaborate 
on my arguments:

Drupal is not *designed* nor *intended* as a library. It is an 
application. A module, which links to Drupal, calls functions in Drupal 
and shares data structures with Drupal, can therefore not be said to 
merely using Drupal. In fact, the very purpose of the module is to 
modify how Drupal works. Therefore, Drupal and the module, as a whole, 
is a derived work of Drupal. And as a such, it must be under GPL.

Now, suppose we develop a module that bridges Drupal with another 
application. The very need of a bridging module implies that the 
application is not *designed* nor *intended* as a library. As a bridge, 
the module must obviously link to the application, call functions in the 
application and share data structures with the application. In fact, the 
very purpose of the module is to be a proxy for the application. 
Therefore, the application and the module, as a whole, is a derived work 
of the application. And as a such, it must be under a license compatible 
with the license for the application.

Thus, the module can only be licensed if and only if the license of the 
application is compatible with GPL. Q.E.D. :-)


> Drupal's strength IMHO relies on its community, and defining the risks 
> we're willing to take in terms of technical semantics feels like a 
> step in the wrong direction.  I agree, that the SMF bridge case takes 
> it too far.  Distributing non-gpl code using the drupal infrastructure 
> would be a step backward for us also.  I think we should continue to 
> feel free to distribute code that says it's GPL, no matter what, but 
> not try and second guess lawyers on what is considered a derived work 
> or not.

I think your position is naive. Every time someone is downloading a 
contrib module, Drupal.org is distributing that module. By copyright 
laws, that is absolutely prohibited without permission. The GPL gives 
that permission. Now, suppose the module violates the GPL. A failure to 
comply with the conditions in the GPL will mean that downloading is no 
longer exempted from infringement of  copyright. Ouch! Therefore it 
should be important for Drupal.org to make whatever is reasonable to 
control that the modules they distribute really do comply with GPL.

Lack of such control can be utilized by unscrupulous. For an example, 
suppose a closed source company in the CRM business wants to put and end 
to its worst competitor: Drupal. They engage a decoy who check in a 
module bridging Drupal with their own closed source licensed CRM. Next, 
they sue Dries, in his capacity of owner of the drupal.org domain, for 
copyright infringement... Okay, it is not likely to happen (I hope), but 
it is an illustration why copyright and licensing should not be taken 
easily.


Best regards,
Thomas