[support] phc obfuscate / drupal 7

[MBR]

On 12/30/2012 4:52 PM, Richard Damon wrote:
> 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
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.

    Mark


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