Skip to main content

Idea

Floating licenses let you limit how many copies of your application can run at the same time. For example, a company may install your software on 100 computers, but only use 20 copies at once. Unlike node-locked licenses, each running copy needs to keep renewing its seat and must stop licensed work when that seat expires. In the examples below, each application process uses one seat. It generates a random ID at startup and uses it as MachineCode whenever it activates, renews, or releases the seat. Two licensed processes on the same computer use two seats. You can find Docker and Kubernetes examples in Containerized Environments. If you want to count devices instead, you can use a stable machine code. Multiple processes using that same code will then share a seat. Whichever approach you choose, use it consistently throughout the application.
These examples require access to the licensing service. For disconnected deployments, see the License Server guide and its offline floating setup. An ordinary cached license file does not coordinate concurrent seats.

Implementation

In the dashboard

Set Maximum Number of Machines to the seat limit, greater than 0. This enables the activation limit required for floating licensing. Choose the license’s features and expiry policy, and create an application access token with the Activate permission. Add the Deactivate permission to release seats early. Both permissions can be on the same access token.

In your application

Create the random identity outside the renewal loop. Do not persist or reuse it across process restarts, copy it into an image, or generate a fresh ID for each heartbeat. See the process ID examples.

Floating without overdraft

We can reuse the code from the Key Verification tutorial and add FloatingTimeInterval. The examples below use 100 seconds and no overdraft. Replace product ID 3349, the example license key, and the credentials with your own values. Generate machineCode once when the process starts. Repeat the activation request with that same value to renew the seat before the 100 seconds are up. The renewal and release flow below explains the timing.
The examples check for the same process ID used in the activation request, with floating mode enabled. Before enabling licensed features, also apply the other license checks.

Floating with overdraft

Overdraft lets you allow more processes than Maximum Number of Machines would normally permit. For example, MaxOverdraft=1 allows one extra process. The default is 0, so the examples above do not allow extra seats. If you enable overdraft, use the same setting for all processes and allow it in the SDK’s floating-license check (allowOverdraft=true or equivalent). Those extra processes still need to renew their seats. Only enable overdraft if you want to allow the extra seats, including during restarts or rolling updates.
Make both changes in the example for your language:

Notes about the code

FloatingTimeInterval is the recent activation window in seconds; MaxOverdraft is additional allowed capacity. Configure renewal timing in the lifecycle below. A once-daily check is sufficient only if it meets your floating window and enforcement policy.

Tips

Releasing a floating license

Stop licensed work and stop scheduling renewals. Wait for any pending renewal to finish, then call Deactivate with Floating=true and the same process ID. Your access token needs the Deactivate permission; it can also have the Activate permission. The examples below use the same machineCode that was used to acquire the seat. If the process crashes or the release request is lost, the seat stays in use until the floating window expires.

Number of used and free licenses

You can see how many floating seats are in use by setting Metadata=true in the request. In .NET, GetFloatingLicenseInformation reads this information from the response:
C#
These counts are a snapshot; they do not reserve capacity. See crash recovery for when a seat becomes available again.

FAQ

Yes. The examples above show how to acquire a floating seat and check that it belongs to this process. Keep the usual checks from Key Verification when adding floating licensing:
  • Signature: Java and Python verify it during activation. In C# and VB.NET, use HasValidSignature(RSAPubKey).IsValid() with your account’s RSA public key before accepting the license data.
  • Product and license key: check that the returned values match the product and license key you requested.
  • Blocking, expiry, and features: reject data that reports Block=true, check expiry according to your licensing model, and enable only the features included in the license.
Floating licensing also requires Maximum Number of Machines greater than 0, as described in the dashboard setup above. At 0, machine locking is disabled and the floating-seat check does not apply.
A successful floating activation updates the stored floating-device FriendlyName to the value submitted in the request. For example, after registering a machine as Office laptop, another successful floating activation with the same MachineCode and FriendlyName="Renamed laptop" changes that floating-device label.For node-locked activations, calling Activate again with the same machine code leaves the stored name unchanged. If the dashboard still shows the old name, check which activation mode you are using. Changing FriendlyName does not change which device is registered or how many seats it uses; see Activate for details.
Floating seats limit how many application processes can run at once. Usage counters can track things such as reports generated or credits spent. Updating a counter does not renew a seat. If you increase a counter at startup and decrease it on exit, a crash or lost exit request can leave the count too high.
Configure FLOATING_INTERVAL (seconds sent as FloatingTimeInterval) and a shorter RENEWAL_INTERVAL. Allow time for network latency and retries before expiry. Use a consistent floating interval across participating processes. Keep MaxOverdraft=0 unless you deliberately allow extra capacity.
  1. Acquire: call Activate with the process ID and floating interval. Apply the validation checklist, including the floating-identity check, before enabling work.
  2. Renew: reuse that ID before the confirmed deadline. Only a successfully validated renewal can extend the deadline.
  3. Stop: stop licensed work when the confirmed seat expires or a renewal is rejected. The failure table below covers retries and crashes.
  4. Release: stop work and stop scheduling renewals. Wait for any pending renewal to finish, then call Deactivate with the same ID and Floating=true.
The following is language-neutral lifecycle pseudocode, not an SDK API.
Use a conservative deadline: it must be no later than the validity granted by the confirmed activation. For the configured window, measuring from the start of that successful request, rather than from when its response arrives, avoids adding network delay to the allowance. Respect any earlier applicable license expiry or returned seat expiry. Use elapsed-time tracking that accounts for suspension, and revalidate before resuming work after sleep; a timer alone does not establish trustworthy wall-clock time.Enforce the deadline independently of a pending network call, and set request timeouts. Serialize renewals so overlapping requests cannot apply results out of order.
GetKey only reads license information. Neither GetKey nor usage-counter updates acquire or renew a floating seat. A longer offline cache allowance cannot override the floating deadline.