Settings trial days to zero (rental license)

Don't use trials or trial extensions for rental licenses because trials/trial extensions aren't hardware locked (i.e. the data can be cloned to other computers).

What you want to use is a license feature of the Date / Time type. For example "rental_expires". Then, in your app, you can use the GetFeatureValue("rental_expires") and IsDateValid() functions to get the feature and check if the rental has expired.

You can also "renew" rentals by editing the product key (either manually or using the web API). Then, on the customer's end, simply calling Activate() will download the latest cryptographically signed feature values locked to that customer's hardware.

Does that make sense?

Thank you Wyatt ,for your prompt answer. Really appreciated.

I perfectly understand what you are saying. I wanted to use trial extensions because I already implemented this in my product. But license features is easy too.How to clear a "date" license feature from web interface ? A "string" license feature seems more convenient, as I can clear it easily without using the web API ... Anyway.

You point something interesting on OSX : I call UseTrial() as a TA_USER, because it's more user-friendly not to ask for admin password (especially in university, where students cannot be admin).However, there is a flaw : they can create another session, and use the trial version again ... I guess it's because the trial version isn't locked to hardware (MAC address or whatever). How can I do, so people can only use a trial per computer ?My idea : validating every trial via my own server by testing the MAC address (for offline machine, giving only 2 or 3 days of trial)

Moreover, I'm still facing the case where my customer has a 30 days trial + a rental license : so when the rental license finishes, I don't want that this customers got trial days left.

Thank you so far. Philippe

How to clear a "date" license feature from web interface ? A "string" license feature seems more convenient, as I can clear it easily without using the web API ... Anyway.

We're changing the Javascript datetime picker to a better one that actually allows you to clear date/time values. Right now, though you can only do it from the web API.

However, there is a flaw : they can create another session, and use the trial version again ... I guess it's because the trial version isn't locked to hardware (MAC address or whatever). How can I do, so people can only use a trial per computer ?

Product keys, activations, and a feature value with a date time expiration. These trial product keys don't even have to stick around long. For instance, if a customer's trial expires you can just delete the keys.

Moreover, I'm still facing the case where my customer has a 30 days trial + a rental license : so when the rental license finishes, I don't want that this customers got trial days left.

Yeah, it sounds like you'll want to avoid our trial functionality (also called "unverified" trials) and just use our product keys / activations for both trials and actual purchases.

Hello Wyatt,

Ok, thank you for the explanations. I already add the "rental license" mode to my product, via a license feature. Just as you said. Very easy, cool 🙂And thank you for the new datetime picker : the current one is hell ...

So as far as I understand, I should have 3 types of license :- Trial license- Rental license- Lifetime license

I need 2 licenses features :- an "integer" feature for the type of license- an "expiration date" feature (set to none for lifetime licenses)

One question : as I should dynamically generate a "trial" license, how could I know if the users already request its trial license ?Example : a user uses its "trial" license, then uses a "lifetime" license from a friend, and finally deactivates the product. This way, the original "trial" license features are lost, and I cannot state if this users already got a "trial" license or not.Of course, I'm looking for a solution where the process is transparent for the user. My idea : giving this "trial" version via my own server, that will check if the MAC address was already used or not. What do you think ?

Thank you for your help. Philippe

One question : as I should dynamically generate a "trial" license, how could I know if the users already request its trial license ?Example : a user uses its "trial" license, then uses a "lifetime" license from a friend, and finally deactivates the product. This way, the original "trial" license features are lost, and I cannot state if this users already got a "trial" license or not.

A user can only have 1 license activated on a computer at a time. Also, a user can't activate a single product key on multiple computers (not unless you allow it by increasing the activations allowed to a number greater than 1).

Of course, I'm looking for a solution where the process is transparent for the user. My idea : giving this "trial" version via my own server, that will check if the MAC address was already used or not. What do you think ?

That's one way to do it. Or just have the user enter an email address (either in your app or on your website), then generate a trial license from that. It would be easier to spot fraud that way (rather than using MAC addresses which are meaningless and easily modified).

Hello Wyatt,

Thank you for your answers. I understand that the "trial" license is the ultimate solution. But on the other side, I quite like your "unverified" trials :- it's easy to setup, and I already did it- it's safe even if the user modify the system date- I can send trial extensions to my customers, so they can try longer

The flaw is just at the beginning : the UseTrial() method shouldn't be called if a trial was already requested by the same machine.My solution is pretty simple : everytime a user asks for trial, an encrypted request is sent to my server that checks whenever to call or not call UseTrial (via MAC address). That way, I keep the nice TA trial system.More complex that what I got right now, but safer, while transparent for the user (except that offline machines cannot get trial : but it's ok for trying).

PS about your solution (email address to generate a proper trial license) : I already get email before download, but how can I link email address with the machine asking for a trial ? I cannot, unless the user enters its email address in the app. But I don't want that for user-experience reasons.

I already get email before download, but how can I link email address with the machine asking for a trial ?

Well if you get the email before the download then you can just generate the trial key right then. Then either display the trial product key with their download link or send them the product key to their email.

Thank you, but I don't want that my users enter a key for trying my product : it's already a lot to ask for email. If there is some complexity, it's should be on my side, not on user's side. My 2 cents rule.

I thank you again for the time and explainations. I know this is your job, but you're doing it quite greatly. This is definitly making the difference with others 🙂

I thank you again for the time and explainations. I know this is your job, but you're doing it quite greatly. This is definitly making the difference with others

Thanks, that means a lot.

How to clear a "date" license feature from web interface ? A "string" license feature seems more convenient, as I can clear it easily without using the web API ... Anyway.

We're changing the Javascript datetime picker to a better one that actually allows you to clear date/time values. Right now, though you can only do it from the web API.

Hi Wyatt,

Just to let you know someone else would be glad to be able to clear the datetime field from a licence feature. Is there a planned release date for this new picker to be deployed?

Best regards,Alexandre Leclerc

Hey Alexandre,

A quick and dirty short-term roadmap:

1. Android version of TurboActivate & minor bug fix release for other platforms (this week, a couple days away)2. TurboFloat (next week).3. Searching custom license fields in the LimeLM interface (as opposed to being forced to use the web API) & replacing the date/time picker to be sane, usable, and nice looking (the week after next).

So our goal is to have all these things done before May.

Hi Wyatt,

Thank you very much for this short-term roadmap. The comming weeks will be very interesting, feature-side. Keep up the good work!

Best regards,Alexandre Leclerc

Hi Wyatt,

Just wanted to know about the new date/time picker for the Dashboard - it would be very useful for us to be able to clear the field. (Or a quick and dirty "clear" button by the side of the field.)

Best regards,Alexandre Leclerc