I assume that when you negotiate a license, you know the Client's Company Name; eg. "ACME Company", "ABC Limited" ... (besides some other "unique" info).

You could stipulate that the Client will also have to use this same name when they setup the "Company Parameters" in the software ... because you could include a software module or DLL that contains all the (encrypted) names/Co info of your registered clients. At run time, the system will do a lookup of the "company information" against this "name module".

Each time you distribute an EXE to a new client, simply add them to the "name module" and include it with the EXE. The "name module" could even include # of concurrent Users, expiry date, etc.

A FLL or DLL would be harder to hack, especially if you include "dummy" ones in your distribution and use a "generator" to create the original C source code for the "name module" that contains the encrypted company information. Each Company name can be its own encryption/decryption seed.

The maintenance of this "name module" is simple part and parcel of you maintaining your "user/prospect list".

>Hello,
>
>Recently I've been looking at different ways to create unique keys to stop users from using my companies software w/o payment.
>
>Currently we program the users specific information into the program. This works because our software sends out invoices, etc to the companies customers. So, say we sold our software to 'Blah-Blah Company, Inc.' and they tried to give it to 'Illegal Pirates, Inc'. Illegal Pirates would find that at the top of all invoices and reports the name 'Blah-Blah Company' would be show. Unless they had a LOT of white out they'd have to buy their own copy.
>
>Anyhow, this system works fine but this process is EXTREMELY laborsome when we update the program, which we are in the middle of doing. The idea of making 1000 different copies of the program w/ unique address information frightens me.
>
>So we're moving to a unique key system. And this is where my question comes in. Obviously we don't want to use a system like Windows 95 or 98 because a user could simply give his friend his key. So we've come up with a 'seed key' idea.
>
>The user installs the software, they are prompted for their address information. They type the info in and click on okay. At this point the software looks at the computer and grabs a couple unique ID's from the computer, say from a NIC and the HD. It then creates a hash (the seed) from the ID's and the address information. The customer at this point can call us and give us the seed or go online and type the seed in. On our end we type the seed in and get an activation key that we tell the client. They entire the activation key in and the program is ready to go.
>
>Now the activation key is based on the seed, so when it is entered the program compares the seed and activation code. This way each customer has a UNIQUE activation code and if they make copies we don't care because they'd have to have the activation code for that address AND that computer.
>
>Pitfalls of this system:
>- Users have to go through more work to get their program running.
>- Users would need multiple activation codes for a network setup.
>- Could possibly be decrypted if they new what we're looking at.
>- If a user upgrades they need a new activation code.
>
>So my question, are there more pitfalls I havn't seen? And what's a good way to make a hash in VFP?
>
>Thanks,
>Bryan Smith
>
>PS: Sorry so long.