An IBM part number, not the product name, defines what you may deploy. This guide explains how part numbers and Proof of Entitlement records map to software, what a supporting program is, and the bundling traps that turn a restricted-use component into a full-use audit finding.
In IBM licensing, the unit of truth is the part number, not the product name. Admodum is an independent, buyer-side software licensing advisory firm, and this page explains how IBM part numbers, supporting programs and bundles fit together so a buyer can read its own entitlement before an auditor does. A single product such as Db2 or WebSphere exists under many part numbers, each describing a different metric, charge type or use right, which is why the name on a server tells you almost nothing about what you are entitled to run.
A part number distinguishes a new licence from a renewal or a trade-up, a per-PVU charge from a per-VPC or per-user charge, and a full-use entitlement from a restricted-use one. Two lines that both read "WebSphere Application Server" can grant materially different rights. The PVU (Processor Value Unit) and VPC (Virtual Processor Core) distinction, explained in the PVU metric explained and in Cloud Paks and the VPC metric, is itself encoded at the part-number level.
This page is part of the IBM sub-capacity licensing pillar. It pairs naturally with the Passport Advantage agreement structure, which governs how these part numbers are transacted and renewed.
Every IBM purchase generates a Proof of Entitlement, the document that records what you bought. The PoE is anchored on a part number, and reading the two together is the only reliable way to establish an entitlement.
The part number on the PoE fixes the metric and quantity, for example a number of PVUs of a named program, or a count of authorised users. The accompanying Licence Information (LI) document for that program defines the use rights: what counts as a single installation, which components are included, whether any bundled software is restricted-use, and any conditions on deployment. A PoE without its LI document is half the entitlement record, and auditors test against both.
The buyer-side discipline is to maintain a register that ties each deployed product to its part number, its PoE, and the relevant LI document. That register is the foundation of audit defence, because it lets you reconcile deployment against entitlement on your own terms. The defensive playbook sits at surviving an IBM licence review.
Many IBM products ship with bundled software that enables them to run. These supporting programs are the single richest source of bundling traps, because they install and behave like the full product while carrying far narrower rights.
A supporting program is software IBM includes with a principal program to make it work, for example a Db2 instance shipped to hold a product's repository, a WebSphere Application Server bundled to host an application, or an MQ component included for messaging. The LI document grants restricted use: you may run the supporting program only in support of the principal program it shipped with. It is not a free instance of Db2, WebSphere or MQ for general use.
The trap is technical rather than contractual. Because the supporting program is fully functional, an engineering team under delivery pressure will reasonably reuse a bundled instance for a second application, with no awareness that the act converts a restricted-use entitlement into a full-use requirement. The exposure accumulates silently until a review surfaces it.
The same handful of patterns account for most bundle-related findings. Naming them is the first step to designing them out of an estate.
Each of these is avoidable with an accurate deployment register and a rule that bundled components are never repurposed without a licensing check. The cost of the discipline is trivial against the cost of discovering the same gaps inside an audit, where they are valued at list and often at full capacity.
The reason these traps persist is organisational rather than technical. The team that buys an entitlement is rarely the team that deploys it, and the deployment team sees a fully functional piece of software with no visible label distinguishing restricted-use from full-use rights. A bundled Db2 instance does not refuse the second connection; a bundled WebSphere does not warn that it is now hosting an unrelated application. The control therefore cannot live in the technology, which is indifferent to the licence terms, but must live in process: a rule that any reuse of an existing IBM component for a new workload triggers a licensing check before it goes live. Embedding that single checkpoint in the change-management process closes the largest source of bundling exposure at almost no cost, and its absence is why the same findings recur across otherwise well-governed estates.
The defence against bundling traps is the same artefact that supports every other part of an IBM position: a complete, current map of what is deployed against what is entitled.
For each product the map should record the part number, the metric and quantity on the PoE, the use rights in the LI document, the environments it runs in, and whether any component is a restricted-use supporting program. Maintained continuously rather than reconstructed under audit pressure, this map turns a review from an investigation into a confirmation. It also feeds renewal leverage, because a buyer who can demonstrate exactly what it uses negotiates from evidence rather than from IBM's deployment estimate.
The wider compliance model sits in the sub-capacity pillar; the negotiation context sits in IBM contract negotiation and renewal. The aggregated reading sits at the IBM knowledge hub, the wider engagement at the IBM practice, and to have a senior advisor build your entitlement map, get in touch.
An IBM part number is the unique catalogue identifier for a specific licensable item, distinguishing the product, the licensing metric, the charge type and whether the line is a new licence, a renewal or a trade-up. Two part numbers can describe the same software under different metrics or use rights, so the part number, not the product name, is what defines exactly what you are entitled to deploy.
A supporting program is software IBM bundles with a principal program to enable it, such as a database, application server or messaging component shipped inside a larger product. It carries restricted use rights: you may deploy it only in support of the principal program, not as a free-standing instance. Deploying a supporting program for an unrelated workload requires a separate full licence.
Bundled components carry restricted-use rights, but technically they install and run like the full product. Teams frequently reuse a bundled WebSphere, Db2 or MQ instance for a second, unrelated workload, which converts a restricted-use entitlement into a full-use requirement. Auditors look specifically for this because it is common, hard to see internally, and expensive to remedy.
Read the Proof of Entitlement against its part number and the product's Licence Information document. The part number fixes the metric and quantity; the Licence Information document defines the use rights, including any restricted-use supporting programs and bundling conditions. The product name alone is never sufficient, because the same name can ship under several part numbers with different rights.
Only where IBM's terms permit it, typically through a defined trade-up or a flexible bundle such as a Cloud Pak that allows components to be exchanged within a shared metric. Outside those mechanisms, an entitlement is tied to its specific part number and product, and informal reuse of a licence for a different product is a common and avoidable source of non-compliance.
Our white paper sets out the sub-capacity, ILMT and entitlement model IBM tests against, including how supporting-program rights are scoped. A senior Admodum IBM advisor will then build the entitlement map that closes your bundling exposure before a review opens. Renewal moments route to the Renewal Programme; the newsletter carries vendor-policy alerts.