RHEL White Paper

Executive Summary

Red Hat Enterprise Linux (RHEL) has always been the enterprise Linux OS distribution of choice. This is partly due to Red Hat’s support infrastructure which has been exceptional and provides great value to its customers.

Culturally and historically, Red Hat policies have always been building blocks of Open-Source ideals. However, since IBM’s acquisition of Red Hat in 2019 there have been subtle shifts in policy and culture.

Take for example, Red Hat’s announcement^[1] that *“CentOS Stream will now be the sole repository for public RHEL-related source code releases”  *or read by some industry experts as Red Hat has decided to remove public access to the Red Hat Enterprise Linux (RHEL) source code. There have been some passionate reactions to this announcement so much so that CIQ, Oracle and SUSE have decided to set up the Open Enterprise Linux Association.

Eagle eyed Software Asset Managers are acutely aware of impacts, changes in ownership or distribution policy changes, have on licensing environment for the software. SAM industry has seen many a Red Hat’s review requests received by its customers over the last 3-4 years and we expect this trend to continue and grow.

RHEL licensing is deceptively complex, even though on the surface it seems docile. Complexity is generated due to various reasons such as:

• 150+ catalog items in RHEL family;
• Subtle metric definitions (Sockets, Virtual Nodes, Virtual Guests);
• Plethora of IT environments with RHEL OS (Physical, Cloud, Virtualisation, Containers);
• RHEL policies (Backdating, “All or None”);

This white paper endeavours to guide any Software Asset Management (SAM) professional trying to understand RHEL licensing terms and enabling compliance for their organisations or customers. For more SAM professionals, this white paper also aims to discuss possible optimisation opportunities that may slip under the radar.

Objective and Target Audience

It’s difficult to stay abreast with all the regular changes to licensing terms and policies associated to Red Hat. In contrast to gaining expertise, experience is always built through years of effort and sharing of information among peers. Through this white paper, we bring expertise and experience to your doorstep. This white paper is updated and reviewed yearly and provides the latest licensing information related to Red Hat Enterprise Linux (RHEL) and shares the experience of various contributors from across the industry spectrum on all topics RHEL.

Red Hat releases a RHEL Subscription Guide at the following link^[2].

This white paper does not attempt to replace the RHEL Subscription Guide but to add much needed context derived from experience running successful SAM programs and RHEL subscription audits. This white paper should be useful for Software Asset Managers, Software Licensing Specialists, IT Procurement, IT Sourcing Experts, IT Managers and CIOs.

Problem Statement

In the previous sections we have established that Red Hat licensing is fraught with challenges and uncertainties which impacts organisation’s ability to efficiently manage software costs, compliance, and operational continuity. There are possible pitfalls at each level of Software Asset Management cycle for Red Hat software and addressing these issues is crucial for organisations seeking to optimise their IT investments and ensure regulatory compliance.

We start breaking down the problem into pieces and offer advice along the way discussing the most common issues and then delve deeper into license compliance and optimisation process.

Most Common Issues

Based on our experience managing and auditing Red Hat Enterprise Linux (RHEL) environments, we’ve determined the most common issues as follows:

1. Managing Red Hat Contracts and Procurement;
2. RHEL Licensing Pitfalls;
3. RHEL Product Scope;
4. Subscription and Support Misconceptions;

1. Managing Red Hat Contracts and Procurement

This section provides key insights to IT leaders and Procurement specialists involved in Red Hat Support subscription purchases.

• Red Hat product and services are governed by the terms and conditions listed in the Red Hat Enterprise Agreement^[3]. This agreement is deemed to be accepted on purchase and/or utilisation of Red Hat products. Procurement and Legal teams should regularly review the agreement document for any changes. Read more about agreement types in Appendices → RHEL Agreement Types.
• RHEL OS is a licensable distribution of open-source Linux software. Any misconceptions that IT might have, about free use of RHEL must be dispensed off quickly.
• Red Hat has made purchasing RHEL extremely easy and quick which means that SAM/ITAM Managers must guard against unmanaged subscription purchases across their organisation.
• RHEL OS can be purchased through Retail on their website, third party suppliers, through an Enterprise Account directly with Red Hat, as part of a bundle with other Red Hat products like OpenShift, Bundled along with Server Hardware and as part of managed instances from Cloud Service Providers. Sourcing teams need to be aware of all these channels and regularly track them to remain vigilant of new purchases.
• Red Hat account teams and managers are segregated across geographical boundaries and generally do not have view of subscriptions purchased outside of their remit. Procurement/Sourcing must be informed while renewing their subscriptions.
• All RHEL purchases are linked to an organisation Admin Account which is allowed to access the Red Hat Customer Portal. Red Hat requests information for this admin account during every purchase. Sourcing should make sure to standardise one account as admin so that all purchases are allocated and visible under the same account.

