Oracle PULA – Oracle Perpetual ULA

What is Oracle PULA?

• Perpetual Unlimited License Agreement (PULA).
• Grants unlimited deployment rights for specific Oracle software.
• No set end date, unlike ULA.
• Simplifies asset management.
• Eliminates license fees for included products.
• Reduces audit risks.
• Requires customers to forgo partial termination of unused licenses.

What is Oracle PULA?

Oracle’s Perpetual Unlimited License Agreement (PULA) is a specialized enterprise contract granting unlimited, perpetual rights to use specific Oracle software.

It eliminates the fixed term of a traditional Unlimited License Agreement (ULA), allowing indefinite deployment growth without the need for end-of-term true-ups.

While a PULA offers simplicity and the freedom to scale, it comes with a very high upfront cost and ongoing support fees; therefore, organizations must weigh the long-term value against potential financial and contractual risks.

Oracle License Agreements Overview

Oracle offers a range of licensing models for its software, from standard perpetual licenses (pay-per-license) to enterprise agreements like ULAs. Unlimited License Agreements (ULAs) are deals that let a customer deploy unlimited quantities of certain Oracle products for a specified term (often 3-5 years).

At the end of a ULA term, the customer “certifies” their usage and receives the corresponding number of licenses to continue using them going forward.

ULAs are popular for companies anticipating rapid growth or facing large compliance gaps, as they provide short-term flexibility and audit peace of mind.

However, ULAs eventually expire, requiring renewal or recertification, and can lock in high support costs if a large quantity is deployed.

In contrast, the Oracle Perpetual ULA (PULA) is an unlimited agreement with no expiration date.

A PULA grants the same kind of unlimited usage rights as a ULA, but on a perpetual basis, meaning there is no predefined end date after which certification is automatically required.

This model is relatively rare and intended for Oracle’s largest customers who expect to use Oracle software extensively for the long haul.

Below, we delve into how a PULA works, its differences from a standard ULA, its benefits, and its drawbacks.

What is an Oracle PULA?

Oracle PULA (Perpetual Unlimited License Agreement) is a contract in which Oracle allows a customer unlimited deployment rights for specified Oracle products forever (as long as the agreement remains in effect). Unlike a normal ULA that runs for a term and then ends, a PULA has no fixed term.

The customer makes a one-time license investment upfront, typically much larger than a standard ULA fee, in exchange for perpetual unlimited use of the agreed-upon products. The customer must also pay annual support fees to Oracle to maintain the PULA’s activity.

As long as support is paid, there is effectively no limit to how much of the included software the company can deploy across its enterprise, without needing to purchase additional licenses.

Oracle PULA offers unlimited, perpetual rights with no fixed term or certification requirement.

Under a PULA, companies gain the freedom to scale their Oracle deployments indefinitely without worrying about running out of licenses or negotiating new contracts every few years.

This can be extremely valuable for organizations that rely heavily on Oracle databases, middleware, or other software and expect that reliance to continue or grow.

For example, a global firm running hundreds of Oracle Database servers could opt for a PULA to ensure any future expansion, new projects, or acquisitions can utilize Oracle technology without any new licensing costs. Once the PULA is in place, all those deployments are covered under the unlimited agreement.

However, it’s important to note that “perpetual” does not mean free forever – ongoing support fees are required to maintain the unlimited usage rights.

Oracle’s support fees are typically 22% of the license value per year, and in a PULA, the notional license value is very high (since it’s effectively an “all you can eat” license). This means the company will be paying a substantial support bill every year.

Moreover, Oracle often applies annual increases to support (commonly ranging from 4% to 8% per year), so support costs can rise over time.

Suppose a customer decides to stop paying support.

In that case, the PULA’s unlimited rights terminate, and a certification process will be initiated, essentially freezing usage and converting it into a fixed number of perpetual licenses based on what is deployed at that time.

In other words, the PULA is only unlimited while you continue paying support; there is no option to partially reduce support costs by dropping unused licenses during the PULA.

Key Differences: PULA vs. Standard ULA

While both the traditional Oracle ULA and a PULA provide unlimited usage rights, they differ significantly in structure and long-term implications.

The table below summarizes the key differences between a standard term-limited ULA and a Perpetual ULA:

In simple terms, a ULA is like an “all-you-can-eat buffet” for a limited time – great while it lasts, but you eventually have to step on the scale (certify your usage).

