Oracle ULA vs. PULA: Flexibility or Long-term Stability

Oracle ULA vs. PULA: Flexibility or Long-term Stability

Updated November 2026: we corrected the claim that a PULA ends Oracle audits (it does not; the audit terms of your licence agreement still apply) and added Oracle's rule that ULA licences deployed in AWS, Azure or Google Cloud cannot be counted at ULA certification. Unverifiable figures on term length and cost were removed.

Oracle licensing models significantly influence IT strategies, budgets, and operational flexibility. Understanding the distinctions between Oracle's Unlimited License Agreement (ULA) and Perpetual Unlimited License Agreement (PULA) is essential for optimizing your organization's licensing approach. Neither is a licence metric: both sit on top of the metrics of the programs they cover (Processor, Named User Plus and so on), and the detail of each lives in your own ordering document. The LICENSEWARE Wiki's article on Oracle ULA and PULA licensing sets out what Oracle does and does not publish about them.

Oracle ULA: Flexibility for Growth

An Oracle ULA grants the right to deploy an unlimited number of the Oracle programs named in the agreement for a fixed term set in the contract. Oracle publishes no standard term; its own advisory team describes a customer case built on a three-year ULA. This licensing model is advantageous for organizations anticipating significant growth, infrastructure expansions, or major IT transformation projects involving Oracle technologies. The key benefit of a ULA is its flexibility: during the term you can deploy as much of the covered programs as you need without buying further licences for them.

However, when the ULA term concludes, organizations must certify their usage, declaring what they have deployed of each covered program. Oracle does not publish a certification formula; the mechanics are in your contract. Certification can become complex and may expose companies to compliance risks or unforeseen expenses if not proactively managed. After certification, the certified quantities are the licences you keep: any deployment beyond them, or of a program the ULA never covered, needs additional licences or a new ULA.

The cloud rule: ULA licences in AWS, Azure and Google Cloud

Oracle's policy Licensing Oracle Software in the Cloud Computing Environment (policies in effect as of 4 September 2026) names three Authorized Cloud Environments: Amazon Web Services (EC2 and RDS), Microsoft Azure and Google Cloud Platform. It lets you use ULA licences there during the term, but says customers "may not include those licenses in the certification at the end of the ULA term".

In practice, everything you run on AWS, Azure or Google Cloud under the ULA drops out of the count you certify. If a large part of your estate has moved to those clouds by the end of the term, you can leave the ULA owning far fewer licences than you deploy, and those cloud workloads then need licences of their own. Plan your certification with that in mind well before the end date. The policy is an educational document, not part of your contract, and Oracle can change it without notice; it names ULAs only and says nothing about PULAs. The LICENSEWARE Wiki's Authorized Cloud Environments entry tracks the vCPU counting rules that apply in those clouds.

Ideal scenario for ULA: Organizations expecting short- to medium-term expansion and those seeking predictable licensing costs during periods of significant transformation, with a clear plan for what they will certify, and where it will run, when the term ends.

Oracle PULA: Long-term Stability

Unlike a ULA, an Oracle PULA has no specified time period: you hold the right to use the covered Oracle programs perpetually, within the terms and conditions of the contract. With no term to expire, there is no end-of-term certification date to plan around, and no ULA renewal to negotiate. It is well-suited for enterprises with stable or continuously growing Oracle usage that seek operational simplicity and cost predictability.

A PULA does not end audits. Your Oracle licence agreement, including its audit terms, still applies, and Oracle License Management Services audits compare your deployments with your contractual entitlements. The PULA's unlimited right reaches only as far as the agreement does. A program it does not list, or an entity or territory the contract does not include, is licensed like any other Oracle deployment and can produce an audit finding. Using covered programs outside the agreement's terms can too. Keep tracking what you deploy, and where, against what the PULA actually covers.

Oracle does not publish ULA or PULA pricing, so the cost case rests on your own forecast. If your Oracle usage is likely to fall, check how your contract sets the annual support fee and whether it can come down with your estate; a perpetual unlimited right you no longer use is still paid for.

Ideal scenario for PULA: Large, mature organizations with long-term Oracle commitments that want to stop counting licences for the covered programs and simplify ongoing administration, while still managing compliance for everything the agreement does not cover.

Strategic Impact on Your Business

Compliance Risks:

  • Misreading what the agreement covers (programs, entities, territories, cloud use) turns into findings in an audit or at ULA certification, and unexpected costs.

Strategic Planning:

  • Accurately forecasting growth, Oracle usage and cloud migration is crucial to choosing between a ULA or PULA effectively.

Staying Ahead with LICENSEWARE:

  • Regularly perform licensing reviews to align Oracle agreements with actual usage.
  • Deploy SAM tools to monitor, optimize, and forecast license consumption accurately, including which deployments run in Authorized Cloud Environments.
  • Maintain meticulous documentation of deployments to mitigate compliance risks.
  • Leverage informed negotiation strategies to secure favorable contract terms.

If your organization is currently evaluating Oracle licensing strategies or aims to streamline existing license management, LICENSEWARE offers practical insights and modular solutions tailored to your business needs. Contact us to learn more.

Posted in
Alex Cojocaru

Alex Cojocaru

Alex has been active in the software world since he started his career as an Analyst in 2011. He had various roles in software asset management, data analytics, and software development. He walked in the shoes of an analyst, auditor, advisor, and software engineer, being involved in building SAM tools, amongst other data-focused projects. In 2020, Alex co-founded LICENSEWARE and is currently leading the company as CEO.