Reading your ULA contract properly

By the Meridian advisory team, former Oracle LMS and GLAS licensing analysts. Updated 4 June 2026.

Which ULA clauses matter most at certification?

Four clauses carry almost all of the value and almost all of the risk. The certification rights set what you declare and how. The cloud clause governs whether public cloud deployments count. The customer or entity definition sets whose deployments are in scope. The territory clause limits where deployments count. Everything else in the agreement matters less than these four, and every one of them is decided by specific wording rather than by general practice. Read them first, then measure.

1. The certification clause

This is the engine of the exit. It defines who must sign the certification, usually a senior executive, and what is declared. Read it for three things. First, the basis of the count, because the metric, whether processor or Named User Plus, and the treatment of options and packs all flow from here. Second, any deadline or notice period, since the window to certify is finite and missing it can force a renewal. Third, any restriction on what may be counted, because some agreements limit certification to specific environments or exclude particular deployments. The certification clause is where you confirm that the perpetual entitlement you expect is the one the contract will actually grant.

2. The cloud clause

Cloud counting is the clause that surprises teams most, because the assumptions are usually wrong. Many ULAs require deployments in AWS or Azure to run for 365 continuous days to count toward the certification baseline, which means a workload spun up late in the term may not qualify. Some agreements exclude public cloud entirely. Many are silent on GCP, and silence is not inclusion: a clause that does not grant counting rights does not create them. Read the cloud clause for the named providers, the continuous use condition, and any baseline cut off. Where cloud does not count, the workloads can be repatriated on premises or moved to OCI before the exit so they do count, but only if you act inside the term.

Does silence about GCP mean GCP counts?

No. This question comes up so often it deserves its own line. If your ULA names AWS and Azure with conditions and says nothing about GCP, the GCP deployments do not automatically count, and you should not build a certified number on the assumption that they do. The safe reading is that anything the contract does not grant, it withholds. If GCP volume is material to your count, the move is to plan a migration or repatriation inside the term, not to argue silence into permission at the exit.

3. The customer and entity definition

The customer definition decides whose deployments are covered. It names the legal entities that may deploy under the ULA, and it bites hardest after corporate change. If you acquired a business during the term, its deployments are only in scope if the definition reaches them, and an acquired entity running the named products outside that scope can trigger a remediation demand rather than a covered deployment. Read the definition for the named entities, for any provision covering majority owned subsidiaries, and for how acquisitions and divestitures are treated. A deployment in the wrong entity is one of the most common and most fixable problems we see, but it has to be addressed before the certification, not after.

4. The territory clause

The territory clause limits where deployments count. Some agreements are global, others are restricted to named countries or regions. A deployment in a territory outside scope is the same problem as a deployment in the wrong entity: it does not count toward your certification and it can become an exposure. For multinational estates this clause deserves a careful read against where your Oracle workloads actually run, because data centre footprints and the contract territory do not always match.

A clause by clause checklist

Clause	Read it for	The risk if you skip it
Certification rights	Basis of count, deadline, restrictions	A smaller or invalid declaration
Cloud	Named providers, 365 day rule, exclusions	Cloud volume that does not count
Customer definition	Named entities, subsidiaries, M&A	Remediation demands after acquisition
Territory	Covered countries and regions	Out of scope deployments and exposure

This checklist is a starting point. The specific consequence in your case depends on your wording, which is exactly why the contract reading comes before the measurement.

Why the order matters

Teams often measure the estate first and read the contract second, then discover the count they built does not match what the agreement allows. Reversing the order saves the rework. When you know what counts, where, and for whom before you measure, the baseline is built against the right rules from the start. This is the same discipline set out in our pillar, the Oracle ULA certification guide, and it pairs with the structural overview in what an Oracle ULA actually is. It also defuses several of the costly beliefs we cover in the ULA myths that cost money.

The takeaway

Your ULA is worth what its clauses allow you to certify. Read the certification rights, the cloud clause, the customer definition, and the territory clause before you measure, treat silence as exclusion rather than permission, and fix entity and territory problems inside the term. Do that, and the count you build will survive both the certification and the audit risk that follows it.