[Discuss] GPL and code linkages

[mbr at arlsoft.com (MBR)]

A question came up on another mailing list dealing with Drupal and PHP 
that raised questions in my mind about the GPL.  discuss at blu.org seemed 
more likely to have members knowledgeable about GPL issues, so I'm 
asking my questions here.

I thought I understood the GPL until I read a posting asking about 
whether the source code to a Drupal module could be proprietary.  For 
those who don't know, Drupal is a GPL'd content management system 
written in PHP, a language whose interpreter is GPL'd.  While going 
through the mental exercise of whether a proprietary Drupal module could 
be written and how it could be done, it became clear that the legal 
ramifications of interfacing with GPL'd code are more complex than I'd 
previously realized.

In traditional compiled code, linking object files together to form a 
single executable made them part of the same work, and if any object 
file was compiled from GPL'd source, then the source for all objects had 
to be under GPL-compatible licenses.  On the other hand, two separate 
executables can be distributed in a collection of code (e.g. on the same 
CD), and either one being GPL'd doesn't require the other one to be 
GPL'd.  To the best of my understanding, even if one of the executables 
provides a service callable via an RPC interface and the other 
executable calls it, either one being GPL'd doesn't require the other 
one to be GPL'd.  On the other hand, LISP's been around for a long time, 
and it doesn't involve linking objects to create an executable.  I've 
always assumed that multiple LISP source files running as the same 
instantiation of a program would have the same GPL requirements as 
objects linked together into an executable.  This is the closest analog 
I can think of to the question of whether a Drupal module can be made 
proprietary.

But in the modern world, there are a number of other ways to allow a 
function to be called besides simply linking the object file containing 
the call with the object containing the function definition or writing 
PHP functions in a Drupal module that get called by PHP functions in the 
GPL'd Drupal core.  The ways I can think of off the top of my head are:

  * Write your function in C or C++ as an extension to the PHP interpreter
  * RPC on the local machine: call PHP's proc_open() to pipe data to and
    from a separate executable
  * RPC to a remote machine:
      o use PHP's socket functions to send data to and from a server
        anywhere on the Internet
      o pass arguments and receive results via an HTTP GET or POST. 
        (This also involves socket calls, but not directly from the PHP
        code.)
      o pass arguments and receive results via something like SOAP. 
        (This also involves HTTP protocol.)

Each of these approaches would have different legal ramifications WRT 
the GPL and would need to be analyzed separately.  Writing a PHP 
extension probably requires licensing the extension under a 
GPL-compatible license because the PHP interpreter itself is GPL'd.  But 
what if it weren't?  What if the question had to do with some other 
language implemented as a proprietary interpreter -- call it PLP for 
Proprietary Language Processor.  Imagine someone writes an application 
in PLP, licenses that application under the GPL, and that application 
calls an extension to the PLP interpreter.  Does the fact that the 
application is GPL-licensed mean that the extension is required to be 
under a GPL-compatible license even though the interpreter the extension 
is linked into is proprietary?

Or in the RPC cases listed above, if the calling code is GPL'd, must the 
called code be licensed under a GPL compatible license?  And what about 
in the other direction?  If the called code is GPL'd, must the calling 
code be licensed under a GPL compatible license?  I think the answer to 
both of these is "No", but either answer creates some strange situations.

And how do the answers to these questions change if we're talking about 
GPL3 rather than GPL2?

    Mark Rosenthal