Red Hat is moving away from the Red Hat Customer Portal and The Hybrid Cloud Console (console.redhat.com^[4]) will be the source for our customers to find all necessary Information.

Find more info here^[5].

• All Red Hat subscriptions follow the Break-in-Subscription policy where subscription renewal for an expired subscription requires payment for the period between the expiry and the renewal. Sourcing teams must analyse the costs of back payments before deciding to renew an expired subscription or letting a subscription expire.
• Red Hat also follows “All or None” subscription policy for its product families. It means that as long as there is at least one active subscription all RHEL devices require and active subscription. This rule ensures that customers fully license their use of RHEL products, rather than only partially licensing their deployment and sharing the update packages, leading to loss of revenue for Red Hat.
• In the event of an audit, Red Hat will backdate RHEL installations that at some point in time did not have an active subscription attached. This is typically done by comparing the OS install date with the RHEL subscription activation date.
• Other Linux distributions are capable of installing and running RHEL packages and often require an active RHEL subscription. In the event of an audit, Red Hat will request to also scan CentOS, openSUSE, Fedora, Oracle Linux and Scientific Linux systems.

2. RHEL Licensing Pitfalls

On the outside, RHEL licensing seems quite straightforward. However, continuing from the Executive Summary, it’s evident that challenges for RHEL license management are increasing as their product line evolves and adjusts over time.

In the following sub-sections we’ll detail the most common challenges we’ve encountered.

Visibility Risk

The tools, technology and processes utilised might not be enough to effectively track RHEL Licenses and Deployments across multiple geographies and IT environments.

• We have seen procurement processes and ERP tools stumble in managing RHEL license tracking.

Case Study: An international financial services company was tracking all its RHEL purchases through Coupa, a business management software. Coupa was considered the single source of truth for RHEL subscriptions. However, the company was also using RHEL managed instances from public cloud providers. This led to double licensing for the same cloud instances.

• Organisations often don’t properly use (ITAM/SAM or general IT) discovery tools to their capabilities and have missed RHEL deployments in non-traditional IT environments such as containers and cloud managed instances.

Complex Licensing Agreements

RHEL purchases are usually made through retail, order forms or invoices. As previously stated, there is usually no separate agreement signed between a company and Red Hat. However, all Red Hat products are governed by the Enterprise Agreement^[6] and Product Use Cases.

These agreements are complex, and their limited visibility is also a challenge. In most purchases, these agreements are agreed upon just as a footnote without proper vetting of the terms and conditions.

Compliance Risk

RHEL is a widely used technology across IT environments all over the globe. Traditional datacenters, public clouds, containerised environments and virtualised environments have a substantial RHEL presence and often require subtle changes in the licensing terms and conditions.

IT leaders must have a view of all terms and conditions to effectively license an environment for RHEL OS. They must also be aware of bundling and exclusion scenarios to enable effective licensing.

The terms described in Product Appendices^[7] affect the way in which a Red Hat product can be utilised. IT leaders must be aware of the use cases before allocating subscriptions across IT environments.

Red Hat’s policy of “All or None” (explained in “1. Managing Red Hat Contracts and Procurement”) is a big contributor to the compliance risks faced by organisations with distributed ownership of compute environment. All deployments of RHEL must have valid subscription which entails that IT leaders must allocate subscriptions to assets owned by all units within the company irrespective of whether the unit requires Red Hat support or not.

The “Review” rights included in the Enterprise Agreement allows Red Hat to effectively audit any customer to validate compliance with the agreement and the licensing terms. These rights enable compliance risks for all users of Red Hat products.

