Seat-Based Licensing Explained

Seat-based licensing prices and entitles software by the number of users, not by the number of copies or devices. A buyer acquires a right to use the product for a specific number of people, and the licensing system counts and enforces that number. This page explains what a seat is, how named and floating models differ, and how enforcement works when the app needs to run without a network connection.

What a seat is

A seat is an entitlement for one user to use a piece of software. It is distinct from a copy (a binary installed somewhere) and from a device (a physical machine). One user might run the app on a laptop and a desktop — that is still one user, potentially two devices. One device might be shared by several users in shifts — that is multiple users, one device.

A five-seat license means up to five users may use the software. The licensing system’s job is to count those users and stop a sixth from activating. How it identifies users — by account, by machine, by something else — is an implementation choice that sits underneath the seat model, not part of its definition.

Named seats vs floating seats

A named seat is assigned to a specific person. Seat one belongs to Alice, seat two to Bob. Once assigned, that seat cannot be used by anyone else until it is explicitly transferred. Named seats are straightforward to administer and to enforce: you know who holds every seat, and a seat cannot drift.

A floating seat (sometimes called a concurrent seat) comes from a shared pool. Any user can claim a free seat when they launch the app and release it when they close it. A ten-seat floating license can serve a team of thirty as long as no more than ten are using the software at once. Floating seats get more usage out of a license for teams with uneven patterns of work, but they require the licensing system to track active sessions and time out stale ones.

Most independent and desktop applications do not run per-user accounts at all. They approximate named seats by binding a seat to a device: one device, one seat. The user is identified by their machine rather than by a login.

How seats are counted and enforced

A seat needs a countable identity. In a system with user accounts, that identity is an account. In a system without accounts, it is typically a device fingerprint — a stable identifier derived from the machine.

Enforcement happens in two stages. The first time a user claims a seat — on a new device or under a new account — the app makes an online activation call to the licensing server. The server checks the current seat count against the license’s limit. If a seat is available, it records the new identity and confirms; if the limit is already reached, it rejects the request. That single transaction is the authoritative count.

After that initial check, the app does not need a network call for every launch. The signed lease the server returns confirms the entitlement — product, plan, expiry, and features — and the app verifies its signature locally on every launch, so the licensed state holds offline. The seat count itself stays on the server, which remains the source of truth; claiming or releasing a seat is always an online step. The signed lease stays valid across launches until the app’s next scheduled online revalidation.

Seats, devices, and the activation limit

For a desktop app without per-user accounts, the practical mechanism for counting seats is the device activation limit. Each license carries an activationLimit — a number that says how many devices this key may run on. A five-seat license is an activationLimit of five.

This works well for the common case: one user, one or two machines. It is worth being accurate about the edges, though. The activation limit counts devices, not people. A user who runs the app on a work laptop and a home Mac uses two activation slots, not one. If your product is priced per user and sold to people who own multiple machines, sizing the limit generously — or selling per-device explicitly — avoids friction for honest buyers.

The flip side is also true: two employees sharing one machine consume one slot, not two. For most independent app businesses, the device-as-seat model is a practical simplification that aligns closely enough with user intent.

Read more about how the device count is recorded and verified in device activations and how an app activation system works.

Doing it with Keylight

Keylight enforces seats through the activation limit set per license tier. When you create a product in Keylight, you choose an activationLimit for each tier — personal, team, or any other grouping you define. A customer who purchases a five-seat tier receives a signed key with activationLimit: 5. The Keylight server enforces that limit on every activation attempt.

Customers manage their own activated devices through Keylight’s customer portal. When someone replaces a machine or hits their limit, they deactivate an old device themselves — no support ticket needed, and the freed slot is immediately available.

The signed lease that Keylight issues after a customer enters their license key and activates lets the app verify the license offline on every launch. The seat count and limit live on the server: you see how many seats a license is using from the Keylight dashboard, and customers free a seat by deactivating a device themselves. For larger purchases — a team buying ten seats or an organisation buying in bulk — see team licensing and volume licensing.

import KeylightSDK

// Activate a customer-entered key on this device
await licensing.activate(key: enteredKey)

switch licensing.state {
case .licensed:
    enablePaidFeatures()
case .invalid:
    // activationError carries the reason — e.g. activation limit reached
    showActivationError(licensing.activationError)
default:
    break
}

If the activation limit is already reached, the server rejects the request and the SDK surfaces the reason through activationError, so the app can prompt the customer to deactivate an old device or upgrade to a higher tier. Pricing starts at $19/month with a free tier to test the complete flow before going live.