On 25-Dec-12 16:26, Austin Einter wrote:

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

Source code of what? Drupal or some modules? Drupal is GPL-ed, so anybody can have it. Or your own drupal-module? I'm not sure but I think if you develop something for Drupal, you have to distribute it under the same license at no charge. So which php-code you want to obfuscate and why? Jarry --- _______________________________________________________________ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.

Thanks a lot all. I know Drupal is open source, I wanted to protect only the custom modules developed. I learnt from this discussion that - 1. Take a dedicated m/c, so root access is with me. That gives some protection. 2. Will go for a trusted / reputed web hosting company. On a side note, I read somewhere a separate branch is maintained for Drupal code base (probably 7.4) that is compatible with hihop use., Can somebody give more information in this regard such as is it maintained and available for latest Drupal 7 releases.. Thanks and Regards Austin On Tue, Dec 25, 2012 at 10:12 PM, Richard Damon <Richard@damon-family.org>wrote:

On 12/25/12 10:49 AM, Jarry wrote:

...

On 25-Dec-12 16:26, Austin Einter wrote:

...

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.., Source code of what? Drupal or some modules? Drupal is GPL-ed, so anybody can have it. Or your own drupal-module? I'm not sure but I think if you develop something for Drupal, you have to distribute it under the same license at no charge. So which php-code you want to obfuscate and why?

Jarry ---

The GPL means that *IF* you distribute the results, you need to provide the source, but there is no requirement to publish source if you do not distribute your "product" (i.e. for your own use). This is good, as it means you are not required to publish your settings.php file with your database passwords!

This does mean that if you produce as a product a Drupal module, (I believe) you can not just distribute it as a protected file, you need to provide the source for it, but this is only if you distribute it.

-- Richard Damon

-- [ Drupal support list | http://lists.drupal.org/ ]

Hi Lary Thanks for input. I am not going to distribute code to any customer. It is developed by us (taking Drupal as base) and we will be hosting it. We will never give it to any customer in future also. The only worry is, in hosting company, if any of their ADMIN guys takes code and give to other competitors without our knowledge. Ofcourse I will have root access and its going to be a dedicated solution. But I feel thats not the solution. One can just take hard disk, put to another machine, copy data and then again put back to original machine. Otherwise absolutely no worry Probably Drupal community need to think in line of hiphop or develop something similar. Thanks a lot. Austin On Wed, Dec 26, 2012 at 11:18 AM, Larry Garfield <larry@garfieldtech.com>wrote:

The last I heard, HipHop doesn't work with Drupal because Drupal uses parts of PHP that HipHop doesn't support. Really, HH is not a general solution for PHP performance tuning. You have to write code with HH in mind for it to be effective, which Facebook did when creating HH.

As far as "protecting" source code, the GPL license basically says you can't do that; or rather, it's worthless to do so because anyone you distribute the code to is legally entitled to the un-obfuscated source code as well. That includes any custom modules you write. Note that only triggers if you distribute the code to someone else; putting code on a web server does not count as distribution (AFAIK), so the host is not legally entitled to do anything with your code other than host it.

That said, if your business model for your site relies on some non-trivial set of modules remaining forever-secret, then your business model is already buggered and you need to find a new one. Really, the investment in working with the community rather than building a lot of custom code that you have to maintain is worth far more than your custom code. That will be especially true then next time you decide to do a major version upgrade, where you'll find yourself with a lot of custom code that only you can possibly upgrade and no one willing to help you in the slightest. That is a bad bad place to be.

--Larry Garfield

On 12/25/2012 05:38 PM, Austin Einter wrote:

Thanks a lot all.

I know Drupal is open source, I wanted to protect only the custom modules developed. I learnt from this discussion that -

1. Take a dedicated m/c, so root access is with me. That gives some protection. 2. Will go for a trusted / reputed web hosting company.

On a side note, I read somewhere a separate branch is maintained for Drupal code base (probably 7.4) that is compatible with hihop use., Can somebody give more information in this regard such as is it maintained and available for latest Drupal 7 releases..

Thanks and Regards Austin

On Tue, Dec 25, 2012 at 10:12 PM, Richard Damon <Richard@damon-family.org>wrote:

...

On 12/25/12 10:49 AM, Jarry wrote:

...

On 25-Dec-12 16:26, Austin Einter wrote:

...

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.., Source code of what? Drupal or some modules? Drupal is GPL-ed, so anybody can have it. Or your own drupal-module? I'm not sure but I think if you develop something for Drupal, you have to distribute it under the same license at no charge. So which php-code you want to obfuscate and why?

Jarry ---

The GPL means that *IF* you distribute the results, you need to provide the source, but there is no requirement to publish source if you do not distribute your "product" (i.e. for your own use). This is good, as it means you are not required to publish your settings.php file with your database passwords!

This does mean that if you produce as a product a Drupal module, (I believe) you can not just distribute it as a protected file, you need to provide the source for it, but this is only if you distribute it.

-- Richard Damon

-- [ Drupal support list | http://lists.drupal.org/ ]

-- [ Drupal support list | http://lists.drupal.org/ ]

What stops people from stealing or killing? Easy - nothing, except the law (and morals). I use to work in the hosting business. What you are basically describing amounts to "stealing trade secrets" and is prosecutable under the Economic Espionage Act. As mater of fact it's one of those acts that gives the U.S. Attorney General some huge, sweeping power. Fines can be up to $500,000 for an individual and $5,000,000 for a corporation. Having said that, when people are hired on at a reputable hosting provider, they are made very aware of it and even sign agreements. So the penalties are in some cases worst than murder. That's a pretty good protection. Mainly just stick with a reputable host. But you are using Drupal, which is open source, meaning the source code (minus any custom modules) is available. There are always ways to reverse engineer code, so even obfuscating the code isn't a real protection. Another consideration. Drupal does come out with security releases. Compiling the source code takes extra time and means it will take longer to update your site. I would rather be able to update my code quickly to protect my customers then worry about someone taking the source code. As far as HipHop, some people have had success and some not. It depends on the modules and custom code you use. For research on this, I suggest Google. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 12/25/2012 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

On Tue, Dec 25, 2012 at 6:53 PM, Jamie Holly <hovercrafter@earthlink.net <mailto:hovercrafter@earthlink.net>> wrote:

Those aren't errors. They are notices.

Since the errors only occur when using PHC, then the problem lies in PHC. I would ask on their mailing list.

I doubt you would find much help from the Drupal Community since obfuscating is generally frowned upon (and even consider a violation of terms by some) by the open source world and therefor not really used.

Jamie Holly http://www.intoxination.net http://www.hollyit.net

On 12/25/2012 5:26 AM, Austin Einter wrote:

...

Dear All I compiled phc in ubuntu 10.04 lts. Next I am trying to obfusace some php code (which is part of a drupal based code). I just tried obfuscating a single file using phc. It did work.

But when I am trying to access my site, I get bunch of below errors.

/Notice: Undefined variable: TSa200978216 in doc_search_my_form() (line 475 of /var/www/example.com/sites/all/modules/doc_search/doc_search.module <http://example.com/sites/all/modules/doc_search/doc_search.module>). Notice: Undefined variable: TSa1454652404 in doc_search_my_form() (line 482 of /var/www/example.com/sites/all/modules/doc_search/doc_search.module <http://example.com/sites/all/modules/doc_search/doc_search.module>). /

Mostly these are variable undefined errors. When the file is in normal mode (having normal php code), it does not throw any error. When the file is in obfuscated mode , when I access my site I get lots of variable undefined error. Any idea what's wrong here.

Thanks

-- [ Drupal support list | http://lists.drupal.org/ ]

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.

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