What is a floating license?
A floating license is a license that is only allowed to be used on a set number of devices (referred to as machines). Think of it as a node-locked license, but with many seats — the license is still locked to a machine, but instead of being locked to a single machine, it can be locked to many.
In a floating license environment, licenses are activated on a first come, first served basis. Activations can be short-lived or long-lived, there are no life time requirements. Activated machines can be deactivated at any time to free up activation slots for other machines.
- Floating "per-seat" license model
- Licensing applications in virtual environments
- Licensing software in cloud environments
- Check-out/check-in license model
- Licensing by CPU core count
- Licensing by process count
How do I implement a floating license?
Keygen is a full-fledged activation licensing service. To configure a floating license model, you will want to create a new Policy resource, or modify an existing Policy, and enable floating on the policy, as well as set a maximum machine limit that is greater than 1. You may also wish to set the Policy to strict, which is explained below.
Then, within your software, you will want to integrate the following request flow:
- Validate the license key along with a fingerprint validation scope
- Activate the current machine for the license if not activated
- Revalidate the license key after activation (optional)
When you validate the license in step 1, the response data will contain the full license object, including the license's ID, which can be used for subsequent activation requests. Step 2 will only need to be performed if one the following validation codes are received:
FINGERPRINT_SCOPE_MISMATCH: Not activated. The provided fingerprint does not match the fingerprint for any of the license's currently activated machines.
NO_MACHINES: Not activated. The license has no machine activations.
To ensure that every license validation request is scoped to a machine fingerprint, you can configure your Policy to require a fingerprint scope.
Strict vs non-strict
Setting the Policy to strict will require that each license has at least 1 machine activation to be considered valid. A non-strict license will not take machine activations into account when validating a license, unless a specific scope is provided during the license validation request. We recommend setting your Policy to strict to ensure that all usage is accounted for.
Concurrent vs non-concurrent
Enabling concurrency on the Policy will allow more machine activations than the maximum machine
limit, but the license will become invalid when the activation limit is exceeded. When a concurrent
license exceeds its maximum machine limit, subsequent validation requests will respond with a
TOO_MANY_MACHINES validation code, until the license deactivates enough machines to return to
a valid state.
A non-concurrent license will allow machine activations up to the maximum limit as defined for the license, and an API error will be returned when an activation request attempts to exceed that limit.
It's worth noting that all "floating" licenses allow for "concurrent" usage across the license's
activated machines. The policy's
concurrent attribute may have been better named "allow
machine overages", which is what it actually does. The attribute was originally added for
node-locked licenses, which may make more sense semantically, but it's useful for some
floating license scenarios as well, as outlined here.
We apologize for any confusion this may cause. Naming things is hard, and maintaining API backwards compatiblity makes changing bad naming choices rather challenging.
Floating "per-seat" license model
Concurrency is particularly useful for a "per-seat" license model, where you bill your customers based on a maximum number of available license seats. You (and your customers) may wish to allow seats to be filled even though it may cause the licensee to exceed their seat limit. When an overage like that occurs, all seats will be considered invalid on subsequent validations until the overage is resolved, or until the license is transfered to a policy with a higher seat limit.
In this scenario, paying attention to the license validation code that occurs during an overage,
TOO_MANY_MACHINES, may offer a good opportunity to automatically up-sell your customer to a
higher seat limit, allowing all concurrent users to remain activated. You can upgrade a license by
transferring it to a policy with higher limits.
Licensing virtual machines
Since virtual machines and containerized environments can share underlying hardware identifiers, using identifiers such as a HDD or CPU ID for a machine fingerprint is not advisable, since that could result in multiple VMs having the same fingerprint, which is undesirable. Instead, we recommend generating a secure random UUID as a fingerprint each time the application boots inside of a virtual environment.
The typical flow would look like this:
- App boot: generate a UUID fingerprint, activate the current VM.
- App exit: deactivate the current VM.
Now, if software was perfect, this would work perfectly. Unfortunately, software is not perfect. We also can't predict environmental problems as well, such as loss of power. If the app or device suddenly crashed, our machine deactivation procedure could fail, resulting in a crashed machine now taking up an activation slot. If a customer had hundreds of activations, all identified by a random UUID fingerprint, this could be hard to manually resolve.
Fortunately, we have a solution for this. Monitoring machine heartbeats can help automate deactivation of crashed or unresponsive nodes, which would otherwise remain active and be considered a "zombie activation."
So, in addition to the flow outlined above, we also recommend using a heartbeat monitor during normal app use. You can define how long the heartbeat interval is, depending on your requirements. The default is 10 minutes.
Licensing cloud and SaaS applications
When licensing cloud applications where rolling deployments are common, which may cause licenses
to temporalily exceed their node limit, we recommend allowing machine overages (i.e. enabling
concurrent on the policy).
Rather than deny new node activations, the license will temporarily become invalid, until the rolling
deployment is complete and the previous deployment's nodes are decommissioned. License validations
during the overage will return validation code
TOO_MANY_MACHINES, which can be uniquely handled
in your application code.
Similarly to licensing VMs, a great feature to look at for licensing cloud-based apps is machine heartbeat monitoring. Monitoring machine heartbeats can help automate deactivation of crashed or unresponsive nodes, which would otherwise remain active and be considered a "zombie activation."
Achieving a check-out/check-in, or "leasing", license model with Keygen requires that your application follow the typical machine activation flow above, in addition to a couple additional steps:
- Set up a heartbeat monitor for the currently activated machine
- Deactivate the machine when your application exits
The heartbeat monitor will catch any instances where your application or the host machine crashes without deactivating the machine. Any machine that doesn’t send a heartbeat ping within the allotted timeframe will automatically be deactivated. This will prevent “zombie machines” from sticking around, freeing up that activation slot for another machine.
This flow would achieve that "classic" check-out/check-in (lease) floating license model.
In this flow, since activations are short-lived — that is, machines are only 'activated' while your application is running and deactivated when the application exits — a machine’s fingerprint value could simply be an in-memory UUID, generated each time the application starts. No need to 'fingerprint' the device’s actual hardware.
This may help simplify your integration, and also allow your application to uniquely identify and activate virtual machines or cloud-based environments which may actually share underlying hardware identifiers.
Licensing by CPU core count
You can configure a Policy to enforce a maximum CPU core count. This is great for CPU-intensive applications, where you want to segment licenses by CPU core count. CPU cores are counted as the sum of all CPU cores across a license's machine activations. Any machine activation that exceeds the license's CPU core limit will be rejected with a detailed API error.
Licensing by process count
You can configure a Policy to enforce a maximum Process count. This is especially useful when you want to control application or instance concurrency for each machine. For example, you could configure your policy to allow 5 machines with 5 processes per-machine.
By utilizing cryptographically signed license keys and license files, you can implement an offline-capable floating license model. Cryptographic license keys and files can be distributed to air-gapped environments in a variety of ways: email, license file, USB key, on-premise license server, or through the use of QR codes.
|Perpetual License||Timed License||Floating License||Node‑locked License||Feature License|
|Activation Limits||Optional||Optional||> 0||1||Optional|
|Learn More||Learn More||Learn More||Learn More|