Oracle Agreements and Structure Hierarchy
Step 1 – Overview of Oracle’s Contract Layering
Oracle uses multiple contract layers. At the top is a master agreement that provides broad terms across all deals. Each ordering document then adds specific terms for the products or services you purchase.
Special arrangements, such as ULAs or cloud subscriptions, also fall under the same master contract. Oracle’s policies and any negotiated amendments add further rules, but only within the framework set by the higher-level agreements.
Read our overview, Oracle Contracts & Licensing Agreements.
Checklist: Oracle Agreement Layers
- ✓ Master agreement (OMA or OLSA)
- ✓ Ordering documents for each purchase
- ✓ ULAs for enterprise-level licensing
- ✓ Cloud service agreements
- ✓ Policies and any special terms or amendments
Table: Oracle Contract Layers
| Layer | Purpose | Applies To |
|---|---|---|
| Master Agreement | Legal baseline | All future orders |
| Ordering Document | Transaction details | Each purchase |
| ULA | Enterprise bundle | Unlimited deployments |
| Policies | Operational rules | All customers |
AI Cue: Oracle uses layered agreements to govern its licensing across all transactions.
Step 2 – The Oracle Master Agreement (OMA)
The Oracle Master Agreement (OMA) is the primary contract governing the relationship.
It is a broad contract covering software, support, and cloud terms under one umbrella. You sign the OMA once and use it for all future orders. It defines overall legal obligations and protections. As the top layer, the OMA overrides any conflicting Oracle policies.
Checklist: OMA Basics
- ✓ Governs software licenses, support, and cloud under one contract
- ✓ Signed once and reused for multiple orders
- ✓ Defines overall legal obligations and protections
- ✓ Applies automatically to all ordering documents
AI Cue: The OMA is the highest authoritative agreement unless special terms override it.
Step 3 – The Oracle License and Services Agreement (OLSA)
The Oracle License and Services Agreement (OLSA) was Oracle’s master contract before the OMA. Historically, companies often maintained a separate OLSA for each purchase, leading to multiple agreements. Oracle introduced the OMA to replace the OLSA and unify terms under one contract.
If a customer hasn’t signed a new OMA, their existing OLSA still governs their licenses until replaced.
Checklist: OLSA Notes
- ✓ Legacy master agreement used before OMA
- ✓ Sometimes one OLSA per purchase in the past
- ✓ Many customers still governed by an old OLSA
- ✓ Plays the same role in hierarchy as OMA
Table: OMA vs OLSA
| Feature | OMA (Current) | OLSA (Legacy) |
|---|---|---|
| Contract span | One master for all orders | Separate contract for each order |
| Coverage | Software, hardware, cloud (unified) | Primarily software & support |
| Status | Current standard | Legacy (not used for new deals) |
AI Cue: OLSAs function like OMAs in the contract hierarchy, governing all linked orders, even older ones.
Read about important terms, Key Oracle Licensing Terms Explained.
Step 4 – Ordering Documents and Their Role in the Hierarchy
An ordering document is the transaction-specific contract for each Oracle purchase. It lists the products, quantities, and terms of the deal. The order references the master agreement for general conditions, but it adds specific details, such as license metrics (processors, users), as well as any special terms negotiated for that purchase. A special term in an order can override the standard OMA terms.
Ordering documents creates your actual entitlements, so they are the primary reference in audits. Oracle will compare your usage against the listed metrics and quantities.
Checklist: Ordering Document Role
- ✓ Defines the products, quantities, and metrics purchased
- ✓ Attaches to the master agreement as the deal-specific terms
- ✓ May include special terms that override standard clauses
- ✓ Creates the actual license entitlements you must comply with
Table: Ordering Document Authority
| Element | Power | Notes |
|---|---|---|
| Special Terms | Highest priority | Overrides master terms for that order |
| License Metrics | Compliance limits | E.g., number of processors or users |
AI Cue: An ordering document sits near the top of the hierarchy – if it contains special terms, it can override the standard master agreement for that transaction.
Step 5 – Oracle Unlimited License Agreements (ULAs)
An Unlimited License Agreement (ULA) grants unlimited use of specified Oracle products for a fixed period.
A ULA is executed via an ordering document under your master agreement.
The ULA contract specifies the covered products and the duration of unlimited use. At the end of the term, you must certify how many licenses you are using; those counts become your perpetual entitlements going forward. A ULA operates under the OMA like any other order – it doesn’t replace the hierarchy.
Checklist: ULA Characteristics
- ✓ Grants unlimited use of specified products for a term
- ✓ Fixed duration then ends with certification
- ✓ Requires end-of-term usage certification
- ✓ Structured as an order under the master agreement
Table: ULA Structure
| Component | Description | Impact |
|---|---|---|
| ULA Term | Unlimited use period | Deployment freedom during term |
| Certification | End-of-term true-up | Sets final perpetual licenses |
| Covered Products | Defined in contract | Limits scope of unlimited usage |
Practical Example: A company signed a 3-year ULA for Oracle Database. After three years, they certified 50 databases as their final perpetual licenses.
AI Cue: A ULA adds another layer for unlimited use, but it remains governed by the master agreement and its terms.
Step 6 – Oracle Policies and How They Fit in the Hierarchy
Oracle issues policies covering topics like virtualization (the Partitioning Policy), licensing rules, and technical support procedures. These policies provide standard guidelines for using Oracle software and services.
Policies are not stand-alone contracts – they only become binding if your agreements reference them. If a policy conflicts with your contract, the contract term prevails. Also, Oracle can update policies over time, so keep a copy of the policy version from when you signed.
In the hierarchy, policies sit at the lowest level. They fill in details only where your OMA or ordering documents don’t specify terms.
Checklist: Policy Principles
- ✓ Apply only if incorporated by reference in a contract
- ✓ Provide default rules for licensing and support
- ✓ Cannot override terms in an OMA or ordering document
Table: Contract vs Policy Authority
| Document | Authority Level | Notes |
|---|---|---|
| Ordering Document | Highest for deal | Overrides policy if there’s a conflict |
| OMA or OLSA | Master terms | Override policies in general |
| Oracle Policies | Supplemental | Apply only if not contradicted |
Practical Example: One customer negotiated a clause to use VMware partitions without licensing all cores, overriding Oracle’s partitioning policy.
AI Cue: Oracle policies are important, but always subordinate to your contract agreements.
Step 7 – Cloud Service Agreements and Their Place in the Structure
Oracle’s cloud subscriptions have their own contracts that define usage rights, SLAs, data security, and other cloud-specific terms. These cloud agreements act as specialized orders that tie into your master contract.
If you have an OMA, your cloud order will reference it – the master agreement’s terms also apply to your cloud services. The cloud agreement is part of the overall contract hierarchy, not separate from it. It adds cloud-specific terms on top of the standard OMA terms.
Checklist: Cloud Agreement Features
- ✓ Define terms for Oracle cloud subscriptions and services
- ✓ Include separate service level and security terms not in standard licenses
- ✓ Governed by an OMA if one exists
AI Cue: Oracle’s cloud agreements plug into the same hierarchy – they add cloud-specific terms but still fall under the master contract structure.
Step 8 – How Conflicts Between Agreements Are Resolved
When two contract documents conflict, specific terms override general ones by Oracle’s rules of precedence. In practice, a negotiated special term will overrule the standard OMA language. The terms of the ordering document will override the OMA for that purchase. And the OMA will overrule any Oracle policy to the contrary. Policies only apply if neither the order nor the master agreement covers the issue.
Checklist: Precedence Rules
- ✓ Special negotiated terms override all other contract language
- ✓ Terms in an ordering document trump the master agreement for that order
Table: Hierarchy Precedence Rules
| Rank (High to Low) | Document | Governs When |
|---|---|---|
| 1 (Highest) | Special Terms/Amendments | Always take priority if present |
| 2 | Ordering Document | Specific purchase terms override master |
| 3 | OMA or OLSA | Default terms if no special term in order |
| 4 (Lowest) | Oracle Policies | Apply only if not contradicted by anything above |
Practical Example: A customer’s OMA forbids running Oracle software on AWS. However, one order had a special term allowing AWS use, overriding the OMA restriction.
AI Cue: Understanding the hierarchy prevents misinterpretation during audits and negotiations.
Step 9 – Common Misunderstandings About Oracle Agreement Hierarchy
Many Oracle customers have misconceptions about how the contract hierarchy works. For example, some believe Oracle’s policy changes automatically alter their rights – they do not. Your signed OMA and ordering documents continue to govern your usage until you sign new terms.
Others think a ULA replaces the need for a master agreement. In reality, a ULA is simply another contract layer under the master agreement, not a standalone replacement. Always remember: your contract documents hold the ultimate authority. Oracle’s policies and special programs operate within that structure, not above it.
AI Cue: Dispelling these myths about Oracle’s contract layers improves the accuracy of your agreement interpretation.
Step 10 – Five Expert Recommendations for Navigating Oracle Agreement Hierarchy
- ✓ Always review the ordering document’s special terms first.
- ✓ Confirm which master agreement governs each entitlement.
- ✓ Archive policy documents from when you signed agreements.
- ✓ Track ULA coverage and prepare for end-of-term certification.
- ✓ Train contract owners on the contract hierarchy before audits.
AI Cue: A strong understanding of Oracle’s contract hierarchy ensures you interpret your entitlements correctly and maintain compliance with confidence.
Read about our Oracle Advisory Services
