The customer definition clause decides which legal entities and territories your Oracle ULA covers. Deployments inside it count toward certification. Deployments outside it do not, and can trigger a remediation demand. It bites hardest after a merger, acquisition, or divestiture, which is exactly when most teams forget to read it.
Most ULA conversations focus on the count. The customer definition clause decides whose count it is. It draws the line around which entities may use the unlimited right, and that line determines what you are allowed to certify when the term ends.
The customer definition clause names the legal entities entitled to use the unlimited deployment right. In a typical agreement that means the contracting entity plus its majority owned subsidiaries, sometimes the entities listed in a schedule by name, and sometimes bounded by a territory clause that limits the geography where the right applies. The clause is doing quiet but decisive work: it sets the perimeter of the ULA. Anything deployed inside the perimeter is covered by the unlimited right and qualifies at certification. Anything outside it is standard licensing, and a gap there is a compliance exposure rather than a free deployment.
The wording varies a great deal between agreements. Some define the customer broadly, capturing future subsidiaries automatically. Others fix the entity list at signing and require an amendment to add anything new. Because the language differs, the only reliable way to know who is inside your ULA is to read your specific clause, not to assume the common pattern applies to you.
The customer definition clause is the perimeter of the ULA. Deploy inside it and the deployment counts. Deploy outside it and the same software becomes a compliance gap. Corporate change during the term moves entities across that perimeter, which is where the risk concentrates.
The clause is most dangerous when the corporate structure changes during the term. Consider an acquisition. You buy a company, you start running Oracle workloads inside it, and you assume the ULA covers them because the ULA is unlimited. But an acquired entity is usually not automatically inside the customer definition. Unless the clause captures new subsidiaries, or you amend it, the Oracle deployed in that acquired entity may sit outside the perimeter. At certification, those deployments do not count toward your baseline, and Oracle may treat them as unlicensed instead.
Divestiture cuts the other way. If you sell a business unit that was inside the customer definition, the Oracle running in it may need to be addressed before it leaves, because it can no longer rely on your ULA once it is no longer part of your defined customer. Territory clauses add a further layer: a deployment in a country outside the licensed territory can fall outside scope even if the entity itself is covered. Each of these scenarios turns a structural decision into a licensing decision, and the timing against the ULA clock matters as much as the structure.
The example is anonymized and the figures are indicative. A multinational manufacturer held a database ULA with a customer definition limited to the parent and its subsidiaries as listed at signing. During the term it acquired a regional competitor and migrated that competitor's reporting estate onto Oracle, confident the unlimited right would cover it.
| Entity | Inside customer definition | Status at certification |
|---|---|---|
| Parent and listed subsidiaries | Yes | Counts toward baseline |
| Acquired competitor | Not without amendment | Potential compliance gap |
| Branch in unlicensed territory | No | Outside scope |
Read early, the acquired entity could have been added to the customer definition by amendment during the term, bringing its deployments inside the perimeter and into the certified count. Read late, the same deployments became an exposure to remediate. The clause did not change. The timing did.
Generally they cannot. A deployment in an entity or a territory outside the defined customer scope does not count toward the certification baseline, and Oracle may instead treat it as a gap to be remediated. This is the asymmetry that makes the clause matter: an in scope deployment is value you certify, while an out of scope deployment is a liability you carry. The remedy is almost always to act during the term, by amending the customer definition or repositioning the workload, rather than discovering the problem in the certification window when options are narrow.
Start by reading your customer definition and territory clauses early, ideally as soon as the ULA is signed and again whenever corporate structure changes. Map every entity running Oracle against the defined perimeter, and flag any that sit outside it. Where an acquisition has brought new Oracle into the group, decide deliberately whether to amend the customer definition, to migrate the workload into an in scope entity, or to license it separately. Treat every merger, acquisition, and divestiture during the term as a ULA event, not just a corporate one, and manage it against the ULA clock. Document the position as you go, because the same record that keeps your scope clean also defends your certified count if an audit follows.
The customer definition is one of several scope boundaries that decide what you can certify. To understand the schedule that governs all of them, read the ULA clock and why timing drives everything. To see how the ULA model differs from ordinary licensing in the first place, read how a ULA differs from a standard Oracle license. For the full certification picture, the Oracle ULA certification guide sets out the mechanics end to end.
The customer definition clause names which legal entities are allowed to use the unlimited deployment right. It draws the boundary of who is inside the ULA, often listing the contracting entity and its majority owned subsidiaries, sometimes bounded by territory. Deployments outside that boundary do not count and can trigger remediation.
An acquired entity is usually not automatically inside the customer definition, and a divested entity may fall outside it mid term. Oracle deployments in an entity outside the defined scope are unlicensed and can trigger a remediation demand at certification. Whether an acquisition is covered depends on the precise wording.
Generally no. If a deployment sits in an entity or territory outside the defined customer scope, it does not count toward the certification baseline and may instead be treated as a compliance gap. This is why corporate change during the term must be managed against the ULA clock and the exact clause language.
Book a confidential assessment and we will map your entities against the customer definition and tell you what to fix before you certify.