Red Hat’s audit clause is typically found in Section 10 of the Enterprise Agreement, under “Review”. The clause typically states the following (example from the US version of the Enterprise Agreement^[8]):

Review. While the Agreement is in effect and for one (1) year thereafter, Red Hat or its designee, acting in accordance with Section 8, may inspect your facilities and records to verify your compliance with this Agreement. You agree to (a) respond promptly to requests for information, documents and/or records; (b) grant appropriate access for on-site visits in order to verify your compliance; and (c) reasonably cooperate in connection with any such verification. Red Hat will provide at least ten (10) days prior written notice for any on-site visits, and will conduct on-site visits during regular business hours in a manner that reasonably minimizes interference with your business. If Red Hat notifies you of any noncompliance or underpayment, then you will resolve the non-compliance and/or underpayment within fifteen (15) days from the date of notice. If the underpayment exceeds five percent (5%), then you will also reimburse Red Hat for the cost of the inspection.

Here’s a summary of the key points of this clause:

1. Purpose and Duration: The clause allows Red Hat or its designee to inspect your facilities and records to verify compliance with the Agreement. This right extends while the Agreement is in effect and for one year thereafter.
2. Inspection Process: The clause outlines how Red Hat can conduct these inspections. You are expected to respond promptly to requests for information, provide access for on-site visits (with at least ten days prior written notice), and cooperate with the verification process.
3. Non-Compliance and Underpayment: In cases of non-compliance or underpayment discovered during the audit, you are required to resolve these issues within fifteen days from the date of notice. If the underpayment exceeds five percent, you must also reimburse Red Hat for the cost of the inspection.

This clause is a standard feature in enterprise software agreements, allowing the provider to ensure that their software is being used in accordance with the terms of the license.

Cost Optimisation

RHEL’s widespread availability, diverse licensing terms, policies, and pricing provide numerous opportunities for optimising license costs and engaging in arbitrage.

IT leaders must not only be champions of licensing terms but also understand the nitty gritty of IT environments which would allow them to effectively save costs and suggest licensing optimisations to stakeholders.

Case Study: By changing the type of RHEL subscription to from a standard RHEL SKU to RHEL for Virtual Data Centers, an organisation was able to use RHEL virtualisation benefit and save $130,000 yearly in subscriptions.

Information Security Risk

RHEL has a specific product support roadmap for all its versions. It can be accessed following this link^[9].

Running legacy or older versions of RHEL may generate additional costs (Subscription Add-Ons required) as well as could be a possible breeding ground for information security risks (malware & other malicious attacks).  IT leaders must always monitor and report these risks to their IT stakeholders as well as relevant management committees so that the organisation is aware and primed to face these risks.

3. RHEL Products in Consideration

Red Hat Enterprise Linux has over 150 SKUs (term that refers to Red Hat’s Stock Keeping Unit, i.e. unique subscription product id) of various types which are utilised in varying environments. In this white paper, we shall keep our focus on the following RHEL Subscriptions:

RHEL product families have both base Subscriptions and Add-On subscriptions. Add-On Subscriptions follow the same metrics as the base Subscription. Add-On Subscriptions can be purchased in a bundle with the base subscription or can be purchased separately as per requirements.

There are other RHEL base products targeted to specific applications (SAP), compute assets (HPC) and IT Environments (Disaster Recovery) as well as Add-ons that cater to specific requirements (Resilient Storage, High Availability).

Usage of these product families and add-ons is dependent on each individual case and currently out of scope of this white paper. However, since these products follow the same metrics, compliance licensing for these products and add-ons is like that described in the following sections for the above four product subscriptions

Below is a list of add-ons for various RHEL products which provide specific functionality and require subscriptions in addition to the base RHEL Subscription.

4. Subscription Support

Even though RHEL is an open-source software, the subscription support from Red Hat has many benefits for the infrastructure and application management teams. The available support levels and their features can be reviewed following this link^[2].

Red Hat generally provides three types of subscription support for RHEL: Self-Support, Standard Support and Premium Support. The type of support required usually depends on the RHEL infrastructure teams and how they want to manage the RHEL environment.

IT leaders need to be aware of limitations regarding each support level and the environment these support levels can be applied at. These limitations can also be reviewed in the subscription guide.

