What have you all used for "expiration" logic

I've got an app that we want to allow users to have for a given amount of time and then have the app simply stop working.

I was wondering what any of you might have used at a commercial level to achieve something like this.

I don't mind sending a new .EXE every renewal "season" but it would be easier to send a new license key.

btw - we connect to a SQL server with our app.

I noticed that Sony Vegas software takes a CD key and then after install the app gives up a "computer number" - based on specifics in the hardware/OS installed on that box. You give them these two figures on the website and they give you an activation key.

That technique sounds nice - since we have a central SQL box - we could gather a "computer number" off of that...

Any help would be greatly appreciated.

Is it an internet based application? .If not, users could be in a fix if their systems are not connected to the internet.

No it's a intranet app - VB CLIENT (that I want to expire annually) connects to a SQL server over a WAN.

But internet access is not an issue anyway. With that Sony product I mentioned they would take a call over the phone to generate the lic key if the user does not have internet access...

Quote:

---

With that Sony product I mentioned they would take a call over the phone to generate the lic key if the user does not have internet access..

---

Thats the problem.Most commercial apps have the off line/telephone feature which is exploited by crackers.Adobe has a similar feature and is very easy to bypass.but the good news is cracks/key-gens exist only for famous apps. So designing one for your app should not be a problem.

ps:I have no commercial experience btw.

No, since its your software Steve you could have them call in (secondary offline method) and verify their customer credentials like address, EIN, etc.

I'm not worried about hackers...

I'm worried that if I do something silly like put a date in a table in SQL somewhere that it can be simply overcome.

And I certainly don't want client A sharing their keycode with client B (if client B doesn't renew).

The business model that we are pushing is for the customer to not have to drop the large $$'s on purchase price - but instead pay a monthly fee (forever) for use of product. This is very much like leasing but without the leasing company in the middle.

We base our price on number of users at the client site (which can range from 200 to 1000 or more at a site). Each year we need to find out how many users they currently have - set the new monthly price - and start charging that fee. At that time I would like to give them a new key to keep the app running.

You should look at a yearly lease as it will cut down on your accounting time and labor. Allot of companies use this yearly fee licensing scheme as a Annual Maintenance contract.

You could use their company name in one field and a license code in another. The license code will be partially derrived from the company name. I think your software shouldnt be used by non-school or private use too much?

Company Name - that got me thinking...

I'll key it to the DOMAIN NAME they use. That's pretty static with my customers. If I keyed it to the SQL box it would hamper disaster recovery...

So I guess it's a matter of me coming up with a formula that turns DOMAIN NAME and YEAR into some key value that I then drop in the database.

I do work with a major document imaging company here in so. cal and they have a good encryption licensing scheme. They use the registered company name (registered when you purchase their software) and date/time and features purchased. They have indefinate licensing for when you officially pruchase a license and others timed for demo versions. Its not tied to any hardware or software on a system. They have network licensing so the shared data can be accessed over the network and keeps track of systems that have it installed. I could take it home and install it on my own system if I wanted to but I would have to use the company's name which will also show up in the splash screen and help/about form. Not something that any legitimate company would want to do since any of their employees would see they are using another companies license. ;)

It is more of a benefit of having enterprise software solutions then personal software. When you have personal software no one will know if you have it but enterprise software in the workplace wil definately be known.

Your right - if I stored the school district name in a table in SQL and also put that onto the splash screen it would work...

Then I could key the product off the district name itself...

What kind of encryption logic works? How does MS get these funky 25 character product keys?

You should also place the registered company name in the about form for double the visibility.

I believe that each section of the license key is relevant to some feature, product and/or version.

You may want to check out the System.Security.Cryptography.SHA512 class for the tightest encryption available in the .NET FW if thats your software platform.