[development] Modules that integrate non-GPL PHP apps violate the GPL.
thomas at webbredaktoren.se
Sun Sep 9 23:35:50 UTC 2007
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
More information about the development