ALA grant language and the deployment count

A deployment count is not a neutral fact discovered by a scanner; it is a figure shaped by the words that define what is being counted. The same estate can produce very different numbers depending on what the governing grant says counts as a deployment, an instance, an installation, or a use. ALA grant language and the deployment count is about how the precise wording of an Additional License Authorization bounds the figure a finding may assert, and how reading that language closely keeps the count to what the grant actually charges for rather than what a scan happens to detect.

This field note examines how grant language defines the unit of counting, where a finding stretches it, and how the defensible reading holds the figure to the contract. It pairs with our ALA and entitlement review track.

The grant defines what a deployment is

An Additional License Authorization does not merely state a quantity; it defines the thing that quantity counts. Whether the unit is an installed copy, a running instance, an accessing user, a server, or a unit of capacity is set by the words of the grant, and a deployment count is only meaningful against that definition. A scan that reports installations means little if the grant counts concurrent use, and a count of users means little if the grant counts servers. Establishing what the grant counts is the same close reading required to interpret any authorization, set out in what is an Additional License Authorization.

Where a finding stretches the language

The common overreach is a finding that reads the grant language broadly to capture more than it was meant to count, treating every detected artifact as a chargeable deployment. An installation that is present but not in use, a copy retained for recovery, a component bundled with another product, all can appear in a scan and be counted as separate deployments, even where the grant language counts only active use or only the primary instance. Reading the language broadly to inflate the count is precisely the kind of move examined in ALA interpretation and where audits exploit ambiguity, and it is answered by holding the count to the unit the words actually define.

Installed, deployed, and in use

Grant language often distinguishes, explicitly or by implication, between software that is installed, software that is deployed, and software that is in use, and these are not the same population. Installed copies may include images never brought into service; deployed instances may include standby or recovery copies; only some of either may be in active use. A finding that collapses these into a single deployment count, charging installed copies as if they were active deployments, overstates the figure wherever the grant counts the narrower population. Sorting the detected artifacts into these categories is part of the line by line work described in defending an ALA based finding line by line.

Capacity language and the count

Where the grant counts capacity rather than instances, the deployment count interacts with how capacity is defined, because the number of chargeable units depends on the capacity rule. A grant that counts cores, or some other capacity unit, requires that the count follow the capacity definition the grant sets, not a raw instance tally. The relationship between the grant language and the capacity figure is the subject of capacity definitions in Micro Focus ALAs, and getting the capacity definition right is often what determines whether the deployment count is defensible.

How reading the language reduces the number

In a recent engagement, a finding counted every detected installation of a product as a separate chargeable deployment, while the grant language counted active production instances. A large share of the detected installations were inactive images and recovery copies that the grant did not count, so holding the count to the unit the language actually defined removed those artifacts from the chargeable figure. This is the ordinary mechanism: each detected artifact that does not meet the grant's definition of a counted deployment subtracts from the finding. Applied carefully, this reading of the grant language is part of how we deliver the 68 percent average reduction we have achieved across more than 200 defended audits.

Measurement must follow the definition

Once the grant language settles what counts, the measurement method has to follow that definition, because a measurement that counts the wrong unit produces the wrong number no matter how precise it is. A scan calibrated to count installations cannot answer a grant that counts active use, and accepting such a measurement at face value imports the very error the grant language should prevent. Challenging the measurement so that it counts the unit the grant defines, rather than the unit the tool defaults to, is the work set out in how to challenge an ALA capacity measurement.

Fixing the count definition forward

After the present finding is corrected, the forward agreement should state plainly what counts as a deployment for each product, so a future review cannot reopen the figure by reading the language more broadly. A clean forward arrangement records the unit of counting, defines how it is measured, and removes the ambiguity that let the audit charge installed or inactive artifacts as active deployments. Resolving the finding and fixing the count definition forward are two halves of the same work. If a finding has counted detected artifacts that the grant language never charged for, open a case and we will hold the count to the unit the words define.

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.