Floating (Concurrent) Licenses Explained

Years ago I worked with a vendor selling a specialised analysis tool to engineering firms. A customer had 200 engineers but, on any given day, maybe 15 of them actually opened the tool. The customer flatly refused to buy 200 node-locked seats for software 92% of their staff wouldn’t touch that week — and honestly, they were right. The answer wasn’t a discount. It was a different licensing model: sell them 20 floating seats and let the whole firm share them. That one change turned a lost deal into a signed one.

This post explains floating (also called concurrent) licensing properly: what the model actually is, how it differs from node-locked and named-user, how a concurrency ceiling is enforced with check-in/check-out and leases, and — just as important — when not to use it.

Key takeaway: A floating license caps how many copies run at the same time across a shared pool, rather than binding the license to specific machines or people. It trades the offline simplicity of node-locking for a server that counts live sessions — and in return lets a big team share a small number of expensive seats.

The three models, side by side

Every licensing conversation eventually lands on one of three ways to decide who’s allowed to run your software:

• Node-locked — the license is bound to one machine via a hardware fingerprint. That device runs it; nothing else does. Great offline, dead simple to reason about, but it wastes seats when people share hardware or rotate.
• Named-user — the license is bound to a person (an identity), who can typically run it on their own devices. Good when usage tracks individuals, common in SaaS-adjacent desktop tools.
• Floating / concurrent — the license is bound to neither a fixed machine nor a fixed person. Instead you own N simultaneous uses, and anyone in the organisation can grab one while it’s free.

I wrote a fuller taxonomy in software license types explained, and covered the machine-binding mechanics in node-locking and seat management. The one-line summary: node-locking answers “which machines?”, named-user answers “which people?”, and floating answers “how many at once?”.

How a concurrency ceiling actually works

The heart of floating licensing is a check-out / check-in cycle against a server that holds the live count.

1. When your app starts (or when a user invokes a licensed feature), it asks the server for a slot: check out.
2. The server compares held slots against the ceiling. Under the limit, it grants a slot and returns a short-lived token; at the limit, it refuses with a “no seats available” result.
3. When the app closes, it returns the slot: check in. The count drops by one and the next person can proceed.

A naive version of this breaks the first time an app crashes — the slot is never checked in, and it leaks out of the pool forever. The fix every real implementation uses is a lease: the granted slot is valid only for a short window, and the client must renew it periodically to keep it. If the client dies, the renewal stops, the lease expires, and the server reclaims the slot automatically. Leaks self-heal.

In SDK-shaped pseudocode it reads about like this:

// Check out a concurrent slot at startup.
var slot = await license.CheckOutAsync(feature: "analysis");
if (!slot.Granted)
{
    // Ceiling reached — fail closed, tell the user to try again shortly.
    ShowMessage(slot.Message); // e.g. "All 20 concurrent seats are in use."
    return;
}

// Keep the slot alive while the app runs; the SDK renews the lease for you.
// On exit, return it to the pool.
await license.CheckInAsync(slot);

Notice the failure path unlocks nothing. Like every license check, a floating check-out should fail closed — a refused slot, an unreachable server, or an expired lease all resolve to unlicensed, never to a silent unlock. I go deeper on that principle in offline license validation explained.

Concurrency needs a server — and that’s the trade

You cannot count concurrent usage on the client. A single machine has no idea how many other machines in the organisation are holding a slot right now; that’s shared, real-time state, and shared state lives on a server. This is the same reason seat caps and revocation need a server, just turned up a notch: seats are counted at activation time and change slowly, whereas concurrency is counted continuously and changes second to second.

The practical consequence: pure offline floating licensing is a contradiction. You can soften the dependency — cache a lease so a brief network blip doesn’t kill an in-progress session, add a grace window so an outage doesn’t yank the tool out from under someone mid-task — but the ceiling itself is only real while the server is reachable. That’s the honest cost of the model, and it’s why floating suits connected corporate environments far better than air-gapped ones.

Active-device ceilings: floating’s easier cousin

Full session-level check-in/check-out is the strictest form of concurrency, and it’s more machinery than most products need. A lighter variant covers a lot of real cases: cap the number of active devices rather than simultaneous sessions.

Here, each machine activates against the server and holds an activation until it’s explicitly deactivated (or its lease lapses). You allow up to N active devices at once; a device that’s retired frees its slot for another. It’s not true “who’s running it this second” concurrency — it’s “how many machines currently hold a live activation” — but it delivers most of the business value with far less client complexity, and it degrades gracefully offline because a device keeps its already-granted slot without a live connection. If your goal is “a team of 50 should share 20 installs,” an active-device ceiling is often the right, pragmatic choice.

When to reach for floating — and when not to

Floating is a specialist tool. Reach for it when:

• The software is expensive and used occasionally by a large group — concurrent demand is a fraction of headcount. This is the whole reason CAD, EDA, and heavy engineering/analysis tools have used floating licensing for decades.
• Your customers work in a connected environment where a licensing server (yours or theirs) is reliably reachable.
• Buyers explicitly ask to “share seats across the team” instead of assigning them.

Skip it when:

• Usage is roughly one user, all day — then you’re maintaining a session-counting server for a benefit you never realise, and plain per-seat node-locking is simpler and cheaper to run.
• You need to work air-gapped or offline-first — concurrency can’t be enforced without a live count. For those deployments, node-locked seats plus signed offline files are the right pairing.
• Your price point is low enough that the operational overhead of concurrency management costs more than the seats it saves.

Be honest about the limits

Two caveats worth stating plainly. First, like any client-side gate, the check-out call runs on the user’s machine and can be patched out by a determined attacker with a decompiler — which is why the ceiling is enforced on a server they don’t control, and why you pair the client with obfuscation (see protecting your licensing checks). Second, floating licensing can frustrate legitimate users when the ceiling is set too low: nobody enjoys “all seats in use” at 9 a.m. Size the pool to real peak concurrency, not to average, and give admins visibility into who’s holding slots.

Doing this with Keyright

Keyright is the licensing infrastructure we build at Delta1 Labs, and it enforces the counting half of all this server-side so you don’t build it. You model a product with a seat or active-device ceiling, embed the SDK (.NET, Node, Python or Java), and let activations, leases and self-service deactivation handle the pool — with a short-lived signed lease that keeps users working through a brief outage and reclaims slots automatically when a client goes away. Concurrency is a shared, stateful decision, and that’s exactly the part Keyright runs for you, whether on our managed cloud or self-hosted inside your network.

The free plan is enough to wire real seat enforcement end to end before you pay anything — start free, or read the .NET integration guide for the exact activation surface.