[support] phc obfuscate / drupal 7

[MBR]

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

On 12/25/2012 11:33 AM, Richard Damon wrote:
> On 12/25/12 10:26 AM, Austin Einter wrote:
>> Thanks all for your kind responses.
>>
>> I am new to web world.
>>
>> I am worried for few things.  Lets say I will be taking a dedicated
>> server say from rackspace or doster or godady and host my site as a
>> commercial one.
>>
>> I would not doubt the companies like rackspace or godady ..., but
>> difficult to believe admin engineers who may take the source code and
>> give it to somebody else for few dollars..,
>>
>> How do we protect such things.., please guide me..., thats the reason
>> I would like to obfuscate the code or build the exe by using hiphop or
>> phc.
>>
>> Again.., not sure if it is feasible to build drupal using hiphop or
>> phc.., has anybody tried and running as commercial site...
>>
>> Thanks
>> Austin
>>
>>
> If you are using a root server (where you have root access and admin the
> server yourself), you just need to change the root password and you are
> about as safe as possible.
>
> If you are using a managed or shared server (where the hosting company
> manages root), you just need to use a reputable company and trust them.
> They could do much worse to you than steal a bit of source code, they
> can get access to your whole customer database if they really wanted to
> (which is why it is important to use a reputable company).
>
> As to the feasibility, I suspect the only method that has a hope of
> working would be a PHP compiler that turns your files into byte-code
> that is run through the PHP interpreter. PHP generally works by first
> reading your file and then "just in time" compiles the file to
> byte-code, then starts interpreting the byte code (until it hits and
> include, which reads the file and compiles that one). There are programs
> that will do the first step, of compiling all your code first, leaving
> byte code that would be a bit harder to analyze than raw source code.
> Not sure if it is worth it, unless you have something REALLY unique that
> would prompt some major corporate espionage, since as I said, there are
> bigger things on your site than the source code.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20121230/e48e26b9/attachment-0001.html