Our advice is to always start with a simple licensing approach and then layer on advanced licensing capabilities. Many of these software licensing models can be used in conjunction with each other to build complex licensing models.
Find example code in your coding language of choice: SDKs | Licensing REST API
One thing to understand first: Lease period for a license
For most licensing models (other than passive licensing) described below, you will set a lease period timer (e.g. 12 hours) to define how frequently an end user’s application should call back to the licensing server to refresh the details of the license. This is how Zentitle does "dynamic licensing", which allows you to make changes to a customer’s license from your Zentitle dashboard (or programmatically using our REST API) and know that those changes will propagate down to your end user. For example, giving access to a new feature or elongating their maintenance end date.
You will always check the license status before allowing your app to start. The status will tell you if a license is past the refresh interval; the application should not start until the refresh has taken place.
How it works:
check_license_status {
if (license is valid AND lease period remaining > 0 seconds) // you define the interval in Zentitle
{
(allow application to start)
else
(refresh the license license details from the cloud and then try again)
}
}
Depending on the application, you might decide that just checking the license status at startup is good enough. Or, you might check license status at appropriate code junctures, e.g. at the beginning of code sections under control of a feature. It is up to you to decide the optimal lease period for your app, and how rigidly it should be enforced.
Note: Setting lease period as "0" means the lease won't expire. This is not recommended.
You can read more about this here: Dynamic entitlements via API driven cloud
Perpetual licensing
Perpetual licenses have lifetime validity, the "buy then use forever" approach.
How it works:
if (a perpetual license is stored in the secure cache)
{
(allow application to start)
else
(prompt user for license code, then obtain license details from the cloud)
}
How to implement: Integration guide (the integration guide walks you through basic license activation / deactivation for Perpetual, Subscription, and Expiry Date licensing)
Subscription licensing
Subscription licenses expire after a certain amount of time. Your customers would usually pay a monthly or a yearly subscription fee and, when they renew, the license would also renew.
How it works:
if (the license type is subscription and it isn’t expired)
{
(allow application to start)
else
(prevent application start and probably prompt the user to renew)
// you could use custom fields (see below) to add a grace period to give them time to renew before shutting off access
}
How to implement: Integration guide (the integration guide walks you through basic license activation / deactivation for Perpetual, Subscription, and Expiry Date licensing)
Trial periods
Zentitle offers a native trial feature which does not require the user to have a license code. It is basically a ticking clock; when it reaches zero, the user would be prompted to enter a valid license code to continue using your product (or a valid username/password if you use account-based licensing).
How it works:
if (user has started a trial AND days remaining > 0) // we track the time for you
{
(allow use of the product)
else
(prevent access and prompt user to enter a valid license code)
}
How to implement: Integration guide (the integration guide walks you through basic license activation / deactivation for Perpetual, Subscription, and Expiry Date licensing)
Concurrent/Floating licenses - check out/return seats of a license
A concurrent license (or floating license) allows a customer to have a set number of “seats” to use. For example, if you issue a 50-seat concurrent license to a customer, up to 50 of their users can use that license at any given time - when your application shuts down on one device, it should return its seat so that someone else can use it. If it doesn't return the seat at shutdown, and its lease period expires, the server may hand the seat to another user if no other seats are available.
How it works:
if (the license type is concurrent and there is at least 1 available seat)
{
(check out 1 seat, allow application to start);
else
(prevent application start and show user error e.g. “no seat available”)
}
How to implement: Concurrent licensing
For end-users on restricted networks with limited outside access ("dark networks") who require network license models such as concurrent licensing, floating features, or element pools, read about our LAN Daemon.
Feature-based licensing: Activate/deactivate features
You can control which features different customers have access to. Many customers like to define plans - e.g. for Basic, Better, Best - that have different features enabled or disabled (we call these Code Profiles).
How it works:
if (user tries to access this feature)
{
if (their license contains rights to this feature)
{
(allow them to use the feature)
else
(prevent access to this feature)
}
}
How to implement: Activating / deactivating features based on license
Feature-based licensing: Floating features - check out/return seats of a specific feature
Similar to how a floating license allows you to limit the number of devices that can use a license at the same time (concurrently), a floating feature allows you to limit the number of devices that can use a certain feature at the same time on a license.
For example, you might have a customer with 10 users who are using copies of your software; you can put in a restriction that only a maximum of 3 of them can use a certain feature at once.
How it works:
if (user tries to access this feature)
{
if (their license contains rights to this feature AND there is an available seat for this feature)
{
(check-out a seat against this feature and allow them to use the feature)
else
(prevent access to this feature and indicate e.g. “there are no seats currently available for this feature”)
}
}
How to implement: Floating feature licensing
For end-users on restricted networks with limited outside access ("dark networks") who require network license models such as concurrent licensing, floating features, or element pools, read about our LAN Daemon.
Consumption licensing - metered usage, i.e. pay-per-use models
Consumption-based licensing is a metered model that enables you to track how much of a measurable thing a license uses in a certain time frame. Thus unlocks pay-per-use models.
For example:
- Server infrastructure: Charge by bandwidth used or users logged on.
- 3D printers: Charge by printer time-in-use and/or material used.
- Dog-walker app: Charge by how many miles, how many dogs, and size of dogs walked.
Consumption licensing can be used in conjunction with subscription licensing so that usage limits apply within a subscription period. If you wish you can then charge at that point for extra usage, or bill for any extra usage when the subscription period ends.
How it works:
if (user uses a feature with consumption tracking)
{
(+1 to that consumption meter)
// we call these “consumption tokens”
// add whatever increment you want
// you can reset the consumption meter on any schedule, e.g. after a monthly billing cycle
}
How to implement: Consumption tokens
Element Pool licensing - sharing a limited resource
Element pools allow you to define the maximum quantity of a resource that is allowed to be used at any given time. Users check-out quantities from the pool to use and then return that quantity when done.
For example, if your software is run on 10 graphics workstations, and for final animation rendering the workstations have access to a total of 100 processing cores to render the frames Element Pools lets any of the 10 workstations have access to as many cores as they’d like, but the total cores used by all machines together at any one time cannot exceed 100.
How it works:
if (user tries to use a feature with element pool tracking)
{
if (there is sufficient available quantity of the element pool)
{
(allow access of the feature AND check-out a certain code quantity from the pool)
else
(prevent access and show message e.g. “users on this license are currently using the maximum permitted quantity of this thing“)
}
}
How to implement: Element pools
For end-users on restricted networks with limited outside access ("dark networks") who require network license models such as concurrent licensing, floating features, or element pools, read about our LAN Daemon.
Using custom parameters to fine-tune your licensing
We allow you to create custom fields (called Total Application Agility fields) that are essentially key-value pairs that you can use to fine-tune your licenses.
For example, you could define these fields (you can set default values for custom fields and modify them for each individual license):
- “GracePeriodDays=10” → you can use this field to notify users that their renewal is overdue, and gives them 10 more days to renew before shutting down access
- “MaxVersion=2.1” → you can use this to limit the version a customer can get
- “CustomerName=Boeing” → you can use this on a splash screen to welcome users with their company name
How to implement: Total Application Agility (custom fields) licensing
Account based licensing (ABL) - email/password instead of license codes
Instead of your end users entering a license code to activate your product, they can use a username and password. This is a better experience for your end users because it’s easy for them to remember their login details.
Even more powerfully, you can allow your end users to activate/login to your product using SSO (Single Sign On) to identity providers like Okta and Auth0 or using social identities like Google and Facebook.
ABL is usually paired with our End User Portal, which is how your customers can see and manage their own licenses. This allows you to create an environment like Office365 of Adobe Creative Cloud wherein your users can login to the portal using their username / password and see all the products they have access to.
How to implement: Account-based licensing
Offline Licensing: Offline Activation / Deactivation
For end-user environments that do not have Internet access to activate a license, our library can generate a “license activation request certificate” that the user can put on a USB key and bring to an Internet connected device, where they can go to our offline activation webpage (which we host for you) and paste the activation request certificate. This then communicates with the Zentitle licensing server, which activates a seat against that license and generates a “license unlock certificate“ that the user puts back on the USB key, brings to the disconnected device, and uses to activate your product.
How it works:
if (license is valid and user activation type is off-line)
{
(Allow the user to use the product)
// For offline activations, you will define a separate - usually longer - lease period at the end of which the application would need a refresh of the license
// We also offer Long Term Check Out to allow even longer but not indefinite offline use
}
Similarly, we also have an off-line deactivation process wherein our library can generate a license deactivation certificate, which the person can put on a USB key.
How to implement: Offline Activation / Deactivation
Offline Licensing: Passive Licensing
Passive licensing is a classic certificate-style approach. You use your Zentitle dashboard to generate a certificate that is tied to a hardware ID of your choosing, and send it to your customer (you can also do this programmatically with our REST API, of course).
It is for your customers who have no internet connection and where physical access to the machine is difficult or impossible (e.g. IoT or embedded systems).
Passive licensing requires the passive licensing library (PSL) rather than our standard library (NSL).
How it works:
if (a passive license is stored on the machine)
{
(allow application to start)
else
(prevent access)
}
}
How to implement: Passive licensing
Long Term Check Out (LTCO)
Long Term Check Out (LTCO) is for end-users who require the ability to use your product for long, but not indefinite, periods of time without having to refresh the license from the Zentitle licensing server. The user may then be completely offline during this time interval.
How to implement: Long Term Check Out