View Full Version : Running CMS remotely to protect source code
09-26-2004, 01:38 AM
I'm currently in the final phase of developing my own CMS and I've already started selling the product. Within a few weeks time I'm installing the first CMS with one of my clients.
Now I need some advise on how to distribute my CMS, without giving away the complete source. I've searched the internet for encryption tools (Zend, IonCube etc. etc.) and I've also read some of the posts on this forum on this topic. However I'm not sure what option to follow. Off course I'd like to have a free option, as I'm just starting the business.
While getting into the subject I came up with another possibility and I'd like you to comment on it. The idea behind it is that I don't actually install the source code on the users webspace, but keep it on my own server. However keeping the content of the websites on their own webspace. I was thinking to put just one file on the clients server that temporarily imports the code from my website and executes it.
Advantages of this system would be that I can check for licensed use (ip-check) and I can easily update the entire system for everyone at once.
Now my question is whether this is possible at all? I forsee a problem with writing content on the clients server (fwrite() doesn't work on another server, does it?). And how would that work when multiple files are executed (base class, library class, module class etc.). Furthermore I can imagine that this leads to quite some workload for my server. Does this slow the websites down or will mine crash?
Remeber that this is just a concept I'm considering, but I'd appreciate your input on it .... So what'd you think ... ?
what you describe is sounds like a webservice.
I'm not entirely sure what your soft looks like. I mean, a real CMS will not put heavy load on a server because it'll only take up resources from your server when changes are made (new content, edited content, new layout, whatever). But regular use of the sites shouldn't cause load on your server.
if you wanna do it through a webservice then i think you have two options:
- require an ftp-account for the webdirectory on the clients server;
- write an XML-server and XML-client. You then only install the client on the other server (using SOAP, this should be a relatively small effort)
but i fear you're thinking about this a bit to late + i got the impression that your code generates large parts of the pages at runtime (composes the layout or template at runtime, or loading it from the db and executing it etc?).
What wrong with encryption (aside from the regular disadvantages of distributed software)?
09-27-2004, 01:15 PM
thank you for your reply. You a right about the fact that I started too late thinking about how to protect the source of my app. I started to think about it because one of my clients says that he 'knows a bit of php' and I actualy don't want him to snoop around my code, for obvious reasons.
So what I need is some sort of protection to achieve 2 things:
- make it impossible, hard or just difficult to figure out how the actual software works
- include some sort of IP-protection to prevent copying to another server, which cannot be deleted easily.
Reading about this topic, gave me the idea that the only way off *really* protecting the source was simply not to put the source on the clients server. I'm not sure whether this is a correct observation, but at least I'm exploring the possibility.
Off course I could encrypt or obfuscate the source. I already tried scrambling the code (http://pobs.mywalhalla.net/), but this didn't seem to work properly, because the user's input for example defines which function has to be executed, which files have to be included etc.. And this doesn't work anymore after scrambling the code. This can be overcome, but it requires a lot of time, to figure it out.
Furthermore, I'm not yet in the position to purchase a commercial product like Zend or Ioncube, and I'm a bit conservative as well, becuase of my experience with free products that don't really work.
Those are the actual reasons of my interest in other methods (like hosting the CMS on my own webspace). The problem I mentioned earlier, with the server load, is valid a guess, since building the actual website/ menu's/ layout requires a part of the CMS as well.
I'm willing to explore different options and I'm open for suggestions on how to protect the source or for now create the illusion of protected source, to discourage people to look any further.
Thanx again for your help,
09-27-2004, 01:27 PM
It depends on what kind of product you sell, and where it should be used. You have to decide if you sell a product a la shrinkwrap software, which the customer needs to install, or if you see yourself as an ASP (application service provider) and sell the usage of the service. As an ASP, you have the advantage of doing bugfixes and updates on one central server. But you can't sell that kind of product for every client, because some might prefer a solution that integrates with their own web server architecture.
A problem might arise with the IP-check idea. I'm not a network admin, but I think that this approach does not work with virtual hosts, i.e. a setting where multiple domains share a single IP number. Other hosted sites on such a server could use your central CMS as well.
I wouldn't follow the route with dynamically loading code over the network. Seems to fragile and too complex to develop. frwite() doesn't work on other servers, as you assumed. Plus, it doesn't protect your source code if your customer should decide to tinker with your CMS client code and write the loaded code to a file.
Encryption can work, but you must be sure that the host where you install your CMS provides the necessary encoder plugin. If you chose a commercial encoder, its cost will also raise the total price of your CMS product. Keep that in mind.
A nice alternative would be that you sell domain + hosting + CMS in one package. You order the domain, and install the CMS for your customer. This has the great advantage that you control the environment in which your CMS will be used. However, if you provide your customer with FTP access to his domain (which will ask for in most instances), he could still get at the source code.
I would not worry too much though. Be sure to include in the contract that you grant the customer only usage rights with the source code and prohibit any selling or redistribution of the code. You could allow the user that he modifies/checks the code as he wants (this can be a good selling argument), but inform him that in this case you can't provide any support for bugs etc. Keep a copy of the final CMS installation with you and run a diff tool on it once a support call comes.
09-27-2004, 01:36 PM
Posts crossed, a quick follow up on your latest post:
There is a good business argument against a central "activation" server. What if your business does not exist anymore in one year? Your customer bought something that he expects a work regardless whether your company/your services are available or not. It can get tricky to convince a suspicious customer to trust your business that much.
It comes all down that PHP scripts are not compiled, without the help of an encoder. If you would want to supply compiled code, then you're probably better off using a different language like Java.
Anyway, I would just sell it and distribute the code. vBulletin is commercial, and you get the complete source code. Seems to work for them. Let us know what final decision you make regarding this issue. :)