The PULA customer definition risk

In a perpetual ULA the customer definition decides who is allowed to deploy under the unlimited right. Because a PULA never certifies, that boundary is permanent, and an acquisition or divestiture can strand licenses or create exposure that has no clean exit to resolve it.

The short answer

What is the customer definition in a PULA?

The customer definition is the contract clause that names which legal entities are allowed to deploy under the unlimited right. In a PULA it is decisive because the agreement never certifies, so the boundary of who can deploy is permanent rather than reset at an exit. Entities inside the definition enjoy the unlimited right. Entities outside it, including many acquired businesses, do not, and their Oracle use can quietly become unlicensed. With no certification event to force a reckoning, that gap can sit unnoticed until an audit surfaces it.

The Meridian principle

In a standard ULA, scope errors get cleaned up at certification. In a PULA there is no certification, so the customer definition you signed is the customer definition you live with. Read it as a permanent fence, not a starting position.

Why the clause bites harder in a perpetual agreement

Every ULA has a customer definition, an entity list, and often a territory clause. In a standard ULA these matter, but the certification window gives you a moment to measure scope, resolve mismatches, and certify a clean position. A PULA removes that window. The unlimited right runs indefinitely for the named entities and only the named entities, and there is no built in event at which deployments outside scope are forgiven or absorbed. Corporate change during the life of the agreement, which for a perpetual deal can mean decades, accumulates against a boundary that never moves on its own.

This is why customer definition is the single clause we read first in any perpetual agreement. It determines whether your real organization, the one that exists after years of acquisitions, restructurings, and carve outs, still matches the organization the contract licenses.

What happens to a PULA after an acquisition?

It depends on the customer definition and any change of control wording, and the default is rarely generous. An acquired business is usually outside the original definition, so its Oracle deployments are not covered by the unlimited right unless the contract reaches majority owned affiliates, or you amend it. Some agreements extend automatically to entities you come to control, with conditions. Many do not, or impose a notice period, a headcount or revenue ceiling, or a waiting period before new entities qualify. Because a PULA never certifies, there is no natural exit at which to absorb the acquired estate, so any uncovered deployment can persist as exposure and emerge in an audit two or three years later.

Worked example, indicative

A diversified industrial group held a PULA covering its named operating entities. It acquired a mid sized competitor and migrated several of the new databases onto shared infrastructure, assuming the unlimited right simply covered them. The customer definition did not reach newly acquired entities without amendment. With no certification window to reconcile scope, the acquired deployments sat outside the agreement until an Oracle review identified them. The remediation was negotiated, but it was avoidable. The lesson is that corporate change has to be managed against the contract wording in real time, because the perpetual structure offers no later cleanup. Figures and outcomes are indicative and depend on the specific contract language.

Can a divestiture strand PULA licenses?

Yes, and in the opposite direction. When a business unit is sold, its deployments often leave the customer definition, and the unlimited right does not travel with the divested entity unless the contract permits assignment or carves out a transition. The buyer can find the business unlicensed on day one of separation. Meanwhile the seller may keep carrying support on capacity it no longer uses, because a PULA gives no exit at which to shed that cost. Both outcomes are governed by the assignment and customer definition language, and both are far cheaper to handle before the deal closes than after.

The clauses that decide your answer

Four pieces of wording carry most of the risk. The customer or licensee definition sets the named entities. The affiliate language decides whether majority owned or controlled entities are included and on what terms. The assignment clause governs whether the agreement can move with a divested business. And any territory clause restricts where the unlimited right applies. In a PULA, read all four together and against your live corporate structure, not the structure that existed when the deal was signed.

How to manage the risk while you hold a PULA

Treat customer definition as a standing governance item, not a one time review. Keep a current map of which legal entities deploy Oracle and whether each sits inside the contract definition. Test every acquisition, divestiture, and internal restructuring against the wording before infrastructure changes are made, because once workloads move it is harder to unwind. Where the definition is too narrow for your real organization, the time to widen it is during a commercial conversation you control, not during an audit. The perpetual structure gives you no exit, so disciplined scope management is the substitute for the cleanup a certification would otherwise provide.

Your next step

If you hold a PULA, or are weighing one, map your live entity structure against the customer definition before anything else. Start with the PULA pillar guide, then read the economics of a perpetual ULA and the cap mechanics and the true up.

Questions

PULA scope risk, asked plainly.

The customer definition is the contract clause that names which legal entities are allowed to deploy under the unlimited right. In a PULA it is decisive because the agreement never certifies, so the boundary of who can deploy is permanent. Entities inside the definition enjoy the unlimited right. Entities outside it, including many acquired businesses, do not, and their Oracle use can become unlicensed.

It depends on the customer definition and any change of control wording. An acquired business is usually outside the original definition, so its Oracle deployments are not covered by the unlimited right unless the contract extends to majority owned affiliates or is amended. Because a PULA never certifies, there is no exit event at which to clean this up, so the exposure can persist and surface in an audit.

Yes. When a business unit is sold, its deployments often leave the customer definition, and the unlimited right does not travel with it unless the contract allows assignment or a carve out. The divested entity may end up unlicensed on day one, and the seller can be left carrying support on capacity it no longer uses. Both outcomes turn on the specific assignment and customer definition language.

Strictly confidential

Map your entities against the wording.

Book a confidential assessment and we will test your live corporate structure against the customer definition before an acquisition or divestiture turns it into exposure.

Book a ULA assessment