The phrase end user licence agreement suggests a single document, but an Oracle licence is built from several layers that work together. The master agreement, historically the Oracle Licence and Services Agreement and now often the Oracle Master Agreement, sets the general terms. The order document records what was actually bought, at what price, and under what metric. Behind both sit Oracle's policies, which are referenced rather than reproduced and which Oracle can change over time. A buyer that reads only the order, or only the master terms, sees only part of the bargain. Understanding how the layers fit together, and which layer controls in a conflict, is the foundation of knowing what the licence permits and what it forbids. This note sets out the structure and how a buyer should read it.
The three layers.
The master agreement is the framework. It contains the definitions, the licence grant in general terms, the audit clause, the limitation of liability, the indemnity, the assignment and affiliate provisions, and the other terms that govern the relationship as a whole. It is signed once and governs every order placed under it. The order document is the specific transaction. It lists the programs licensed, the licence metric, the quantity, the price, and any terms specific to that purchase. The policies are Oracle documents referenced by the agreement, such as the partitioning policy or the technical support policies, which fill in operational detail.
The buyer must hold and read all three. The master terms without the orders do not show what was bought. The orders without the master terms do not show the rights and restrictions. And neither shows the policy detail that often decides a compliance question, such as how virtualisation affects the licence count. The buyer that has assembled the complete stack can answer questions that the buyer holding only fragments cannot. This is the contract record that supports every other discipline, including the compliance posture set out in the compliance posture note.
Where the rights live.
The licence grant tells the buyer what it may do with the software, and the detail matters. The grant is usually limited to the buyer's internal business operations, which excludes using the software to provide services to third parties unless that right is specifically purchased. The grant is tied to the licence metric, so a licence by named user plus permits a different deployment from a licence by processor. The grant is also tied to the specific programs ordered, so the buyer that deploys a program it did not licence, even an option bundled with one it did licence, is outside the grant.
These boundaries are where compliance gaps open. A buyer that uses a database option without a separate licence, or that lets a third party access the software, or that exceeds the licensed metric, has stepped outside the grant. The buyer should read the grant against its actual deployment to confirm the use is within scope. The metric questions in particular reward close reading, as set out in the named user plus counting note.
Where the restrictions bite.
The restrictions are as important as the grant. The agreement typically forbids the buyer from assigning the licence without consent, from using it outside the defined scope, from benchmarking the software without permission, and from removing the software from the territory where that is limited. The restrictions also include the buyer's obligations on records and audits, which give Oracle the right to verify compliance and which shape the audit exposure. The buyer that has not read the restrictions does not know which ordinary business actions, such as a reorganisation or an outsourcing arrangement, could breach the agreement.
The assignment restriction in particular catches buyers during corporate change, because a merger or divestiture can constitute an assignment that requires Oracle's consent. This intersects with the affiliate definition, which controls which entities may use the licence, discussed in the affiliate clauses note. The buyer planning structural change should read the assignment and affiliate provisions together before the event.
The policies that move.
The most subtle layer is the policy documents, because they are referenced rather than reproduced and because Oracle can change them. A policy that affects how the licence count is calculated, such as the partitioning policy that governs virtualisation, can shift the compliance position without any change to the signed agreement. The buyer that relies on a policy as it stood at signing may find Oracle applying a different version at audit. The buyer should understand which policies the agreement references, hold the versions that applied when each order was placed, and watch for changes that affect the deployment.
The partitioning policy is the sharpest example, because it determines whether virtualisation reduces the licence requirement or not, and it is the foundation of the long running dispute over Oracle on VMware. The buyer running Oracle in a virtual environment must read the policy carefully, as discussed in the soft partitioning note. The policy detail can be worth more than the price.
Conflict and precedence.
When the layers say different things, which controls? The agreement contains an order of precedence clause that resolves conflicts, and the buyer must know what it says. In many Oracle agreements the order document prevails over the master terms for the specific transaction, which means a buyer can improve its position for a particular purchase by negotiating terms into the order even where the master terms are fixed. This is a useful lever, because Oracle is sometimes more willing to grant a concession in an order than to amend the master agreement.
The buyer should use the precedence rule deliberately, negotiating favourable terms into the order document where the master terms cannot be moved. The buyer should also confirm that the precedence clause does not let the policies override the negotiated terms, because a policy that Oracle can change should not be allowed to undo a hard won contractual right. For the framing of such negotiation moves see the negotiation frameworks note.
Reading it before signing.
The time to read the agreement is before signing, when the buyer holds leverage and can negotiate the terms that matter. The buyer should read the grant against its planned deployment, the restrictions against its planned business actions, the policies against its planned environment, and the precedence clause against the terms it most wants to protect. The reading should surface the points to negotiate, from the indemnity and liability cap to the affiliate definition and the audit clause, so they can be addressed while Oracle wants the signature.
The buyer that signs first and reads later has reversed the order of leverage. For the deal structures the agreement governs see the perpetual licences deal page, and for the wider product context see the Oracle Database product page. The reading is the foundation of every term the buyer might improve.
Engaging an independent advisor.
An independent advisor assembles the complete agreement stack, reads the grant and restrictions against the buyer's actual deployment, identifies the policy references that affect the compliance position, applies the precedence rule to protect the terms that matter, and builds the negotiation asks that improve the agreement before signing. The advisor sits on the buyer side and reads the document as a set of commercial terms to be shaped rather than as a fixed condition to be accepted. For the full reading service this sits within see our contract review service, and for the complete framework read the Oracle Negotiation Playbook.
A North American retail buyer engaged an advisor to read a master agreement before a large new purchase in 2024. The advisor found that a referenced policy could change the virtualisation licence count and that the order precedence clause allowed favourable terms to be placed in the order document. The advisor negotiated the key protections into the order and fixed the policy version, so the buyer held a defensible position that did not depend on policies Oracle could later change.