Some licensing terms such as “Physical Node”, “Virtual Guest”, “Stacking”, “Socket-Pair” etc. are also defined in detail in the subscription guide referenced above. IT leaders need to understand these concepts to license a RHEL environment for optimal cost and risk effectiveness.

Some of the RHEL relevant terms used extensively are reproduced below:

Subscription Management Process

To run an effective and compliant subscription management we need a minimum set of information. For an ideal subscription management the following data should be collected:

1. Detailed subscription entitlement information including contracts, contract addendums, order forms, invoices, and any other types of purchasing documents;
2. Information related to the subscription activation status of each device;

Most tools don’t pick up this information. You can use the subscription-manager command in the terminal to display the subscription status of the device:

$ subscription-manager status

Read more in the Appendices: A1. How to check if a RHEL instance is licensed; A2. RHEL Subscription statuses explained.

1. Access to Customer Portal and reports or documents including data such as entitlement, registration, ownership, usage etc.;
2. Access to any relevant SaaS portals/reports that list SaaS usage, SaaS entitlements;
3. Software deployment information preferably from centralised ITAM/SAM or generic IT tools or through painstaking collection of software deployment information from each compute asset using scripts or manual terminal commands (not desirable);
4. Compute asset information including Device Model, Device Type, Sockets, CPUs, Cores, CPU Model, logical CPUs, ;
5. Complete IT topology (datacenter → cluster → physical devices → virtual devices → containers) for the relevant RHEL environments;

There are multiple ways in which the above information can be collected. In following sections, we would explain the ways to collect all the above information as well as their utilisation in RHEL license compliance.

Data Collection

The data collection of a given RHEL subscription management project can be divided into three types of data:

1. Entitlement Data;
2. Software Inventory Data;
3. Hardware Inventory Data;

Let’s see what each one of them entails.

1. Entitlement Data

Refers to the RHEL subscription entitlement information, i.e. documentation that proves you bought the software or that you are entitled to use it. The most common ones are listed below:

The ideal strategy to collect entitlement information would be a combination at least two of the following sources.

2. Software Inventory Data

Refers to RHEL deployment information, i.e. what is installed on each device in scope. This includes all compute assets where RHEL OS, or other distributions capable of installing RHEL packages, and the related add-ons installed. Some of the sources listed for entitlements such as Red Hat Customer Portal, Red Hat Satellite, Public Cloud Billing Reports would also have deployment information. In addition to these sources, you may also leverage any of the following sources:

Scanning scope should to include other relevant Linux distributions

Several Linux distributions are capable of running RHEL packages. Some of these distributions include:

1. Rocky Linux: A free and open-source fork of CentOS 8, completely binary compatible with RHEL1.
2. AlmaLinux: Another CentOS 8 alternative, 1:1 binary compatible with Red Hat Linux, and developed to fill the gap left by the discontinuation of CentOS 82.
3. CentOS Stream: A rolling-release distro that serves as the upstream release for RHEL2.
4. Fedora: An upstream community distribution that allows Red Hat to beta test new features before they are included in RHEL2.
5. Oracle Linux: A distribution based on RHEL and maintained by Oracle3.

These distributions are all based on the source code of Red Hat Enterprise Linux (RHEL) and are capable of running RHEL packages. A RHEL subscription is required if RHEL packages are installed on devices running any of the above mentioned distributions.

3. Hardware Inventory Data

Refers to hardware or compute information.For RHEL subscription management we would need the following hardware data:

Capturing the RHEL OS Version could dictate whether Extended Lifecycle Support (ELS) is required for that installation in addition to the base subscription.

The type of cluster (Active/Passive/DR) could define the MSRP of the RHEL subscription purchased.

Subscription Allocation Analysis

For the purpose of this white paper we’ll cover the most common scenarios and provide explanations.

Physical Server or Node environments

This environment shall be licensed with a RHEL Server subscription with the metric of one RHEL subscription → 1 Socket-Pair/2 Virtual Guest.

Scenario: Physical Server with 2 occupied sockets and RHEL 9 OS in production environment.

