The word unlimited in an Unlimited License Agreement is doing less work than most buyers assume. The rights are unlimited in quantity, but they are sharply limited in who may use them, and that limit lives in a clause most people never read until it bites: the customer definition. When a company grows by acquisition, sheds a division, or restructures its legal entities, that clause decides whether the change sits comfortably inside the agreement or quietly creates exposure. It is the single most contract dependent part of a ULA, and one of the most expensive to get wrong.
What is the ULA customer definition?
The customer definition is the clause that names the legal entities entitled to deploy Oracle products under the ULA, and it is contract dependent, so only the named entities and whatever affiliates the contract includes may use the unlimited rights. Some agreements define the customer narrowly as a single named entity. Others extend to majority owned subsidiaries, or to affiliates as they existed on the signing date, or to a corporate family defined by a percentage of ownership. The exact wording controls everything that follows, because a deployment by an entity outside the definition is not covered by the ULA at all, no matter how unlimited the agreement feels.
How does an acquisition affect an Oracle ULA?
An acquisition affects a ULA the moment the acquired entity starts using Oracle, because that entity is almost never inside the original customer definition. The result is a gap: the parent has unlimited rights, the acquired business has Oracle deployments, and the contract does not automatically bridge the two. The acquired estate may be running unlicensed in the eyes of the agreement, and because Oracle watches for mergers and acquisitions as an audit trigger, this is a gap Oracle is actively looking for. The reverse problem appears in divestitures, where licences may not travel with a business being sold, stranding the buyer or the seller depending on the wording.
| Event | The risk | The buyer move |
|---|---|---|
| Acquisition | Acquired entity outside the definition deploys Oracle | Read the definition, reconcile before deploying or certifying |
| Divestiture | Licences may not transfer with the sold business | Confirm transfer rights in the contract before close |
| Internal restructure | Entities renamed or reorganised out of scope | Map current entities to the named ones in the agreement |
| Certification at exit | Only in scope entities certify cleanly | Resolve structure against the contract before the exit date |
Why is this a common audit trigger?
It is a common trigger because a merger creates a predictable mismatch between corporate reality and contract wording, and Oracle knows it. After an acquisition, integration teams naturally extend shared systems, including Oracle databases and applications, to the new business, often without anyone checking whether the customer definition reaches that far. From Oracle's side this is visible, valuable, and easy to raise. The audit then arrives framed as a compliance question, but it is really a commercial opening, with the acquired estate as the lever. Preliminary findings in these situations arrive inflated at list, and an independent line by line review typically cuts the claim 60 to 80 percent once the contract and the structure are read together.
A group operating under a ULA acquired a mid sized competitor and, during integration, extended its Oracle database estate to the new entity. Two years later an audit framed the acquired deployments as unlicensed, with an opening claim in the eight figures. The buyer side review read the customer definition, which covered majority owned subsidiaries as of any date during the term, and established that the acquired entity had become a majority owned subsidiary before deployment. Most of the claim fell away on the contract language alone. The residual was settled and folded into the certification, and the estate certified cleanly at exit.
Can you certify a ULA after a merger?
You can certify after a merger, but only deployments by entities inside the customer definition certify cleanly, so the structure and the contract have to be reconciled before the exit date. This is where the certification decision and the customer definition collide. If the acquired entity is genuinely within scope, its deployments add to what you certify, which can be a substantial benefit. If it is outside scope, those deployments do not certify and may instead surface as exposure. The work, done in advance, is to map every deploying entity to the named entities in the agreement and resolve any mismatch while there is still time to act, whether by amendment, by restructuring, or by negotiation.
What is the buyer move?
The buyer move is to read the customer definition before any deal closes, not after the audit arrives. During due diligence on an acquisition, treat the Oracle ULA as a document that needs reconciling with the new structure, the same way you would treat any other material contract. Confirm which entities are in scope, decide how the acquired estate will be licensed or brought within the definition, and document the position. The same applies in reverse for divestitures, where transfer rights must be confirmed before the business leaves. Getting this right early turns a classic audit trigger into a non event.
For the exit decision itself, see the ULA certification decision. For how support and repricing behave around these agreements, see matching service levels and repricing. The full method sits in the Oracle license compliance guide.