Micro Focus ALA cloud deployment rights

Software bought to run on owned hardware often ends up running in a public cloud, on infrastructure the buyer does not own and cannot fully measure, and licensing terms written for the data centre do not always translate cleanly to that environment. A finding that applies on premises assumptions to a cloud estate, or counts elastic cloud capacity at its peak, can overstate the obligation considerably. Micro Focus ALA cloud deployment rights is the question of how an Additional License Authorization treats use in cloud and hosted environments, and how the defensible reading holds the count to what the grant actually permits and charges for in the cloud.

This field note explains how cloud rights work under an ALA, where a finding overreaches in cloud environments, and how the grant decides the count. It pairs with our ALA and entitlement review track.

What the grant says about cloud use

An Additional License Authorization may address cloud and hosted deployment explicitly, may be silent, or may set conditions on where and how the software runs, and the treatment varies by product and grant. Some grants permit deployment on third party cloud infrastructure without restriction; some restrict it; some define how capacity is counted on shared or elastic infrastructure. The decisive question is what the specific grant says, and a finding that imports cloud restrictions or counting rules the grant does not contain is asserting terms beyond the contract. Reading the cloud terms is the same close interpretation applied to any authorization, set out in ALA territory and use restrictions.

Elastic capacity and the count

Cloud infrastructure scales up and down, and a finding that counts cloud capacity at its observed peak can charge for a level of use that existed only briefly, treating a momentary scale out as the standing entitlement requirement. Where the grant counts capacity, the count must follow how the grant measures it over time, not the highest reading a cloud platform ever reported. This is the same burst versus sustained problem that arises in capacity measurement generally, and the defensible figure rests on the capacity definition the grant sets, examined in capacity definitions in Micro Focus ALAs.

Shared infrastructure and virtual counting

In a public cloud the buyer's software runs on shared, virtualized infrastructure it does not control, and how capacity is attributed to a tenant on that infrastructure is a question the partitioning rules of the grant must answer. A finding that counts the full capacity of an underlying host, rather than the capacity actually allocated to the buyer's instance, can charge for hardware the buyer never used. The relationship between cloud deployment and the grant's partitioning rules is the subject of ALA virtualization and partitioning rules, and it frequently decides the cloud count.

Non production and recovery in the cloud

Cloud estates commonly host development, test, and disaster recovery environments alongside production, and the cloud setting does not change whether those environments consume a license; the grant's non production and recovery terms still govern. A finding that counts every cloud instance as production overstates wherever the grant grants non production or standby rights, and the correction is to classify each cloud environment by function exactly as on premises. This connects the cloud reading to the use distinctions examined in ALA development versus production rights and the failover treatment in ALA disaster recovery and standby rights.

How the cloud reading reduces the number

In a recent engagement, a finding counted a buyer's cloud deployment at the peak capacity its platform had ever auto scaled to, and charged the full host capacity of the shared infrastructure rather than the capacity allocated to the buyer's instances. Holding the count to the capacity actually allocated, measured as the grant defined it rather than at the momentary peak, removed a large share of the asserted cloud figure. This is the ordinary mechanism: each unit of cloud capacity that the buyer never sustained, or never controlled, subtracts from the finding. Applied to a cloud estate, this reading is part of how we deliver the 68 percent average reduction we have achieved across more than 200 defended audits.

Evidence in an environment you do not own

Defending a cloud count rests on evidence the buyer can produce about its own use, even though it does not own the hardware: allocation records, instance configurations, scaling logs, and billing data from the cloud provider. This evidence establishes what capacity was actually allocated and sustained, which is what the grant charges for, against a scan that may have inferred far more from the shared infrastructure. Assembling that record is the same evidentiary discipline applied throughout the entitlement defense, and in the cloud it is what answers a measurement the buyer could not otherwise verify.

Fixing the cloud question forward

After the present finding is corrected, the forward agreement should state plainly how cloud and hosted deployment is treated for each product, so a future review cannot reopen the count by importing on premises assumptions or charging elastic peaks. A clean forward arrangement records whether cloud deployment is permitted, how capacity is counted on shared infrastructure, and how elastic use is measured, removing the ambiguity that let the audit overreach. If a finding has counted your cloud deployment at its peak, or charged shared infrastructure you never controlled, open a case and we will hold the count to what the grant permits in the cloud.

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.