Floating Licenses

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.

How do I implement a floating license?

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:

Diagram of validating and activating a floating license key

  1. Validate the license key along with a fingerprint validation scope
  2. Activate the current machine for the license if not activated
  3. 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: The provided fingerprint does not match the fingerprint for any of the license's currently activated machines
  • NO_MACHINES: 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.

Concerned about activation-deactivation abuse? You can add max activation and deactivation limits to activation tokens. These can be set to values that are considered 'reasonable' for a typical user, e.g. 10 activations and 9 deactivations. Once a limit is reached, a new activation token will need to be generated for the license.

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 validations 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 may wish to allow new seats to be filled even though it may cause the licensee to exceed their seat limit. When an overage occurs, all seats will be considered invalid in 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, i.e. 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.

Have you ever been kicked out of a streaming service for using too many devices at once? Popular streaming services utilize a concurrent per-seat licensing model, employing the same logic as outlined above. Some of them allow overages (concurrency) for up-sell purposes, while others do not allow the user to go over their seat limit.

Licensing cloud applications

Concurrency may also be enabled when licensing cloud applications where rolling deployments are common, which may cause licenses to temporalily exceed their node limit. Rather than deny node activations, the license will temporarily be 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.

Another great feature to look at for licensing cloud-based applications 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."

Check-out/check-in licenses

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:

  1. Set up a heartbeat monitor for the currently activated machine
  2. 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.

Offline capability

By utilizing cryptographically signed license keys and machine activation proofs, you can implement an offline-capable floating license model. Cryptographic license keys and proofs 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 LicenseTimed LicenseFloating LicenseNode‑locked LicenseFeature License
Expiration DateNoYesOptionalOptionalOptional
Activation LimitsOptionalOptional> 01Optional
Feature LimitsOptionalOptionalOptionalOptionalYes
Offline SupportYesYesYesYesYes
Learn MoreLearn MoreLearn MoreLearn More