How to create a trial version of a Java program [closed]

Here is an idea:

1. Create a database (such as a SQL Server database) that is publicly available on the web. It will keep a list of "trial version" license keys. You can use the same system for full-version license keys when your product is purchased.

2. When your Java software is first run, it'll cause a trial license to be created which will be stored in the database

3. The Java software checks for a valid license each time it is run. The date that the license was created is stored in the database so it doesn't matter what the client clocks are set at.

4. The software stops functioning when the license is expired

Standard windows software can look up the CPU ID and use that as part of the license, so that each computer can only run the trial software once. Does anyone know if there is a "JVM ID" of some kind that can be used for this purpose?

Maybe there is free or open-source license-related code out there already?

Why not just hard code an expiry date into the trial program so that you don't have to continue to support it? You could put this in main().

// Die after October 1, 2010
Calendar expireDate = Calendar.getInstance();
// January is 0 (y, m, d)
expireDate.set(2010, 9, 1);
// Get current date and compare
if (Calendar.getInstance().after(expireDate)) {
  // Die
  System.exit(0);
}

This is how Microsoft distributes their large scale beta software. They just give it an expiry date.

If you're talking about preventing reverse engineering or modifying the code, you can't. You could obfuscate the compiled program, but this won't stop the people who would be reverse engineering your code anyway.

I would just do something really simple and just hard enough such that non-programmers wouldn't be able to figure it out.

I would something like write to a file the number of milliseconds when the program was first installed in a 64-bit long in binary to a file. And have your main class check and enforce the time limit. Yes people can change their clocks to work around this, but really you don't want to sell to those people anyways. Also ensure the current time is strictly within 30 days of the install. Most users will just set their clocks back one year and it works with most programs because they just did a simple less than the difference check. You should also check that the difference in number of days from current to install is also greater than 0.

If you feel you need more protection than that, then you have a business model problem more than a software one. Its basically impossible to make it unhackable, especially since you can just extract and disassemble the class files.

The problem with trying to limit the dates is that the naive solution of just checking the date is easily fooled if the person sets back their system clock. I worked with a guy who kept a VMWare virtual box just for running time limited software. A better approach would be to record the time of the last time it was run, and if the time ever goes before that time, you know the clock was set back and you can abort. The problem is figuring out how to stash that file somewhere where the user can't find it an overwrite it. Again, in the the VMWare or VirtualBox environment, the user could just roll back to an earlier snapshot.

In other words, you can limit some of the people some of the time, but not all of the people all of the time.

I work on a commercial Java software and it is protected.

Is mandating an Internet connection acceptable in your case? In our case, our software only makes sense if there's an Internet connection and hence we can make reverse engineering impossible by simply following this mantra:

make sufficient part of the computation happen on the server side

There's nothing against this an attacker can do besides:

• rewrite the part of your software that is happening on the server side

• pirating your server

If our potential users are not happy with the fact that our software mandates an always-on Internet connection they can either buy or pirate one of our competitor's inferior product.

Think of it this way: nobody ever succeeded in playing on Blizzard's battle.net using fake/generated license keys.

Sure, a pirate could try to fake the whole battle.net, but then the pirated version wouldn't allow people to play in, say, the real WoW economy nor to compete on the real Starcraft ladder, etc.

Why did no-one managed to do that: because Blizzard made sufficient part of the computation happen on the server side.

Sufficient part of the computation happening on the server side effectively means: "good games pirates".

The more we move to an always-connected world, the easier it is to protect apps against piracy. Same for content (DRM), for the better or the worse.