views:

90

answers:

3

Hi, My company is building a platform on top of a heavily extended Drupal core. I have multiple customers who will be using separate instances of this system and will want to customize both the theme and the functionality.

I'm trying to design a system to allow them to add themes and modules, some of which might interact with some of my modules, without giving them access to the actual code. (This isn't open source)

The way that Facebook and Ning do this is to have the developer host their own custom code, and have a callback to it. This won't really work for me, as these sites need the ability to be fully customized, so callbacks for specific integration points don't really work.

One option is to set up a sandbox environment where the custom developers only have access to a couple specific directories to build their themes and custom modules. We could then integrate with git to commit these when they're ready and deploy them with the rest of our code into production. The problem with this setup is that developers have to develop remotely and have to use our source control system.

A more typical setup is to allow the developers to download something to build their custom code against. They can develop locally and use whatever source control practices they already have. As we don't want specific point integrations, I don't think this can be a library that runs against a separate server. The alternative is to download our full core Drupal system and develop locally against that, uploading the custom code when it's ready, but then they would have access to all our code and IP.

Thus the predicament, as I don't think there is any way to effectively obfuscate PHP.

Anyone have any brilliant ideas here?

+1  A: 

I hope you're aware that Drupal is GPL licensed, be sure to read their licensing FAQ before you start obfuscating.

fvu
Thanks, I am aware of that. I'm not distributing the code for reuse. I'm building sites for clients and I'd like them to be able to customize it without them seeing the code. This is fine under the GPL, see questions 8 and 11. For example, Facebook internally uses many GPL-licensed pieces of software and lets developers write applications against their code. That's all I'm trying to do. Just trying to figure out the best way to accomplish that.
Nader
+2  A: 

It sounds like your system is a derivative work of Drupal and thus covered by the GPL. If you distribute the code to your clients they have all of the rights provided by the GPL, Including modifying and redistributing it.

Be aware that distributing obfuscated GPLed code is not allowed. To quote the GPLv2 "The source code for a work means the preferred form of the work for making modifications to it."

Obfuscated code does not comply with this clause of the GPL.

That said, if you really want to provide your clients a way to customize your system you could provide your clients access to the existing Drupal module and theme system but only on your sandbox.

Of course since the modules and themes are PHP and you "don't want specific point integrations" it seems they would have the sort of freedom that would allow them to write a module that reads all of the source code for the rest of your system and then tar it up and send it to themselves.

I think you've painted yourself into a corner by depending on GPL. Keeping your IP private while allowing your clients to extend/customize the system in general ways doesn't really work.

Craig
Craig, you're right. There is no good way to do what I was initially trying to do. We've shifted strategy, to just allow customization through the app, as opposed to via the Drupal API.
Nader
+1  A: 

Why not just create an FTP user for them which can only access /sites/theirsite? What am I missing?

Mike Crittenden