Need Advice on Implementing a Time-limited Trial

Question

I'm developing a shareware desktop application. I'm to the point where I need to implement the trial-use/activation code. How do you approach something like this? I have my own ideas, but I want to see what the stackoverflow community thinks.

I'm developing with C++/Qt. The intended platform is Windows/Mac/Linux.

Thanks for your advice!

Horatia

Not related, but please keep in mind that if you develop commercial apps using QT you must have a QT developer license. The QT license forbids using the Open Source edition for commercial software, which includes shareware. See trolltech.com/products/appdev/licensing/licensing for details. – Main

Thanks for the advice. We have a commercial license. Wouldn't want to upset the trolls... – Horatia

That's good to hear :) Trolltech has given so much to the community that I feel the need to defend them even if it's probably not required... Glad to see you're supporting them. – Main

Answer 1

What to protect against and what not to protect against:

Keep in mind that people will always find a way to get around your trial period. So you want to make it annoying for the person to have to get around your trial period, but it doesn't matter if it's impossible to get around you trial period.

Most people will think it's too much work to try and get around your trial period if there is even a simple mechanism. For example people can always use filemon/regmon to see which files and registry entries change upon installing your software.

That being said, a simple mechanism is best, because it wastes less of your time.

Here are some ideas:

• You can do a tick count somewhere in registry for every unique day that is run. If tick count > 30 then show them an expired message.
• You can store the install date, but take head to check if they have more days available than your trial is supposed to be, then do tell them they are expired. This will protect against people changing their date before installing to a future day.
• I would recommend to make your uninstall, remove your "days running" count. This is because people may re-evaluate your product months later and eventually buy. But if they can't evaluate it, they won't buy. No serious user would have time to uninstall/re-install just to gain extra use of your product.

Extending trials:

For us, when a customer requests a trial extension, we send them an automated email that contains a program "TrialExtend.exe" and a trial extend code. This program contacts our server with the trial extend code to validate it. If the code is validated, their trial period is reset.

Trolley

` No serious user would have time to uninstall/re-install just to gain extra use of your product.` - I certainly will – Evaevacuant

Answer 2

Whatever you do, keep a keen eye on the system date. The oldest trick in the book is to install an application at some point in the future and then return to the real date once the application stored the silly date on first run. Maybe synchronise the key with a online repository ?

Crestfallen

To prevent that, one can use the absolute value of System.currentTimeMillis() - expirationDate.getTimeMillis(); Sorry, I am a java guy. Regards, Steff – Manas

Answer 3

Brian's answer's great, but I'd like to add something.

Linux users generally aren't used to paying for software, and they tend to be more tech-savvy and possibly even "religious" on open-source issues.

For that reason, I'd really recommend keeping it simple - it's really just a small barrier to make buying the software at least as easy as stealing it.

I'd suggest that it nags or disables certain features (eg saving) after the trial period rather than dying completely. Just an observation, but feature-based restrictions seem more common in the linux world.

As an aside, making the linux version a "first class" version - decent installer etc will help.

If you're relatively small, or your program's relatively niche, there's a pretty small chance anyone will bother to crack it - so just concentrate on making a good product with a straight forward niggle once the time's up.

Marthmartha

Answer 4

If you are [fairly] likely to have a network connection, you can have the installer register with your website, then check against it every time it starts.

If that's not feasible, writing a value into a world-modifiable point on the filesystem (a registry entry, entry in and /etc conf file, etc) may be workable.

Hospodar

Be careful about this. Users are very wary of programs that "phone home" -- they have no way of knowing what it's sending back, it could be their credit card numbers and banking passwords for all they know. – Eastbourne

Answer 5

Perhaps the real problem is the Time-limited trial. The company I work for does a lot of Active Directory work and we usually limit our software to a small amount of users for trial versions. I feel that limiting functionality in some way is sometimes better, easier to implement, and doesn't fail when the user simply changes the date on their computer.
There is balancing act in that you can't limit functionality too strictly, otherwise users get nothing out of the trial. At the same time, a limit that is too loose gives no incentive to purchase.

Cryostat