• This device can be licensed with either Standard or Premium subscription based on support requirements;
• This server may not be licensed with Self-Support subscription since it is in a production environment;
• This server has two occupied sockets, hence it needs one RHEL Standard or Premium subscription is required;

Notes

• If the server had 4 sockets but with only 2 occupied by a processor, it would still need only one (1 Socket Pair) RHEL subscription as RHEL is licensed based on number of “occupied” sockets;
• If the server had 4 sockets with all occupied by a processor each, it would require two RHEL Subscriptions (2 Socket Pair) stacked;
• If the server was in a non-production environment, we could have used Self-Support subscription to license this server to achieve a lower cost;
• Since Self-support subscription cannot be stacked, even in a non-production environment, a 4 socket (2 Socket pair), fully occupied server cannot be licensed with self-support subscription;
• If the server was running a RHEL version which is in its Extended Life Phase (4, 5, 6, 7), an Extended Lifecycle Support (ELS) Add-On would be required along with the base RHEL subscription. This ELS Add-On would have the same metric as base subscription, so we would need one ELS Add-On Subscription for a 2 occupied socket configuration;
• Any of the other Add-Ons such as High-Availability, Resilient Storage, Satellite, etc. would require the same subscription count as that of the base RHEL subscription;

Virtual Guest environments

This environment shall be licensed with RHEL Server subscription with the metric of one RHEL subscription → 1 Socket-Pair/2 Virtual Guest.

Scenario A: RHV Virtualised Host (2 Occupied Sockets) with 5 VM Guests running RHEL 9

• This server can be licensed with either Standard or Premium subscription based on support requirements. However, all subscriptions attached to this environment must have the same support level i.e., either Standard or Premium;
• Since RHEL is installed at the Host virtualisation layer, we need to license both the host and the guest VMs with RHEL subscriptions;
• One (Socket Pair) RHEL Subscription is required for the Host;
• 3 RHEL Subscriptions (covering 6 Virtual Nodes) are required for the Guest VMs. Even though there are 5 VMs, RHEL Subscriptions cannot be broken to accommodate a single occupied socket or a single VM. These environments must be licensed with full subscriptions i.e., 1 socket pair or 2 Virtual Nodes;

Notes

• This environment cannot be licensed through Self-Support subscription since the subscription does not support stacking or production environments;
• Our earlier note regarding ELS Subscription would apply to this scenario as well. Either the host or any of the VMs running a RHEL version in Extended Lifecycle Phase would require an ELS Add-On subscription;
• Hosting 5 Guests VMs is not a limiting factor but just an example. The count of Guests VMs can be a deciding factor in choice of RHEL Server Subscription or a RHEL for VDC Subscription as explained in later sections;
• Other Add-on subscriptions shall follow the same licensing terms as the base RHEL subscriptions;

Scenario B: VMware Virtualised Host with 5 VM Guests running RHEL 9

• This server can be licensed with either Standard or Premium subscription based on support requirements. However, all subscriptions attached to this environment must have the same support level i.e., either Standard or Premium;
• Since the Hypervisor layer is not RHEL, only the guest VMs require a RHEL Subscription;
• This environment would require 3 RHEL subscriptions (covering 2 Virtual Nodes each) to be correctly licensed;

Unlimited Virtualisation environments

This environment should be licensed with RHEL Virtual Data Center (RHEL VDC) subscription with the unlimited virtualisation. This subscription is available on the Socket-Pair basis only.

The only difference between this environment and virtual environment in Scenario 2 is that in this environment, there is no licensing limit for the number of VM guests which can run in a physical environment.

Scenario: VMware Virtualised Host (2 occupied sockets) with 20 VM Guests running RHEL 9

• High density virtual environments such as these can be licensed with the RHEL VDC subscription;
• This subscription type allows licensing the host without consideration for the count of Guest VMs running on the host;
• For this configuration we would need one (Socket Pair) of RHEL VDC subscription;

Notes

• Subscription stacking is applicable in RHEL VDC in case of more than 2 occupied sockets in the Host configuration;
• If any of the guest VMs are running RHEL versions in the extended lifecycle phase, RHEL Extended Lifecycle Support for Unlimited Guest Add-On would be required for this environment. The count would be equivalent to the base RHEL VDC subscription;

Optimisation Scenarios

