IPLA, Passport Advantage, the License Information document, and which one binds you. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real SAP negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back. Session two, and today is the paper. Last time we said the metric that applies to you is defined in a document most people never open, and today we open it. Four layers in the IBM contract stack, what each one governs, and which one wins when they disagree. We will read a License Information document properly, we will go through the four sub capacity obligations in their original form, and we will deal with restricted use, which is where good engineers create expensive problems by being sensible. Three knowledge checks. Let's begin.
Five objectives. First, place any question in the right layer, because four documents govern different things and change at different speeds. Second, read a License Information document, so you know where the metric is defined and where restricted use is quietly stated. Third, recite the sub capacity conditions from memory, since those four obligations decide whether your capacity number is the small one or the large one. Fourth, recognise restricted use when you see it in an architecture rather than in a contract. And fifth, build the contract library, which is the folder that turns a three week evidence hunt into an afternoon.
So, the four layers. The IPLA is the base licence terms: signed once, rarely revisited, broadly the same for every customer. Passport Advantage is the purchasing and support programme, which carries bands, renewals and the sub capacity conditions. The License Information document is per product and per version, and this is where the metric definition and the restricted use rights live. And the order forms record what you actually bought, in what quantity, under which agreement, on what date. The rule that governs all four is specificity: the specific document beats the general one. Let me put that in terms of how it actually plays out in a room.
Guest analyst clip.
The specific beats the general, every single time. And notice the practical consequence of that. If you are preparing a position, the first document you go and find is not the one you signed. It is the one covering the exact product, at the exact version, that you are actually running.
Right, the master agreement, and what it genuinely settles. What a program is, including the machine readable parts, the documentation, and anything IBM supplies with it. What use means, which is running it, storing it, displaying it, and crucially making it available to others, and that last phrase does more work than people expect. That the licence is perpetual, so for IPLA products the right to run what you bought does not expire when support does. Verification, which is the clause that permits an audit on notice and obliges you to keep records that make it answerable. And then what it does not settle: your metric, your quantities, and your sub capacity eligibility. Those all live one layer down, which is exactly why arguing from this document tends to go badly.
First knowledge check. The master agreement and a License Information document conflict. Which governs? A, the master agreement, since it is the signed contract. B, the License Information document for the specific product and version. C, whichever is more recent. D, neither, it must be negotiated. Pause here and pick an answer before you continue.
B. The stack is built so that product specific terms qualify the general ones, and the master agreement says so itself. A is the intuition of anybody who has signed contracts in other contexts, and it is the reason licensing teams argue from the wrong document for weeks at a time. C sounds sensible and is not the rule, because the governing question is specificity rather than date. And D describes what happens only when the documents are genuinely silent, which is rarer than people hope. The practical version of this answer: when you are told what a metric means, ask which License Information document, and which version.
Now Passport Advantage, and what the programme actually governs. Volume bands set price by accumulated purchase volume, which means consolidating agreements can move you up a band and splitting them can lose you one. The agreement number ties purchases, entitlement and support together, and acquisitions arrive with their own, which is how estates fragment quietly. The support renewal is the annual annuity and its uplift, and it is your one scheduled moment of commercial leverage each year. The sub capacity terms carry the conditions for counting less than full capacity. And the portal is a purchase history and a download service rather than a statement of what you may run. One thing to keep in mind throughout: this is a programme rather than a negotiated contract, so its terms change for everybody at once. Read the current version, not the one you remember.
So let us read a License Information document properly. Five things, in order. The metric definition: exactly what is counted, on what boundary, and at what moment it is measured. Restricted use: the bundled components you may run, and the single purpose you may run them for. Supporting programs: what ships alongside, whether it needs its own entitlement, and on what terms. Prohibited uses, which is where surprises are cheapest to avoid, because they are listed. And the version stamp, because this document is per release and you are held to the one covering what you run. The second of those, restricted use, deserves a proper explanation.
Guest analyst clip.
What is licensing this component, and is that entitlement restricted. Two questions, asked at design time, and they cost nothing. Asked eighteen months later by an auditor, the same two questions can cost a seven figure sum, and the deployment in between was entirely well intentioned.
Second knowledge check. A database ships inside a licensed product. A second application starts using it. What is your position? A, fine, the database is already fully licensed. B, fine, provided the second application is also an IBM product. C, unlicensed, because the bundled entitlement is restricted to the product it shipped with. D, fine, until the database needs more capacity. Pause here before you continue.
C. Restricted use means what it says: the component is licensed to support its parent product and nothing else, and the License Information document states that plainly, usually in a single paragraph. A is the reasonable engineering view, and it is precisely how this finding gets created. B invents a rule that does not exist, because the restriction is about purpose rather than about who wrote the other application. And D confuses capacity with entitlement, since the deployment was outside the grant from the very first connection, at any size at all.
Now the sub capacity bargain, in its original form. Four obligations. One, an eligible product on an eligible virtualisation technology, and both lists are published by IBM and both change, so check them rather than assume them. Two, deploy the measurement tool within ninety days, measured from first sub capacity deployment rather than from when somebody got round to it. Three, keep it current, so new hosts get agents, upgrades get applied, and coverage is verified rather than presumed. Four, report at least quarterly and retain those reports for two years, generated, reviewed and filed. Miss any of them and the count is full capacity. Let me be precise about what kind of obligations those actually are.
Guest analyst clip.
Ownership and a calendar, rather than clever arguments. That is the whole defence, and it is worth noticing how unglamorous it is. Nobody was ever saved from a full capacity finding by a good explanation. They were saved by eight quarterly reports in a folder.
So what does an auditor actually ask for? Five things. Proof of entitlement by part number, with the quantity, the metric and the agreement it was bought under. The sub capacity reports for the period under review, from the tool, unedited, with dates. The deployment picture: which hosts, which clusters, what capping, and what changed during the period. The bundled entitlement chain, meaning which parent product licenses that component and the document that says so. And evidence of transfers, so anything that moved with an acquisition or a divestiture, and the paperwork that moved it. Notice that every single item is a document. None of them is an opinion, and none of them improves with explanation.
Five failures in this area. Arguing from the wrong layer, so weeks spent on the master agreement when the answer was in a product document all along. Reading the wrong version, meaning the License Information for the current release when you run one from four years ago. Multiple agreement numbers with no owner, so entitlement scattered across agreements nobody has consolidated since the last acquisition. Restricted use treated as spare capacity, which is the bundled component quietly serving a second purpose because somebody sensible spotted an efficiency. And no document library, so every question becomes an archaeology project, and speed of response is itself a form of evidence.
Last knowledge check. What most improves how an IBM audit goes, before any number is discussed? A, a strong relationship with your IBM account team. B, answering specific, dated questions quickly with documents. C, limiting the scope in the response letter. D, engaging a third party adviser early. Pause here and pick an answer before you continue.
B. An audit is an evidence exercise, and how quickly you produce evidence tells the reviewer what kind of organisation they are dealing with, long before anybody discusses a settlement. A is pleasant and largely irrelevant here, because the reviewer is a third party working to a procedure. C is worth doing, and it is a negotiation about the frame rather than a change in your underlying position. And D genuinely helps, and it helps far more once your own documents are in order, because no adviser can produce entitlement that you cannot find. Let me describe the folder that makes all of this work.
Guest analyst clip.
Worth real money before anybody discusses a number. So, the library, five things in it. The master agreement, signed copy, with any amendments and the date each took effect. Every Passport Advantage agreement number, including the ones that arrived with acquisitions and were never consolidated. Order forms as far back as they exist, with part numbers, quantities, metrics and dates, because that is your entitlement evidence. License Information documents per product and per version, for what you run rather than for the current release, and saved as files rather than as links, since links move. And an index page listing what is in the folder and where each document came from, so that the next person to hold this role can actually use it.
Three sentences. The IBM contract stack is layered by specificity rather than by seniority, so the master agreement sets the general terms while the product's License Information document decides your metric, your restricted use rights and, in practice, your number. Passport Advantage is a programme rather than a negotiated contract, which means its sub capacity conditions apply to you as written and change for everybody at once, so those four operational obligations are worth knowing by heart. And an audit is an evidence exercise, so the contract library is not administration for its own sake, it is the difference between answering a dated question in an afternoon and spending three weeks looking for a document that may not exist. Next session, the metric catalog.
Homework before session three, about ninety minutes, and the first item is the one that compounds. One, create the library: one folder, the index page, and whatever you can put in it today, and start it rather than plan it. Two, count your agreement numbers and work out which acquisition each one came from. Three, download two License Information documents, your two largest products, at the versions you actually run. Four, find the restricted use paragraph in one of them, read it, and then ask whether anything in your estate is currently doing that. And five, open the current Passport Advantage terms and read the four sub capacity obligations in the original wording, because my summary is not the contract.
Five guides, all on redresscompliance dot com. IBM Passport Advantage explained covers bands, agreement numbers, renewals and the sub capacity terms, which is the reference version of today. IBM licensing explained puts the estate, the metrics and the agreement stack in one place. IBM PVU and sub capacity licensing goes into the four obligations and the full capacity fallback in detail. IBM audit defence covers what evidence the third party review asks for and how it is assessed. And the IBM licensing assessment page describes what an independent review of an estate covers.
That is session two. The thing to take away is that the specific document beats the general one, the sub capacity conditions are operational rather than commercial, and the contract library is the cheapest insurance in this entire course. Next time, the metric catalog, and how to tell which metrics you are actually exposed to. See you then.