<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Times New Roman, Times, serif">I thought I understood
      the GPL.&nbsp; But this issue started me thinking about whether a
      proprietary Drupal module could be written and how it could be
      done.&nbsp; 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>
    On 12/25/2012 11:33 AM, Richard Damon wrote:
    <blockquote cite="mid:50D9D55C.4060408@Damon-Family.org" type="cite">
      <pre wrap="">On 12/25/12 10:26 AM, Austin Einter wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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


</pre>
      </blockquote>
      <pre wrap="">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.

</pre>
    </blockquote>
  </body>
</html>