Implementing a 30 day time trial [closed]

Question

Question for indie Mac developers out there:

How do I implement a 30-day time trial in a non-evil fashion? Putting a counter in the prefs is not an option, since wiping prefs once a month is not a problem for an average user. Putting the counter in a hidden file somewhere sounds a bit dodgy - as a user I hate when apps sprinkle my hard drive with random files. Any ideas?

Answer 1

At the time of download, provide them with a trial serial number. When they enter the serial number, have it connect to your server and gets expiration information (stored and encrypted locally to prevent any additional "phone home" calls).

By doing it this way, you make it fairly hard for them to get around your 30-day window, as the expiration date is permanently stored on the server. You could set it up so deleting the key and re-entering it would cause your application to connect to your server again and download the same expiration date as before.

Or you can do it like WinZip does (or used to do it?): Provide a 30-day trial and just pop-up a screen at every load that shows how long you've been using it and links to purchase.

Answer 2

I would suggest to implement few of things which are less intrusive and may avoid a normal user to either uninstall or buy at one month period.

1. Use a special series of trial-serial number which stores expiry date in it. You can use encrpytion to store expiry date within the serial number.
2. Now create a configuration file which stores data in the encypted format and contain the serial number.

Additionally implement these things in the config file.

1. Make a note of time/date every time user starts the application.
2. Note the duration of the time application was open.

By doing the logging of timestamp you can avoid these workarounds:

1. If user reverses the computer date, you would know that app was already run on that day. Say user ran app on 1 and 3 day of month. Now after 30 days reverses the date and sets it to 2nd of month. Now by config file you would know that app already ran on 1 and 3 so user has messed up dates on the computer.
2. Let’s say every time user starts your app by first setting date to 5th of the month. By logging your application running time you would see that if the total hours in a day exceed 24 then user is fooling around.

Ensure that your app doesn’t run without the config file. So essentially you send the encrypted serial number in a file or maybe upon entering the serial number you can create file. Since the serial number already has the expiry date user can’t reuse the serial number also.

I would not suggest the internet way because people get pissed off when app tries to connect to server every time. Plus, one may get suspicious that you trying to send some personal data of users to your servers.

One thing I would like to say: No matter how strong the anti-piracy technique you use, someone is bound to break it. You are not making your app for those guys. You are making your app for people who would like your software and will buy it happily. So have the anti-piracy in limits without losing the genuine customers by making your application too intrusive during the trial period. One thought also says, if your software is getting cracked that means it’s getting popular also. Again opinions may differ and would not like to digress on these issues.

Answer 3

The least evil way is to just ask the user to delete the program after one month or pay for it ;)

Answer 4

This issue comes up repeatedly on the cocoa-dev mailing list and the consensus answer is always do the simplest thing possible. Determined hackers will break all but the most over-engineered solution. And they're unlikely to pay for the software anyways. Go for the 80/20 solution: the easy solution that gets 80% effect for 20% effort. In this case, putting something in ~/Library/Application Support/your.app.com/. You might name the file something innocent if you want to obfuscate things just a bit. Using the user defaults is easy too.

Whatever you do, don't use the MAC address or an other hardware ID. Users with a network home directory (e.g. in a shared lab setting) will hate you. Using hardware IDs is just evil.

If someone is in love with your program so much that they're willing to break your trial limits, let them. The free software costs you nothing and their good will (and maybe recommendation to others) is worth a lot.

Finally, write software that people want to use and price it for its value. If your price is a good value and people want to use it, most people will pay for it.

Answer 5

Read an UUID from some hardware component and make a check against your web service to see if your software has already been installed for 30-days upon program launch?

Answer 6

Having the software expire after 30 calendar days is bad because what if someone downloads it, runs it once, and then decides they'll evaluate it a month later? Next time they launch it, a month later, it'll say it's expired.

I'd go with having it limited to 14 launches, or something like 120 minutes of use.

As for implementation, a file (hidden or not) in the user's Preferences folder, with an obfuscated name, seems like the best way to go. The file isn't randomly placed on the hard drive, but the user can't easily figure out which file to delete.