Red Hat Licensing.

The term itself is a bit of a misnomer as Red Hat don’t sell licenses,
rather they sell subscriptions. But many of the methods of licensing perpetual
software still apply to subscriptions, and by the end of this course you will be familiar
with the metrics and subscription options that Red Hat offers.
Red Hat products fall under various categories. It is important to understand each of these categories
as many of them need require different licensing approaches.

Linux Platforms
The most popular of the Linux platforms if Enterprise Linux, usually referred to as RHEL.

Middleware
Includes the JBOSS Application server, Data Grid, Fuse, and Decision Manager amongst many others.
Middleware is software that provides common services and capabilities to applications. It acts like
the connective tissue between applications, data, and users.

Virtualization Platform
Red Hat offer two platforms; Virtualization and Hyperconverged Infrastructure. Virtualization is
technology that allows you to create multiple simulated environments or dedicated resources from a
single, physical hardware system.

Cloud Computing
Cloud computing is the act of running workloads within clouds—which are IT environments that
abstract, pool, and share scalable resources across a network. A number of Red Hat products can be
utilized both in the cloud and on-premise, while some are only available in the cloud.
As with perpetual licensing, methods by which usage is measured for Red Hat subscriptions are
varied. This section will explain the metrics and how they are applied to the subscription model.
Socket-pair
This is how RHEL, in particular, is best licensed in a physical environment. Put simply, a socket-pair
license is required for 2 CPUs in your physical environment. For example, if you have a total of 48
CPUs you would require 24 socket-pair licenses. This model can also be used to license virtual
instances in the cloud or heavily virtualized environments.
Virtual Instance Pairs
This model is best for low and medium-density virtualized environments. Subscriptions here are
based on the number of instance-pairs running the product. For example, 16 VMs will require 8
subscriptions.
Cores
Products such as JBOSS are licensed by processor cores. They are based on the lesser of the total
virtual cores in use across the virtual machines or the number of physical cores in the server.

Example: a server with 12 Physical cores but only 8 allocated to VMs would require 8 core
subscriptions:

2-Cores
Similar to the concept above, but a single license covers 2 cores. This licensing model is used for the
OpenShift Container platform and is based on the number of logical cores on the CPUs in the system
where OpenShift runs. This model is used for both virtual and physical infrastructures.

Please note that logical cores in this instance does not include hyperthreading. A 2-core
hyperthreaded Intel chip may display 4 cores, for example, but only one 2-core license is required.

Systems that require an odd number of cores will need to use a full 2-core subscription. For example,
a system that is calculated to require only 1 core will end up using a full 2-core subscription once it is
registered and subscribed.

User
Certain subscriptions, such as a Red Hat developer subscription, are based on ‘users’. Simply put, one
user subscription covers one individual.
Stacking
Stacking gives you the flexibility to aggregate Red Hat subscriptions to accommodate any size physical
server. The base Red Hat Enterprise Linux model, for example, includes entitlements for two sockets,
which is all you need for a 2-socket server. If you have a 4-socket server, you would need two Red Hat
Enterprise Linux subscriptions. For an 8-socket machine, you would need four subscriptions, and so
forth. In this way, your Red Hat Enterprise Linux subscriptions can “stack” to scale to any size system.
Moreover, as your physical infrastructure changes, you can adjust your subscriptions to match your
infrastructure. You can replace two 2-socket systems with a 4-socket system and vice versa without
increasing the number of subscriptions. This method can also be used for the core and 2-core
metrics.

Repurposing
Subscription repurposing gives you another degree of flexibility. It lets you change a physical 2-socket
Red Hat Enterprise Linux subscription into a 2-virtual-instance subscription without contacting Red
Hat to adjust your terms. Repurposing virtual instance-pairs as physical socket-pairs is also possible.
This allows you to convert your infrastructure from physical to virtual and have your Red Hat
Enterprise Linux subscriptions convert along with you. The ability to repurpose between physical and
virtual deployment applies to Red Hat Enterprise Linux Server and its add-ons.
With Red Hat subscriptions, there are no license or upgrade fees. And Red Hat doesn't charge additional
maintenance fees, per-incident support fees, or user access fees. This model means there are no upfront costs
that lose value over time. You only pay for what you’re using, meaning software isn’t sitting there unused.
Subscription comes with a number of benefits, including:

