Introduction: Oracle’s licensing framework is complex, filled with specialized terms and policies that can bewilder even seasoned IT professionals.
This glossary provides a high-level overview of essential Oracle licensing concepts in plain language.
It breaks down key ideas into five core areas: (1) fundamental Oracle contract terms, (2) common license metrics, (3) support and maintenance policies, (4) audit-related acronyms, and (5) cloud licensing lingo.
Each section below offers clear definitions, real-world examples, and best-practice recommendations.
Whether you manage Oracle licenses or just need a grounding in the basics, these explanations will help you navigate Oracle’s licensing landscape with confidence and avoid costly mistakes.
Key Oracle Contract Terms (OMA, OLSA, CSI, etc.) Defined in Plain Language
Oracle’s contracts and paperwork form the foundation of your rights and obligations when using its software. Understanding the acronyms and documents involved is critical.
Below is a summary of the most important Oracle contract terms and agreements, translated into plain language:
| Term | Definition & Role |
|---|---|
| OMA (Oracle Master Agreement) | The predecessor to the OMA, used in the past as the primary license agreement. An OLSA similarly outlined terms and conditions for using Oracle software, but they were often issued separately for each purchase. Many long-time Oracle customers still have OLSA documents governing older licenses. After 2013, Oracle transitioned to the OMA to consolidate agreements. |
| OLSA (Oracle License and Services Agreement) | The predecessor to the OMA was used in the past as the primary license agreement. An OLSA similarly outlined terms and conditions for using Oracle software, but they were often issued separately for each purchase. Many long-time Oracle customers still have OLSA documents governing older licenses. After 2013, Oracle transitioned to the OMA to consolidate agreements. |
| Ordering Document / Order | A transaction-specific contract that lists the exact products, quantities, and metrics you are licensing, along with pricing. When you buy Oracle software, you sign an ordering document (sometimes called an order form or order schedule) that references the OMA/OLSA. The order document details the licenses you obtained (e.g., 100 Processor licenses for Oracle Database Enterprise Edition) and any special terms for that purchase. |
| CSI (Customer Support Identifier) | A unique number Oracle assigns to each set of licenses with an active support contract. Think of a CSI as an ID for your support entitlement. Oracle uses CSI numbers to track which products you can get updates and help for. For example, after purchasing Oracle Database with support, you receive a CSI that you register in Oracle’s support portal. All support requests, patch downloads, and maintenance renewals tie back to that CSI. It’s important to keep track of your CSIs as they represent proof of your licensed support coverage. |
Plain Language Explanation: When your company buys Oracle software, you typically sign an Oracle Master Agreement (OMA) that sets the overall rules (covering things like how you can use the software, confidentiality, payment terms, audit rights, etc.).
Then, for each purchase, you get an Ordering Document that lists exactly what you bought under that OMA. In the past, Oracle used separate Oracle License and Services Agreements (OLSA) for each purchase, but now they are mostly consolidated under one OMA for convenience.
Along with your license purchase, if you subscribe to Oracle’s support, you receive a Customer Support Identifier (CSI) number. This CSI is used whenever you need to download updates or contact Oracle Support – it’s your support account number.
Real-World Usage Example: Imagine a growing tech firm initially bought an Oracle database in 2012. That purchase was under an OLSA, so those licenses follow the terms of that older contract. In 2025, the firm signs a new OMA with Oracle to cover all future transactions. Later, it purchases additional database licenses under the OMA via an ordering document.
Now the OMA’s terms apply to both old and new licenses, often superseding the OLSA for consistency. The company receives a new CSI for supporting the additional licenses. They add this CSI to their records, ensuring they can download patches and log support tickets for the new licenses. Over time, they consolidate all support contracts under a handful of CSI numbers to streamline support renewals.
Guidance: Always read your Oracle agreements carefully. Key contract terms, such as the audit clause or usage rights, are found in the OMA/OLSA. For instance, the OMA typically stipulates that you may use the software for internal business operations only and describes how audits work, including Oracle’s notice, your obligation to cooperate, etc.
Make sure you retain copies of all ordering documents and CSIs – these are your proof of what you are entitled to use. If you are unclear about any contract definitions, seek clarification from independent licensing experts rather than assuming. Small misunderstandings (e.g., over a term like “Processor” or restrictions on third-party use) can lead to compliance issues later.
Recommendations (Contract Terms):
- Centralize Your Agreements: Maintain a repository of all Oracle contracts – master agreements, OLSAs, order forms – so that you know which terms apply. Consolidating under an OMA, if possible, can simplify management.
- Understand Key Clauses: Focus on sections like License Grants, Usage Restrictions, and Audit clauses in the OMA/OLSA. Ensure that business and IT teams have a plain-language summary of what these terms mean (e.g., who can use the software, on which machines, and how an audit could occur).
- Track Support Identifiers: Keep an updated list of your CSI numbers and what products they cover. This will help with support renewals and any license reviews. For example, if Oracle contacts you about support renewal, knowing your CSI and the licenses tied to it will make the process smoother.
- Seek Independent Advice: If you’re negotiating terms (for example, trying to modify the indemnification clause or an outsourcer usage clause in an OMA), consider consulting an independent Oracle licensing advisor, such as Redress Compliance. They can help interpret contractual language and suggest favorable adjustments based on industry best practices.
- Examples and Training: Provide internal stakeholders with plain-language examples of how your Oracle contracts work. For instance, illustrate what “internal use only” means by scenario (using the software to service external clients would violate the standard contract). Regular training on these terms can prevent unintentional breaches.
