Software license types explained: perpetual, subscription, floating, trial

Software license types are the models that define how a customer is allowed to use your software: perpetual (buy once, use forever), subscription/term (valid for a fixed period), floating/concurrent (a shared pool of seats), node-locked (bound to one machine), trial/evaluation (time-limited access), and volume/site (many seats or a whole organization under one agreement). Most products combine several. This reference explains each one, when to use it, its trade-offs, and how it maps to what a modern licensing system enforces.

Comparison at a glance

Model	What it grants	Best for	Main trade-off
Perpetual	Use forever, one purchase	Buyers who dislike recurring fees; on-prem tools	No recurring revenue; needs a separate maintenance window for updates
Subscription / term	Use for a fixed period (e.g. 1 year)	Most modern software; SaaS and cloud tools	Customer loses access if they stop paying; needs expiry + renewal logic
Floating / concurrent	Shared pool; N active at once	Teams sharing licenses across many users	Requires a server to track who is active in real time
Node-locked	Bound to one machine	Fixed installs, per-device pricing, air-gapped sites	Hardware changes can lock users out without tolerance
Trial / evaluation	Full features for N days	Driving conversion; letting buyers self-serve	Must auto-expire and resist abuse (one per customer)
Volume / site	Many seats or a whole org	Enterprise and education deals	Pricing and fulfillment complexity; needs bulk operations

Perpetual licensing

A perpetual license is bought once and runs forever — there is no expiry. It’s the model buyers like most, because they own what they paid for, and it’s common for on-premise and developer tools.

The catch is updates. A perpetual license usually pairs with a support-and-maintenance window: a period (often a year) during which the customer is entitled to new versions and support. When that window lapses, the installed software keeps working, but the customer must renew maintenance to get further updates. This lets you sell perpetual licenses without giving away every future release for a single payment.

Use it when your buyers strongly prefer one-time purchases, or you sell a tool that must keep running unchanged for years. The trade-off is no recurring revenue and the need to manage a maintenance window separately from the license itself.

Subscription / term licensing

A subscription (or term) license is valid only for a fixed period — typically annual — and carries an expiry the app enforces. When it lapses without renewal, the paid features lock. This is the default for most modern software because it ties revenue to ongoing value and funds continuous development.

Use it when you ship regular updates or run any kind of service. The trade-offs are that you now need reliable expiry enforcement (including defense against a customer rolling the system clock back to extend a trial or term) and a smooth renewal path that extends the existing license rather than re-issuing a new key.

Floating / concurrent licensing

A floating (concurrent) license is a shared pool: an organization buys, say, ten seats, and any ten machines can be active at once. When a user finishes, their seat returns to the pool for someone else. It maximizes value for teams where far more people could use the software than ever use it at the same time.

Use it when you sell to organizations that share access across shifts, labs, or large teams. The trade-off is that true concurrency requires a server tracking active sessions in real time — the most infrastructure-heavy model. A common, simpler middle ground is seat-based licensing: a fixed number of activations, each bound to a machine, with the ability to release or transfer a seat when a device is retired. That gives teams flexibility without a live concurrency broker.

Node-locked licensing

A node-locked license is bound to a specific machine through a hardware fingerprint derived from stable device and OS attributes. It only works on that machine, which stops one license from being copied across an organization.

Use it when you price per device, ship to fixed installs, or serve air-gapped and high-security environments where per-machine control matters. The trade-off is tolerance: fingerprint too strictly and a customer who swaps a network card or upgrades a disk gets locked out; too loosely and the lock is meaningless. A good implementation allows a small amount of hardware drift and lets you control which components identify a machine for VMs and CI.

Trial / evaluation licensing

A trial is a time-limited license that unlocks the full paid experience for a set number of days, then expires. It’s the most effective conversion tool you have, because it lets a buyer prove value before paying.

Use it when your software’s value is best demonstrated hands-on. The trade-offs are abuse prevention and expiry: a trial should be one per customer per product, idempotent so a refresh or a second click never resets the clock, auto-expiring, and ideally able to convert to a paid license with no reinstall. Air-gapped evaluators may need a signed offline trial file instead of an online activation.

Volume / site licensing

Volume and site licenses cover large deployments under one agreement. A volume license is really about issuing many keys efficiently — in bulk, or automatically through your store’s fulfillment — while a site license is typically a single license with a very high seat count that covers an entire organization or location.

Use it when you close enterprise or education deals. The trade-off is operational: you need bulk issuance and management (bulk seat changes, bulk revocation, reporting) and clear terms for how the seats are counted.

How these map to Keyright

Keyright supports these models directly rather than forcing you into one:

• Perpetual and term — issue a license with no expiry for perpetual, or set an expiry for subscription/term. Perpetual licenses aren’t subject to the clock-tamper check that protects time-limited ones.
• Node-locked seats — bind each seat to a machine fingerprint with configurable tolerance, enforce the seat count server-side, and let customers release or transfer a seat when they change devices — the practical, seat-based take on floating.
• Entitlements and tiers — define per-tier feature flags and numeric limits so one binary unlocks different capabilities per plan, and change what a plan includes without shipping new code.
• Trials — turn on self-service trials per product, one-per-email and idempotent, that activate through the exact same path as a paid key and convert seamlessly.
• Volume / site — issue keys via the admin API or automatic store fulfillment, manage them in bulk (bulk seat changes and bulk revocation), or cover an org with a single high-seat license.
• Revocation — kill a refunded or leaked key in one click; it reaches online clients on the next refresh and offline clients through a signed revocation list.

Every license and lease is signed with your tenant’s own RSA key and verified offline by the SDK, so all of the above works air-gapped and fails closed by design. See the full capability list on the Keyright features page, or read the Keyright documentation to wire up the model that fits how you sell.