How to inventory products governed by ALAs

Before any entitlement can be defended, the buyer has to know which of its software is governed by which contract, and in a portfolio as broad as the combined OpenText and Micro Focus estate that is not a trivial exercise. How to inventory products governed by ALAs is the practical work of identifying every product whose use is controlled by an Additional License Authorization, separating it from software governed by the OpenText EULA, and matching each product to the specific authorization that sets its terms. Done before an audit, this inventory is the map the whole defense is built on; done badly or not at all, it leaves a finding free to assert whatever governing terms it prefers.

This field note sets out how to build that inventory, what distinguishes ALA governed products from the rest, and how the result anchors a defensible position. It pairs with our ALA and entitlement review track.

Why the governing contract is the first question

Most Micro Focus products are governed by Additional License Authorizations, while OpenText's own ECM line, including Documentum, Extended ECM, Content Suite, eDOCS, and InfoArchive, predates the 2023 acquisition and is governed by the OpenText EULA rather than the ALAs. Which contract governs a given product determines which metric definitions, which rights, and which conditions apply to it, so identifying the governing document is logically prior to any argument about quantity. The boundary between the two regimes, and why it matters to a finding, is the subject of Micro Focus ALA versus OpenText EULA scope.

Identifying the ALA governed products

The security portfolio brought by the acquisition, Fortify, ArcSight, Voltage, NetIQ, and Sentinel, the DevOps tools including ALM, Quality Center, Octane, LoadRunner, UFT, Dimensions, and AccuRev, the COBOL products Visual COBOL and Enterprise Server, and the broader Micro Focus lines are typically governed by Additional License Authorizations. Inventorying them means cataloguing every deployment of these products across the estate and recording, for each, the authorization that governed its purchase. This is the same per product, per grant discipline required to read any single authorization, set out in what is an Additional License Authorization, applied across the whole portfolio at once.

Building the inventory from two sides

A reliable inventory is built from both the deployment side and the entitlement side, because neither alone is complete. The deployment side catalogues what is actually installed and running, drawn from inventory tools, configuration data, and operational records. The entitlement side catalogues what was purchased, drawn from order forms, authorizations, renewals, and migration records. Reconciling the two reveals where deployment exceeds entitlement, where entitlement is unused, and where the records disagree, and that reconciliation is the substance of reconciling ALA entitlements before an audit.

Recording the metric and edition for each product

An inventory that records only product names is not enough, because the same product can be licensed under different metrics and editions, each governed by different authorization terms. For each product, the inventory should capture the edition or module deployed, the metric under which it is licensed, and the authorization that defines that metric, so that a finding cannot quietly apply a metric the grant never set. Capturing this detail is what lets the inventory anticipate the way a vendor will attempt to map products to authorizations during the audit, examined in how OpenText maps products to ALAs in an audit.

How the inventory shapes the defense

In a recent engagement, a finding applied Additional License Authorization terms to a product that was in fact governed by the OpenText EULA, importing a metric and condition the correct contract did not contain. A complete inventory, built before the audit, had already established the governing contract for that product, so the misattribution was answered immediately rather than argued from scratch. This is the value of the inventory: it converts what would otherwise be a contest of assertions into a documented map the finding must respect. The clarity it provides across an estate is part of how we deliver the 68 percent average reduction we have achieved across more than 200 defended audits.

From inventory to baseline

The inventory is the raw material; the entitlement baseline is the finished position. Once every product is mapped to its governing contract, its authorization, its metric, and its deployment, the next step is to settle the defensible entitlement figure for each line, which becomes the baseline the buyer measures every future finding against. Turning a complete inventory into that durable baseline is the work described in how to build an ALA entitlement baseline, and it is what gives an organization a prepared answer before the next notice arrives.

Keeping the inventory live

An inventory taken once and shelved decays as the estate changes, so the discipline that protects a buyer is keeping it current as products are deployed, retired, renewed, and migrated. A live inventory means the next audit meets a maintained map rather than a stale snapshot, and it removes the ambiguity that lets a finding assert governing terms the buyer cannot quickly refute. If you are facing an audit without a clear map of which products fall under which authorizations, open a case and we will build the inventory that anchors the defense.

For the full method, read the complete OpenText audit defense playbook, and for entitlement defense across the Micro Focus estate see our ALA and entitlement review track.