Arguments Against IBM License Metric Tool – What Does and Doesn’t Work?
By Christopher Barnett
Scott & Scott LLP
Each of the major software publishers has one or two tricks up its sleeve – tricks that often are missed by licensees – affecting how its server products may be used in virtualized environments. For example, Microsoft SQL Server requires a minimum of four core licenses per vCPU, even if the actual number of vCPUs allocated to a VM is less than four. Oracle offers even more pitfalls for the unwary, in that it strictly – some would say unreasonably – limits and defines the specific virtualization technologies that may be used to license its products based on virtual resources (as opposed to host resources).
Falling somewhere between those two extremes is IBM.
IBM allows a wide array of its products to be licensed on a “sub-capacity” basis, and it also allows for a wide array of virtualization and processor technologies to be used to support sub-capacity-licensed virtualization environments. Moreover, while its Processor Value Unit (PVU) framework entails processor-specific PVU values to be used in licensing calculations, it does not apply an arbitrary minimum number of licenses that must be purchased for VMs as opposed to physical servers.
However, what it does require is that the licensee (1) deploy and use the IBM License Metric Tool (ILMT) in the virtualized environment to measure the resources allocated to the VMs running its products and (2) run at least quarterly reports out of ILMT to track that usage over time. The ILMT requirement is where most businesses get into trouble with IBM’s PVU licensing.
In the face of that failure, it is not uncommon for businesses to try to turn the ILMT requirements against IBM. They may argue that the sub-capacity requirements were not properly incorporated into the agreements or not clearly communicated to the licensee, and, thus, that those requirements do not apply to the licensee. The big problem with this line of argument – other than the facts that IBM would reject it out of hand and that a business would face significant challenges convincing a court to accept it – is that the default licensing requirement for all IBM products licensed based on Value Units, PVUs, or other processor capacities is – and always has been – full capacity. If the sub-capacity requirements in the contract were somehow defective, then the business would be left with no choice other than to license its servers to their full, physical capacities.
Therefore, in the event of an audit, instead of attacking the contracts directly, it makes more sense to look at other aspects of the ILMT-deployment process and the relationship with IBM to see if there may be other defenses against the ILMT requirement. Here are three examples:
(1) It really is IBM’s fault. Sometimes, prior to an audit, a business will have signed an agreement with IBM for implementation services related to one or more sub-capacity-licensed products. If, in that agreement, IBM expressly or even impliedly undertook any responsibility to ensure that the products being deployed were correctly licensed – and then failed to deploy ILMT as part of the implementation project – then it may be possible to obtain a concession with regard to adverse audit findings affecting those products. Again, however, what is typically needed here is an agreement with IBM and not merely an authorized IBM reseller. If a reseller failed to deploy ILMT as part of such a project, IBM may agree to deeper discounts or other pricing concessions during negotiations to resolve the audit findings, but it typically will not agree to concede the findings altogether.
(2) ILMT Does Not Work. ILMT is not an easy product to deploy or to use, and many businesses experience technical problems in attempting to implement it. If an audited company can show that it has tried to use ILMT and has sought assistance in getting the tool to work, then it may be possible to secure concessions with regard to adverse audit findings. However, the likelihood of success for this line of argument will be heavily dependent on the facts of each case. When did the company first try to deploy ILMT? Was it for the complete virtualization environment or just for one IBM product? Was IBM support contacted regarding the problem? What problems were reported regarding ILMT implementation? How diligent has the business been in working with support to resolve the problem? All of the above questions would be relevant to determining whether and to what extent any ILMT-deployment problems could affect the outcome of an IBM audit.
(3) Sub-Capacity Levels Never Were Exceeded. Even if IBM never undertook any responsibilities for ILMT deployment and the licensee wholly failed to even try to install the tool, there is a third, potential option for avoiding adverse audit findings associated with that failure – historical reporting. If the audited business can produce historical, system-generated reports demonstrating (1) that the processor resources allocated to VMs running PVU-licensed products are and have been definitively capped and not subject to any automated augmentations based on system demands, and (ideally) (2) that historical usage of sub-capacity licensed products has not exceeded licensed levels, then it may be possible to avoid adverse findings associated with an ILMT deficiency. However, in our experience, relatively few businesses are able to produce historical reporting that satisfies IBM’s requirements. In addition, even in the best cases, the outcome may be discounts or other pricing concessions and not alterations to the audit findings. Absent a separate agreement signed by IBM, no business should count on any non-ILMT reporting to satisfy IBM as being an acceptable substitute to the ILMT requirement described in IBM’s license agreements.
Finally, it is important to keep in mind that even if any or all of the arguments above is successful, IBM still will insist that the audited company deploy ILMT going forward as a condition of settlement. Thus, if a decision has been made to reject ILMT under any circumstances, it may be necessary to formulate a different strategy for contending with the adverse audit findings.
IBM audits always are very fact-intensive exercises, and no two ever are exactly the same. Companies facing unexpected licensing shortfalls identified during an audit should consult with counsel or knowledgeable licensing advisors to determine whether the above arguments – or any other arguments – may help to mitigate the exposure associated with those shortfalls.
