None of those entries allow you to limit per-machine. Why aren't you just using verified trials?
Free trial-question if users are cheating?
JurajWe allow a free trial of our software-one time (30 days), limited to one machine.
As part of our free trial procedure, we collect some user's data such as Win32_ComputerSystemProduct_UUIDWin32_OperatingSystem_SerialNumberWin32_Processor_ProcessorIdto be able to see if someone wants to repeatedly trial our software. We have a database of these entries and occasionally I see users that show duplicate 'Win32_OperatingSystem_SerialNumber'. So far haven't seen duplicates on any other entry. Is it correct to assume that a repeating OS serial number suggests that it's the same person who installs our product on their second computer (for which they likely used the same OS installation disk)?
Hi Wyatt,
This is an interesting topic. I thought that a Trial was already managed by LimeLM servers to avoid cheating. I did not saw this "new" documentation with verified trials before.
This brings me to a suggestion that could be implemented.
It would be nice to simply add a boolean parameter to UseTrial() to make the trial automatically checked with LimeLM servers (or UseVerifiedTrial()).- You already have all the footprint logic- You already have the database support- You already have all the code for extended trials
My suggestion is to do the following when UseTrial(True) or UseVerifiedTrial() is called:- Send footprint to LimeLM server and answer back with a trial key.- When trial expires, it's possible to use a trial extension key as it is already the case.- The user cannot cheat because if a new trial is asked, the trial key will be the same (for the same machine).
In the web interface, we could have a new section called "Trials" where we see the list of trial keys issued. It could even be possible to automatically extend a trial key (once) when user ask for it, or we could do so manually (the user providing its key).
The trial keys and footprint could be deleted automatically after a given amount of time (like, one year). So this avoids cheating.
Well, an implementation in the like would be good and save us a lot of false-key management by using real keys and consuming our key limit. (Yeah, trial keys should not be counted.) Unless a way to avoid the cheating is found. (Like a "file" could be sent to our database servers and required for the trial to work. One piece on their PC, one piece on our server, or in a local file/database, but the idea is that we manage that piece, etc. So a validation is made and cheating not possible.)
Best regards,Alexandre Leclerc
We're working on a method for verified trials without keys, but it's not an easy problem to solve.
hachemI would be very interested in this feature of having automated verified-trials, especially if it doesn't use up activations.Even if the trials are still not trackable from the web interface (with serials numbers, etc), at least knowing that the trial time limitations are strictly enforced (because the application has to connect and verify with your servers). Of course, being able to track them would also be nice.
The fact that verified-trials currently use up activations is a significant problem. With a lot of trial users, this could rack up a lot of activations (perhaps exceeding the limit) without actually making a single sale.