Sub-Capacity Licensing

A licensed message broker is containerised and scheduled onto a 96-core node in a shared cluster, with a CPU limit of 4 cores. Technically it uses 4 cores. Twelve months later an audit assesses the licence against every activated physical core on every node the container was eligible to run on, and the invoice is orders of magnitude larger than the budget line.

Per-core licences were written for fixed hardware, where the countable surface is obvious. Virtualisation broke the count, and vendors answered with sub-capacity programmes: the right to license the capacity a workload is constrained to rather than the capacity of the machine underneath it. That right is contractual, not technical, and it is conditional.

The condition is almost always approved metering. IBM's sub-capacity terms require an approved tool, such as the IBM License Metric Tool, to be installed within 90 days of first use of an eligible product and to report at least every 90 days, with the reports retained. Miss the requirement and the entitlement reverts to full capacity for every activated core on the server.

Why it matters

The gap between the two counts is the whole licence bill. Four cores against 96 is a factor of 24, and on a product priced in the hundreds of dollars per core it is the difference between a line item and a crisis. The exposure accrues silently, because nothing in the platform reports a licensing state, and it is realised at audit as a retrospective true-up at list price without the discount a planned purchase would have carried.

It also constrains architecture directly. A design that lets a licensed component be scheduled anywhere in a large cluster is a design that has maximised its own countable surface, and the cheapest fix is almost always a scheduling constraint rather than a commercial negotiation.

Implementation patterns

• Pin licensed workloads to a dedicated node pool of the smallest viable core count, with taints and node selectors, so the countable surface is small, fixed and provable.
• Treat the metering agent as a production dependency: monitored, alerted, covered by the upgrade runbook. A cluster upgrade that silently stops it reporting is a financial event with no technical symptom.
• Keep the entitlement position continuously, not at audit: deployed cores against purchased cores, per product, reviewed monthly.
• Read the metric definition before choosing the architecture. Some terms count the cluster rather than the running workload, which rules out designs that would otherwise be obvious.

Industry example

IBM's Passport Advantage sub-capacity programme is the best-documented instance: as its terms stand in 2026, eligible products may be licensed on virtualisation capacity, conditional on the IBM License Metric Tool or an approved equivalent being installed within 90 days of first use and reporting at least every 90 days. Other vendors count differently, and some decline to recognise soft partitioning at all, which makes the licence a hard architectural constraint rather than something to negotiate. The common shape is that the discount is real and the paperwork is load-bearing, which is why platform teams that treat licensing as procurement's problem are the ones that fail an audit.

Failure scenarios

• Metering lapses after a platform change and the next audit assesses full capacity for the period.
• A node pool grows to absorb unrelated workloads, taking the licensed component's countable surface with it.
• A migration business case omits licence cost, concludes in favour of the larger instance family, and doubles the per-core bill while halving the server count.

Trade-offs

Sub-capacity licensing buys a smaller bill and pays in bin-packing efficiency, operational constraint and audit paperwork. A pinned pool runs at lower utilisation than the shared cluster, and that lost efficiency is the price of a bounded licence exposure. The arithmetic is usually overwhelming: a few percent of wasted node capacity against a 24x difference in licence count.

When not to use it

Where the component is open-source or consumption-priced there is nothing to meter, and pinning only costs you packing efficiency. Where the licensed footprint is small enough that full-capacity licensing is affordable, the simpler position is to pay it and delete the metering obligation along with its failure mode. And where the licence is a large share of total cost of ownership, the better question is not how to count fewer cores but whether to carry the product at all.

Interview question

Q: You are moving a per-core licensed database onto Kubernetes. Walk me through how you keep the licence bill from multiplying, and what you would put in place so that the position stays true a year from now.

What a strong answer covers: the default is full capacity, so the entitlement must be established before migration; pinning to a small dedicated pool with taints; the metering obligation and its monitoring; a monthly entitlement-versus-deployment report; and the recognition that the architecture choice and the commercial choice are the same decision here.

Quick check

Quiz: A licensed product is limited to 4 cores on a 96-core host. What is licensable by default? All 96 activated cores, unless an approved sub-capacity metering tool is installed and reporting.

Flashcard: What makes a sub-capacity licence revert to full capacity? — A lapse in the approved metering requirement, typically installation within 90 days of first use and reports at least every 90 days.