Individual lease duration for clients

Floating Licenses
#1

Hi,

is there any way to let clients borrow a hosted floating license for a duration other than the one specified in the license policy?

Background: In our scenario users lease floating licenses from the same license pool either:

  1. for a short period of time (some hours) during which they typically remain online or

  2. for an extended period of time (some weeks) during which they will not have a connection to the license server.

In case 2. we’d like to give our users the choice to select a date until which their license will be borrowed.

Setting the lease duration in the license policy to some expected maximum, let’s say eight weeks, by default seems like overkill and will most likely result in many zombie licenses as we’d have to rely on our users to return their licenses if they don’t need them for the whole lease duration. Also, the impact of failing to return the short term licenses properly will be amplified.

If this is not possible, is there some clever workaround?

Thanks!

#2

Hi,

You can override the value of lease duration while creating the license. For your usecase I would recommend creating two separate keys. One should be used for short uses and other for borrowing.

#3

Hi,

in your proposed solution, how would I make sure both keys use up activations from the same pool, so customers don’t exceed their total number of activations?

Thanks!

#4

Instead of allowing 10 activations in one license, create two licenses one allowing say 6 activations and other allowing 4 activations

#5

Oh, that is kind of a bummer. I would very much like to suggest as a feature, that one can override the default lease duration using LexActivator/LexFloatingClient up to a maximum duration defined by the license. FlexNet does support this, so I assumed the documentation stating Borrowing floating licenses for offline usage is supported out of the box. meant exactly that.

Quick follow up: On the client, can I somehow retrieve the date/time until which the license is borrowed? Or the lease duration? GetLicenseExpiryDate and GetServerSyncGracePeriodExpiryDate seem not to serve that purpose.

#6

This is useful feature request, we will see the feasibility of implementation and get back to you. Adding functions to get the lease expiration will also be a useful addition.

#7

Thank you, that sounds great! In the meantime, I’ll try to get a slightly modified version of your suggestion up and running. I might also try to somewhat misuse metadata to make the lease duration available to the client for now.

#8

Hi,

We have added SetActivationLeaseDuration() function to allow this use case. You will be required to enable “Allow Client Lease Duration” option for the license wherein you want to allow this behaviour.

#9

Thank you, this is great news! We will incorporate this in our products asap.

#10

Hi,

this is working as expected using a hosted floating license with LexActivator which is great.

I can also create an on prem floating license with “Allow Client Lease Duration” enabled. But in LexFloatClient (C/C++ libraries) there is no way to set an individual lease duration. Why is that?

Best

#11

Hi,

Consider a scenario wherein an end-user sets a very high lease duration (say 30 days) and exits the app. This makes the floating client activation zombie up to 30 days and there is no way to delete this activation.

In the case of hosted-floating licenses the activation can be removed from the dashboard but in case of LexFloatServer it is not allowed to prevent abuse.

Regards,
Adnan

#12

Hi,

I see how this scenario would be problematic. That’s why I suggested to allow for an individual lease duration up to a maximum duration defined by the license.

Actually, I think it is the other way around: consider a scenario where users (at times) need to borrow a license for those 30 days. At the moment the only solution to this would be to globally set the lease duration to 30 days and count on those users who need a shorter lease duration (say 15 minutes) to return their licenses properly. This in turn would increase the risk of zombie licenses dramatically, right?

Best regards

#13

The floating clients don’t use device fingerprinting and the data is not persisted on disk by floating client. This would first require adding support for persisting the activation data on disk in case of LexFloatClient.

Next, it will require adding device fingerprinting support in LexFloatClient to prevents users from simply copying the locally saved activated data to another machine.

So, this has some high dev effort, It is on the roadmap but will take some time.

#14

Ok, thank you for giving me some background to the technical challenges. Still, I would greatly appreciate it, if this got implemented in the near future.

Best