Software licensing models explained: what you're actually buying
A client once asked me to review a €14,000 invoice from a vendor. Nothing was broken. No one had hacked anything. The problem was simpler and dumber: they'd bought a license model that didn't match how they actually used the product. Three people touched it daily. The contract was priced for fifty.
That's what software licensing really is, underneath the legal language. It's the rulebook that decides who can use a piece of software, how, how much, and for how long. Get the model right and you pay for what you use. Get it wrong and you pay for a story the vendor told you at the sales meeting.
Understanding software licensing models for beginners isn't about memorizing legal jargon. It's about recognizing the handful of pricing shapes behind every contract you'll ever sign, and knowing which one quietly punishes your specific usage pattern.
Key Takeaways
- A software license is a permission, not a purchase — you buy rights to use, not the code itself.
- Four families cover almost everything: perpetual, subscription, usage-based, and open source.
- The same product often ships under multiple models at once, priced differently per segment.
- Microsoft licensing is genuinely complex because it stacks models — per user, per core, per month.
- The real cost driver is rarely the headline price. It's the metric the vendor chose to count.
- Every licensing model eventually becomes a technical constraint: entitlements, limits, metering.
What a software license actually is (and why you never own the software)
When you "buy" software, you're buying a license. That's a legal permission slip describing what you may do with someone else's code. Copy it onto three machines? Maybe. Modify it? Usually not. Resell it? Almost never.
Here's the part beginners skip. A license has two layers that don't always agree with each other.
The legal layer
The contract states your rights in plain (sometimes deliberately unplain) language. It defines scope, territory, duration, and what counts as a breach. This is the layer lawyers argue about during an audit.
The technical layer
The license almost always has a mechanism underneath it. A license key. A seat counter. An entitlement API that checks, in real time, whether your account is allowed to call a feature. And this is where most beginner confusion lives: the contract says one thing, the software enforces another, and the gap between them is where surprise bills are born.
I once spent two days debugging "why can't this user see the export button" before realizing it wasn't a bug. Their subscription tier simply didn't include exports. The entitlement service had been quietly saying no the whole time. Nothing was broken. Everything was working exactly as licensed.
Practical rule: whenever you evaluate a tool, don't just read the pricing page. Ask what the software counts, and how it enforces the count.
What are the four types of software licenses?
Most licensing conversations collapse into four families. Learn these and you can decode almost any contract you're handed.
| Model | How you pay | Best fit | Main risk |
|---|---|---|---|
| Perpetual | One-time fee, upfront | A tool you'll use for years | Support and upgrades often cost extra |
| Subscription | Recurring, monthly or yearly | Teams that change size often | Cost creeps up and never stops |
| Usage-based | Per call, per GB, per seat-hour | Spiky or unpredictable workloads | A traffic spike becomes a finance event |
| Open source | Free, with obligations attached | Anything you can support yourself | License terms can restrict how you ship it |
Perpetual licenses: pay once, own the right to use forever
You pay a large sum today and keep the right to use that version indefinitely. It sounds like the honest option, and for stable tools it often is. The catch is that "forever" applies to the version you bought, not to future ones. When the vendor ships a major release, you're usually buying again — or subscribing to a maintenance plan that costs roughly 18-22% of the original price each year.
I still run a perpetual license on an old design tool. It works. It hasn't received a meaningful update in years. That's the trade, in one sentence.
Subscription licenses: access as long as you keep paying
This is where most of the market has moved, and honestly, for a growing team it's the sanest choice. You scale seats up when you hire and down when you don't. Stop paying and access ends, immediately and completely.
The trap isn't the model. It's the drift. You start at 10 seats, someone adds 4 for a project, nobody removes them, and two years later you're paying for 31 seats and can name 19 users.
Usage-based licensing: you pay for what you consume
Also called consumption or metered pricing. Instead of buying seats, you buy units — API calls, gigabytes stored, transactions processed. For a product with wild demand swings, this is genuinely fair. For a product with one runaway integration, it's a loaded gun.
I set up usage-based billing on a side project once and forgot to add a hard cap. A single misconfigured script hammered one endpoint over a weekend. The bill wasn't catastrophic, but it was memorable enough that I now add spending limits before I write the first line of integration code.
Open source licenses: free to use, not free of rules
Open source doesn't mean "no license." It means a license that grants broad freedoms — and attaches conditions. Permissive licenses let you use the code in commercial products with few strings. Copyleft licenses require that if you distribute modified versions, you share your changes under the same terms. For a beginner, the practical question is one: are you using this library internally, or shipping it inside a product you sell? The answer changes which licenses are safe.
What are the different types of software licensing models?
The four families above describe how you pay. But vendors slice them further, and this is where the vocabulary gets genuinely messy.
- Named user — a specific person gets a license, tied to identity. Clean accounting, awkward when people share a role.
- Concurrent user — you license a peak number of simultaneous users, not a headcount. Great for shift-based teams, painful to predict.
- Device or node-locked — the license attaches to a machine, not a person.
- Core-based — you pay according to the processing power you run it on. Popular with databases and infrastructure software, and the reason a server upgrade can trigger a licensing event.
- Floating — a pool of licenses anyone can check out and return.
Notice how the last three have nothing to do with who uses the software. That's the point. Vendors pick the metric that grows alongside your success. Your job is to figure out which metric grows faster than your budget.
How to understand Microsoft licensing
Microsoft gets its own section because it's the classic case where all these models stack on top of each other, and because it's the one people ask me about most.
The core idea: Microsoft prices differently depending on where the software runs and who touches it.
On-premises versus cloud
On-premises server products are typically licensed by processor core, with a minimum number of cores per physical server that you must license whether you use them or not. On top of that, anyone or anything accessing the server usually needs a Client Access License — a CAL. User CALs cover a named person across all their devices. Device CALs cover one machine used by many people. Pick the wrong one and you're paying twice what you needed to.
Cloud versions flip the logic entirely. You're billed per user, per month, and the core-counting problem disappears. That's a big part of why organizations keep migrating: not features, but predictability.
The CAL trap
Here's a concrete example I've seen play out. A company licenses a database server by core, correctly, and buys 40 user CALs for its staff. Then they connect a reporting tool that queries the same server. That tool isn't a person. It needs its own access license, and nobody budgeted for it. The mistake wasn't malice or incompetence. It was assuming "user" meant "human."
Before you sign anything with Microsoft's name on it, write down every single thing that will connect to the licensed software — people, integrations, scripts, backup tools — and check each one against the contract. That list is worth more than any discount you'll negotiate.
How to pick the right model for your situation
There's no universally best model, and anyone who tells you otherwise is selling one. But the decision tree is shorter than it looks.
- Is your usage steady and your team stable? A subscription at a negotiated rate usually wins.
- Is your usage spiky, with quiet weeks and brutal peaks? Usage-based, with a hard spending cap configured on day one.
- Will you run this exact version for five years without needing new features? Perpetual is worth pricing out.
- Can you support it yourself? Then open source is genuinely on the table, and often excellent.
- Does the vendor count something you can't measure? Push back. If you can't audit it, you can't control it.
The one thing I'd tell any beginner: the pricing page is marketing, and the contract is the product. Read the second one.
What happens if you use software outside your license terms?
Usually nothing visible — until an audit. Vendors have the right to verify compliance, and the resulting bill typically covers the shortfall plus back-maintenance fees. I've watched a mid-sized company settle a five-figure true-up because a contractor's account was never removed. The software never complained. It just kept working, quietly, outside the agreement.
The model is the product now
Here's what I keep coming back to after years of watching these decisions get made badly. The licensing model isn't a commercial detail bolted onto a finished product. It's a design decision that shapes who can afford to use the software, and how.
Which means the next time a vendor tells you the model is "industry standard," you're allowed to ask a harder question. Standard for whom? Because perpetual pricing favors the buyer who plans in decades. Subscription favors the vendor who plans in quarters. Usage-based favors whoever can forecast their own traffic — and punishes everyone else.
You'll rarely change the model on offer. But you can almost always choose which vendor's model fits the way you actually work. That choice, made deliberately, is worth more than any discount you'll ever negotiate — and it's the one nobody will make for you.
