IBM Red Hat Open Source Licensing: RHEL, OpenShift and the 2023 Source Code Controversy

Red Hat's Open Source Subscription Model Under IBM

Red Hat's commercial model is built on a distinction between open-source software availability and enterprise support subscriptions. Red Hat distributes its products under open-source licences — Red Hat Enterprise Linux (RHEL) and Red Hat OpenShift are fundamentally open-source code bases. What Red Hat sells is not the software itself but the subscription: the right to enterprise support, access to the Red Hat Customer Portal for software updates and errata, certified integrations, and compliance indemnification.

IBM's acquisition of Red Hat in 2019 did not alter this fundamental model. Red Hat continues to operate with open-source licence foundations, and IBM has largely allowed Red Hat to maintain its independent product strategy and open-source commitments. However, IBM's ownership has introduced three notable changes: enhanced compliance programme rigor, cross-sell integration between IBM and Red Hat products (particularly IBM Cloud Paks, which bundle OpenShift), and — most controversially — the 2023 decision to restrict public access to RHEL source code.

RHEL Subscription Licensing

How RHEL Subscriptions Work

Red Hat Enterprise Linux subscriptions are sold per server (or per socket pair), covering the right to run RHEL on that system, receive updates and security patches through the Red Hat Customer Portal, and access Red Hat technical support. A standard RHEL subscription covers two CPU sockets — a two-socket x86 server requires one subscription. Virtual machines and cloud instances running RHEL also require subscriptions, unless covered by a separate cloud provider programme.

RHEL subscriptions come in multiple service tiers: Standard (business hours support, standard SLAs), Premium (24x7 support, faster response SLAs), and Self-Support (updates and patches access but no technical support). The tier choice affects both price and the enterprise's ability to receive timely support for security incidents. Many organisations purchase Standard subscriptions for most servers but Premium for business-critical systems — a tiering approach that requires active management to keep aligned with actual criticality classifications as infrastructure evolves.

RHEL for Hyperscalers and Cloud

RHEL is available on major public cloud platforms (AWS, Azure, Google Cloud) through either customer-supplied licences (BYOL, using existing RHEL subscriptions) or on-demand marketplace instances where the cloud provider charges a per-hour RHEL premium. Red Hat's Cloud Access programme allows existing RHEL subscribers to use their subscriptions in supported public cloud environments, avoiding double-counting between on-premises and cloud usage. Managing RHEL subscription coverage across hybrid environments requires systematic tracking of where RHEL instances run and which subscription pool they draw from.

RHEL Compliance Enforcement Under IBM

Since IBM's acquisition, Red Hat has enhanced its subscription compliance programmes. Red Hat uses Red Hat Subscription Manager (RHSM) and the Satellite product to monitor subscription registration and compliance. Systems running RHEL that are not registered against a valid subscription will eventually lose access to updates and may trigger compliance notifications. IBM's integration of Red Hat into the broader IBM licensing compliance framework means that Red Hat subscription gaps can surface during broader IBM account reviews — a compliance dynamic that did not exist when Red Hat operated independently. Enterprises that also run IBM middleware products should note that IBM License Metric Tool (ILMT) — the mandatory measurement tool for sub-capacity PVU licensing — operates independently of RHSM; both tools must be correctly deployed and continuously generating reports for an organisation to maintain full IBM licensing compliance across its hybrid estate.

The 2023 RHEL Source Code Controversy

What Changed

In June 2023, Red Hat announced that it would cease making RHEL source code publicly available through git.centos.org. Going forward, RHEL source code would only be accessible to Red Hat customers and partners through the Red Hat Customer Portal, with CentOS Stream serving as the publicly available upstream development branch rather than a downstream RHEL equivalent.

This decision effectively ended the practice of organisations building 1:1 bug-compatible RHEL clones from freely available source code. CentOS Stream, as a pre-release development branch of RHEL, does not provide the same stability or enterprise-suitability as RHEL itself — making it unsuitable as a production substitute for organisations that had relied on CentOS (and later CentOS Stream) as a free RHEL-compatible platform.

Impact on RHEL Clone Distributions

The 2023 source change directly affected the viability of Rocky Linux and AlmaLinux — two community-created RHEL clones that emerged after Red Hat's 2020 announcement that CentOS Linux would be discontinued in favour of CentOS Stream. Rocky Linux and AlmaLinux had positioned themselves as binary-compatible RHEL replacements for organisations unwilling to pay for RHEL subscriptions.

