Controlling Unauthorized Distribution of Database (1 Viewer)

[Pac-Man]

You would be suprised what I could put together just from what I've found on the net

You must have used your 20yr experience in that too and your time (not to forget).

Just to clarify, I'm not selling freely available code and I am not okay with it too ethically. I'm developing a database for a friend who runs non profit school and a month or two before, when I started this database, I came to this forum for help and mention this fact too.

Purpose of putting such options are not need based mostly. I try to learn different ways and methods You might have come across my post when I wanted to switch to SQL server where few asked me reason of switching, that wasn't need too.

I am developing database only to learn Access otherwise it has nothing to do in my job. I started using Access few months before, not years . Even if it's free app being developed for friend even then I want to put registration system as @MickJav said below.

All my projects are freeware but I do use a reistration system

 

[Dreamweaver]

I am developing database only to learn Access otherwise it has nothing to do in my job. I started using Access few months before, not years . Even if it's free app being developed for friend even then I want to put registration system as @MickJav said below.

My System allows them to register there copy but doesn't force them too.

 

[CJ_London]

that wasn't your original question which was how to prevent unauthorised distribution.

Since this is work for a friend, I would have thought you can trust them to not give it away freely.

Either way, you have a number of suggestions of what you could do.

 

[gemma-the-husky]

There's no reason not to sell products of your own design. Most code you find just asks for it be included with warnings and caveats included. What's as important as protecting your work, is deciding how you can support your software in the event of it not working correctly.

 

[isladogs]

@abdullahkhan
You have already been in contact via PM (unsuccessfully) trying to obtain the code for the latest version of my Encrypted Spilt No Strings - Mendip Data Systems application. I am aware you've since found the much earlier (and less secure) version I posted here a couple of years ago. You are welcome to use the ideas in that (with suitable acknowledgement!)

However, trying to 'cobble' together a highly secure app from a variety of online sources when, in your own words, your own coding skills are limited, is never going to be wholly successful. Any code you do use should of course be acknowledged including any copyright notices provided ...though if you distribute ACCDE files that information will of course be inaccessible!

The guidance given by @CJ_London in post #5 is fairly close to what I'd recommend - and is very similar to what I use in my app referenced above.

When distributing applications for schools, I ALWAYS do so with a site license for an unlimited number of workstations at that site.
This is BY FAR the simplest method of distributing software for use on multiple PCs
The application is however restricted to one school and that is enforced both in code and by the license agreement

In fact several of my schools applications are actually sold with ACCDB FEs, precisely so schools can modify them if they choose to do so. However, it is VERY RARE for schools to do their own code modifications, partly because doing so means they cannot use any of the version updates I provide - typically several times per year

I also sell other business applications for a specified number of workstations only. Managing this is far more complex as its extremely difficult to prevent users installing Access apps on more workstations than their license allows.
The method I use (based on a suggestion originally by AWF member @gemma-the-husky) is to allow users to do an unlimited number of installations BUT only allow as many PCs to run the application concurrently as they have licenses for
e.g. If 10 licenses were purchased, up to 10 PCs can run the app at once. If user number 11 tried to login, they are blocked...until someone else closes the app. This is easily enforced using code built in to the app.
Of course if this situation happens frequently, the organisation may choose to purchase additional licenses ...which suits me just fine!

 

[Pat Hartman]

Another method which helps to prevent unauthorized distribution is to require annual renewals. So, the application expires on a given date unless the user enters a new license key. This doesn't block access to their data. The data is theirs and is in either a SQL Server database or a Jet/ACE .accdb

I also use the site license concept which eliminates worrying about user count. But as Colin described, concurrent user count can be managed without too much trouble. In my case, it is not the kind of app that people would share with friends so we have little risk of the app being sent around to different companies. Most corporations will adhere to a license agreement. You could include some kind of fingerprint in each FE you distribute so that if necessary, you could actually track down the source of the leak if you discover the app being used by unauthorized schools.

 

[Isaac]

Find code that takes pictures of people using the database surreptitiously. Anyone who is an imposter, take out a full page ad in their local newspaper "imposter gallery".

 

[isladogs]

I also use the yearly subscription approach.

As a serious response to Isaac's post, my main schools app includes an error logging feature that saves details of any program errors to a table AND 'silently' sends an email to me with details of who/what/where/when/how etc the error occurred (my clients have of course consented to this being done)

There would be nothing in theory to stop the same system being used whenever someone logs in to your app. If the email generated comes from a non-licensed source you could take appropriate action including terminating the license.
It seems totally over the top to me but the possibility is there!

 

[Isaac]

I also use the yearly subscription approach.

As a serious response to Isaac's post, my main schools app includes an error logging feature that saves details of any program errors to a table AND 'silently' sends an email to me with details of who/what/where/when/how etc the error occurred (my clients have of course consented to this being done)

There would be nothing in theory to stop the same system being used whenever someone logs in to your app. If the email generated comes from a non-licensed source you could take appropriate action including terminating the license.
It seems totally over the top to me but the possibility is there!

I mean I have to admit, also on a serious note, the coolest "app locking" cell phone app I've seen takes a picture of who tried to break into the app, it was pretty fun. Generally there ended up just a lot of pictures of me.

 

