A PULA, or Perpetual Unlimited License Agreement, grants unlimited deployment of named Oracle products with no end date and no certification exit. It trades the ULA's one time conversion for permanence, which suits an estate that will keep growing but removes the strongest lever a fixed term ULA gives you.
Most buyers meet the PULA late, often when Oracle offers it as a way to settle a difficult certification or to close a renewal without another negotiation in three years. The word perpetual sounds like a gift, and in the right estate it can be. In the wrong one it is a recurring cost with no defined finish line. This guide explains what a PULA actually is, how it differs from a standard ULA, where the money goes, and the small number of situations where signing one is the rational choice. The recurring theme is that a PULA removes the certification moment, and the certification moment is where a ULA holder captures most of the available value.
A PULA is a Perpetual Unlimited License Agreement. It grants unlimited deployment of a named list of Oracle products for a fixed annual fee, and unlike a ULA it has no end date. There is no term to run out, so there is no certification step and no point at which your deployment converts into a fixed perpetual count. You hold the unlimited right for as long as you hold the agreement, and you pay the associated support stream the whole time. The structure is set out in plainer terms in what a PULA is and how it differs from a ULA.
A standard ULA is a fixed term agreement, usually three to five years, that ends with a choice: certify the deployed quantity into a permanent entitlement, or renew for another term. A PULA collapses that choice by never ending. The practical differences matter more than the definitions, so it helps to set them side by side.
Term. A ULA runs a fixed term and then forces a decision. A PULA runs indefinitely and forces nothing.
Exit. A ULA ends with certification, which converts unlimited use into a defined, owned, finite count. A PULA has no certification exit, so the unlimited right and the support stream simply continue.
Cost shape. A ULA fee is paid once for the term, then support continues at the ULA level after certification. A PULA fee is an ongoing stream with no conversion event.
Leverage. A ULA gives you a walk away at term end, which is leverage in any renewal talk. A PULA removes that recurring leverage because there is no term end to negotiate against.
The single most important line in that comparison is the exit. With a ULA, the end of the term is the one moment you can turn unlimited deployment into permanent, owned licenses and stop paying for the unlimited right. The mechanics of that conversion, and why a higher count is free value, are covered across our certification material. A PULA never reaches that moment, so the question to ask before signing is whether you are giving up a conversion you would have wanted.
No. A PULA has no certification exit by design, and that is the defining feature, not an oversight. Because the agreement is perpetual, there is no term that expires and therefore no certification declaration to make. You keep the unlimited deployment right and you keep paying the support stream for as long as you hold the agreement. If your strategy depended on certifying and walking away from ongoing fees, a PULA forecloses it. The economics of holding an unlimited right that never converts are worked through in the economics of a perpetual ULA.
The headline fee buys the perpetual unlimited right. The cost that lasts is the support stream attached to it. As with a ULA, support is the long tail expense, and under a PULA that stream has no natural end because there is no certification to fix a count against. A buyer evaluating a PULA should model the support stream over a long horizon, because the lifetime cost is dominated by years of support, not the upfront fee. We never quote a price here, and any figures in our examples are indicative; the point is the shape of the cost, not a number.
A PULA can be good value for an estate that will keep expanding for many years. If your Oracle footprint is set to grow well beyond what any single ULA term could capture, the unlimited right that never closes can be cheaper than a sequence of renewals, each negotiated under pressure. The unlimited right has the most value when you are deploying heavily, and a PULA lets you keep deploying without another term clock.
For a flat or shrinking estate the logic reverses. If your deployment has plateaued, the rational move with a ULA is to certify the count you have, own it, and stop paying for an unlimited right you are not using. A PULA denies you that move. You keep paying the perpetual support stream while gaining nothing from the unlimited grant, which is the most common way a PULA turns from a convenience into a trap. The situations where this bites are described in when a PULA is a trap.
A PULA carries the same scope traps as a ULA, and they last longer because the agreement does. The customer definition, the entity list, and the territory clause all govern who may deploy under the unlimited right and where. In a fixed term ULA these clauses bite hardest at certification. In a PULA they bite continuously, because there is no certification to close the question. After a merger or a divestiture, a PULA's customer definition can either include entities you did not intend or exclude entities you assumed were covered, and the absence of a term end means the misalignment persists. The specific customer definition exposure under a perpetual agreement is detailed in the PULA customer definition risk.
A PULA is the right choice in a narrow set of circumstances, and recognising them is the whole skill. It makes sense when the estate will grow strongly for a long period, when the organisation values cost certainty over the option to exit, and when the products under the agreement are genuinely strategic and will not be replaced. It is the wrong choice when deployment has stabilised, when there is a credible plan to reduce Oracle reliance, or when the buyer would otherwise certify a strong count and own it outright. Because every one of these turns on your own trajectory and your contract language, the assessment is specific to you. The questions that separate a sound PULA from a costly one are set out in the PULA questions to ask before signing.
If Oracle has put a PULA on the table, treat it as a strategic decision rather than a paperwork shortcut, because it removes the certification exit permanently. Start by understanding the structure in what a PULA is and how it differs from a ULA, model the lifetime support stream with the economics of a perpetual ULA, and read the full cluster through our PULA and capped ULA guide. The decision is not whether perpetual sounds appealing, but whether your estate will use the unlimited right enough to justify giving up the conversion a ULA would offer.
A PULA is a Perpetual Unlimited License Agreement. It grants unlimited deployment of named Oracle products for a fixed annual fee with no end date. Because it never expires, there is no certification step and no point at which deployment converts to a fixed perpetual count.
No. A PULA has no certification exit by design. A ULA ends and you certify the deployed quantity into a perpetual entitlement. A PULA simply continues, so you keep the unlimited right and keep paying the support stream for as long as you hold the agreement.
It depends on growth. A PULA can be cheaper than repeated ULA renewals for an estate that keeps expanding, because the unlimited right never closes. For a flat or shrinking estate it is usually worse value, since you pay the perpetual stream without converting to a defined, finite entitlement.
We model the lifetime cost of a perpetual agreement against the certification you could take instead, so the choice is made on evidence rather than on the word perpetual.