Close this search box.

Reserved area

Close this search box.

IBM compliance: why it is so complicated to verify it

What information we need to monitor to be compliant

IBM is one of the world's largest providers of infrastructure and software, and its intense R&D and acquisitions (think Red Hat,leader in the open source solutions market) have led it over time to a very broad and diverse product portfolio, which is also matched by a growing profit ($927 million in the first quarter according to Wall Street).

IBM's licensing is also very complicated by virtue of these numbers: more than 18,000 products and more than 32,000 "part numbers", or the different types of offerings that involve a combination of products (and metrics) into which the various software components fit.

Adding complexity is also the constant evolution of this portfolio: even if you have a clear idea of the edition and version of the products purchased, these are not immutable.

Their licenses, in fact, can change, and the news is given in the so-called "announcement letters" because IBM keeps doing extraordinary operations (e.g., HCL or Red Hat), launching new products, and there can be renaming or new bundling so that you have hundreds of thousands of different ways of bundling different products, all with different licensing rules.

We have seen in another article (go here to read it), that IBM has introduced from the 1st of May 2023, an annual obligation for the creation of usage reports for all software contained in the Passport Advantage to be provided to the vendor within 30 days of the request. They will have to be prepared in the format required by IBM.

We do not have the format available yet (it will be published by the end of the year), but we do know what information IBM will focus its audits on. To understand them, let's try to put the complicated IBM licensing landscape in order. Let's start with agreements.

What are IBM agreements?  

Usually when we refer to IBM licensing agreements, we have to take into account three levels that give us an overview:

  • the basic licensing agreements, which describe in detail what was purchased
  • the commercial agreements, which are those that describe how to purchase licenses and the terms under which they are managed
  • the enterprise-level agreements, which are negotiated with the vendor

In the Basic Agreements, we find the IPLA (International Program License Agreement), which is nothing more than the standard agreement that IBM customers accept when they download, install, or purchase any IBM product. It contains hyperlinks to a number of embedded documents: the most important are the License Information (LI) and Policies .

The License Information establishes the detailed license terms that apply to each individual program: they are different for each product and version (so if you upgrade the version, the LIs change and so do the terms of the conditions). So you have to be careful whenever there is a change on one of those products. Generally inside we find this information:

  • Program name and PID number (product identifier), which links to usage rights
  • Details of bundled and/or supporting programs that may be installed to provide functionality to the licensed program and any restrictions on their use (e.g., if it is running on separate servers you need to make sure you have PVU-based licenses for both machines)
  • licensing metrics that can be used to license the program, (including any conversion tables)
  • components that must not be used, known as "prohibited components"(Prohibited Components))
  • components that may be installed but are not used to establish license requirements (Permitted Components)
  • specific restrictions on customer use of the program (e.g., related to metrics on authorized users)
  • use of the program in a non-production environment

Here we can see an example of License Information (LI) for Cognos, one of IBM's most popular programs.

We now come to Passport Advantage (PA), which is the contract that concerns us: it falls under commercial agreements, along with Passport Advantage Express (PAX) and Embedded Software Agreements (ESA),, which are focused on business partners. PA is the agreement that manages volume purchases of IBM licenses. Unlike PAX, which is purely transactional and designed primarily for targeted purchases or small orders, it has a lot of flexibility and allows points to be accumulated for discounts.

Within it, we can find hyperlinks to other documents (e.g., Terms&Conditions, Policies, Relationship Suggested Volume Pricing (RSVP), Sub Cap Terms and PVU Calcolator covering sub-capacity terms, Notification, Lifecycle on software lifecycle).