[Pac-Man]

Thanks a lot everyone who responded. I've got number of suggestions. I'll try to put one then, doable for me, into my app.

 

[Zedster]

You can make it hard for people. For example:

• Make FE/BE as someone has already suggested
• Make BE MS SQL if possible
• Make .accde
• One thing I do on my databases is have a table in BE SQL with a version number and a hard coded version number in the FE, if the FE version number < BE. It closes down on startup. Then issue periodic updates. I do it to force users to stop using old databases in case for example they have bugs.
• You could do similar with usernames. Keep a table of usernames on the backend and use windows authentication to check the person opening the database has a username in the table.

If you are considering developing for commercial use, I would recommend sharpening up your VBA skills. What sets apart a well designed database from something that anyone could design after attending a course, is a slick user interface (and good data structure obviously). Generally that requires a fair degree of coding.

 

[Pac-Man]

You can make it hard for people. For example:

• Make FE/BE as someone has already suggested
• Make BE MS SQL if possible
• Make .accde
• One thing I do on my databases is have a table in BE SQL with a version number and a hard coded version number in the FE, if the FE version number < BE. It closes down on startup. Then issue periodic updates. I do it to force users to stop using old databases in case for example they have bugs.
• You could do similar with usernames. Keep a table of usernames on the backend and use windows authentication to check the person opening the database has a username in the table.

If you are considering developing for commercial use, I would recommend sharpening up your VBA skills. What sets apart a well designed database from something that anyone could design after attending a course, is a slick user interface (and good data structure obviously). Generally that requires a fair degree of coding.

Thanks a lot for detailed reply and for suggestions.

 

[sainivedant41]

I'm not a pro in coding. It'll be greatly helpful if some sort of sample db or code is available.

 

[Cotswold]

You must study security to protect your code. Give it as much thought and attention as you do for your software.
This is not a general statement but from my experience, of the few County and Local Councils I have dealt with, they have no concerns regarding pirating software. They also can often be a source of viruses. You must protect your systems. If you don't then don't be surprised if someone else starts selling your software sometime. Then it is up to you to prove a copyright infringement. It will be far quicker to install the security at the start.
For commercial software:
1. Write the name of your client into a system table. Link it to a complex code so that if it is changed in the slightest, the
program spots that and closes down. On the main first screen show the name as Licensed to.
2. On all reports print the client's name. If they insist on using pre-printed, still print their name somewhere. Maybe vertically in
a small font, or as a watermark. Something they can't just trim off.
3. Do not sell your software, sell a license to use only. Take a look at Microsoft's and other major companies licenses. You know,
the ones you always agree to without reading. They have spent a lot of money on those licenses, all just for their benefit.
4. Give your client T&Cs and copyright. Include a popup in the software with the details. So they can't say I have not had that!
Refer to your T&Cs applying somewhere on your quotations and invoices
5. As suggested in earlier posts see @isladogs for ideas.
6. Do not allow the client to install your systems. Maybe get a copy of TeamViewer or similar for remote installs.
7. If you use someone elses security and it goes wrong, maybe more difficult to fix. Be sure you can understand it first.
8. One simple install is to use a batch file to copy, rename, etc, whatever you want where you want BUT get a Batch-File-To-EXE program.
That way the client sees only an EXE running with no screen information showing what is going on. Don't give a batch file, easy to read.
9. Even a simple security system is better than nothing. Think about it and I'm sure you can come up with something. Well you'll need to!!

 

[Pac-Man]

You must study security to protect your code. Give it as much thought and attention as you do for your software.
This is not a general statement but from my experience, of the few County and Local Councils I have dealt with, they have no concerns regarding pirating software. They also can often be a source of viruses. You must protect your systems. If you don't then don't be surprised if someone else starts selling your software sometime. Then it is up to you to prove a copyright infringement. It will be far quicker to install the security at the start.
For commercial software:
1. Write the name of your client into a system table. Link it to a complex code so that if it is changed in the slightest, the
program spots that and closes down. On the main first screen show the name as Licensed to.
2. On all reports print the client's name. If they insist on using pre-printed, still print their name somewhere. Maybe vertically in
a small font, or as a watermark. Something they can't just trim off.
3. Do not sell your software, sell a license to use only. Take a look at Microsoft's and other major companies licenses. You know,
the ones you always agree to without reading. They have spent a lot of money on those licenses, all just for their benefit.
4. Give your client T&Cs and copyright. Include a popup in the software with the details. So they can't say I have not had that!
Refer to your T&Cs applying somewhere on your quotations and invoices
5. As suggested in earlier posts see @isladogs for ideas.
6. Do not allow the client to install your systems. Maybe get a copy of TeamViewer or similar for remote installs.
7. If you use someone elses security and it goes wrong, maybe more difficult to fix. Be sure you can understand it first.
8. One simple install is to use a batch file to copy, rename, etc, whatever you want where you want BUT get a Batch-File-To-EXE program.
That way the client sees only an EXE running with no screen information showing what is going on. Don't give a batch file, easy to read.
9. Even a simple security system is better than nothing. Think about it and I'm sure you can come up with something. Well you'll need to!!

Thanks a lot for this detailed information.

 

[Cotswold]

Not only is it a lot..................it's totally free!