All posts
Strategy Licensing Models ISV

License Key Distribution: The 5 Models Every Software Vendor Should Know

PC
PermitCore
June 8, 2026 · 6 min read
PERPETUAL Buy once Own forever Node-locked v1.0 → v2.0 upgrade fee SUBSCRIPTION Monthly/annual Auto-renew Lapse = revoke Predictable ARR growth FLOATING N seats shared Check-out/in Concurrent Enterprise teams METERED Pay per use API calls, docs seats, GB… Variable revenue TRIAL Time-boxed or feature-gated → convert to paid on upgrade FIVE DISTRIBUTION MODELS — CHOOSE FOR YOUR PRODUCT

The model you choose for distributing license keys will shape your revenue structure, your support burden, and your relationship with customers for years. Most ISVs start with the simplest option and migrate later — an expensive process that often requires re-issuing keys and updating integrations. Choosing deliberately at the start saves that pain.

Model 1: Perpetual + Node-Locked

The oldest model in commercial software. A customer pays once, receives a key tied to a specific machine (the "node"), and owns that version indefinitely. Upgrades cost extra, typically 30-50% of the original price.

When it works: Desktop tools with long shelf lives (CAD software, audio plugins, font libraries). Customers who distrust subscription lock-in. Markets where annual budget cycles make subscriptions difficult to justify.

The catch: Node-locked keys require machine fingerprinting — collecting hardware identifiers, hashing them, and validating them server-side on each launch. This creates support tickets every time a customer replaces hardware. You need a clear machine transfer policy and tooling to support it.

Model 2: Subscription

The customer pays monthly or annually and gets access for as long as they pay. The key remains valid until the subscription lapses, at which point it is automatically revoked or enters a grace period.

When it works: SaaS-adjacent tools, anything with frequent update cycles, cloud-connected software where you control the server-side validation. The ARR predictability is a strong argument for investors and acquirers.

The catch: Churn. Every expiry date is a decision point for the customer. "Is this still worth it?" The answer is often influenced by how much value they extracted in the last period, not the next. You need to make recent value visible — a "your last 30 days" summary beats a generic renewal email every time.

Model 3: Floating (Concurrent) Licenses

Instead of one key per seat, you sell N concurrent seats that can be shared across an unlimited user pool. When a user opens the application, it checks out a seat from a license server. When they close it, the seat is returned. If all N seats are in use, additional users are queued or blocked.

When it works: Enterprise tools where not every user is active simultaneously — EDA software, simulation tools, specialized analysis platforms. A team of 80 engineers might need only 30 concurrent seats if peak usage is staggered.

The catch: Complexity. You're now running a license server, dealing with network partitions (what if the user is offline?), and handling checkout timeouts. PermitCore's floating license model handles the concurrent seat accounting, but your SDK must still handle the check-out/check-in lifecycle.

Model 4: Metered Usage

The customer pays for what they consume: API calls, documents processed, active users, GB stored, render minutes. The license key gates access; a separate counter drives billing.

When it works: APIs, data pipelines, AI inference endpoints — anything where usage is clearly measurable and the cost-to-serve scales with consumption. Lower friction for new customers (no upfront commitment), and the revenue ceiling grows with each customer's success.

The catch: Unpredictable revenue. Month-to-month variability makes forecasting hard and churn harder to detect (a customer might reduce usage gradually rather than canceling explicitly). You need robust real-time metering infrastructure, and your pricing model must be simple enough that customers can estimate their bill.

Model 5: Trial Keys

A time-boxed (14-day, 30-day) or feature-limited key that converts to a paid license on upgrade. Trial keys are often a distribution mechanism layered on top of one of the above four models rather than a model in their own right.

When it works: High-complexity products that require hands-on evaluation. Devtools, B2B desktop software, anything where a freemium web demo doesn't capture the full value. The trial period is your best marketing channel — invest in the activation and onboarding experience accordingly.

The catch: Trial abuse. Without machine fingerprinting or email verification, a determined user can create unlimited trial accounts. The solution is rarely technical and more often product-level: make the paid version obviously more valuable than cycling through trials, rather than implementing increasingly aggressive anti-fraud measures that hurt legitimate users.

Hybrid Models and Real-World Combinations

Most mature ISVs combine models. A common structure: a subscription-based license that allows N concurrent activations per seat, with a built-in 14-day trial for evaluators. The trial key converts to a subscription on first payment, and the subscription key respects activation limits enforced by the license management backend.

PermitCore supports all five models through a single API. The MaxActivations field controls node locking, ExpiresAt handles subscriptions and trials, and the metering layer counts usage events against tenant-level thresholds. Floating license seat management is handled by the concurrent checkout/checkin endpoints.

Choosing Your Model

A simple heuristic: if your customers are individuals, start with perpetual or subscription. If your customers are teams, consider floating. If your product's core value grows with usage, metered is often the right long-term answer even if it takes longer to model. Run the math on customer lifetime value under each model before you commit — a subscription at 80% annual retention often outperforms a higher perpetual price with no recurring component within three years.

The model you choose should match what your customers naturally expect to pay for, not what's easiest to implement. Technical debt in a licensing model is recoverable; customer trust is not.

Previous: Zero-Knowledge Encryption Next: Integrate with .NET