Software licensing models explained: perpetual, subscription, node-locked, floating and more

You have a working desktop tool and a few people asking to buy it. Before you can put a price on the product page, you have to answer a question that sounds simple: what exactly is the customer buying? Access forever or for a month? On one computer or on any computer, one at a time? Every feature or only the basic ones? The answer is your licensing model, and it shapes your revenue, your support load and how much work your licensing server has to do.

This guide walks through the commercial software licensing models developers actually sell with: perpetual, subscription, time-limited and lifetime keys, trials, node-locked, floating, seat-based, feature-based and usage-based licenses. It compares them in one table, says which fit desktop tools, plugins and gaming tools, and explains how to enforce each one with checks on the server rather than in the client.

What is a software licensing model?

A software licensing model is the set of rules that defines how a customer may use the software they paid for: for how long, on which machines, by how many people and with which features. In practice it is expressed as a license key plus the attributes attached to it on your licensing server, such as an expiry date, a device limit or a plan name.

It helps to treat the model as four independent dimensions rather than one choice from a list. Duration covers perpetual, subscription, time-limited and trial licenses. Placement covers node-locked and floating licenses. Quantity covers seats and device counts. Scope covers feature tiers and usage limits. A typical product picks one option on each axis, and the combination is the model you sell.

Software licensing models compared

The table below lists the common models side by side. Each row is a building block; most real products use two or three of them together.

Duration: perpetual, subscription, time-limited and trial

Duration decides when a license stops working. It has the largest effect on revenue, so it is usually the first decision.

• –Perpetual. The customer pays once and the license never expires. Some sellers charge separately for major upgrades or a year of updates. This suits small, stable utilities with little server cost.
• –Subscription. The license renews each billing cycle and expires when payments stop. It fits products that need constant updates, hosted features or support, because revenue keeps arriving while costs do.
• –Time-limited key. A key valid for a fixed term, such as one day, one week or 30 days, that simply ends. It is popular for tools used for a single event or project and for markets where buyers prefer prepaid access over a recurring charge.
• –Lifetime key. Effectively a perpetual license sold alongside time-limited or subscription plans, usually at several times the monthly price.
• –Trial. A short, time-limited license that lets buyers test the product before paying. Its length should match how long it takes the product to prove itself.

The detailed trade-offs between perpetual and subscription licenses, including billing cycles, grace periods and renewals, are covered in subscription licensing for software. Trials have their own pitfalls, which free trial licenses for desktop software goes through. The point that matters here is enforcement: whatever the duration, expiry should be calculated by the server's clock, never by the customer's.

Placement: node-locked vs floating licenses

Placement decides which machines may run the software. The two main options answer the question in opposite ways.

A node-locked license is bound to a specific machine. On first activation the application sends a hardware fingerprint, the server stores it against the key, and from then on the key only works on that machine. This is what HWID locking means, and it is the standard defence against a key being posted in a group chat and used on thirty PCs. What is HWID locking explains fingerprints, resets and common mistakes in detail.

A floating license, also called a concurrent license, is not tied to any machine. Instead, the customer buys a pool, say five, and any five machines may run the software at the same time. When a user closes the app, their slot returns to the pool. This suits teams where many people use the tool occasionally but rarely all at once.

Floating licenses are harder to run well. The server must know which sessions are alive, so the application has to check in regularly, and a slot held by a crashed or disconnected client must be released after a timeout. If you sell mainly to individuals, node-locking is almost always the better starting point.

Quantity and scope: seats, feature tiers and usage

Once you know how long and where, the remaining questions are how many and how much of the product.

• –Seat-based licenses cover a fixed number of named users or devices. A three-seat license might allow three hardware bindings on one key, or three separate keys issued to one buyer. Unlike floating licenses, seats are assigned rather than borrowed. They are a natural fit for small studios and for selling through resellers.
• –Feature-based tiers sell the same application at several levels, such as Basic and Pro. The license tells the application which tier it may run. This keeps one build and one download, but it only works if Pro functionality cannot simply be switched on by patching a flag in the binary.
• –Usage-based licenses charge for what is consumed: renders, exports, API calls or hours. Price follows value closely, but you need reliable metering on your server and a billing system that can turn counts into invoices, which is significant engineering for a small team.

