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 RosenthalThe 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