Re: Licensing a database app

Yet 'another' suggestion. You could make a serial number algorithm that stores the magic number as an 'encrypted' part of it (like so many other serial numbers do) then you can store the serial number 'in the open'. Your app then would have to 'unscramble' the serial number and then could make a select count(*), whatever. I would suggest you hardcode the 'unscrambling' within your app so as not to be dependant of 3rd (whatever) party tools.

--
Aigars, 921

Jason Short wrote:


> 

> >So, it's not that we permit our customers to modify our database.  Simply


> >put, we cannot prevent a customer from doing so.

> 

> Agreed, the customer will find some way to get into the system and screw

> around with things.

> 

> >- Store the number in the database, but encrypt and/or digitally sign the

> >number first.

> 

> If you have an application running on the server you could also have it

> store the "magic" number in a binary file on the server.  Without an app

> running on the server this gets a lot more complicated (Out of Process

> remote ActiveX server would do it though).

> 

> >- Hardcode the number in the code.  Since there will probably be under 25

> >customers, recompiling a component for each customer is not unrealistic.

> >This was suggested by Jason Short.

> >- Use a hardware dongle also suggested by Jason Short.  We feel most

> >companies will not allow any hardware to be installed on their corporate

> >servers.

> 

> Agreed.  Most companies will balk at hardware dongles these days.  But, some

> can be talked into.

> 

> >- Use the Microsoft Licensing API. This was just suggested by huh.  I

> >haven't had a chance the seriously look at the licensing API.  Any

> >suggestions/concerns/comments on the LSAPI? Does anyone actually use it?

> 

> We looked into and finally decided to roll our own.  It looked a little to

> early in the adoption phase for us.  You have problems with the user

> "upgrading" a service pack that kills the 128 bit encryption and suddenly

> you are back to 40 bit.  Try to explain this to a customer (Honest it's not

> our fault).  This was about 1.5 years ago, so it might have changed by now.

> 

> Good Luck.  Let us know which method you decide to adopt.

> 

> Jason