A question came up on another mailing list dealing with Drupal and PHP
that raised questions in my mind about the GPL. discuss@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
_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
