<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/30/12 3:19 AM, MBR wrote:<br>
</div>
<blockquote cite="mid:50DFF920.2080401@arlsoft.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<font face="Times New Roman, Times, serif">I thought I understood
the GPL. But this issue started me thinking about 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.<br>
<br>
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, </font><font face="Times New Roman, Times, serif">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.<br>
<br>
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 </font><font face="Times New Roman,
Times, serif">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:</font><font face="Times New
Roman, Times, serif"><br>
</font>
<ul>
<li><font face="Times New Roman, Times, serif">Write your
function in C or C++ as an extension to the PHP interpreter</font></li>
<li><font face="Times New Roman, Times, serif">RPC on the local
machine: call PHP's proc_open() to pipe data to and from a
separate executable</font></li>
<li><font face="Times New Roman, Times, serif">RPC to a remote
machine:</font></li>
<ul>
<li><font face="Times New Roman, Times, serif">use PHP's
socket functions to send data to and from a server
anywhere on the Internet</font></li>
<li><font face="Times New Roman, Times, serif">pass arguments
and receive results via an HTTP GET or POST. (This also
involves socket calls, but not directly from the PHP
code.)</font></li>
<li><font face="Times New Roman, Times, serif">pass arguments
and receive results via something like SOAP.</font><font
face="Times New Roman, Times, serif"> (This also involves
HTTP protocol and socket calls.)</font></li>
</ul>
</ul>
<font face="Times New Roman, Times, serif"> </font><font
face="Times New Roman, Times, serif"> </font><font face="Times
New Roman, Times, serif">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 like Drupal 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?<br>
<br>
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? I</font><font face="Times
New Roman, Times, serif">f 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.<br>
<br>
And how do the answers to these questions change if we're
talking about GPL3 rather than GPL2?<br>
</font>
<blockquote><font face="Times New Roman, Times, serif">Mark
Rosenthal</font><br>
</blockquote>
<br>
</blockquote>
The GPL license, and the documentation/FAQs around it, seem to admit
that there can be grey areas in what constitutes a "program", and
lists two extremes that are clear, two processes connected with a
pipe or via exec is not "one program", while an executable module
with custom code linked to a GPL'ed library is "one program". Drupal
and PHP method of combining scripts together seems fairly clear to
fall under the "one program" domain, but I can imagine someone
trying to argue against it (and as the FAQ says, this might end up
needing to be decided in a court of law). It is possible that a
Drupal site might connect to some code in other ways and not fall
under this rule, for example, I have a Drupal module that imbeds a
dynamic image on a page. The file called that display the image uses
no Drupal code, so even though the file is "inside" (file system
wise) a Drupal module, I could technically make that code non-GPLed
if/when I distribute that code. Similarly, I believe that an RPC
call is of the same type of connection that the license allows
without having the GPL attach, so that would seem to work. <br>
<br>
My initial comments weren't so much focused on the legal aspects of
distributing an obfuscated module, but the technical problems with
it. Because of the way Drupal treats functions with names like
module_foo(), any obfuscation will need to be "Drupal aware", and
obfuscate the terms module and foo separately, and convert ALL uses
of module (including file names and most usages of 'module') the
same and all uses of foo the same (and if foo is actually foo_bar,
the same with each part).<br>
<br>
Now, if you do this, you need to decide if you are going to
obfuscate the full install (which will break when an update to core
or any modules/theme occurs, requiring a new obfuscated distribution
to be made), of just the a few modules, in which case the obfuscator
needs to figure which "foo"s can't be changed (which will be a lot),
and likely you end up with a fairly weak obfuscation. <br>
<br>
<pre class="moz-signature" cols="72">--
Richard Damon</pre>
</body>
</html>