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.

• 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:

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: 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 license model

All floating licenses support concurrency. You may adjust overage allowances using the policy's overage strategy, which 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 transferred 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. 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.

Here's an example implementation written in Python, as well as an example in Node.

Licensing cloud and SaaS applications

When licensing cloud applications where rolling deployments are common, which may cause licenses to temporarily exceed their node limit, we recommend allowing machine overages (i.e. setting an overage strategy on the policy to something like ALLOW_2X_OVERAGE).

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."

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.

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.

Offline capability

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.