A PULA is more like buying an all-you-can-eat pass for life – you pay a fortune upfront and an ongoing fee to keep it, so it only makes sense if you plan to dine at Oracle’s table for a very long time and very frequently.

Benefits of a Perpetual ULA

For the right organizations, an Oracle PULA can offer several compelling advantages:

• Unlimited Growth Capacity: You can deploy covered Oracle products without ever worrying about license limits. This is ideal for businesses expecting significant growth, large projects, or fluctuating usage. The PULA removes the need to constantly procure new licenses as you expand – every new server, database instance, or user is automatically licensed under the agreement.
• No Renewal Deadlines: Unlike a standard ULA, there’s no looming contract end date. This eliminates the periodic negotiation cycles with Oracle and the resource-intensive certification process. Companies avoid the stress and preparation that comes with certifying deployments or negotiating a renewal every few years.
• Simplified License Management: Asset management becomes easier in a PULA because tracking exact counts of deployments is less critical on a day-to-day basis. IT and procurement teams can spend less time on micromanaging Oracle license compliance during the agreement. There’s also reduced audit risk for the products in the PULA, as you’re always compliant by definition (with unlimited use rights), so Oracle can’t claim that you have exceeded your licenses for those products.
• Predictable Budgeting (Long Term): With a PULA, your Oracle licensing costs become more predictable over the long term. You know the big upfront cost and can plan for the steady annual support fees. There are no surprise license purchases needed for spikes in usage – it’s all covered. This can align well with long-range IT budgeting for organizations that plan 5-10 years ahead. (For example, a company that knows it will deploy hundreds of Oracle databases over the next decade might calculate that a PULA is cheaper than multiple successive ULAs or constant license purchases.)
• Strategic Flexibility: The freedom of a PULA enables IT teams to pursue projects without delay for licensing. Mergers, new product launches, global expansions, or cloud migrations can be executed using Oracle technology without requiring the procurement team to scramble for licenses. In essence, a PULA future-proofs the organization’s Oracle estate for any foreseen needs (within the product scope of the agreement).

Drawbacks and Risks of PULA

Despite its advantages, a PULA carries significant drawbacks and risks that need careful consideration:

• Enormous Upfront and Ongoing Cost: The entry price for a PULA is extremely high. Oracle typically charges a massive one-time license fee (often tens of millions of dollars) for a PULA, since you’re essentially buying unlimited rights in perpetuity. Additionally, the annual support fees (22% of the huge license value) result in millions of dollars in yearly expenses. Over time, the total cost of a PULA can far exceed a standard ULA or other licensing approach if your actual usage doesn’t grow as expected. It’s a significant financial commitment that’s only justifiable if your Oracle usage remains extremely large.
• Locked-In Support Payments: With a PULA, you are committing to pay Oracle support indefinitely to maintain your unlimited rights. There is no way to reduce support costs even if your usage drops or you decide to decommission some systems. In a normal scenario, if you had surplus licenses, you could choose not to renew support on some of them to save money; in a PULA, such partial termination isn’t allowed – you must pay for the full suite as defined in the contract. This lack of flexibility means if your organization’s strategy changes (for example, a shift to open-source databases or another vendor), the PULA support costs become a sunk cost that drags on the IT budget.
• Risk if Business Needs Change: A PULA is a long-term bet on Oracle. If, in a few years, the company decides to divest a division, migrate to cloud services that use different technology, or standardize on a different database platform, the PULA becomes a poor deal. You might end up paying for unlimited Oracle use that you no longer need. Essentially, there is execution risk – you are betting that your need for Oracle software will stay high for the foreseeable future. If that bet is wrong, there is no refund on the big investment.
• No Natural Exit Point: Since there is no end date, there is no built-in opportunity to renegotiate or adjust the license footprint. With a term ULA, you have a checkpoint in a few years to reassess and possibly decide not to renew if it no longer suits you. With a PULA, you’re continuously in it. Exiting a PULA early would typically require triggering a certification (for instance, by stopping support or by a negotiated agreement with Oracle), which could be complex and potentially costly. Essentially, once you’re in a PULA, Oracle holds all the leverage – they know you depend on that unlimited agreement.
• Contractual Triggers and Surprises: PULA contracts often include specific clauses that can terminate the unlimited period if certain events occur. Mergers and acquisitions are a prime example – if your company is acquired or merges with another, Oracle usually inserts a clause that the PULA will terminate, and you must certify your usage immediately. This protects Oracle from a scenario where a non-PULA company suddenly gains the benefits of your PULA. However, it means that an unplanned corporate event could force you to update your licenses at the worst possible time. Similarly, any material breach of the contract (like violating the terms of use) could let Oracle terminate the PULA and require certification. These triggers are risky because they might occur when you have deployed far more Oracle software than you could afford to license otherwise, leaving you with a huge compliance exposure if the unlimited grant ends unexpectedly.
• Compliance Scope and Coverage: It’s critical to remember that a PULA only covers the specific products listed in the contract. If your teams mistakenly use an Oracle product or component not included in the PULA, that usage would be unlicensed (since you didn’t buy those). Unlimited agreements can give a false sense of security; companies might get lax and deploy additional Oracle options or features, assuming everything is covered. This can lead to compliance problems. For instance, a PULA might cover Oracle Database Enterprise Edition and certain options, such as Partitioning and Diagnostics Pack. However, if a team also enabled a feature like Advanced Security, which wasn’t included in the agreement, that would be outside the scope. Continuous internal governance is necessary to ensure that you only use what the PULA covers; otherwise, you must negotiate to add any necessary products or services. In complex environments (especially with virtualization or cloud deployments), tracking this can be challenging if not managed properly.

