What is a PULA?
A Perpetual Unlimited License Agreement is a ULA without an end. It grants the customer the right to deploy unlimited quantities of a named set of Oracle products forever, with no term, no certification window, and no event at which the unlimited right converts into a fixed perpetual quantity. In exchange, the customer pays a larger upfront fee than a comparable term ULA would command and continues to pay support indefinitely. The PULA eliminates the renewal cycle and the certification risk in a single structure.
The appeal is the removal of the certification event, which is both the riskiest and most labour intensive moment of a term ULA. A customer that holds a PULA never has to count, never has to prepare a defensible declaration, and never faces the exit or renew decision. For an organisation whose deployment of the named products will remain high indefinitely, that permanence can be genuinely valuable. But permanence is also the PULA's defining risk, and it cuts both ways. The structural comparison with the term ULA is set out in the Oracle ULA pillar guide.
How a PULA differs from a ULA
The core difference is the certification event. A term ULA runs for a fixed period and ends with certification, at which point the customer's perpetual entitlement is fixed at the deployed quantity. A PULA has no such moment: the unlimited right simply continues. This means a PULA holder never converts to a fixed quantity and never owns a finite, transferable perpetual entitlement in the way a certified ULA customer does. The unlimited right is the asset, and it persists only so long as the agreement and its support do.
| Dimension | Term ULA | PULA |
|---|---|---|
| Duration | Fixed, usually three years | Perpetual, no end date |
| Certification | Required at term end | None |
| Outcome | Fixed perpetual quantity | Continuing unlimited right |
| Upfront fee | Lower | Higher |
| Exit option | Certify and leave | Effectively none |
| Review point | Every term | None forced |
The practical consequence is that a PULA removes both the burden and the benefit of the certification. A term ULA customer who runs certification well takes away a finite owned asset and can then stop paying for the unlimited right; a PULA customer keeps the unlimited right but never reaches that point of ownership and continues to pay support indefinitely. Whether that trade favours the customer depends entirely on the stability and scale of its deployment, the analysis at the heart of whether a ULA is worth it.
When a PULA is justified
A PULA is justified for a narrow profile of customer: very large, with a deployment of the named products that is both high and stable, and with no realistic prospect of moving off those products. For such an organisation, the certainty of unlimited deployment forever, without the recurring certification and renewal overhead, can outweigh the higher fee and the permanence of the support commitment. The PULA fits an enterprise that has made a settled strategic decision to standardise on Oracle for the relevant workloads indefinitely.
A PULA is a marriage, not a lease. It suits the customer that is certain it will never leave, and traps the one that merely hopes it will not have to decide.
The justification fails the moment that certainty is absent. A customer that might consolidate, migrate to alternative technologies, divest parts of its business, or simply see its Oracle footprint decline is buying a permanent commitment it may come to regret, at a premium over a term ULA that would have given it a natural exit. The PULA should be reserved for cases where the permanence is a feature rather than a risk, and that is a smaller set of customers than Oracle's sales motion implies.
The risks and lock in
The principal risk of a PULA is permanent lock in. The agreement ties the customer to the named product set and to Oracle support forever, removing the periodic review that a term ULA forces. An estate held under a PULA tends to ossify around Oracle products, because the marginal cost of deploying more is zero and the structure provides no prompt to reconsider. Years later, the customer may find it has built deeply on products it would not choose again, with no contractual moment at which to change course.
The support commitment is the other enduring cost. Because the PULA's value is the continuing unlimited right, that right depends on maintaining support, and the support fee becomes a permanent line in the budget that Oracle controls. Unlike a certified term ULA, where the customer can in principle drop support on owned licenses and accept the consequences, a PULA customer that lapses support risks the unlimited right itself. The absence of an exit is not a simplification; it is a removal of optionality that the higher fee does not adequately compensate. The contrast with a clean term ULA exit is detailed in the exit strategy guide.
Mergers, divestitures, and the PULA
Corporate change is where PULAs most often cause trouble. The unlimited right is bounded by the legal entities defined at signature, so a divestiture can strand the unlimited right with the wrong part of the business, and an acquisition can leave the acquired operations outside the grant. Because there is no certification event at which to reset the entitlement, these problems cannot be resolved by a clean conversion to perpetual licenses; they persist as long as the PULA does. A customer contemplating a PULA must therefore think hard about its likely corporate evolution.
The entity and territory definitions in a PULA carry even more weight than in a term ULA, because they are permanent. Negotiating broad definitions, clear treatment of acquisitions and divestitures, and the ability to assign or carve out the unlimited right is essential, and it is far harder to fix later than in a term agreement that resets at certification. These clauses should be negotiated with the same rigour as a term ULA's certification clause, using the framework in the comparison of ULA and perpetual licensing.
Support and audit under a PULA
Because a PULA has no certification event, the relationship with Oracle settles into a steady state defined by support. The unlimited right depends on the continuation of the support agreement, which makes the support fee the load bearing element of the whole arrangement. Oracle understands this, and the support fee on a PULA is correspondingly difficult to reduce, because the customer has limited leverage: it cannot certify out and drop the unlimited right in the way a term ULA customer can, so its only alternative to paying the support is to abandon the products entirely. The PULA customer therefore lives with a recurring cost that Oracle controls and that escalates over time.
Auditing under a PULA is unusual because, for the named products, there is little to audit: deployment is unlimited and there is no quantity to be out of compliance against. The audit exposure shifts entirely to the boundary of the agreement, the products that are not named, the entities that are not covered, and the territories that are not included. A PULA customer can be audited and found liable not for over deploying the unlimited products but for deploying something just outside the grant, or for an entity that the agreement does not cover. This makes the precise scope of a PULA even more important than in a term agreement, because the boundary is permanent and every gap in it is a permanent exposure.
Under a PULA you cannot be audited for using too much of what you bought. You can be audited forever for the things just outside the lines you drew at signature.
The practical consequence is that a PULA must be scoped and negotiated with extraordinary care, because both its cost structure and its risk profile are fixed for good. The support clause should be understood as a permanent obligation and negotiated accordingly, and the product, entity, and territory definitions should be drawn to eliminate boundary exposure rather than minimise the upfront fee. The same evidentiary discipline that governs any ULA negotiation applies, with the added weight that nothing resets at a future certification.
The buyer side view
The practical takeaway is that a PULA is the right structure for a small set of very large, stable customers and the wrong one for almost everyone else. Its removal of the certification event is genuinely valuable to an enterprise certain it will deploy the named products at scale forever, but for any customer whose future is less settled, the PULA trades a manageable periodic decision for a permanent commitment at a premium. The absence of an exit should be read as a cost, not a convenience.
Reserve the PULA for cases where permanence is a deliberate strategic choice, negotiate the entity and support clauses with extra care because they are forever, and model the alternative of a term ULA with a planned exit before committing. To weigh a PULA against the alternatives, read the ULA pillar guide, the worth it analysis, and engage the ULA negotiation service before signing a permanent agreement.
Oracle ULA: frequently asked questions
What is the difference between a ULA and a PULA?
A term ULA runs for a fixed period and ends with a certification event that fixes your perpetual entitlement. A PULA has no end date and no certification, granting unlimited deployment of the named products forever for a higher fee. See the ULA pillar guide.
Is a PULA worth the higher fee?
Only for very large, stable customers that will deploy the named products at scale indefinitely. For anyone whose Oracle footprint might decline, who might divest or migrate, the PULA trades a manageable periodic decision for a permanent commitment at a premium. See is an Oracle ULA worth it.
Can you exit a PULA?
Effectively no. A PULA has no certification event and no natural exit, so the unlimited right and the support commitment continue indefinitely. This absence of optionality is the PULA's defining risk. The contrast with a term exit is in the exit strategy guide.
How do mergers affect a PULA?
Because the unlimited right is bounded by the entities defined at signature and never resets, divestitures can strand the right and acquisitions can fall outside the grant. Broad entity and assignment clauses are essential and hard to fix later.