Which licensing model fits your product

The same models apply to every kind of software, but some combinations fit certain products far better than others. The table below reflects what tends to work for the kinds of products sold on PapelShip.

Gaming tools are worth a closer look because they stress every part of a licensing system. Buyers often want short access around a game update, keys get resold or shared quickly, and builds are a constant target for crackers. Short time-limited keys, a lifetime option, strict HWID binding with a reset cooldown and server-side delivery of anything valuable is the combination that holds up best in that market.

Plugins sit at the other end. Buyers of a plugin for a DAW or a design app usually expect to own it, and they often move between machines. A perpetual license per major version, two device activations and a painless self-service reset keeps most of them happy.

How to enforce each model on the server

Every model on this page can be bypassed if the client is the one deciding. A license file with an expiry date can be edited, a clock can be wound back, a tier flag can be flipped and a seat counter stored locally can be reset. The pattern that works is the same for all of them: the application sends its key and hardware fingerprint, and the server answers with what that license is allowed to do right now.

1. 01

   Duration

   Store the license start and term on the server and compare against server time on every check. Never ship the expiry date as something the client evaluates on its own.

2. 02

   Node-locking

   Send a hash of stable hardware components with each check. The server binds it on first use and refuses mismatches, with a reset path and cooldown for genuine hardware changes.

3. 03

   Seats and devices

   Count bindings per key on the server and refuse the next device once the limit is reached. Issue separate keys per seat if buyers need to manage users individually.

4. 04

   Floating pools

   Track live sessions on the server, require regular check-ins and release a slot when a session times out, so crashed clients do not hold licenses forever.

5. 05

   Feature tiers

   Sell each tier as its own product or key type, and deliver the configuration, strings or files a tier needs only after the server confirms that tier.

6. 06

   Usage

   Count usage where the work happens, on your server, rather than trusting a counter the client reports.

Decide, too, how the app behaves when it cannot reach the server. Failing closed is the safe default. If customers need offline use, allow a short window measured from the server's last answer, and never longer than the remaining paid term. The broader argument for keeping decisions server-side is in client-side protection vs server-side secrets.

Implementing licensing models with qPapel Auth

qPapel Auth is PapelShip's licensing system for C, C++ and C# applications, and it is built around the server-side pattern above. License keys carry their duration, so lifetime, subscription, time-limited and trial keys each show a live status. HWID locking binds keys to a machine, with reset cooldowns so honest customers can move to new hardware without opening a ticket.

Sessions are encrypted and signed, and server-side strings and files are delivered only after a valid check, which is how you gate a feature tier with something the client cannot fake. Remote settings let you change behaviour without a rebuild, and custom key formats with KeyMask let you give each model a recognisable prefix, such as TRIAL- or PRO-, which makes support easier. For the runtime side, anti-tamper, anti-debug, anti-VM and process blacklists make the client harder to patch, and Binary Trace helps you find the source of a leaked build.

On the selling side, the PapelShip storefront delivers license keys instantly at checkout and supports subscriptions, so the key a buyer receives already matches the plan they paid for. The software licensing overview shows how the pieces fit together, and pricing starts with a Free plan.

Pick the simplest model your customers will accept

A licensing model is a product decision before it is a technical one. Start from how customers actually use the software: how long they need it, how many machines they work on and which features they would pay more for. Choose one option on each axis, and resist adding floating pools or metered billing until buyers ask for them.

Whatever you choose, enforce it in one place. When expiry, bindings, seats and tiers are all decided by the server, changing your model later is a configuration change rather than a new release, and the rules you sell are the rules your software actually follows.