PULA Cost Example and Contract Considerations

To illustrate the cost implications, consider a hypothetical example.

Suppose a company requires a large amount of Oracle licensing for the next several years – say 1000 processor licenses of Oracle Database Enterprise Edition to support global operations:

• Traditional Perpetual Purchase: The list price for 1,000 Oracle DB EE processors could easily exceed $40 million (at roughly $47,500 per processor license). However, large discounts might bring the purchase down to perhaps $10–15 million in a negotiated deal. Annual support would be approximately 22%, which would be roughly $2.2–3.3 million per year. The company pays as it grows, purchasing additional licenses as needed later.
• 3-Year ULA Scenario: Oracle might offer a 3-year ULA for a fraction of the cost of buying outright. For instance, a ULA might be priced at a one-time fee of $5 million for unlimited database deployments over a three-year period. During that term, the company’s support might be pegged at, say, $2 million annually (and then adjusted after the term). By the end of the three years, if the company deployed, for example, 1,200 processors, they would certify that number and then own 1,200 licenses in the future (with support on those 1,200 licenses, perhaps approximately $2.64M/year at 22% of whatever notional license value was locked in).
• Oracle PULA Scenario: A PULA for the same scope (Oracle DB EE unlimited, with no end date) may require an upfront fee of approximately $15–20 million (significantly higher than the ULA, reflecting the perpetual value). The annual support would then be based on that huge license value – for instance, 22% of $20M is $4.4 million per year. That support cost would likely increase each year (for example, 4% uplift would make it about $4.576 in year 2, and so on). Over the next 10 years, this company might end up paying $20 or more (roughly $50 in cumulative support) for a total of approximately $70 million. In return, they have unlimited rights to Oracle Database EE for the duration. If their actual usage grows to, say, 2000 or more processors within that time, the deal could be justified compared to buying licenses piecemeal. But if their usage only ever reached 500 processors, they would have massively overinvested.

The example above highlights the importance of a careful analysis before committing to a PULA. Organizations should model different scenarios (best-case growth vs. worst-case stagnation) to see if the economics make sense.

It’s also critical to negotiate the contract terms of a PULA very tightly:

