Perhaps a bit of an odd question but I can’t think of a way to achieve what I want.
I produce a product which ends up installed on-site at clients premises. It is a business critical and high availability application, and has to handle processes very quickly.
While obviously most of the work goes into the actual application (Windows Services) part of the reason why the product is so good is intelligent database design.
Until recently I usually provided the servers and I was the only person to have access to the database and SQL Server instance. However more recently customers have asked to run the application on their production server, usually VMWare, and use their SQL Farm for the database.
This is fine for the application, however I am worried about who will have access to the SQL server and if they would be able to have a poke around in my application’s database.
Is there anything I can do to prevent access to it? Or is it a case of if they’re hosting it there is nothing I can do?
Thanks
EDIT:
If I am hit by a bus, company folds etc. there is an escrow agreement which will give them the source code of everything they need.
As to why I am worried I have seen examples in the past of people making changes to data tables and reports, and no they did not have the nous to do so. This meant that someone had to go in and fix everything, while of course we charge for this I was wondering if there was a way to avoid it all together, or at least minimise the risk.
7
It is perfectly reasonable for a corporate customer to prefer to host your application internally. It allows them to set the standard for accessing the data directly, for backups, to survive your eventual death, etc.. A business should be concerned if one individual over whom they have no oversight and for whom they have no replacement controls something that is critical to their business. What if you get hit by a bus?
To mitigate this, contracts were invented. You can sign a new contract with them, that (for example)
- Grants them a copy of the source code.
- Grants them permission to run an instance of the application for their business.
- Grants them permission to modify the application for their business.
- Denies them permission to release the source code, and specifies penalties.
- Denies them permission to derive new applications from the source code, and specifies penalties.
- Absolves you of any responsibility for correcting their changes to the source code.
- Absolves you of any responsibility for integrating changes to your version of the source code and their version of the source code; you are required only to provide them with the source code that produces the application you host for other clients.
You should see a lawyer about what should be included in any contract, I am not a lawyer.
The major software players, Oracle, SAP, ACI, Sunguard etc. etc. all have best selling products which come with a relational data base. None of them make any effort to hide or obfuscate the database schema.
In addition many customers for mission critical apps will demand a copy of your source code, as insurance that they can keep the system running should you go bust or get taken over by Computer Associates.
So why risk alienating your (ex-)customers who are after all not interested in writing their own software or they would not be interested in buying yours.
It should be noted that the databases supplied by the above mentioned customers are very hard to decipher — but this is because the level of abstraction required to make the product flexible leads to a lot of indirection in their database designs (i.e. rather than a cust_name column in a customer table they have a cust_name_location column which refers to column ref256 in ip_ref_table)
If they’re hosting it on a hardware to which they have root access, in their copy of a database program, you cannot prevent them from gaining access to your database’s design. At best, you could add a layer of obfuscation to your code, such as writing a program to re-name all of your internal tables and fields and variables and attempting to scrub the “SQL Text” contents of some system tables.
Should you not trust your customers that much, you can require that the software only run on hardware that you manage, and then YOU could manage their internal SQL server farm. Which may result in them kicking you to the curb regardless.
(The best answer is “don’t worry”, and have an install program that checks for modifications to protect you from supporting someone else’s alternations, and a license agreement that protects your rights if they try and take your work and sell it as their own.)