Re: Deployment of PostgreSQL Applications - Mailing list pgsql-general
From | Jeff Davis |
---|---|
Subject | Re: Deployment of PostgreSQL Applications |
Date | |
Msg-id | 0GIY00497SQFDM@mta7.pltn13.pbi.net Whole thread Raw |
In response to | Deployment of PostgreSQL Applications ("Mike Arace" <mikearace@hotmail.com>) |
List | pgsql-general |
On Friday 31 August 2001 05:59 am, you wrote: > Hi everyone, > > I'm working on a (sorry) closed source application which consists of Java > servlets, beans, and client applications talking to a postgresql database. > Now, lets say I'm interested in bundling this all together and selling it > to customers. > > 2 questions: > > 1) Is it legal to bundle Postgresql with another commercial application, > assuming the database will have to be significantly reconfigured and tuned? > (at the application level, not the source code level) I read over the > licenses I could find on the site and they seemed to imply that the answer > was yes, but I'd like to reaffirm that. I think so. The copyright notice might need to be somewhere... but BSD lisence is pretty forgiving. > > 2) More importantly, is it possible to prevent a customer from peeking into > said database once it is deployed on their machine? A large part of what > makes my application proprietary is the data model in the database, and > it'd be tough to maintain a competative edge when everyone can see exactly > how I do things in the database by logging into their postgres account, > adding some users and changing permissions on their machine. I really need > to make sure the database is bulletproof before I can begin deployment. > It is not difficult to find myriad essays and casual opinions attacking such a business model, but that wasn't your question (hey, if you have something new it could certainly be justified to keep it secret a while). It's just a matter of time anyway (open source now or later?). Every piece of software *could* be reverse engineered; it sounds to me like you want to hold it off long enough to make a buck or two (return on investment, hopefully). Some simple stuff can go a long way towards this goal. Maybe add a very small layer to all disk reads in postgres that uses a weak (but fast) encryption method before it gets processed (maybe XOR everything with alternating values?). For a quick method try making a wrapper for the system read/write calls and do a search/replace on the source. That way, the data on disk is unreadable. The encryption would be breakable by any experienced programmer, but I think you already know that can happen anyway. It all depends on how much time you want to spend. One comment brought up the point that you may want to include automatic maintainence (vacuum, reindexing) so the customers don't get too frustrated :). Oh, and do use a different port as well as completely nonconflicting setup. > I' very new to postgresql and unix system administration in general, never > having secured a system or played with permissions much in the past. Any > advice would be greatly appreciated. > I am sure you'll like it more the more you learn. Hopefully some of your development efforts will be to improve postgres or some other project later on (and contibuting it, of course). Regards, Jeff Davis > Thanks, > Mike > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
pgsql-general by date: