Perpetual License vs Subscription License: Which Should You Sell?
The real tradeoffs between selling a license that never expires and one that renews — revenue shape, maintenance obligations, and how to configure either (or both) for the same product.
Perpetual and subscription aren't really about the license technology at all — a license key doesn't care whether it's "supposed to" last forever. The real difference is a business model decision: does the customer own access forever after one payment, or do they keep paying to keep access? Most licensing platforms, including this one, can issue either from the exact same product.
How purchase type determines access
For a one-time Store purchase, LicenseExpiryDays sets the number of days of access; leaving it blank creates a perpetual key. Monthly and annual purchases follow Stripe's paid billing period instead: each paid invoice extends the same key. Failed renewals use the configured payment grace window, 14 days by default, and access expires when it ends. A product can offer one-time, monthly, and annual options side by side; the selected purchase type determines which expiry rule applies. Activations, node locking, and feature flags remain independent controls.
Perpetual: what you're actually trading
A perpetual license (one payment, access forever) is simple to explain to a customer and creates no ongoing billing relationship to maintain — no dunning emails, no cancellation flow, no "why was I charged again" support tickets. The tradeoff is revenue shape: each sale is a one-time event, so growth depends entirely on new customers or paid upgrades, not a compounding base of renewals. It also creates a real, ongoing support obligation most vendors underestimate: a customer who paid once five years ago may still expect their software to run, even as the surrounding OS/platform changes underneath them — perpetual access doesn't obligate perpetual free support or updates, but the two get conflated by customers constantly, and being explicit about what perpetual actually includes (usually: this version, as-is) avoids that friction later.
Subscription: what you're actually trading
A subscription (recurring charge, access requires staying current) creates a predictable, compounding revenue base and a natural mechanism to fund ongoing development — the customer relationship doesn't end at the sale. The tradeoff is real operational surface: failed payments need handling (see how failed-payment grace and expiry work), cancellations need a clean flow, and every renewal is a moment a customer can decide to leave — churn is a metric you now have to actively manage, not a one-time sale you never think about again.
Selling both isn't unusual
A common real pattern: subscription as the default (lower upfront price, steady revenue) with a perpetual option at a higher price point for customers who specifically want to avoid recurring billing — enterprise procurement teams in particular often prefer a one-time capital purchase over an operating subscription for budgeting reasons that have nothing to do with your product. Since both are just a price + an expiry-days setting on the same product, offering both isn't extra engineering work, just a second price point.
What doesn't change either way
Node-locking, floating seats, feature gating, and offline support are all independent of whether the license is perpetual or subscription — see node-locked vs. floating and feature-based licensing for those. The perpetual-vs-subscription decision is purely about the business model; everything else about how the license actually behaves is a separate, orthogonal choice.
Build your first licensed product without building a license server.
Create a free PermitCore account, issue a test license, and validate it from your application.