Throughout 2023, ITAA has consistently supported IBM customers with software audit defense services. Following a brief reduction in audits in 2020, there has been a notable surge in Software License Review (audit) notification letters.

While most aspects and challenges of IBM licensing have remained relatively unchanged over time, there are two recent developments that are significantly impacting organizations in 2024. One development is related to old technology, namely the fact that IBM is withdrawing sub capacity eligibility from more legacy operating systems this year. The other development is related to the relatively new technology of containerization and its implications on IBM licensing.

Legacy Operating Systems

As most IBM licensing professionals know, for any licenses with a processor-based metric it is very important that the requirements for sub capacity are met, in particular the use of a sub capacity licensing reporting tool such as the IBM license metric tool (ILMT). However, what is sometimes overlooked is that IBM has a policy of removing sub capacity eligibility for operating systems that are no longer supported by their respective vendors. In 2024 eligibility will be removed for two operating systems that can still quite commonly be found in large organizations:

• Red Hat Enterprise Linux (RHEL) 6 – end of Q2 2024
• Windows Server 2012 (including Windows Server 2012 R2) – end of Q3 2024

As a result, IBM customers who were fully compliant with their sub capacity terms and conditions, may find that in the course of 2024 their compliance risk will suddenly spike due to these policy changes. Full capacity licensing can often require up to ten or twenty times the number of licenses compared to sub capacity licensing, so it is important to anticipate and address this issue as quickly as possible. Note that several operating systems have already been removed from the list of sub capacity eligible technologies, including Windows Server 2008, AIX 6.1, VMware vSphere 6.5/6.7, RHEL v5, Solaris 10, and all HP-Unix versions. It is recommended to frequently check the latest list of unsupported technologies as these may sometimes be announced only 6 months in advance: https://www.ibm.com/support/pages/schedule-removing-items-list-subcapacity-eligible-technologies

Here are the remediation options for addressing IBM products with processor-based licenses installed on soon-to-be unsupported operating systems:

• Upgrade the operating system to a newer version: This is the most straightforward solution, although it may be challenging for technical teams to implement swiftly. Ensure that ILMT/BigFix agents are redeployed on the upgraded system to maintain compliance with sub capacity reporting requirements.
• Decommission the existing system: In some cases, IBM software installations on legacy operating systems may no longer be used or required. In this instance decommissioning the system is the quickest way to remediate the issue.
• Uninstall/migrate IBM software: Rather than decommissioning the system, it is also possible to uninstall the IBM software and install it on a system with a newer OS version. This is the most logical approach when the IBM software itself is no longer required on the old system, but other software on the same system is still required.
• Consider non-processor metric: Some IBM products can be licensed using either processor-based or non-processor-based metrics, such as Authorized User. Switching to these metrics remediates the legacy OS compliance risk.

If it is difficult to implement any of these remediation actions in the near future, the most recent IBM Passport Advantage terms provide some possible leniency in section 10.2e:

“For EPs that no longer meet Sub-Capacity Licensing requirements for which Client would like to continue to license under Sub-Capacity Licensing terms, Client will submit a migration plan to meet the Sub-Capacity Licensing requirements for IBM’s review and approval. During this migration, Client shall maintain the version of ILMT that supported the EP based on the Sub-Capacity Licensing requirements prior to becoming ineligible and continue to generate ILMT reports. With IBM’s prior written consent, Client may manually manage and track such EPs in accordance with item d above.”

According to this clause, an organization who presents a migration plan to IBM to address this issue could be granted additional time to achieve full compliance, subject to IBM’s approval. It is therefore essential that, when the scheduled OS removal dates cannot be met, a migration plan is developed including timelines on when this issue will be remediated.

Container licensing

IBM’s container licensing policy has been around for a while, and we have discussed it previously on this site. In 2024 we are seeing more organizations starting to deploy IBM software in containerized environments, and therefore have also seen a few practical issues that arising when managing IBM software licensing in these environments.

Software Asset Management (SAM) teams in organizations often rely on tools such as the IBM license metric tool (ILMT) to keep track of what software is installed on which systems. The added benefit of this tool is that it enables meeting the requirements for sub capacity licensing. Organizations are sometimes surprised to learn that ILMT is also capable of discovering IBM software deployed in containers running in Kubernetes clusters. Any such software found by ILMT, such as WebSphere Application Server (Network Deployment), DB2, or MQ, will then often be counted towards PVU or VPC software deployment quantities in ILMT reports.

The problem, however, is that this measurement approach does not comply with the requirements for sub capacity licensing, nor does it comply with the requirements of container licensing. Consequently, in this setup such installations would default to full capacity licensing, which can cause significant license compliance (and financial) risk.

ILMT is not designed to track containers running in Kubernetes clusters – any PVU quantities reported by ILMT on such systems will either be too low or too high. In order to license less than the full capacity of the physical hosts on which the containers run; IBM requires that customers use the IBM License Service tool. More information on the container licensing terms and this tool can be found here: IBM Container Licenses

Once the IBM License Service tool has been deployed and is reporting on all IBM software running in containers, remember to ensure these systems are not also being reported in the sub capacity reporting tool (ILMT). This can be achieved by removing the BigFix agent (or ILMT scanner) from systems that are used exclusively to host containers. If the systems are still reporting into ILMT, new components may frequently be discovered as containers move around from worker node to worker node. Therefore, it may not be practical to keep excluding such components through software classification in ILMT.

For organizations who prefer not to install the IBM License Service tool, it is always possible to choose to license the full physical capacity of each host on which IBM container software runs. This option will likely only make financial sense if a dedicated Kubernetes cluster is created that is saturated with a single IBM product.

License compliance audits

As mentioned at the beginning of this article, IBM has been increasingly initiating software compliance audits.

For many organizations, preparing for an IBM software audit is low on the list of their priorities, but being unprepared can jeopardize your legal standing and professional reputation.

At ITAA, we can provide in-depth audit guidance, helping you to prepare for and manage an audit, as well as minimising the impact on your business.

If you relate to the situations outlined in this article and would like support in defense of an IBM software audit, or if you have any questions about the IBM audit defense services ITAA provide, please do not hesitate to contact our IBM Service Director, Koen Dingian.