The above environments may also be licensed with RHEL Server based on Virtual Nodes (1 Subscription = 2 Virtual Nodes). In this licensing structure, we would need 10 RHEL Server Subscriptions (20 Nodes / 2).

The optimisation opportunity arises from arbitrage between prices of RHEL VDC Subscriptions and RHEL Server subscriptions. Considering retail prices for this configuration, the price of licensing would be as follows:

It is evident that there is clear cost benefit in choosing RHEL VDC subscription for this configuration.

Notes

• Calculate the break even point in terms of VM density for every Host environment based on prices to decide which subscription to purchase. For example, for the above prices and configuration the breakeven point would be 6 VM Guests per host;
• Another aspect to consider is prices of add-on for both set of subscriptions. In the RHEL Virtual Node based licensing, we can allocate Add-Ons for specific VMs. However, we need to purchase Add-Ons for the complete environment in RHEL VDC based licensing;
• Keep in mind the cluster formation that these Hosts may reside in. Unless we have limited motion of VMs across hosts in the same cluster, all the hosts of those clusters (Hot Cluster) would require a RHEL VDC License as well. However, moving RHEL VMs when licensed based on RHEL Server 2-Virtual Nodes metric, can move across various hosts without requirement of licensing those hosts;

Disaster Recovery (DR) environments

DR environments for the purpose of RHEL licensing are divided into three categories:

Public Cloud environments

This environment should be licensed with RHEL Server subscription with the metric of one RHEL subscription → Socket-Pair/2 Virtual Nodes.

Scenario A: 20 Cloud Instances with RHEL 9 installed, with BYOL

• These instances should be counted as Virtual Nodes for the purposes of RHEL licensing;
• For this environment, we would need 10 of RHEL Server Subscriptions (covering 20 / 2 Virtual Nodes);

Scenario B: 20 Cloud Instances with RHEL 9 installed, with PAYG

• No additional subscription purchase is required for this environment as the cost of instance includes both cost of compute and cost of cloud provider support for RHEL;

Private Cloud environments

A private cloud environment for the purposes of RHEL licensing is considered like on-premises environment. All licensing aspects as discussed earlier in this section shall apply equally to the private cloud environment.

The number and type of RHEL subscriptions required for private cloud environments shall depend on type of virtualisation technology, RHEL OS versions, Dedicated/Shared nature of physical infrastructure, etc..

RHEL Workstation environments

RHEL Workstation subscription has been designed for single user use cases and as per the subscription guide is an optimised OS for high performance, graphically intensive workloads like animation, computer-aided design, and computer-aided engineering (CAD/CAE), and scientific research.

Noteworthy points:

• RHEL Workstation subscription is purchased per installed system.
• Each subscription allows you to use RHEL on “one” 2-CPU personal computing system AND 1-4 Virtual Guests (depends on SKU) hosted on the same personal computing system.
• RHEL Workstation subscription use cases are different from RHEL Developer subscription and should be purchased as per requirement. Review use cases in Product and Services Appendices^[7]
• RHEL Workstation subscription can be utilised in VDI technologies as well to provide Virtual workstations to users. Licensing RHEL Workstation for Private Cloud VDI environments is little ambiguous. We have seen contradictory licensing advisory for these environments. To explain this ambiguity lets review a VDI environment with 1000 RHEL based virtual workstations:
• RHEL Workstation subscriptions are purchased per installed system. As per Red Hat definitions, a system maybe defined as “a system which contains or executes all or a portion of the Software including, without limitation, a server, workstation, laptop, virtual machine, container, blade, node, partition, appliance or engine, as applicable.”

If we consider each of 1000 virtual workstations as a system, 1000 RHEL Workstation subscriptions would be required for this VDI environment.

• RHEL Workstation allows for a maximum of 4 Virtual Guests per installation on the personal computing system.

If we consider, each of the virtual workstations as a virtual guest as per the above use case definition, 250 RHEL Workstation subscriptions would be required for this VDI environment.

For organisations planning to implement VDI environment for their RHEL Workstation requirements, we suggest consulting a Red Hat licensing advisory team to quantify the number of licenses required for their environment.

