A PULA grants unlimited deployment only inside a defined scope, and because it never expires, that compliance question never closes. The unlimited right covers named products, defined entities, and a permitted territory. Anything outside those boundaries is unlicensed and exposed in an audit for the life of the agreement.
The word unlimited does a lot of work in a PULA, and not all of it is in the buyer's favour. It is easy to read perpetual and unlimited as meaning compliance free, as though signing the agreement settles every licensing question permanently. It does not. A PULA removes the certification event, but it does not remove the scope of the grant, and the scope is where compliance lives. Because the agreement never ends, the boundaries of that scope matter for as long as you hold it, which is potentially forever. This article explains how audit exposure actually works under a perpetual agreement, what tends to trigger a review, and the governance that keeps a PULA holder genuinely safe rather than merely comfortable.
Yes. A PULA grants unlimited deployment only within its defined scope, so Oracle retains the right to verify that your use stays inside that scope. The unlimited right is bounded by three things: the named product list, the customer definition that sets which entities may deploy, and the territory clause that sets where. Deployment of products outside the list, by entities outside the definition, or in territories outside the clause is not covered by the unlimited grant, and is exposed in exactly the same way as any other unlicensed use. The myth to retire is that unlimited means unauditable. It does not.
A fixed term ULA has a moment of closure. At the end of the term you certify, the deployed quantity converts to a defined perpetual entitlement, and the unlimited phase is over. From that point your compliance question is the ordinary one: do you stay within the certified count. A PULA has no such moment. The unlimited phase continues indefinitely, which sounds like a relief but means the scope boundaries stay live forever. There is never a point at which the agreement resolves into a fixed, owned number, so the discipline of staying inside scope is permanent rather than a phase that ends at certification. This is the heart of why a PULA is operationally demanding in a way a certified estate is not, and it is explored further in governing deployment under a PULA.
Only three categories are covered by the unlimited right, and everything outside them is exposed regardless of the word unlimited.
Unlimited applies to the specific products listed in the agreement, not to the Oracle catalogue. Deploying a database option, a management pack, or a separate product that is not named is unlicensed use, and it is a common finding because teams assume the unlimited grant is broader than it is. The discipline is to know the product list exactly and to govern deployment against it, the same way a ULA holder must.
The customer definition sets which legal entities may deploy under the agreement. Deployment by an entity outside that definition is not covered, and in a perpetual agreement this exposure compounds with every corporate change. A subsidiary acquired after signing, or a joint venture that was never inside the definition, can be running covered products without the right to do so. The specific failure mode is set out in the PULA customer definition risk.
The territory clause sets where deployment is allowed. A PULA written for one region does not silently extend to operations stood up elsewhere later. Because the agreement never expires, a territory you outgrow becomes a continuous gap rather than one corrected at the next term. Global estates need the territory to match the real footprint, and to keep matching it as the footprint moves.
Covered by the unlimited right: the named products, deployed by entities inside the customer definition, in the permitted territory. Quantity is genuinely unlimited within those bounds.
Not covered, and exposed in an audit: products not on the list, entities outside the customer definition, deployments outside the territory, and any product that has left the agreement scope through a contractual change. None of these benefit from the word unlimited.
The triggers are the ordinary ones, and they apply to a PULA holder as much as to anyone. A merger or acquisition that changes the corporate group invites scrutiny of the customer definition. A significant new deployment, especially in a new region or a new product area, raises the question of whether it sits inside scope. A support renewal, a sales conversation about additional products, or a change in account team can all surface a compliance review. Because the PULA never closes, none of these triggers is mitigated by a certification that fixed the position, so the buyer carries the same review risk indefinitely. Treating the agreement as settled is the mistake; treating it as a live grant that must be governed is the protection.
The protection for a PULA holder is the same evidence discipline that protects a certified estate, run continuously rather than once. Three practices carry most of the weight.
Keep a current inventory of where the named products are deployed, by which entities, and in which territories. A PULA holder who can show, at any time, that deployment sits inside scope has answered the audit before it arrives. The record should be refreshed on a schedule, not reconstructed under pressure, because reconstruction after a trigger is where errors and exposure appear.
New deployments should be checked against the product list, the customer definition, and the territory before they go live, not after. This is ordinary licensing governance, but a PULA makes it permanent, since there is no certification to reset the position. The mistakes that follow from neglecting this are durable precisely because the agreement is, and they are catalogued in the PULA mistakes that last forever.
Every merger, acquisition, divestiture, and reorganisation is a scope event under a PULA. Before integrating an acquired entity onto covered products, confirm whether the customer definition reaches it. Before a divested unit keeps using covered products, confirm whether it still may. Managing change against the agreement scope is the single highest value governance habit, because the customer definition is the clause most likely to drift out of line over a perpetual horizon.
Consider an indicative group holding a PULA written several years ago for its then current structure. Since signing, it has acquired two businesses and entered a new region. The acquired businesses were migrated onto covered products as a matter of convenience, and the new region stood up its own instances. None of this was checked against the agreement. A support renewal prompts a routine review, and Oracle asks which entities are deploying and where. The acquired entities sit outside the customer definition, and the new region sits outside the territory, so a meaningful slice of deployment that everyone assumed was unlimited turns out to be unlicensed. The group now faces a remediation conversation it could have avoided with governance at the point of each change. The scenario is illustrative, and the actual outcome depends entirely on the specific customer definition and territory language in the agreement.
A PULA is safe when it is governed and exposed when it is assumed. Read the scope boundaries in your own agreement, build a live deployment record, and manage every corporate change against the customer definition and territory. Start with the Oracle PULA guide for the structure, set up the operating discipline with governing deployment under a PULA, and frame the wider decision with our PULA and capped ULA guide. Because every compliance answer under a PULA depends on the precise wording of your product list, customer definition, and territory, the only reliable starting point is a careful reading of your contract against your real estate.
Yes. A PULA grants unlimited deployment only within its defined scope, so Oracle can audit whether your use stays inside that scope. The unlimited right covers the named products, the defined entities, and the permitted territory. Deployment outside any of those boundaries is unlicensed and exposed in an audit.
Only the named products, the entities inside the customer definition, and the permitted territory are covered by the unlimited right. Products outside the list, entities outside the definition, and deployments outside the territory are not, regardless of the word unlimited, and they remain exposed for the life of the agreement.
We read the product list, customer definition, and territory in your agreement against your real estate, so you can prove you are in scope before anyone asks.