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

[Thomas Barregren]

Jakob Petsovits skrev:
> On Thursday, 30. August 2007, Jeff Eaton wrote:
>   
>> For quite some time, it has been commonly understood in the Drupal
>> community that non-GPL software (like a third-party PHP message board
>> system) can be integrated into Drupal legally by using an
>> intermediary 'bridge' module. After some in-depth emails with the
>> Free Software foundation's license gurus, it's become clear that this
>> is NOT the case.
>>
>> Before going any further, I want to make clear that I'm not
>> expressing approval or disapproval of this: I'm just relaying the
>> conclusions that were reached after several days of discussion and
>> questioning with the FSF.
>>
>> Why do these modules violate the GPL?
>>
>> 1) Under the FSF's accepted interpretation of the GPL, if a module is
>> integrating Drupal and another PHP script, by calling one's APIs when
>> triggered by the other for example, its purpose is to make a single
>> unit of software out of those parts.
>>     
>
> My understanding was that non-GPL software may not be a derivative work of
> GPL code

Let us be careful with the wording here.

As soon as you make a derivative of a GPL:ed code, it automatically 
becomes non-GPL:ed. That is because you and only you have the right to 
derivative work by copyright laws.

GPL don't prohibit you from using the derivative. On the contrary, GPL 
was written to ensure you this right. It is one of the four fundamental 
freedoms that GPL strives to give you.

But you are not allowed to *distribute* your derivative work without GPL it.

Thus, any company or individual are free to download and integrate 
Drupal with their very secret and proprietary software. As long as they 
don't distribute it, they are not violating GPL.

BTW, many people seems to believe that just because a derivative work is 
made from a GPL:ed software, they can demand a copy of the derivative 
work. If the derivative work never has been distributed, they are wrong. 
If the derivative work has been distributed including the source code, 
they are wrong. But, if the derivative work has been distributed with 
only an offer to obtain the source code, e.g. by downloading it, they 
are right. See § 3 (and § 3b in particular) in GPL v2.

> , but that it can go the other way round. As David Strauss mentioned, 
> it is indeed possible to write GPL software by using the Win32 or Cocoa API.
>   

You can that because of an exception in § 3 of GPL v2.

> Following this reasoning, it would mean the following for Drupal modules:
> - Drupal modules are based on Drupal, so they are GPL in any case.
> - Thus, modules may not incorporate code that make the integrated software
>   derive (call functions) from Drupal or the module itself.
>   

You are right so far.

> - Whereas it should be possible to call functions from the integrated software
>   from the module.
>   

It depends on how the module calls the function in the integrated 
software. Read the FAQ:

  * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLAndPlugins

> For example, that would mean no authentication in the integrated software that 
> is based on Drupal users and passwords. Or displaying any information that 
> comes from Drupal.
>   

Again, this only applies to derivate works which is distributed.

> But it should be possible to manage and display stuff from the integrated 
> software from Drupal. Like is done with Apache, for example (which uses the 
> GPLv2 incompatible Apache license). I'm sure there are lots of other good 
> examples.
>
> Would this make sense?
>   

What do you mean? Drupal is not integrated with Apache HTTP Server (as 
far as I understand). It only runs on it.

>> 2) If multiple programs are operating together and functioning as one
>> unit, all the pieces must be GPL'd.
>>
>> There are a lot of angles to approach the question from, but that's
>> what it boils down to. From a developer's perspective, if
>> debug_backtrace() can ever include functions from both Drupal and an
>> external program, you've turned them into a single program.
>>     
>
> David's argument that the GPL only covers distribution, not usage, is a good 
> counter argument to this point of view. Of course, this is somewhat of a 
> difficult issue, quite comparable to the kernel module blobs for the ATI and 
> nVidia graphics card drivers which are widely considered a legal gray area.
>   

Wrong. Jeff Eaton is right. If two programs are so tight integrated that 
"...debug_backtrace() can ever include functions from both...", both 
must be GPL:ed.

The only exception is "...anything that is normally distributed (in 
either source or binary form) with the major components (compiler, 
kernel, and so on) of the operating system..." according to § 3 in GPL v2.

> Also, you could extend the issue not only to PHP code but also to XML-RPC 
> calls, where you do not even know if the software that you communicate with 
> is GPL or not.
>   

I think you are wrong.

PHP: The PHP license is not compatible with GNU v2. If you want to add a 
GPL:ed extension to PHP, that is a problem (which easily can be remedied 
with a FLOSS Exception). But it is not a problem from Drupal. Why? The 
GPL permits this because PHP falls under the exception in § 3 of GPL v2.

XML-RPC: IMHO, a program accessing Drupal through XML-RPC need not to 
generally be under GPL. Why? In normal use of XML-RPC the client is 
separate from Drupal, and hence not subject for reciprocity of GPL. 
Compare this with one program calling another program though fork and 
exec. Read more in the FAQ:

  * http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLAndPlugins


Best regards,
Thomas