Thread: Re: Protection of intellectual property (Schema & SQL
I agree with Jason that you can't really prevent them from getting to the
schema, unless you become an Application Service Provider and host the
application on your own hardware at your business, and they connect over a
network to it. Of course, then you would want to charge them a subscription for
continued use of the service, and be prepared to assume responsibility for
backups, uptime, etc.
One thing you could do just to "tag" it would be to add a prefix or suffix to
all the tables. Say you work for "A Better Company, Inc.", then you might name
all your tables things like
abc_customer and abc_order, etc. The only thing that would help with is if you
find someone else running a copy, it may be easier to prove that it's your
schema. Of course they could change the names, but they would run the risk of
breaking functionality if they don't do it right, plus you can hardcode the
names in your front-end application. If you can compile the front-end such that
you only provide them with a binary executable, it will be that much harder to
change the names. And you may have better luck using other copy-protection
mechanisms with the front end.
I wish you well,
Wes Sheldahl
Jason Earl <jason.earl%simplot.com@interlock.lexmark.com> on 02/21/2002 04:42:58
PM
To: mlq%hotmail.com@interlock.lexmark.com (Michael)
cc: pgsql-general%postgresql.org@interlock.lexmark.com (bcc: Wesley
Sheldahl/Lex/Lexmark)
Subject: Re: [GENERAL] Protection of intellectual property (Schema & SQL code)
mlq@hotmail.com (Michael) writes:
> I want to develop an application using a database server. But I am
> concerned that installing it at client's sites will mean that I am
> potentially exposing my intellectual property to theft. (I'm in Asia
> where this sort of thing is rife).
In other words you want to create a black box. Information goes in,
but it only comes out if you get paid. Such a thing is possible, but
only if the customer doesn't get to poke at the box. If they control
the hardware, then you are sunk.
wsheldah@lexmark.com writes: > I agree with Jason that you can't really prevent them from getting > to the schema, unless you become an Application Service Provider and > host the application on your own hardware at your business, and they > connect over a network to it. Of course, then you would want to > charge them a subscription for continued use of the service, and be > prepared to assume responsibility for backups, uptime, etc. Yes, it is much better to market this sort of thing as a service. A competent Systems Administrator would rather be poked in the eye than be responsible for a system that they can't back up. If you want to keep your customers data out of their hands, then the least you can do is be resposible for the backups. > One thing you could do just to "tag" it would be to add a prefix or > suffix to all the tables. Say you work for "A Better Company, Inc.", > then you might name all your tables things like abc_customer and > abc_order, etc. The only thing that would help with is if you find > someone else running a copy, it may be easier to prove that it's > your schema. Of course they could change the names, but they would > run the risk of breaking functionality if they don't do it right, > plus you can hardcode the names in your front-end application. If > you can compile the front-end such that you only provide them with a > binary executable, it will be that much harder to change the > names. And you may have better luck using other copy-protection > mechanisms with the front end. If you are going to get mean. Why not simply write your application so that it calls home every once in a while. It can then check your database to see if its secret serial number is valid, and if it isn't, or if there is a duplicate it shuts itself down. Good luck signing customers up for that sort of a deal. > I wish you well, I don't. I hate applications that won't share data. I especially hate applications that require some sort of secret handshake to backup properly. As a developer I believe that developers should get paid, but as a former systems administrator I also believe that applications that make it hard for an admin to do his or her job are evil. There has *got* to be a better way to get your customers to pay you. Jason
Another approach is to include as part of your service agreement a very high class Customer Care type of deal at no cost. You present it as In order for ACME to provide you with best level of service, our products does periodical and random self examination and maintain a status link with the mother ship. Our elaborate preventive technologies will inform you of any updates or potential problems. etc etc etc, you get the idea.... But what you are really doing is testing your customer. If your customer says, oh...yeh....what do you mean you randomly check things, and no we don't want any messages to be sent out, then you know you have a problem.... There is also another long term way of fixing this.... Next time you see a friend, a causin or coworker asking you for a copy of some US made software. Tell them I can not let you do that. Because If this goes on, then someday, somebody would do that to my product. Jason Earl wrote: > wsheldah@lexmark.com writes: > > > I agree with Jason that you can't really prevent them from getting > > to the schema, unless you become an Application Service Provider and > > host the application on your own hardware at your business, and they > > connect over a network to it. Of course, then you would want to > > charge them a subscription for continued use of the service, and be > > prepared to assume responsibility for backups, uptime, etc. > > Yes, it is much better to market this sort of thing as a service. A > competent Systems Administrator would rather be poked in the eye than > be responsible for a system that they can't back up. > > If you want to keep your customers data out of their hands, then the > least you can do is be resposible for the backups. > > > One thing you could do just to "tag" it would be to add a prefix or > > suffix to all the tables. Say you work for "A Better Company, Inc.", > > then you might name all your tables things like abc_customer and > > abc_order, etc. The only thing that would help with is if you find > > someone else running a copy, it may be easier to prove that it's > > your schema. Of course they could change the names, but they would > > run the risk of breaking functionality if they don't do it right, > > plus you can hardcode the names in your front-end application. If > > you can compile the front-end such that you only provide them with a > > binary executable, it will be that much harder to change the > > names. And you may have better luck using other copy-protection > > mechanisms with the front end. > > If you are going to get mean. Why not simply write your application > so that it calls home every once in a while. It can then check your > database to see if its secret serial number is valid, and if it isn't, > or if there is a duplicate it shuts itself down. > > Good luck signing customers up for that sort of a deal. > > > I wish you well, > > I don't. I hate applications that won't share data. I especially > hate applications that require some sort of secret handshake to backup > properly. > > As a developer I believe that developers should get paid, but as a > former systems administrator I also believe that applications that > make it hard for an admin to do his or her job are evil. There has > *got* to be a better way to get your customers to pay you. > > Jason > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- ------------------------------------------------------------------------- Medi Montaseri medi@CyberShell.com Unix Distributed Systems Engineer HTTP://www.CyberShell.com CyberShell Engineering -------------------------------------------------------------------------