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 asMachineCode 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 addFloatingTimeInterval. 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.
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.
Allowing One Extra Seat
Allowing One Extra Seat
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 withFloating=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 settingMetadata=true in the request. In .NET, GetFloatingLicenseInformation reads this information from the response:
C#
FAQ
Do I Need Other License Checks?
Do I Need Other License Checks?
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.
0, machine locking is disabled and the floating-seat check does not apply.Why Does Changing Friendly Name Not Update the Dashboard?
Why Does Changing Friendly Name Not Update the Dashboard?
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.Should I Use Floating Seats or Usage Counters?
Should I Use Floating Seats or Usage Counters?
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.
How Should a Process Acquire, Renew, and Release a Seat?
How Should a Process Acquire, Renew, and Release a Seat?
Configure
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.
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.- Acquire: call Activate with the process ID and floating interval. Apply the validation checklist, including the floating-identity check, before enabling work.
- Renew: reuse that ID before the confirmed deadline. Only a successfully validated renewal can extend the deadline.
- Stop: stop licensed work when the confirmed seat expires or a renewal is rejected. The failure table below covers retries and crashes.
- Release: stop work and stop scheduling renewals. Wait for any pending renewal to finish, then call Deactivate with the same ID and
Floating=true.
Full Floating-Seat Lifecycle
Full Floating-Seat Lifecycle
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.
What Happens After a Crash or Failed Renewal?
What Happens After a Crash or Failed Renewal?