How to challenge OpenPass metric definitions

Almost every audit begins with a metric. A loosely worded definition lets the vendor count more than the buyer ever intended to license, and an OpenPass agreement that carries the same loose definitions simply postpones the dispute to the next review. Challenging OpenPass metric definitions means reading each metric the way the vendor will apply it under audit, then narrowing it until it counts what you actually use and nothing more.

Metrics are the hinge of every OpenText and Micro Focus licensing dispute. A named user metric, a capacity metric, an events per second metric, a volume metric: each one is a sentence in the contract that decides how much you owe. The vendor drafts those sentences, and the vendor reads them broadly at audit. The buyer's defense is to read them first, and to insist on definitions that leave no room for the broad reading. The Rebut step of the method is built on exactly this work, and it is where the largest reductions are found.

Why metric definitions matter more than price

A unit price multiplied by a quantity gives the cost. Negotiators tend to focus on the unit price because it is visible, but the quantity is set by the metric definition, and a broad definition inflates the quantity invisibly. A named user metric that counts every account with theoretical access, rather than every account that actually uses the software, can double or triple the count. The same is true of capacity metrics that count provisioned rather than consumed, and volume metrics that count gross rather than net. The definition, not the price, is where the number is really decided.

This is why defined metrics are the most durable protection in an OpenPass agreement. A held price protects against increases, but a tight metric definition protects against being counted for more than you use, which is the more common and the larger exposure. The case for defining metrics in the agreement is set out in defined metrics in an OpenPass enterprise agreement, and the price side in OpenPass price hold and uplift protections.

Read the metric the way the vendor will

The discipline that protects a metric definition is adversarial reading. For each metric in the draft, ask how the vendor's compliance team would apply it at its broadest. Does the named user definition count service accounts, dormant accounts, or accounts with access but no activity? Does the capacity definition count what is provisioned or what is used? Does the volume definition count peak or average, gross or net? Each of these questions has a generous answer for the vendor and a narrow answer for the buyer, and the draft definition usually leaves the question open. The buyer's job is to close it in the buyer's favour before signing.

This reading draws directly on the product specific traps the firm sees across the estate. The named versus concurrent distinction that drives ALM and LoadRunner findings, the scan submitter versus repository access distinction in Fortify, the burst versus sustained distinction in ArcSight events per second: each is a metric definition that the vendor reads broadly and the buyer must narrow. Those product specific defenses live in our ALM and LoadRunner audit defense, Fortify and AppSec audit defense, and ArcSight and security audit defense tracks, and the OpenPass agreement is where those definitions can be fixed for the whole term.

Tie the definition to your deployment reality

A metric definition is strongest when it describes how the buyer actually deploys the software. If the estate licenses by active users, the definition should count active users, with activity defined by a measurable threshold the buyer controls. If the estate runs in a virtualized environment, the capacity definition should reflect the partitioning the buyer actually uses, a subject covered in the cluster note on virtualization and partitioning terms. A definition written in the vendor's abstract terms invites the vendor's broad reading. A definition written in the buyer's concrete deployment terms leaves far less room for reinterpretation.

Tying the definition to deployment reality also requires evidence. The buyer has to be able to show what active means, what is provisioned, what is consumed. Assembling that evidence is part of documenting the estate, covered in documenting your estate for an OpenPass negotiation, and it is the same evidence that supports the target baseline in building an OpenPass target baseline before negotiation.

Close the indirect access gap

One definition deserves special attention: how the metric treats indirect access. Many findings inflate because a metric counts users or systems that reach the software through an intermediary, even though those users never touch it directly. An OpenPass metric definition should state clearly how indirect access is treated, so that the vendor cannot later count a downstream system or an integrated application as a licensed consumer. The way OpenPass handles indirect access is covered in the cluster note on that subject, and it is one of the definitions most worth pinning down at signing.

How challenging a definition plays out

In a recent engagement, a finding was driven almost entirely by a named user metric that counted every account with access rather than every account in use. The challenge was not to the price but to the definition: the buyer demonstrated, with evidence, that a large share of the counted accounts were service or dormant accounts that consumed nothing. Once the definition was narrowed to active users, the count fell sharply, and the corrected definition was written into the forward OpenPass agreement so the same dispute could not recur. That pattern, narrowing the metric and then fixing the narrow definition in the agreement, recurs across the engagements collected in our engagements and is set in full context in the complete OpenText audit defense playbook.

Fix the definition, fix the future

Challenging a metric definition is the single highest leverage move in an OpenPass negotiation, because the definition sets the quantity and the quantity sets the cost. Read each metric adversarially, narrow it to your deployment reality, close the indirect access gap, and write the narrowed definition into the agreement so it governs the whole term. Do that, and the metric stops being the vendor's lever and becomes the buyer's protection. This work is at the centre of our OpenPass enterprise agreement negotiation practice. If an OpenPass draft is in front of you with metrics left loosely defined, open a case before you sign them as written.