[support] phc obfuscate / drupal 7

[Richard Damon]

On 12/30/12 3:19 AM, MBR wrote:
> 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.
>
> 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 and socket calls.)
>
> 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?
>
> 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
>
>
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.

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).

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.

-- 
Richard Damon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20121230/61fe61fd/attachment.html