Licensing a VBA MS Access application - which solution?

[JohS]

I'm going to produce a few (not more than ten) MS Access VBA driven forms
which I'm planning to send out as 10 days trail to companies.
When the potesial customer start the trail software, it neeeds to be
registered to that company (most likely through the users email?) and to
that spesific PC (reading hardware ID?).
Maybe easiest solved by haveing a VBA function & form registrating and
sending the necessary data to me as vendor.
I then need a function (generating a public-private key, maybe encrypted ie
by a hash or two) which is generating a 10 day linsence, sent by email
(maybe a text file attachment 'license.txt') to customer/user.
A VBA functions inside the software are then at start checking whether valid
lisence exists.
Then after passing the 10 days of trail, a payment will be done (after
agreement, a manual invoice is sent & paid), and as the software vendor, I'm
sending to the customer a new license through email.
This license is only going to last for 90 day. Then if the customer still
wants to use the software, yet a renewable license for the next 90 days is
going to be executed.

As this is small scale and low budget systems, I can't go for rather
andvanced and expensive server-side licence trackingt (which maybe also
could include redirected to a payment portal), build online (into my
PHP-driven Drupal webdomain).
1
Is there an economical way to solve this by purchased solutions (and is
there any MS Access add-ins which can solve this?)?
2
If it can be solved purely by code Functions - are there any samples out
there which also are dealing handling reading hardware ID (Mainboard, MAC
address, or..)?

Thanks, JohS

 

[Access Developer]

Access is a great tool for developing database application software, but it
was not intended primarily as a tool for developing generally-distributed
software, so the details of what you want to do are neither particularly
simple nor particularly reliable. There are better methods available for
protecting the _data_ than protecting the application itself.

Even if you generate a "compiled" version (MDE or ACCDE), there is software
available that will reconstruct and expose the VBA code, so anything you
code in VBA can be hacked.

I don't know, exactly, what you mean by "VBA-driven forms". Do you mean
"unbound forms" where you've written VBA to do all the interactions with the
database? In general, that is neither "better" nor more secure than doing
things the "Access way" with bound forms.

As an aside, I would have to really, Really, REALLY, *REALLY* need a
software package to go to the trouble/hassle of re-licensing every 90 days.

The most successful approach most people have reported for 'trial' database
software is to limit the number of records in critical tables, split the
database, and allow no permissions on the linked tables. (Even if you do
this, if it is an Access database, there is software that will let you take
over as 'owner' with full permissions.)

I haven't faced this kind of problem, as all the software I develop is
either "bespoke systems" created for specific clients or demonstration
software that is intended to be open for examination and modification. But,
in "previous incarnations", I have been involved with generally-distributed
software, and, although the development tools we used allowed us to secure
differently, I know that there is no protection scheme (short of software
that you host for your clients -- and maybe not even that) that can protect
your intellectual property from a determined, ingenious cracker.

Larry Linson
Microsoft Office Access MVP

 

[JohS]

Sorry for imprecise description - ref.

"Access is ....not intended primarily as a tool for developing
generally-distributed software"
I know Access best. What alternatives struck you mind?
(is VB a better idea (I haven't any experience in VB)?).

"There are better methods available for protecting the _data_ than
protecting the application itself."
The database if also needed in some jobs, but for the majority of the
application, the forms and the code is the most important to protect.

""compiled" version (MDE or ACCDE),...can be hacked"
Didn't know that. But as this is to me know businesses which is my
customers, I'm not that much worried for hacking.

"VBA-driven forms" ... "interactions with the database".
I meant whatever produced of VBA put inside MS Access. And yes, interactions
with database, but also to communicate with MS word, MS Excel, MS outlook.

"re-licensing every 90 days"
This is the only way this project is going to be secured payment so I must
find a solution where this can be achieved!

""bespoke systems" created for specific clients"
This is what this is. It is not any generally-distributed software.

JohS

 

[Access Developer]

All the "generally-distributed software" on which I was involved was years
ago, on mainframes. So the code ended up as machine language (still
hackable, but if all you've got is binary object modules, not awfully easy).
And, I can relate to "knowing Access best"... I haven't worked in PL/1,
COBOL, or Fortran in a long, long time.

When I say I worked on "bespoke systems", I mean that specific clients paid
me (time and materials rates) to develop database applications for their
use. No complex security scheme was required -- they had all rights to the
application except 'exclusivity', and our contract preserved my rights to
reuse any part of what I conceived, designed, or produced in another
database application. In most cases, those database applications front-ended
data stores on server databases such as MS SQL Server, Informix, or various
Sybase products -- the server's security was what the client relied on to
protect the data.

Almost every conceivable language and development tool has its advocates,
but you don't have to be a software pirate to know that there are very
clever "crackers" around who can break any security scheme.

On the other hand, I know people who were successful in creating software
for (at least a niche) market, and had honest, reliable clients/customers --
they were not overly concerned with trying for "absolute protection".

Larry Linson
Microsoft Office Access MVP