There are five Oracle agreement types every enterprise buyer needs to recognise — the Oracle Master Agreement (OMA), the older OLSA, the Enterprise Agreement (EA), the Unlimited License Agreement (ULA), and the Perpetual ULA (PULA). They differ in term, scope, true-up mechanics, and exit risk, and the one governing your estate decides how much room you have to negotiate. Former Oracle insiders break down each, side by side.
Short answer: Oracle's agreement types fall into two layers. The OMA and the older OLSA are framework contracts that set the legal terms for every transaction. The EA, ULA, and PULA are commercial purchasing structures layered on top — an EA bills actual deployment, a ULA grants unlimited use for a fixed term, and a PULA grants unlimited use forever.
Direct answer: The main Oracle agreement types are the Oracle Master Agreement (OMA), the older Oracle License and Services Agreement (OLSA), the Enterprise Agreement (EA), the Unlimited License Agreement (ULA), and the Perpetual ULA (PULA). The first two are framework contracts; the last three are commercial purchasing structures built on top of them.
An Oracle agreement type is the contractual structure under which you license Oracle software, and it operates on two levels. The bottom layer is the framework — the OMA or its predecessor the OLSA — which sets the universal legal terms: audit rights, definitions, support terms, assignment, and termination. The top layer is the commercial vehicle — a standard Order Form, an EA, a ULA, or a PULA — which determines what you buy, how it is counted, and how you pay.
Understanding both layers matters because they create different risks. The framework agreement is where Oracle's audit leverage lives; the commercial structure is where your money lives. A ULA negotiated on top of an aggressive OMA can leave you with unlimited deployment rights and almost no protection against the audit that follows certification. We unpack the framework layer in depth in our Oracle Master Agreement guide, and the broader picture in the Oracle Database Licensing Guide.
Definition: The Oracle Master Agreement (OMA) is Oracle's current framework contract that sets the general legal terms governing every Oracle license and support transaction. Individual purchases sit on Order Forms that incorporate the OMA by reference. It replaced the OLSA for new customers from around 2014.
The OMA is the legal foundation under most modern Oracle estates. It is drafted by Oracle's legal team to protect Oracle's position in every dispute, and it is not a balanced document. Broad audit rights, auto-renewing support, capped liability for Oracle, and licensing policies incorporated by reference all live in the standard OMA — and most procurement teams sign it without challenge.
The critical feature of the OMA is its reach: terms agreed in the master apply to all Order Forms, past and future, under that agreement. Negotiating an audit notice period, a back-license look-back cap, or a support price cap into your OMA protects the entire estate, not a single product. This is why the OMA is the highest-leverage document to get right before signing — and why every EA, ULA, or PULA you layer on top inherits its terms. Our Oracle contract negotiation service treats OMA clause review as a core deliverable.
Definition: The OLSA (Oracle License and Services Agreement) is the predecessor framework to the OMA. Both govern all transactions, but the OLSA bundled license and services terms together, while the OMA separates master terms from product schedules. Estates signed before about 2014 may still be bound by OLSA terms.
The OLSA governed Oracle relationships through the late 2000s and early 2010s until Oracle restructured its framework into the OMA. The distinction is not academic. OLSA and OMA versions differ in clause wording around audit rights, assignment on a merger or acquisition, and how Oracle's licensing policies are incorporated. An older OLSA can be more favourable on some points and less on others — and many enterprises do not know which framework actually binds them.
If you acquired Oracle before 2014, or absorbed an Oracle estate through M&A, identify your framework before any Oracle engagement. Oracle's account team will often treat the current OMA as the governing document by default, even when your signed contract is an OLSA with materially different terms. Knowing which framework applies — and holding Oracle to the version you actually signed — is foundational, evidence-based audit defense.
Framework trap: After a merger or acquisition, Oracle frequently pushes the acquiring entity onto a fresh OMA — quietly replacing more favourable legacy OLSA terms. Never sign a new framework agreement to "tidy up" an acquired estate without comparing the clause-level differences first.
Our Oracle compliance review identifies your governing framework, the commercial structures layered on it, and the clauses Oracle relies on in an audit.
Definition: An Oracle Enterprise Agreement (EA) is a negotiated, volume-based purchasing framework that lets an organization license agreed Oracle products at enterprise scale, usually with deep discounts and a periodic true-up of deployed quantities. Unlike a ULA, an EA generally counts and bills actual deployment rather than granting unlimited use.
An EA is Oracle's vehicle for large, discount-driven commitments that stop short of unlimited rights. The organization negotiates enterprise pricing across a defined product set, deploys against it, and trues up — paying for what was actually used at the agreed rates. EAs suit enterprises with predictable, measurable growth that want volume discounts without paying upfront for unlimited deployment they may never reach.
The leverage in an EA is concentrated at negotiation and at each true-up. Oracle structures discounts to encourage expansion and frames the true-up as routine, but the deployed-quantity count is exactly where over-claims surface. Treat every EA true-up as a mini-audit: validate the deployment data yourself, challenge any counting Oracle applies that is not supported by your contract, and never accept Oracle's measurement as final without an independent check. Strong EA outcomes — and the discounts behind them — are documented in our client case studies.
Definition: An Oracle ULA (Unlimited License Agreement) is a fixed-term contract — usually one to five years — granting unlimited deployment of a named set of Oracle products for a single upfront fee. At the end of the term the customer certifies the quantity deployed, which converts to that many perpetual licenses.
A ULA is the right structure for an enterprise expecting rapid, large-scale growth in a specific product set — say, a major Oracle Database Enterprise Edition rollout. You pay once, deploy without counting during the term, then certify your deployment to lock in perpetual licenses equal to what you ran. Deploy aggressively and the per-license economics can be excellent; the more you deploy, the more value you extract from the fixed fee.
The trap is the inverse. In our engagements, more than half of enterprises that signed a ULA under-deployed at certification and overpaid for unlimited rights they never used (Oracle Licensing Experts benchmark, 2026). Certification is also where Oracle scrutinises your numbers hardest — counting rules, cloud deployments, and the precise product list all become contested. A botched certification can leave you short on perpetual licenses and exposed to a back-license claim. Getting the exit right is the entire point of our Oracle ULA advisory service; we cover the mechanics in the Oracle ULA guide.
Definition: A Perpetual ULA (PULA) is a ULA with no end date. It grants unlimited deployment of named Oracle products in perpetuity, with no certification deadline. PULAs remove certification pressure but carry the highest upfront cost and the deepest Oracle lock-in, because the agreement and its support stream are designed to be permanent.
A PULA looks attractive on the surface: unlimited deployment of your named products forever, and no nerve-wracking certification event to manage. For a few very large, Oracle-committed enterprises with permanent, growing footprints, that certainty has value. Oracle sells it as the ultimate simplification — never count those products again.
The reality is the deepest lock-in Oracle offers. A PULA ties you to a permanent support stream at 22% of net license value per year (Oracle Technology Price List, 2026), and because there is no certification, there is no natural exit point to renegotiate or walk away. Migrating off Oracle for those products becomes commercially painful, which is exactly Oracle's intent — the PULA is Oracle's agenda dressed as your convenience. Before signing a PULA, model the multi-decade support cost and the cost of exit, not just the headline deployment freedom. This is core to our Oracle support reduction analysis.
The five agreement types operate at different layers and serve different purposes. The table below sets them side by side on the dimensions that decide cost and risk — term, what gets counted, and how hard it is to leave.
| Agreement | Layer | Term | What is counted | Exit / lock-in |
|---|---|---|---|---|
| OMA | Framework | Open-ended | Sets legal terms; nothing licensed by itself | Governs all Order Forms; high audit leverage for Oracle |
| OLSA | Framework (legacy) | Open-ended | Predecessor framework; nothing licensed by itself | May hold more favourable legacy clauses; verify before replacing |
| EA (Enterprise Agreement) | Commercial | Defined term, periodic true-up | Actual deployed quantities | Moderate; true-up is the negotiation point |
| ULA | Commercial | Fixed (typically 1–5 years) | Unlimited during term; counted at certification | Lock-in during term; certification is the exit |
| PULA | Commercial | Perpetual (no end) | Unlimited, never recounted | Deepest lock-in; no natural exit point |
Read across the table and the pattern is Oracle's playbook in miniature: the more deployment freedom you buy, the less exit flexibility you keep. An EA preserves the most room to leave; a PULA the least. The framework layer, meanwhile, quietly determines how much audit pressure Oracle can apply to whatever commercial structure you choose.
Direct answer: Match the agreement type to your deployment trajectory. Choose standard OMA Order Forms for stable estates, an EA for predictable measured growth with discounts, a ULA for a known burst of large-scale deployment, and a PULA only when permanent unlimited use of a specific product set genuinely outweighs the lock-in and decades of support cost.
The decision turns on how fast and how predictably you will deploy. If your footprint is flat, plain Order Forms under a well-negotiated OMA keep you flexible and avoid paying for unused rights. If you expect steady, measurable growth and want volume discounts, an EA lets you commit at scale while still paying for actual use. If you are about to deploy a named product hard and fast — a consolidation, a major rollout, an acquisition integration — a ULA can deliver excellent per-license economics, provided you have a credible plan to deploy enough to justify the fee and certify well.
A PULA is rarely the right answer and should clear a high bar: only when the certainty of permanent unlimited use is worth surrendering your exit and committing to perpetual support. Whichever structure you choose, the framework terms beneath it decide your audit exposure — so negotiate the OMA with the same rigour as the commercial deal. Independent, buyer-side modelling of each option, with the support cost and exit cost made explicit, is what our Oracle license optimization team delivers, and you can explore more on the Oracle Licensing Experts blog.
We model every option buyer-side, expose the support and exit costs Oracle leaves out, and negotiate the framework terms underneath. Talk to a former Oracle insider before you sign.
The main Oracle agreement types are the Oracle Master Agreement (OMA), the older Oracle License and Services Agreement (OLSA), the Enterprise Agreement (EA), the Unlimited License Agreement (ULA), and the Perpetual ULA (PULA). The OMA and OLSA are framework contracts that set legal terms; the EA, ULA, and PULA are commercial purchasing structures layered on top of a framework.
The OLSA is the predecessor framework to the OMA. Both govern all Oracle transactions, but the OLSA bundled license and services terms together while the OMA separates master terms from product schedules, and the two differ on audit and assignment clauses. Customers who signed before about 2014 may still be bound by OLSA terms.
It depends on deployment. A ULA grants unlimited use of named products for a fixed term and converts to perpetual licenses at certification, so it rewards aggressive, large-scale deployment. If your growth is modest, standard Order Forms under a well-negotiated OMA are usually cheaper, because you avoid paying upfront for unlimited rights you will not use.
At the end of a ULA term the customer certifies the quantity of each named product deployed. That count converts into the same number of perpetual licenses, which you keep and continue to support. Certification is where Oracle scrutinises counting rules and cloud deployments hardest, so the exit must be planned and the numbers independently validated.
A PULA never ends, so there is no certification event and no natural point to renegotiate or exit. It ties the customer to a permanent Oracle support stream at 22% of net license value per year (Oracle Technology Price List, 2026), and migrating off Oracle for the named products becomes commercially painful — which is exactly why Oracle promotes it.
Yes. An EA bills actual deployed quantities, and the true-up is where Oracle counts deployment. Treat every true-up as a mini-audit: validate the data yourself and challenge any counting not supported by your contract. Accepting Oracle's measurement without an independent check is how enterprises overpay at true-up.
Pull your signed framework contract and every commercial document. The framework will be titled Oracle Master Agreement or Oracle License and Services Agreement; the commercial layer will be Order Forms, an Enterprise Agreement, or a ULA/PULA schedule. If the paperwork is incomplete after M&A or staff turnover, an independent compliance review can reconstruct the governing structure.
OMA clause analysis, ULA certification tactics, EA true-up benchmarks, and negotiation intelligence from former Oracle insiders. Corporate email required.
Written by the Oracle Licensing Experts Team — former Oracle executives, LMS auditors, and contract managers with 25+ years of combined Oracle licensing experience. Not affiliated with Oracle Corporation. All advisory is independent and 100% buyer-side.