The two lists that define ULA scope
The commercial promise of a ULA is simple: pay a fixed fee, deploy without counting for the term. The legal reality is that this promise is fenced by two definitions that most customers skim past during contracting. The first is the product schedule, the precise list of Oracle programs to which the unlimited right applies. The second is the definition of licensed parties, the named legal entities entitled to install and run those programs. Outside either boundary, the agreement provides no rights at all, and the unlimited word offers no protection. Understanding scope is the foundation for everything else in the agreement, which is why the Oracle ULA pillar guide treats it as the first thing to settle.
Scope is not a technicality. It determines what you may deploy freely, what you must license separately, and crucially, what converts to a permanent perpetual entitlement when the term ends. A product that is in scope and deployed before the cut off date becomes a perpetual licence at certification. A product that is out of scope, no matter how heavily deployed, becomes a liability rather than an asset. The entire economic logic of the agreement runs through these two lists.
The product schedule and why it matters
The product schedule is the list of Oracle programs covered by the unlimited deployment right. It is usually negotiated as part of the order document and reads as a set of named programs with their license metrics. The critical point is that the schedule is exhaustive. If a program is not on it, the unlimited right does not extend to that program, even if it is a close cousin of something that is covered, and even if it is bundled in the same technical stack.
This catches customers most often with database options and management packs. A ULA may cover Oracle Database Enterprise Edition without covering Partitioning, Advanced Security, Diagnostics Pack, or Tuning Pack. Teams assume the options ride along with the database, deploy them freely, and create an unlicensed position that an auditor will find immediately. The discipline of confirming exactly which options and packs sit on the schedule is the same discipline that drives the analysis in our guide to ULA supported products.
The word unlimited describes the quantity, not the catalogue. Scope is the catalogue, and the catalogue is finite.
The product schedule also governs what you can count at certification. Because certification converts deployed in scope quantities into perpetual licences, every program you want as a permanent entitlement must be on the schedule and deployed before the term ends. A program left off the schedule cannot be certified into a perpetual licence no matter how essential it has become, which is why scope and the ULA certification process are two ends of the same lever.
Named legal entities and licensed parties
The second boundary is corporate rather than technical. A ULA grants rights to specifically named legal entities, usually the contracting entity and a defined list of affiliates or subsidiaries. Deployment by any entity outside that list is unlicensed, regardless of common ownership. A wholly owned subsidiary that is not named in the agreement has no more right to deploy under the ULA than an unrelated third party.
This matters enormously for groups with complex structures, holding companies, recently acquired businesses, or entities in jurisdictions that were spun up after the agreement was signed. The definition of licensed parties should be negotiated to be as broad as the corporate structure allows, ideally covering the contracting entity and all majority owned affiliates as they exist from time to time. A narrow definition freezes the licensed parties at signing and leaves every subsequent corporate change as a potential compliance gap. The interaction between entity scope and corporate transactions is examined further in the discussion of true-up triggers in our ULA true-up guide.
What is in scope under an Oracle ULA?
In scope means a deployment satisfies both boundaries at once: the program is on the product schedule, and the deploying entity is a named licensed party. Both conditions must hold. A covered product run by an unnamed entity is out of scope. A named entity running an uncovered product is out of scope. Only the intersection of the two lists is genuinely protected by the unlimited right.
| Deployment | On product schedule? | Named entity? | Status |
|---|---|---|---|
| Covered DB at named entity | Yes | Yes | In scope, certifiable |
| Covered DB at unnamed subsidiary | Yes | No | Unlicensed exposure |
| Uncovered option at named entity | No | Yes | Unlicensed exposure |
| Cloud BYOL of covered product | Yes | Yes | Depends on cloud clause |
The cloud row deserves a note. Even when a product and entity are both in scope, deploying into a public cloud can fall outside the unlimited right unless the agreement explicitly permits it and addresses how cloud instances are counted at certification. This is one of the most contested areas of modern ULAs and is covered in depth in the guide to ULA cloud deployments. The general rule holds: scope is the intersection of product, entity, and the specific deployment rights the contract grants.
The four most common scope mistakes
Across hundreds of ULA reviews, the same scope errors recur. Each is avoidable, and each is far cheaper to fix before signing than after.
The first is treating options and packs as included. As covered above, database options and management packs are separate products and must appear on the schedule individually. The second is a narrow entity definition that omits subsidiaries or freezes the licensed parties at the signing date, leaving organic and acquired growth unlicensed. The third is silence on cloud, where the agreement neither grants nor denies public cloud deployment rights, creating ambiguity that Oracle resolves in its own favour at certification. The fourth is scope creep in reverse, where the customer deploys a covered product so narrowly that the certification count understates the genuine entitlement, leaving perpetual value on the table.
Three of these four mistakes create compliance exposure that an auditor will pursue, which is why scope hygiene and Oracle audit defence are inseparable. The fourth is the inverse problem of leaving value uncaptured, which is the central theme of certification strategy. Both failure modes flow from the same root cause: scope was not modelled carefully at signing.
How to negotiate scope before signing
The leverage to set scope exists almost entirely before signature. Once the ULA is executed, adding a product to the schedule or a subsidiary to the licensed parties requires an amendment that Oracle prices at its discretion, typically at a premium and often bundled with a renewal it wants. Before signing, by contrast, scope is part of an open negotiation where the customer can trade fee, term, and scope against each other.
The buyer side discipline is to start from a forward looking deployment forecast rather than a current inventory. Model where the organisation expects to deploy over the full term, including planned acquisitions, new business units, and cloud migration, and negotiate the product schedule and entity definition to cover that forecast. Push for the broadest defensible definition of licensed parties, explicit cloud deployment and counting rights, and the inclusion of every database option and pack the deployment plan will touch. This forward modelling is exactly what a structured ULA negotiation engagement delivers, and it is the difference between a ULA that becomes a strategic asset and one that becomes a slow accumulation of compliance gaps.
The buyer side view
Scope is the most underrated clause in the entire agreement. Buyers fixate on the headline fee and the unlimited word while skimming the two lists that actually govern what they can do. The practical takeaway is to invert that attention: treat the product schedule and the definition of licensed parties as the primary negotiation, because they determine both your freedom during the term and your perpetual entitlement at the end.
Map your forecast deployment, list every product and entity it will touch, and negotiate scope to cover that map with margin to spare. Confirm cloud rights explicitly, include every option and pack you will use, and define licensed parties broadly enough to absorb growth. Then govern the boundary throughout the term so nothing drifts outside it. To work through your own agreement, read the ULA pillar guide and the certification guide, and engage the ULA negotiation service before scope is locked at signing.
Oracle ULA scope: frequently asked questions
What defines the scope of an Oracle ULA?
An Oracle ULA scope is defined by two lists: the product schedule, which names every program covered by the unlimited right, and the named legal entities, which identify the corporate parties permitted to deploy under it. Anything outside either list is not covered and must be licensed separately. See the ULA pillar guide.
Can you add products to an Oracle ULA after signing?
Adding products mid term requires a contract amendment that Oracle prices at its discretion, usually at a premium. The leverage to set a broad product schedule exists only before signing, which is why scope definition is a pre signature priority. See the supported products guide.
Are subsidiaries covered by an Oracle ULA?
Only the legal entities named in the agreement are covered. Subsidiaries, joint ventures, and newly formed entities are not automatically included. Customers should map their entity structure and negotiate the broadest possible definition of licensed parties before signing.
What happens if you deploy outside the ULA scope?
Deployment of a product not on the schedule, or use by an entity not named in the agreement, is unlicensed. It creates a compliance gap that surfaces in an audit and is not converted to a perpetual entitlement at certification, so it represents pure exposure. See the true-up guide.