Timed Licenses
What is a timed license?
A timed license is a license that has a fixed-duration, i.e. an expiration date. A timed license can be used to implement a variety of different time-based licensing models:
How do I implement a timed license?
Configuring a timed license type is simple. You will want to create a new Policy
resource, or modify an existing Policy, and set the Policy's duration
attribute
to the expiration timeframe that you would like to apply to any license which implements
the Policy moving forward.
Then, within your software, you will want to integrate the following request flow:
The duration of a Policy is measured in seconds:
Timeframe | Duration in seconds |
---|---|
1 Day | 86400 |
1 Week | 604800 |
2 Weeks | 1209600 |
1 Month | 2629746 |
1 Year | 31556952 |
When a license implements a fixed-duration Policy, the expiration will automatically
be applied based on the Policy's duration
and the license's created
timestamp.
license.expiry = (license.created + policy.duration)
Once a license's expiry
has been reached, subsequent license validations will respond
with an EXPIRED
validation code and the license will be considered invalid. A
license can be renewed at any time using the license's renew action.
Subscription licenses
When it comes to Software as a Service (SaaS) licensing, or other types of licenses with timed, renewable maintenance and servicing contracts, subscriptions are the way.
Subscription licenses can be implemented in a couple different ways. If you have a payment provider, such as Stripe, we recommend tethering the license's expiration date to the subscription period. This can be accomplished using webhooks.
Outside of a payment provider tether, a license's expiration can be extended at any time
using the renew license action. This can be used to automatically renew licenses.
When a license is renewed, its expiry
is extended by the Policy's duration
.
license.expiry += policy.duration
Timed trial licenses
You would implement this just like a regular timed license, except the Policy will likely have a shorter duration, and possibly a different set of entitlements. To determine if a license is a trial license within your software, you can compare the trial Policy's ID to the license's current policy relationship.
For trial licenses, it's recommended to set the Policy's machine uniqueness
strategy to PER_PRODUCT
or PER_POLICY
to ensure that a particular machine
fingerprint cannot be shared across many trial licenses.
To convert a trial license, you can transfer the license to a different Policy.
For trials, here's what we typically suggest:
- Set up a trial policy, with a short duration (whatever you want your trial length
to be e.g. 2 weeks). Add a max machine limit,
e.g. 1 machine per-license during trial. Then also set the policy's fingerprint
uniqueness strategy to
UNIQUE_PER_POLICY
, to prevent duplicate trials for the same machine. - Set up another policy, for paying customers. This one can have a longer duration,
and a higher machine limit if desired. Then also set the policy's transfer strategy
to
RESET_EXPIRY
, so that a license's expiration is reset when a trial converts to paid. - Issue trial license keys in a similar way that you would issue normal license keys, e.g. have the customer enter their email and then send them a trial license key.
- In your software, prompt the user for their license key. If the current device is not already activated, activate it. (Tip: you can check the license's policy ID to determine if it's a trial license.)
- When the customer converts to a paying customer, transfer their existing license to the paid policy.
Doing it this way will do a couple things:
- Help you keep track of trials, understand conversion rates, and also prevent duplicate trials.
- Prevent the customer from needing a new license key when converting from trial to paid.
- Keep their existing machine(s) activated, so they don't have to do it again.
Perpetual fallback licenses
This is a twist on the timed license that has been gaining in popularity over the years. Essentially, it acts as a timed license with perpetual access to product versions released within a license's "validity window." For example, let's take a license model inspired by Jetbrains, where a customer can purchase a 1 year timed license, entitling them to automatic upgrades within their license's 1 year "validity window", i.e. the time between the issue date and expiry date.
But that sounds pretty much like a timed license, right?
Well, mostly — but the twist is that the customer will also be allowed to download (and use) any product version released within their license's 1 year window, even after the license expires. This means that upgrades stop, but they can perpetually use the product versions that were released during their license's validity window.
This is one of the most successful licensing models we've seen for desktop apps, and it has been gaining popularity over the years (and for good reason!)
You can enable a perpetual fallback license by setting the policy's expiration strategy
to MAINTAIN_ACCESS
. Even after expiration, the license will remain "valid", but
upgrades to versions released after the license's expiry will be blocked.
Offline capability
Timed licenses can be configured to be offline-capable. To do so, configure the Policy to utilize a cryptographic signing or encryption scheme, which will allow you to verify the authenticity of license keys in offline environments. You can embed an expiration inside of the license key itself, which can be decoded and utilized offline.
Perpetual License | Timed License | Floating License | Node‑locked License | Feature License | |
---|---|---|---|---|---|
Expiration Date | No | Yes | Optional | Optional | Optional |
Activation Limits | Optional | Optional | > 0 | 1 | Optional |
Feature Limits | Optional | Optional | Optional | Optional | Yes |
Offline Support | Yes | Yes | Yes | Yes | Yes |
Learn More | Learn More | Learn More | Learn More |