• Ensure the list of products and options covered by the PULA is comprehensive for your needs. Any Oracle product not in the PULA will still require separate licensing, so the agreement must explicitly include all the software you expect to use widely.
• Negotiate any possible exit or certification clauses. Some PULA contracts may allow for an optional certification at the customer’s initiative (for example, after a certain number of years), providing a way out if needed. If such clauses can be added, they provide a safety valve. Also, clarify what happens if you ever want to terminate support – how the certification will work and what licenses you’d keep.
• Pay attention to merger and acquisition provisions. If you foresee potential acquisitions, try to negotiate terms (if possible) regarding how a merged entity would be managed and operated. Often, Oracle will insist that the PULA ends if the original entity is absorbed; however, the scope can sometimes be extended to affiliates, or a grace period may be allowed for adjustments. Understanding these trigger conditions upfront can prevent nasty surprises.
• Cap support increases if you can. Oracle’s standard support uplift is usually around 4% annually, but there have been instances of higher increases. In a long-term deal like PULA, even a small difference in the annual increase (4% vs 8%) has huge cost implications over decades. During negotiation, some customers attempt to lock in a lower or fixed support increase rate or at least have it specified in the contract.
• Consider including cloud usage rights explicitly. If you plan to use Oracle in the cloud (Oracle Cloud Infrastructure or AWS/Azure with Bring Your Own License), ensure the PULA allows it. Most ULAs and PULAs do cover “Oracle authorized cloud environments” for deployment, but the contract should state which cloud environments are permitted and how they count. The good news is that a PULA typically would cover usage in any environment since it’s unlimited – but verify Oracle’s policies (especially for clouds that Oracle hasn’t “authorized” in their standard contract language).
• Be aware of third-party support implications. Once in a PULA, switching to a third-party support provider (such as Rimini Street) would likely mean terminating your Oracle support, which, as discussed, triggers the end of your unlimited rights. This is a one-way street: you’d then certify your current usage and no longer have unlimited deployment rights (and Oracle likely won’t allow re-entry into a PULA easily). If long-term cost savings through third-party support are something you want to keep as an option, recognize that a PULA effectively forces a choice between unlimited usage (with Oracle support) or leaving Oracle support and forfeiting unlimited use.

In summary, treat a PULA negotiation with the same rigor as any major long-term strategic investment.

Involve your procurement experts, legal team, and even external licensing advisors. Every clause can have a significant impact down the road due to the perpetual nature of the deal.

Recommendations

• Perform a Long-Term Needs Analysis: Before considering a PULA, thoroughly project your organization’s Oracle usage needs 5, 10, even 15 years out. Only opt for a PULA if forecasts show sustained or growing usage that would justify the high cost. If your Oracle footprint may shrink or shift, a PULA is likely not the right choice.
• Compare Alternatives Side by Side: Evaluate standard licensing or a shorter-term ULA against the PULA. Sometimes, a series of 3-year ULAs (with chances to adjust or exit) or an Enterprise License Agreement with a cap can be more cost-effective and flexible. Don’t assume PULA is the only solution for large deployments – weigh the pros and cons in financial terms.
• Negotiate Contract Terms Rigorously: If you proceed with a PULA, negotiate the contract to include clear definitions of the included products, allowed use in virtual/cloud environments, and any events that trigger the end of the unlimited rights. Seek to eliminate or soften clauses that could unexpectedly terminate the agreement (e.g., acquisition triggers), or at least be fully aware of them and plan accordingly.
• Plan for Governance Under Unlimited Use: Even with unlimited rights, implement robust internal controls. Track the deployment of Oracle products, ensure teams don’t use software outside the PULA scope, and maintain documentation of all deployments. Treat it as if you will eventually have to certify, even if you may never need to – this discipline helps avoid compliance problems and keeps your options open.
• Budget for Annual Support Escalation: Incorporate the rising support costs into your IT financial plans. Ensure management understands that the initial cost is just one part – the support fees (which typically go up each year) will be a significant ongoing expense. Have a plan to fund those fees in the long term, and consider negotiating a cap on increases when signing the deal.
• Engage with Licensing Experts: Collaborate with independent Oracle licensing experts or consultants when considering a PULA. They can provide benchmarks from other deals, identify risky contract language, and suggest negotiation strategies. Their insights may help save millions or avoid pitfalls, given the complexity and binding nature of these agreements.
• Keep an Exit Strategy in Mind: Even though a PULA is perpetual, circumstances can change. Strategize what you would do if you ever needed to exit – for example, if a major business change made Oracle less central. Know what that process would entail (certification of usage, potential purchase of any shortfall if usage exceeded expectations, etc.). Having an idea of the “exit cost” helps you understand the true commitment you’re making.

Checklist

