[ACCEPTED]-Implementing a 30 day time trial-licensing

Accepted answer
Score: 62

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

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

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

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

Score: 28

I would suggest to implement few of things 30 which are less intrusive and may avoid a 29 normal user to either uninstall or buy at 28 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 27 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 26 the logging of timestamp you can avoid these 25 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 24 run without the config file. So essentially 23 you send the encrypted serial number in 22 a file or maybe upon entering the serial 21 number you can create file. Since the serial 20 number already has the expiry date user 19 can’t reuse the serial number also.

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

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

Score: 12

Consider this. How many potential users 23 of your software are out there, just itching 22 to use it solidly for the next 30 days?

I 21 suspect the far more normal case is: Users 20 encounter a new software package that solves 19 a problem they've had on a site like lifehacker.com. the 18 software gets downloaded, played with briefly, then 17 put aside. Perhaps its mp3 ripping software 16 and they don't have any cd's to rip at that 15 time. Or they're just busy that day, but 14 they'll get round to reviewing that software 13 'soon'.

30 days pass. Probably more. Only 12 Then do they buy a CD, encounter some sort 11 of 'problem' and remember, 'aha, theres 10 that trial version I downloaded! Where did 9 I put it again?' It doesn't matter. Without 8 ever being used, the 'trial' has timed out.

I 7 can't count the number of software tools 6 that have fallen into that bucket for me. The 5 day a piece of software is recommended to 4 me, the day I see a positive review on lifehacker, is 3 NEVER the day I actually have a need - or 2 even the time - to use / analyse the program 1 I've downloaded and intalled.

Score: 8

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

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

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

Score: 5

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

Score: 3

We did it for one of our client application. Granted 29 it was done in .NET for Windows, but the 28 same principles can be applied in MAC.

Like 27 eckesickle mentioned, if your user have 26 access to the internet (or should), then 25 you can have a web service that will register 24 some unique id from the host computer with 23 the starting date trial (MAC adress is a 22 good one). With this, the user cannot really 21 cheat the program unless he chances his 20 network card every month.

Now, if the user 19 doesn't have access to the Internet for 18 some reason, you can either shut down the 17 program until he connect to it or use a 16 grace period. This file records the last 15 time the app is opened. When the Internet 14 is not accessible, we stop writing the time 13 (we still write something in it so the user 12 doesn't notice the file is not updated).

Should 11 a user notice that this file contains the 10 information and delete it (or change it 9 using a copy he has), then you need a way 8 to counter that. You can have some other 7 value in another config file (encrypted 6 always) and check for consistency. What 5 you do if you discover that the user is 4 trying to cheat is up to you, but we force 3 the user to connect to the internet for 2 it to work.

It might be overkill for a program, but 1 it definitly works.

Score: 3

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

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

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

Score: 3

I used to offer a 30-day lite edition of 21 my iOS app that embedded the install date 20 and various record dates in the export data 19 file that the user could download to his/her 18 computer.

If the user was a cheapskate and 17 just reinstalled the lite edition and tried 16 to re-import the data, logic would notice 15 that at least one of the date was older 14 than 30 days and the app would set its install 13 date to the earliest such date from the 12 file, rendering it expired again.

In the 11 full paid edition, this logic didn't exist 10 and the data file could be imported easily.

It 9 was a pain supporting people in this data 8 migration (since apps are completely sandboxed 7 from one another) and some other users felt 6 the lite edition was enough for them so 5 they never upgraded.

I've since stopped offering 4 my lite edition and just reduced the price 3 of the full edition. Now potential customers 2 just have to pay a small amount or go find 1 some competing software.

All in all, that was the best strategy for getting paying users.

Score: 1

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

More Related questions