| 5:54 am on Oct 13, 2009 (gmt 0)|
The problem with encryption is customers may not be happy running code on their servers when they can't see what it is doing. This is especialy true if them have bought the software from you.
There are some things you can do to limit the software being used by sites that hve not purchased the script. For example if you have an install page where the user can configure and set up the cms add a 1x1 pixel from your own server. This will give you clues as to where is is being installed. This can be removed quite simply by an experienced user who is aware of it being there, but it may help you track down some installs.
Piracy is a big problem, and you may well need to take legal action if you find someone else selling your software.
| 6:23 am on Oct 13, 2009 (gmt 0)|
from your message i understand that encryption is not general practice for proprietary software and it might adversely affect business in other way.
Creating a tracker should be nice thing to actually figure out where and how much your cms is going in right hands....
but i hope there must be we can do to encrypt our site at partial level may be one page...if that helps
| 7:32 am on Oct 13, 2009 (gmt 0)|
You could encrypt one file say for example key.php and you email this file to the customer as part of the purchase. Explain that this file unlocks the software. you could use this file to include other importaint files. For example making navigation invisible in the admin area if the "key" isn't installed. You could then track installs using the key file.
Again this may cause issues with customers not knowing what the file does. I think you may need to be clear with them and explain it logs where the softare has been installed.
Another possible issue with encryption is do all hosts support the decryption and parsing of encrypted code? I know most of the encryption companies offer the decryption software (for the server) freely, but it might not be installed on many hosts.
| 8:24 am on Oct 13, 2009 (gmt 0)|
i am thinking to encrypt config.php and when i include this in all other files instead of using plain include statement need to do some precessing afterwords
| 8:36 am on Oct 13, 2009 (gmt 0)|
How would the user edit the config :)
| 8:44 am on Oct 13, 2009 (gmt 0)|
perhaps a website admin interface can take care of decrypting it and writing the file
| 4:19 pm on Oct 13, 2009 (gmt 0)|
Even if you encrypt parts of the code, you still need to give the client the decryption routines, and a knowledgeable programmer can circumvent that easily enough, unless i'm missing something?
One thing i've been thinking of, not sure how feasible it is: break the software into two parts, one part has the code to create the webpages off the database and also maintain user contribution such as comments, the other part has the modules to maintain the website's actual structure and content. The first part goes to the client server and the second part stays on your server. So now, when the client wants to make a change to their website, they have to login to your server, and of course they can only do that if they've paid.
This way, at least part of your software is never delivered to clients and can't be copied. The drawback is that you need to write some extra rock-solid, secure code to push the changes from your server to theirs, and your server needs to be rock-solid too so clients can access it all the time.