IBM licenses traditional software by Processor Value Unit capacity against the hardware it runs on, while Red Hat, which IBM owns, licenses by simple annual subscription per socket-pair or per core with no capacity counting and no perpetual option. The two models sit inside the same company but follow opposite philosophies, and the difference decides both the cost and the administrative burden of each. This comparison sets out how the IBM capacity model and the Red Hat subscription model work, where they overlap on OpenShift and Cloud Paks, what each costs, and which model fits which workload in 2026.
Inside This Guide
Two licensing philosophies
The cleanest way to understand IBM and Red Hat licensing is as two answers to the same question: how should software be priced against the infrastructure it runs on. IBM answers with capacity. It measures the processing power available to a product, expressed in Processor Value Units, and prices against that, which ties cost to the size and type of the hardware. Red Hat answers with subscription. It charges a flat annual fee per unit of infrastructure, a socket-pair for Red Hat Enterprise Linux or a core for OpenShift, with the same price whether the system is busy or idle. One model prices the capacity; the other prices the entitlement to run and be supported.
That philosophical split matters because IBM acquired Red Hat in 2019 but deliberately left the Red Hat model intact. A buyer dealing with both therefore manages two completely different licensing disciplines from one vendor relationship. This page sits under our complete IBM licensing guide, and the firm-side help spans both in our IBM practice.
The IBM capacity model
Traditional IBM software such as WebSphere, Db2, and MQ is licensed in PVUs, where IBM assigns a value to each processor core from its published table and you license the total PVUs of the cores in scope. A common x86 core rates at 70 PVUs, and the licensable figure depends heavily on whether you qualify for sub-capacity, which counts virtual cores, or are stuck at full capacity, which counts every physical core. The model is powerful but administratively heavy: it requires the IBM License Metric Tool, quarterly reporting, and constant attention to the counting basis. The full mechanics are in our IBM PVU licensing guide.
The capacity model rewards careful management and punishes neglect. Sub-capacity can cut the licensable PVUs by 60 to 80 percent on a virtualized estate, but only with valid tooling, and the same deployment reverts to full capacity if the conditions lapse. Cost is therefore not fixed by the purchase but by the ongoing discipline around measurement, which is the defining characteristic of IBM licensing and the source of most of its audit risk.
The other practical strength of the Red Hat model is that it scales cleanly with virtualization rather than against it. Because the entitlement is tied to sockets or cores and the virtual-deployment options are explicit, a buyer can plan capacity growth without the order-of-magnitude surprises that the IBM full-capacity counting can produce on a virtualized host. This predictability is why many organizations standardize their operating-system and platform layers on Red Hat even while they continue to wrestle with IBM capacity counting on the middleware above it, treating the two layers as separate cost-management problems with separate playbooks.
The Red Hat subscription model
Red Hat licenses by annual subscription, and the model is intentionally simple. Red Hat Enterprise Linux is sold per physical socket-pair, so a two-socket server takes one subscription regardless of core count, with separate subscriptions for virtual deployments based on guest count or unlimited-guest options. OpenShift is sold per core or per socket-pair depending on the edition. There is no PVU table, no capacity measurement tool, and no perpetual license. You subscribe, you receive updates and support for the term, and the entitlement lapses if you stop paying. The simplicity is the point: a buyer can predict Red Hat cost from a hardware inventory alone.
The trade-off is that the subscription is a recurring rental with no owned asset at the end, and that Red Hat support, while substantial, is tied to the active subscription. For organizations that value predictability and low administrative overhead, the Red Hat model is far easier to manage than the IBM capacity model. For organizations that ran perpetual licenses and resent recurring cost, it is the same subscription shift that has spread across the whole industry, and it is not negotiable away because no perpetual option exists.
Side-by-side matrix
| Factor | IBM (PVU capacity) | Red Hat (subscription) |
|---|---|---|
| Metric | Processor Value Units | Per socket-pair or per core |
| Capacity counting | Yes, full or sub-capacity | No |
| Tooling required | ILMT for sub-capacity | None |
| Perpetual option | Historically yes, on older terms | No, subscription only |
| Administrative burden | High | Low |
| Cost predictability | Variable with counting | High, from inventory |
| Audit focus | Sub-capacity proof | Subscription coverage |
Cost comparison
A direct cost comparison is only meaningful for equivalent functions, because the two models cover different software. Where they can be compared, the pattern is that IBM capacity-licensed middleware carries a higher and more variable cost than a Red Hat subscription for a comparable platform layer, because the PVU model multiplies against hardware while the Red Hat subscription is a flat per-socket or per-core fee. The table models representative annual costs for a mid-size deployment to show the shape of the difference, not exact list prices.
| Workload layer | IBM capacity-licensed | Red Hat subscription |
|---|---|---|
| Operating system, 2-socket host | Not applicable | One RHEL subscription per host |
| Middleware, virtualized | PVU sub-capacity, variable | Not applicable |
| Container platform | Cloud Pak VPC bundle | OpenShift per core |
| Cost driver | Cores and counting basis | Sockets or cores, flat |
Different models, different disciplines: IBM cost is controlled by managing the capacity count and the ILMT proof. Red Hat cost is controlled by managing the subscription count against the hardware inventory. A buyer running both needs both disciplines, and the most common mistake is applying capacity thinking to Red Hat or subscription thinking to IBM.
A common and costly error on this overlap is buying a Cloud Pak primarily to obtain OpenShift, on the assumption that the bundle is cheaper than a direct subscription. It rarely is when the IBM software components inside the pack go unused, because the per-VPC bundle price is set against the whole pack. The reverse error is buying OpenShift directly and then separately licensing IBM software that would have been included in a Cloud Pak the workload genuinely needed. Both errors come from treating the two routes as interchangeable rather than mapping them to actual component utilization.
OpenShift and Cloud Paks overlap
The two models meet on the container platform, where the choice is genuinely strategic. IBM Cloud Paks are containerized software bundles licensed in Virtual Processor Cores that run on Red Hat OpenShift, so a Cloud Pak purchase often includes an OpenShift entitlement. A buyer can therefore acquire OpenShift directly from Red Hat per core, or indirectly bundled inside an IBM Cloud Pak in VPCs. The two routes price differently and suit different situations, and choosing the wrong one means either paying for Cloud Pak capacity you do not use or fragmenting an OpenShift estate across two purchasing models. The detail is in our IBM Cloud Paks licensing guide and our IBM VPC licensing guide.
The decision rule is utilization. If you need the IBM software inside a Cloud Pak, the bundled OpenShift entitlement is efficient. If you need OpenShift as a platform in its own right without the IBM software, buying it directly from Red Hat per core avoids paying for the Cloud Pak components you will not run. Mapping which route fits each cluster before renewal is where the saving sits.
Support and updates
Both models bundle support and updates into the recurring fee, but the structure differs. IBM Subscription and Support runs at roughly 20 percent of license value a year and can, on older perpetual terms, be separated from the license, which creates the option of third-party support for stable products. Red Hat support is inseparable from the subscription, because there is no license to keep without it, so the only support decisions are the tier and whether the subscription continues at all. For a buyer planning to reduce vendor support cost, the IBM side offers more levers, while the Red Hat side offers predictability instead.
In practice the support comparison reinforces the broader model difference. IBM gives more control and more complexity; Red Hat gives less control and more simplicity. Neither is universally better, and the right answer depends on whether the organization values optionality or predictability for the workload in question.
The verdict: which when
The models are not interchangeable, so the real question is which to use for a given layer. Use the IBM capacity model where you need IBM proprietary middleware such as WebSphere, Db2, MQ, or the analytics and automation products, because those are only available under IBM licensing, and manage the cost through sub-capacity and ILMT discipline. The capacity model is unavoidable for IBM software, and the work is to license it efficiently rather than to escape it.
Use the Red Hat subscription model for the operating system, the container platform where you do not need the bundled IBM software, and any workload where predictability and low administrative overhead matter more than the optionality of a perpetual asset. Where the two overlap on OpenShift, decide by utilization: bundled through a Cloud Pak when you need the IBM software, direct from Red Hat when you need only the platform.
The practical rule: Do not choose between IBM and Red Hat as if they were rivals; they are two models from one vendor for different layers. Use IBM licensing for IBM software and manage the capacity count; use Red Hat subscriptions for the platform and manage the inventory. The only genuine choice is the OpenShift route, and utilization decides it.
One more discipline ties the two models together at renewal. Because both come from IBM, they are often negotiated in the same conversation, and IBM will sometimes propose bundling Red Hat subscriptions and IBM capacity licenses into a single enterprise agreement. That can simplify administration, but it can also obscure which model is driving the cost and lock both into one baseline. Keeping visibility of the IBM and Red Hat figures separately, even inside a combined agreement, preserves the ability to optimize each on its own terms at the next renewal.
Action steps
Map your estate by layer. For IBM middleware, confirm the PVU position and the sub-capacity proof, because that is where the cost and the risk concentrate. For Red Hat, reconcile the subscription count against the current hardware and virtual inventory so you are neither under-covered nor paying for retired systems. For OpenShift, decide per cluster whether the Cloud Pak bundle or the direct Red Hat subscription is the efficient route, and consolidate onto one model where you can.
For the full IBM picture, start with the complete IBM licensing guide, the PVU licensing guide, and the Cloud Paks guide. For engagement help across both models, our IBM practice and IBM negotiation service size and negotiate the combined position, backed by our software licensing advisory team.