License Policies
A license policy acts as a template (blueprint) for the licenses you create for your customers. Before you start creating licenses, you need to create a license policy which would contain the default values for the fields of any license.
While creating a license from any license policy, you can override all the properties of the license policy. License policy provides you with defaults values for all the properties of a license, so you don't have to provide them every time you create a new license.
You can easily create a license policy through dashboard. Go to the license policies section in the dashboard and click the add the button. A license policy form with following fields will popup:
The name of the license policy.
The duration (in seconds) after which the license will expire.
To create a perpetual license set the validity to zero and for subscriptions set it to any value greater than zero.
There are three types of licenses:
Node locked: This is the default type which locks the license to the machine.
Hosted Floating: This type is used for creating a hosted floating license.
On-Premise floating: This type is used for creating an on-premise floating license.
This option is valid for hosted-floating and on-premise-floating license types only. It sets the duration for which you want to lease the floating license.
In case of hosted-floating license type, if you want license lease to auto renew then ensure that the server sync interval is less than lease duration by a difference of atleast 30 seconds.
In case of on-premise license type, lease duration can be set to 0 to honour the lease duration set in LexFloatServer config file.
This option is valid for on-premise-floating and hosted-floating license types only. It allows for following strategies:
Each machine will only consume a single floating license/activation, irrespective of the number of instances (processes) of you app being run on the machine.
Each instance (process) of your app will consume a separate floating license/activation, irrespective of whether the instances are running on the same machine or different machines.
In case of hosted-floating license type, if you want to use per-instance leasing strategy, ensure that the permission flag in LexActivator SetProductId() function is set to LA_IN_MEMORY.
This option is valid for on-premise floating license type only. It sets the maximum number of concurrent clients which can lease the floating license from the server.
For hosted floating licenses, the maximum number of concurrent clients which can lease the license from the server is determined by allowedActivations property
Allowed number of activations (seats) for the license. If you allow (say) 10 activations for a license, then the license can be used on 10 different machines.
Allowed number of deactivations for the license. This setting is ignored for hosted-floating licenses.
Whenever the application starts (and IsProductGenuine() is called first time), the server sync occurs immediately in a separate thread. This setting determines the interval for further server syncs till the application is not closed.
The minimum allowed server sync interval upto STARTUP plan is 3600 seconds, and for higher plans it is 180 seconds. It is highly recommended to set it to 3600 or greater unless required.
The duration for which the server sync failure due to network error is acceptable.
The allowed difference between the network time and the system time. This can be used to allow license activations on machines where system clocks run behind the network time.
The strategy to determine the expiration start date. It allows for following strategies:
The license starts expiring right after the it is created.
The license starts expiring after the license is activated first time. If the license allows more than one activation then all the other activations will also start expiring right after the first activation of the license.
The license starts expiring after the license is activated. If the license allows more than one activation even then all the activations will start expiring after they are activated.
You may not allow license deactivations if rolling expiration strategy is being used, as it would reset the expiry.
LexActivator generates a structured fingerprint of the machine which allows for multiple fingerprint matching strategies. It allows for following strategies:
This strategy requires an exact match of all the hardware parts which were fingerprinted. If there is a minor change in the hardware, fingerprint will not be accepted, and machine will be treated as a different machine.
This strategy uses fuzzy matching by comparing different hardware fingerprints and if the comparison score is greater than a minimum threshold value, the machine is accepted. This is the recommended strategy.
This strategy is similar to fuzzy but with a much lower threshold value.
Sometimes few machines misbehave by reporting major changes in hardware fingerprints due to many issues, in such cases you should change the strategy to "Loose".
List of required metadata keys which a license inheriting the policy must have.
List of the allowed countries. The country name is resolved using the IP address. If none of the countries is included, this setting is ignored.
List of the disallowed countries. The country name is resolved using the IP address. If none of the countries is included, this setting is ignored.
List of the allowed IP addresses. If none of the IP addresses is included, this setting is ignored.
List of the disallowed IP addresses. If none of the IP addresses is included, this setting is ignored.
Whether to allow an activation inside a virtual machine. Cloned virtual machines may report a same fingerprint.
It prevents multiple users inside an OS from using the same license key. If enabled, each user will consume a license activation from the allowed number of activations for a license.
In case you want to enforce user authentication for license activation in addition to license key, you can set this property to true.
