<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 12/30/2012 4:52 PM, Richard Damon wrote:
<blockquote cite="mid:50E0B7A4.7010002@Damon-Family.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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>
</blockquote>
<font face="Times New Roman, Times, serif">Thanks Richard. As I
tried to explain in my initial post, my posting this was not
because I plan to do any such thing or because I support the
original poster's intent. It's about going through the mental
exercise and coming to realize that it's not as straightforward as
I initially thought.<br>
</font>
<blockquote><font face="Times New Roman, Times, serif">Mark</font><br>
</blockquote>
<font face="Times New Roman, Times, serif"><br>
</font>
</body>
</html>