What product scope means in a ULA
The product scope of an Oracle Unlimited License Agreement is the list of specific Oracle programs that the unlimited deployment right covers, recorded in the ULA product schedule. Understanding the oracle ula supported products in a given agreement is the difference between deploying freely and accidentally creating an unlicensed position, because the unlimited right applies to exactly those products named in the schedule and to nothing else. Everything on the list can be deployed without limit and certified at term end; everything off it is licensed conventionally. This boundary is the fence described throughout the Oracle ULA pillar guide.
Scope is defined at the level of individual programs, not product families. The Oracle Database, its options such as Partitioning and Advanced Security, and its management packs are separate licensable products, and a ULA may include the database without including a given option. Treating the database as a single covered product when only the base engine is on the schedule is one of the most common and expensive scoping errors, and it surfaces precisely when an audit examines option usage.
Products commonly included in a ULA
While every agreement is bespoke, certain products appear in ULA schedules far more often than others, because they are the products organisations deploy at scale and where growth is hardest to predict. The Oracle Database Enterprise Edition is the most common anchor, frequently accompanied by a selection of database options and management packs. Middleware products such as WebLogic Server, and in some agreements application and analytics products, also appear where the customer's deployment justifies them.
| Product area | Typical inclusions | Watch for |
|---|---|---|
| Database | Enterprise Edition | Which options and packs are named |
| Database options | Partitioning, Advanced Security, RAC, Multitenant | Each option is separate; confirm by name |
| Management packs | Diagnostics, Tuning | Often used unknowingly, check coverage |
| Middleware | WebLogic Server | Edition and components named |
| Applications / Analytics | Selected modules | Module level precision required |
The presence of database options on the schedule matters enormously, because options are where most database audit findings originate. A customer that deploys Partitioning, Advanced Security, or the Diagnostics and Tuning packs while only the base database is on the schedule has an exposure that the unlimited right does not cover. Confirming that each option in use is named in the schedule is a core scoping check, and it connects directly to the analysis in the database cluster on database options and packs.
What is usually excluded
Just as important as what is included is what is not. Products absent from the schedule are licensed conventionally, and deploying them under the assumption that the ULA covers them creates true-up exposure, as set out in the ULA true-up guide. Common exclusions include database options not specifically named, products from acquired Oracle portfolios, newer cloud and analytics services, and any program the customer was not deploying at signing. Oracle has no obligation to extend the unlimited right to products added to its catalogue after the agreement was signed.
The unlimited right is unlimited only for the products on the schedule. Off the schedule, every install is a separate purchase, and the auditor knows it.
A particularly important exclusion concerns products that are technically installed by default. Some Oracle options and packs install automatically with the database and can be used inadvertently, generating usage of a product that is not on the schedule. Controlling which features are enabled, and confirming that any enabled feature is covered, is essential to keeping the deployment inside the licensed scope. This is a recurring theme in Oracle audit defence, where inadvertent option usage is a frequent finding.
Can you add products to a ULA?
Products can be added to a ULA, but only by agreement with Oracle and almost always at a cost. The most common occasion is at renewal, where the customer can expand the schedule to cover products it has begun deploying, sometimes at a marginal cost lower than buying them separately. Mid term additions are also possible but give Oracle pricing leverage, because the customer is asking for something it does not currently have. The disciplined approach is to scope the schedule correctly at signing, anticipating the products the organisation will deploy over the term, rather than adding them later from a weaker position.
Conversely, scope should not be inflated with products the customer does not intend to deploy, because each product on the schedule raises the licence fee and the permanent support base. The objective is a schedule that matches genuine deployment intent precisely: broad enough to cover everything the organisation will use, narrow enough to avoid paying for capacity it will not. This balance is central to the ULA negotiation strategy and to controlling the lifetime cost discussed in the ULA cost guide.
Scope and the certification count
Product scope determines not only what can be deployed but what can be certified, and the two are inseparable. At term end the customer certifies the deployed quantity of each in scope product, and that quantity becomes a permanent perpetual entitlement. Products not on the schedule cannot be certified no matter how widely they were deployed, so a scoping error discovered at certification is irreversible: the customer either pays for the out of scope usage or removes it. This is why scope verification should happen at signing and be maintained throughout the term, not examined for the first time when certification approaches.
The completeness of the certified count therefore depends on the completeness and accuracy of the schedule. A customer that scoped precisely, deployed within scope, and tracked usage against the schedule arrives at certification able to convert its full footprint to perpetual licences. The discipline of mapping deployment to scope throughout the term is the foundation of the certification process and of any clean exit.
The buyer side view
The practical takeaway is that the unlimited right is unlimited only for the products named in the schedule, and the schedule is therefore the most important inventory in the agreement. Scope at the level of individual programs and options, confirm that every option and pack actually in use is named, control inadvertent feature usage, and resist inflating the schedule with products the organisation will not deploy.
Treat the product schedule as a living control, reconciled against actual deployment throughout the term, so that nothing is deployed out of scope and everything in scope can be certified. To verify your own schedule, read the ULA pillar guide and the true-up guide, then engage the ULA negotiation service to align scope with your deployment plans.
Oracle ULA Supported Products: frequently asked questions
What products does an Oracle ULA cover?
An Oracle ULA covers exactly the programs named in its product schedule, at the level of individual products and options rather than product families. The Oracle Database Enterprise Edition is the most common anchor, often with selected database options, management packs, and middleware such as WebLogic Server. Anything not named is licensed conventionally.
Are database options included in a ULA?
Only if each option is specifically named in the schedule. Options such as Partitioning, Advanced Security, RAC, and the Diagnostics and Tuning packs are separate licensable products. Deploying an option that is not on the schedule creates an unlicensed position even when the base database is covered.
Can I add products to a ULA later?
Yes, but only by agreement with Oracle and usually at a cost. The cleanest occasion is at renewal, where the schedule can be expanded for products already in use. Mid term additions give Oracle pricing leverage, so scoping the schedule correctly at signing is preferable.
What happens if I deploy a product outside ULA scope?
Deployment of a product not on the schedule is licensed conventionally and creates true-up exposure. It cannot be certified at term end and will surface as a finding in an audit. Confirming that every product and option in use is named in the schedule prevents this.