Need suggestions on how to license custom Access apps to clients

G

Guest

Anyone have any suggestions on licensing methods & enforcement for custom
Access programs (i.e. licensing my apps to customers)?

In particular, I need two things. I can think of a number of ways to do
them, but I don't want to reinvent the wheel if someone already has a piece
of code out there for it (besides that, the one that's out there is likely to
better than my wheel).

1. Auto-creating an expiration date in a demo version based on date of first
use. Here's one way I have considered, obviously staying away from storing an
expiration date in a table due to the almost inherent lack of security
evident a clever user ODBC's his way directly to the table and figures out
how to extend the demo date:
-Create a global variable
-Leave it null
-Have VBA check for a null value
-If null, open the code module and insert a value for the variable of today
+ 30 & save the module
-If not null, compare the variable to Date() and deny access if the variable
is <= Date().

2. License key creation with some measure of piracy-protection (i.e. license
key validation). With a limited number of customers, I suppose I could just:
-Create a developer-side utility that multiplies the year by the day by the
customer ID and gives me the result.
-Create a customer-side utility that requires this key for activation, but

This would require the customer to call me every time the program is
installed, and I'm sure that would get old in a hurry.

Pardon my kindergarten approach to this. I suppose it's a nice problem to
have, this business of having enough customers that I have to think about
licensing, but one I have not had to consider until now. With my luck,
there's probably a CreateLicense method in Access somewhere, and I've just
never seen it.

I know that ideally, I should write a web services-enabled routine to send
the customer information to a centralized & web-enabled (i.e. web services,
perhaps) database to unlock the specific copy, then again to lock it upon
uninstallation, but I'm not sure I'm ready for that yet.
 
T

TC

Your approach 1. wont' work if you distribute the database an an MDE
file - as you normally would. A better place to store the property is
as a user-defined property, in the front or back end database file.
(You have split your application into a front end/back end structure,
yes?) Very few users will think to check the custom properties. And if
you wanted to be really snazzy, you could do what I do: encrypt the
property so its value doesn't make any sense to the user, and checksum
it so the user can not change it to see what happens then. See the
CreateProperty method for how to create a custom database property.

Remember: 1% of effort will deter 99% of evil copiers. /No amount/ of
extra effort will deter the remaining 1% !

HTH,
TC
 
G

Guest

Great idea. Thanks. Yes, my DB's are always split FE/BE. I know how to create
DB properties, but I hadn't thought of using a property for this. I'm already
encrypting passwords, so that part is no problem, either.
 
T

TC

The good part about using db props is that they can't see anything
useful if they use a file or registry monitor (like the monitoing tools
from www.sysinternals.com). All they see is squillions of accesses to
incomprehensible parts of the mdb file :)

HTH,
TC
 
G

Guest

Can you give me some additional guidance on protecting or licensing my db's.
Do you allow so many uses before they have to enter a license key? How do
you program that?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top