Ongoing delivery Commitments

• Patches • Hardware certifications
• Bug fixes • Software certifications
• Updates • Cloud Provider certifications
• Upgrades • Software assurance

Technical support Expertise

• 24/7 availability • Security Response Team (SRT)
• Unlimited Incidents • Customer Portal
• Specialty-based routing • Knowledgebase
• Multi-vendor case ownership • Access Labs
• Multi-Channel • Training Curriculum

Red Hat products are provided on a per-instance or per-installation subscription basis, which gives customers
access to all subscription benefits during the subscription term. This means that while customers have an
active subscription for a Red Hat product, they must maintain subscriptions for each and every instance or
installation of Red Hat software being used in their environment.

When working out subscription requirements you count the number of resources installed with or executing a
Red Hat software or product and apply a subscription to each instance. By maintaining this one-to-one active
relationship with Red Hat, customers are able to distribute the benefits throughout their entire organization.

This is what some call the ‘all or nothing rule’. It means that within a product family, you cannot pick and
choose which installations are covered with active Subscription Services, i.e. if you have 19 JBOSS instances,
you either have to purchase 0 subscriptions or 19.

Support Levels
With many Red Hat products, including RHEL, there are 3 levels of support for Production environments:
• Self-Support
• Standard
• Premium

Only Standard and Premium are available for JBOSS subscriptions.

It is important to note that support levels must match for each family of products. In other words, you can’t
have Premium support for some instances of RHEL and Standard support for others.
Licensing requirements can vary depending on the environment and how it is set up.

Development:
For RHEL, when there are teams of 25 or more, there is Red Hat Enterprise Developer. This comes
with 2 support variants:

• Professional = Response time of 2 business days

• Enterprise = Response time of 4 hours

For smaller teas, including individual developers, the is Red Hat Developer Workstation. If “self-
support” isn’t sufficient, Professional or Enterprise support can be added.

When it comes to JBOSS, developments environments are not required to be covered. Instead, every
16 cores of subscription purchased for other parts of the business allow use by up to 25 developers.
Also, all subscriptions include development use for ALL products in the JBOSS Middleware portfolio,
although support is only provided for the subscribed product.

Test/ QA/ Pre-Prod/ UAT

Subscriptions are required for these environments.

Disaster Recovery

Hot
The server is on and ready to go – such as within a failover cluster. In this case, the backup server
must be fully covered with subscriptions – just as the production server. All servers must be covered
with subscriptions of the same configuration and support SLA.

Warm
Here, the server is periodically (no more than every 60 days) turned on to receive backups and
updates. Warm backups are used in scenarios such as:

• Mirroring
• Replication
• Log-shipping

All servers must be covered with subscriptions of the same configuration and support however, the
warm server subscriptions are 50% of the production subscription costs.

Cold
A cold backup server has the required software installed but is then turned off until the event of a
disaster, or for periodic procedure tests. Red Hat do not allow you to apply updates to the installed
software until the backup server moves into production. As the 2 servers are never running
simultaneously, you do not need to acquire subscriptions for Cold backup servers.
Although Red Hat licensing may seem complex at first, the rules are consistent and are meant to be
easy to interpret. Below are the important take-aways from this course:

• Red Hat offers subscriptions and not perpetual licences.

• Subscriptions are usually based upon the sockets or cores consumed by the server on which the
product is installed, or they are based on instances of the installed product.
• Subscriptions can be ‘stacked’ to cover larger servers
• Subscriptions can be changed (2-socket to 2-virtual instance, for example) to suit the customer’s
needs, without contacting Red Hat first.
• There are two or three support levels depending on the customer’s needs.
• Support levels must match for each product set.
• Development is usually licensed by the number of developers and is sometimes included in the
cost of production licences.
• Most other environments require licensing, but certain DR scenarios do not.

www.licensedashboard.com
[email protected]
+44 (0)1904 562 217 - UK

License Dashboard Head Office

License Dashboard
Blenheim House
York Road
Pocklington
York
YO42 1NS