• RHEL Workstations are also available from AWS as a Service and details for this service are available at the following
• Organisations must take care not to use RHEL Workstation subscriptions for their production servers. Review use cases in Product and Services Appendices^[7]
• Various RHEL add-ons are available with the workstation subscription and can be purchased either in a bundle or separately. Licensing for add-ons would follow the base license metric for the workstation subscription.

Note: Various Licensing Rules & their official sources referred in the above sections are detailed in Appendix-A

Conclusion

Navigating the complexities of Red Hat’s licensing terms and policies can be daunting, especially as these evolve over time. Expertise in Red Hat licensing is both rare and valuable, developed through years of practice in a field where knowledge is scarce. Traditionally, Red Hat has employed a license-only enforcement structure, meaning their products do not restrict usage based on the absence of licenses or subscriptions. However, this approach, coupled with the IBM acquisition and the resultant changes in ownership, has introduced more intricate licensing metrics and various bundling scenarios. As a result, IT stakeholders must be vigilant and prepared to manage Red Hat reviews and IBM audits effectively.

Appendices

A1. How to check if a RHEL instance is licensed

Here is a step-by-step tutorial that includes code snippets detailing how to identify the number of sockets on a device, the version of RHEL running, if there is an active subscription, and the type of subscription needed:

Once you have identified the number of sockets on the device, the version of RHEL running, the active subscription status, and the type of subscription needed, you can choose the appropriate Red Hat agreement type that fits your needs.

Other Linux distributions

To check if Linux distributions capable of running Red Hat Enterprise Linux (RHEL) packages have RHEL packages installed, you generally use package management tools specific to those distributions. While these distributions are RPM-based (like RHEL), they might have different package managers or frontends. Here’s how to check for RHEL packages on some of these distributions:

A2. RHEL subscription statuses explained

A3. RHEL Agreement Types

Red Hat typically offers various agreement types that cater to different requirements of their customers. In this blog post, we’ll discuss the different Red Hat agreement types and their features.

Individual Subscription Agreement (ISA)

Individual Subscription Agreement or ISA is a type of Red Hat agreement that is suitable for individual developers and small businesses. This agreement offers access to Red Hat’s software solutions, including Red Hat Enterprise Linux (RHEL), Red Hat OpenShift, and Red Hat Middleware. It also includes support, updates, and access to Red Hat’s knowledge base.

ISA is a pay-as-you-go subscription, which means you can choose to renew your subscription monthly, quarterly, or annually. This agreement is perfect for businesses that are just starting and need to keep their costs low.

Enterprise Agreement (EA)

The Enterprise Agreement or EA is a Red Hat agreement type that is suitable for medium to large businesses. This agreement is designed for organisations that require a comprehensive solution and a long-term commitment to Red Hat’s software solutions. It includes access to all Red Hat products and services, including RHEL, OpenShift, Middleware, and Cloud Suite.

The EA agreement offers flexible pricing and terms, and it can be customised to fit the specific requirements of your business. It also includes dedicated support, training, and consulting services. The EA agreement is perfect for businesses that need to scale their IT infrastructure and require a comprehensive solution.

Cloud Access

Cloud Access is a Red Hat agreement type that is designed for businesses that use Red Hat solutions in public cloud environments. This agreement allows customers to use their Red Hat subscriptions in the cloud and on-premises environments simultaneously. It includes access to all Red Hat solutions, including RHEL, OpenShift, and Middleware.

Cloud Access provides flexibility and portability for businesses that require hybrid cloud solutions. It also offers cost savings by enabling businesses to leverage their existing Red Hat subscriptions in the cloud. Cloud Access is perfect for businesses that need to deploy their applications in hybrid cloud environments.

Academic Subscription Agreement

The Academic Subscription Agreement or ASA is a Red Hat agreement type that is designed for academic institutions, including schools, universities, and research centers. This agreement provides access to Red Hat’s software solutions, including RHEL, Middleware, and OpenShift. It also includes support, updates, and access to Red Hat’s knowledge base.

The ASA agreement offers flexible pricing and terms, and it can be customised to fit the specific requirements of your academic institution. It also includes dedicated support, training, and consulting services. The ASA agreement is perfect for academic institutions that need to provide their students and faculty with access to Red Hat’s software solutions.

Glossary