Following the 2023 source restriction, both Rocky Linux and AlmaLinux announced alternative approaches to maintain RHEL compatibility — AlmaLinux by explicitly decoupling from 1:1 RHEL compatibility in favour of RHEL "Application Binary Interface" compatibility, and Rocky Linux by using Oracle Linux's publicly released RHEL-based source packages. The community response was substantial and ongoing. Oracle, itself a competitor with its own Oracle Linux RHEL clone, was vocal in criticising IBM's decision.

Enterprise Implications

For enterprise organisations that had built infrastructure on CentOS or were considering CentOS-based alternatives to reduce RHEL subscription costs, the 2023 changes force a decision: migrate to paid RHEL subscriptions, adopt one of the RHEL-compatible alternatives with reduced certainty of long-term parity, or consider alternative Linux distributions. For IBM and Red Hat, the changes are intended to protect the commercial value of RHEL subscriptions by reducing the viability of "free" alternatives — a commercial rationale that aligns with IBM's subscription revenue objectives.

Red Hat OpenShift Licensing

OpenShift Subscription Model

Red Hat OpenShift — the enterprise Kubernetes platform built on top of RHEL CoreOS — is sold on a subscription basis measured per core. OpenShift subscriptions cover the right to run the OpenShift Container Platform in self-managed configurations, receive updates and security patches, and access Red Hat technical support for OpenShift deployments. The per-core metric replaced OpenShift's earlier per-node and per-socket metrics, simplifying the licensing model for container-dense environments.

OpenShift subscriptions cover both the OpenShift container management layer and the underlying RHEL CoreOS worker nodes. A separate RHEL subscription is not typically required for RHEL CoreOS nodes managed by OpenShift — the OpenShift subscription includes the operating system entitlement. However, any additional RHEL nodes outside the OpenShift-managed cluster (for management infrastructure, external services, or non-containerised workloads) still require their own RHEL subscriptions.

IBM Cloud Paks and OpenShift: The Double-Licensing Risk

IBM Cloud Paks are IBM's containerised software bundles — IBM Watson, IBM Cloud Pak for Data, IBM Cloud Pak for Integration, and others — that are built to run on Red Hat OpenShift. Every IBM Cloud Pak deployment requires a Red Hat OpenShift cluster as the underlying platform. This creates a layered licensing requirement: Red Hat OpenShift subscriptions for the container platform plus IBM Cloud Pak entitlements (typically measured in IBM VPCs — Virtual Processor Cores) for the IBM software running within the cluster.

A common compliance gap is double-licensing: organisations that purchased IBM Cloud Pak entitlements assuming those entitlements include OpenShift platform rights, without separately purchasing OpenShift subscriptions. IBM and Red Hat have published guidance indicating that Cloud Pak entitlements do not automatically include standalone OpenShift subscription rights for non-Cloud Pak workloads on the same cluster. Enterprises running both Cloud Pak applications and non-IBM container workloads on shared OpenShift clusters need to ensure their OpenShift subscription coverage accounts for the full cluster core count, not just the cores dedicated to IBM Cloud Pak workloads.

IBM and Red Hat Cross-Selling Under IBM Ownership

Since IBM's acquisition, Red Hat products have been increasingly integrated into IBM's commercial and advisory conversations. IBM account teams actively cross-sell Red Hat OpenShift alongside IBM Cloud Paks, positioning OpenShift as the mandatory platform and Cloud Paks as the IBM-value-add software layer. This cross-sell approach can benefit customers who genuinely need both products, but it also creates pressure to adopt OpenShift in situations where a simpler or lower-cost Kubernetes platform might be equally appropriate.

Enterprise teams reviewing OpenShift adoption should evaluate whether Red Hat OpenShift's capabilities justify its subscription cost compared to managed Kubernetes services (AWS EKS, Azure AKS, Google GKE) or community distributions (upstream Kubernetes with commercial support from third-party providers). For workloads that do not require IBM Cloud Paks, the OpenShift platform premium may not deliver proportionate value.

Red Hat Subscription Compliance Best Practices

Managing Red Hat subscription compliance effectively under IBM's enhanced monitoring requires three core practices. First, maintain systematic registration of all RHEL systems against Red Hat Subscription Manager. Unregistered systems — including development and test environments that are often overlooked in subscription reviews — accumulate as compliance gaps that surface during account reviews.

Second, tier RHEL subscriptions to match actual support requirements. Running all systems on Premium subscriptions is expensive; running business-critical systems on Standard subscriptions creates support risk during incidents. A subscription tiering review aligned with the organisation's actual criticality classification prevents both over-spend and under-coverage.

Third, audit OpenShift cluster core counts against subscription holdings before every renewal cycle. Container clusters grow as workloads are added — core count increases may have occurred since the last subscription purchase. Proactive reconciliation avoids arriving at the renewal negotiation with an unacknowledged compliance gap that IBM can use as leverage.