Fingerprint Robustness

We are finishing up our testing of the LimeLM validation function for our software product. The nature of our application is such that the computers run 24/7 for long stretches. This means that the customers' support people are frequently replacing and upgrading hardware. As we roll out the licensed software, we would like to set expectations on when or how often users may have to re-activate their licenses.

The on-line documentation talks about fuzzy matching, but gives no clue how far I can stray before re-activation is necessary. I'm not looking for proprietary information; nor am I looking to subvert the licensing. Is there any advice you can give me that I can pass on to my customers?

Regards,Jim Fleming

Hey Jim,

but gives no clue how far I can stray before re-activation is necessary.

After they modify every component they should re-activate. So if they change RAM -- reactivate. Switch out a harddrive -- reactivated. Etc. If they will be making a large number of changes at once -- or changes that TurboActivate considers a whole new computer, then they would be best off deactivating first, then re-activating after the changes. See: http://wyday.com/limelm/help/activations/#deactivate

Does that make sense?

Thanks, Sam. That clears things up. I'll be sure to put that in the user's guide.

Does this apply to Virtual Machine environments as well? That is, if the LimeLM protected software were on a cloud server, and its admin added a couple of virtual storage volumes, does that effect the fingerprint as well? Would the user have to reactivate in that case?

Arie

Adding harddrives doesn't effect anything. Replacing the "main harddrive" (where the operating system is installed) does affect things.

But, if you're installing & activating your software on cloud servers, you'd be better off using TurboFloat. Why? Because the underlying hardware is not consistent between reboots. So, if you're using TurboActivate, and the customer is using your software on a cloud service like Amazon EC2, then everytime the customer reboots the machine they'll need to contact you so they can re-activate on the same VM.

If, however, you use TurboFloat when the customer is running on a VM instance, then the customer can just start your app and it will just work (because of the nature of floating licenses, and how TurboFloat is uniquely programmed to handle cases where customers are running on VMs).

Make sense?

Yes, makes sense. But if they deactivate before the VM Is shutdown, it should be fine, yes? There would be no need for a floating license if the user did that, yes?

That's a possibility, but that doesn't handle cases where the customer shut down the VM and forgot to deactivate, or the VM crashed, or they did an update and restarted, etc., etc.

Really, TurboFloat is the solution to these problem.

Reply
Discard post