In the IPLA, IBM refers to the audit clauses (i.e., it enshrines the vendor's right to audit), but it is the PA that provides details on how it will be managed (and we have also seen this with the 4.1 amendment).

At the heart of the PA is the Access Portal, which is the entry point for administering licenses and understanding what user rights are.

Registration is free, but to access you need an IBM ID to which a customer number is linked (it changes in the case of corporate transfers). Since organizations are complex structures, there may be multiple PA sites with respective individual numbers, which are treated as separate arrangements in the event of an audit.

Within a PA site, you can keep track of migration histories (e.g., from one PA site to another, in a scenario of acquisitions, disposals, etc.), orders, downloads, and D&E "part numbers" related to products ("D" represents License Entitlements, while "E" Support and Subscription).

The PA also allows retrieval of the various Proof of Entitlement (PoE), which are certificates that IBM sends to customers who purchase software products. The PoE confirms eligible products and the level of use for which you are authorized. It includes important information about the order, such as IBM customer number, IBM site number, and IBM order number.

Finally, the last type of IBM agreements involve enterprise agreements: enterprise license agreements (ELAs), which are mechanisms for purchasing large volumes in favor of a price freeze. They are usually standardized, but should be checked because special conditions may have been included in the negotiation phase (e.g., clauses, exemptions) because they provide maximum flexibility from a negotiation standpoint.

What information will we have to provide to IBM?

As stated in the March 31, 2023 announcement, audit topics in the report will cover:

  • the quantities distributed for each IBM program deployed
  • full details of "license ratios" for bundled programs such as IBM Cloud Paks (a "ratio" determines how many licenses are needed for deployments of each product e.g., 4 VPCs of WebSphere MQ Program usage require 1 VPC license of Cloud Pak for Integrations). This information is retrieved in the License Information document in the Licensing Terms for Solution Bundles (e.g., 4 Virtual Processor Cores (VPC)/1 VPC; 70 Processor Value Unit (PVU)/1 VPC; 4 Authorized Users / 1 Resource Unit);
  • Distributed quantities related to bundled program license metrics.
  • Distributed quantities of IBM programs based on the "license ratio" of the bundle.

For each individual program, it will be necessary to indicate:

  • the license metric (e.g. PVU, VPC, Install, Authorized User, Concurrent User, Terabyte, etc.).
  • The type of license (perpetual, monthly, Saas, subscription, etc.).
  • The "part number" of the license or Trade-Up (D-Part) and/or the "S&S part number (E-Part)
  • Whether the program is in Subscription&Support (S&S)
  • whether the program is installed on a physical, virtualized or containerized server
  • whether the program is installed on-premises, at a service provider, or at a public cloud provider

In addition to this, the PA site number and business entity corresponding to the installation should be indicated, along with a cross-reference for each program to relevant records, system tool outputs and system information, and other supporting documentation from which the deployment counts (Deployment Data) are derived.

Responsibility that deployments are counted using the correct methodologies rests with the customer.

The details for each individual program

We have seen that for each individual program we need to indicate the metrics, license type, bundling, deployment mode, and the presence or absence of additional support services (the S&S, which is a complete solution of product updates and technical support).

There are four variables to consider when we talk about licensing:

  • the type of license (we generally have three types: perpetual, term, subscription). Each provides for a different delivery of S&S services (e.g., in subscriptions, S&S services are included, but you cannot discontinue them before the scheduled end of the subscription)
  • the type of deployment (on-premise, public cloud, hybrid cloud): license type and deployment mode are two sides of the same coin. Traditionally, perpetual or term licenses are appropriate for on-premise deployments, but as more and more customers decide to deploy software on third-party owned infrastructure (public cloud) or on a combination of multiple cloud providers and on-premise solutions (hybrid cloud), IBM allows customers to deploy their licensed software on public cloud with subscriptions.
  • the technology used: licensing, in fact spans a wide variety of technologies, from physical machines to virtual machines and containers. There are technology solutions such as IBM's Certified Containers and Cloud Paks that allow the solution to be created once and deployed anywhere using a single set of licensing rules.
  • the licensing metrics: their measurement counts the deployment and/or use of the product and along with the Terms and Conditions of Use is the value to focus on to determine compliance.

The licensing metrics in IBM are many (more than 100) and can change continuously as products and bundles evolve. IBM itself specifies:

The same metric name may have different definitions from version to version of the same IBM program or across different IBM programs. The definition in the License Information document and Announcement Letter for the specific version you have deployed is the authoritative source.

Metrics are categorized according to the deployment model used (On-premise, Cloud, Mainframe). Generally, the most common ones fall into three macro-groups:

  • user-based (licenses charged according to authorized users, such as Authorized User, Concurrent User, etc.).
  • capacity-based which are based on the amount of processing capacity made available to the IBM program. The most common parameter is the processor value unit (PVU). How processing capacity is measured depends on the platform and whether the license is Full-Capacity or Virtualization Capacity (sub-capacity).
  • others: a large number of metrics fall into the "Other" category, although the most common type are those based on the calculation of a Resource Value Unit (RVU).

Here we can find an overview of IBM metrics . The authoritative sources for verifying metrics related to programs and bundles are always the LI document and related Announcements. However, in the PA we find additional terms for measuring them and any conversion tables.

As you may have seen, the information to be monitored really numerous and the short time (30 days) required by the vendor to provide a report certifying compliance verification requires both skills and automation to quickly find this data.

IBM provides tools for measuring usage, to be installed and configured on its infrastructure to produce quarterly reports and store them appropriately to be kept on-demand in the event of an audit: this is the case with the ILMT - IBM License Metric Tool, which is mainly used to verify compliance of sub-capacity licenses. Another tool is the License Service, which is specific for managing Cloud Paks and their embedded software.

However, with the new Passport Advantage clause, they are not sufficienlty complete, since the change affects all programs (and their respective metrics). The ILMT, in fact, is limited to a few metrics (as you read here, the metrics monitored are Authorized User, Install, PVU, RVU) and not all environments are being measured (and here we will have to provide for a migration plan, as requested by IBM in the new clause).

Given the difficulties related to verifying compliance of all IBM programs and retrieving information about individual applications and bundle recognition and reconciliation with usage rights, we will be holding a webinar on May 18 at 2:30 p.m., "How to Prepare for the IBM Compliance Clampdown" (in the italian language only) where we will explore these elements in detail in light of the changes introduced by Passport Advantage clause 4.1.

We will provide our expertise to help you identify solutions that can quickly and accurately ensure IBM compliance, so you are prepared for vendor requirements!

                                                                Join the webinar!

02-s pattern02

Vorresti avere il controllo sulle tue licenze IBM?