• Assess Current and Future Oracle Usage: Inventory your Oracle deployments and growth plans. Determine whether your usage trajectory truly requires an unlimited, perpetual agreement or if more incremental licensing approaches are sufficient.
• Define Scope and Products Clearly: Create a list of all Oracle products (including database options, middleware, etc.) that need to be covered in a PULA. Verify that any potential PULA contract includes every critical product to avoid gaps.
• Calculate Total Cost of Ownership: Model the 10-year (or longer) cost of a PULA vs. other options. Include upfront fees, support costs with annual increases, and potential costs after a ULA’s term. Ensure leadership understands the financial commitment.
• Review Contract Terms with Experts: Before signing, have your legal/procurement teams, as well as an Oracle licensing expert, review the PULA terms. Flag any clauses on termination, audit, or restrictions. Prepare negotiation points to address these.
• Implement Governance if Signed: If you enter a PULA, set up a governance team or process to monitor Oracle usage. Schedule periodic internal audits of deployments, and maintain a relationship with Oracle (or a consultant) to stay informed on compliance and support issues. This ensures you maximize the value of the PULA and avoid nasty surprises.

FAQ

Q1: How is a PULA different from a regular Oracle ULA?
A: A standard Oracle ULA is time-bound (e.g., 3 years of unlimited use, then it ends, and you must certify your usage). A PULA has no end date – it gives unlimited use indefinitely. Essentially, a ULA is a subscription for unlimited usage for a few years, whereas a PULA is an outright purchase of unlimited usage rights forever (with ongoing support payments). The PULA’s permanence eliminates the need to count licenses at the end of a term, but it also entails a significantly larger upfront cost and a long-term commitment.

Q2: What kind of companies should consider an Oracle PULA?
A: Typically, only very large enterprises with a heavy and constant reliance on Oracle software consider a PULA. Examples might be a Fortune 100 company running hundreds of Oracle databases and applications, or a software-as-a-service provider whose platform is built on Oracle technology at a massive scale. These organizations foresee using Oracle at high volumes for the next decade or more, making a perpetual deal attractive. If your Oracle usage is moderate or you’re unsure it will remain high, a PULA is likely overkill – a standard ULA or other licensing option would be more suitable.

Q3: What happens if our usage decreases or we no longer require as much Oracle after signing a PULA?
A: Unfortunately, with a PULA, you cannot reduce your costs if usage declines. You will continue paying the same annual support fees regardless of how much of the software you use. There is no built-in mechanism to scale down. The only way out would be to terminate the agreement (or stop paying support), which triggers a certification of whatever is in use at that moment. After that, your unlimited rights end, and you keep a fixed number of licenses. However, terminating a PULA is a serious step – it may mean losing the ability to deploy new instances freely, and Oracle will consider the deal concluded. Because of this rigidity, it’s important to only commit to a PULA if you’re confident you’ll need those unlimited rights for the long term.

Q4: How are Oracle PULA support fees determined, and do they increase?
A: Oracle calculates the annual support fees for a PULA as a percentage (usually 22%) of the contract’s license value. Since the license value for an unlimited perpetual deal is very high, the support fee is correspondingly large. For example, if the notional license value of a PULA is $20 million, the annual support would be $4.4 million. These support fees are subject to annual increases – Oracle often includes a clause for an annual increase (commonly around 4% per year, although it could be higher in some cases). This means if you start at $4.4M, the next year might be roughly $4.6M, then $4.8M, and so on. Over many years, this compounded increase significantly adds to the total cost. It’s crucial to factor in those escalations when budgeting for a PULA.

Q5: What should we watch out for in a PULA contract (common pitfalls)?
A: Key pitfalls include: (1) Incomplete product list: not including all the Oracle components you use – anything left out isn’t covered. (2) M&A clauses: a clause that forces certification if your company is acquired or merges can abruptly end your unlimited rights – try to negotiate this if possible, or be aware of it. (3) Restricted entities or geographies: ensure the PULA covers all your subsidiaries and geographies where you operate; sometimes, the contract might limit the usage to the legal entity signing or specific territories. (4) No exit provision: realize that you won’t have an easy way out; make sure management knows that if they sign a PULA, they are committing to paying support potentially forever. (5) Compliance governance: Don’t assume unlimited means you can ignore license compliance – you still need to stay within the scope (products/metrics) of the PULA. Having an internal compliance program is crucial in preventing the accidental use of non-covered software. By being mindful of these areas and addressing them upfront in the contract, you can avoid nasty surprises later on.

Read about our Oracle Licensing Assessment Service.

Would you like to discuss our Oracle Advisory Services with us?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Message *

Submit