A ULA covers only the Oracle products named in your agreement, not the whole catalogue. The named list decides what you can certify and where your audit risk sits, so reading it precisely is the first move in any exit.
A ULA grants unlimited deployment of the specific products named in the contract for the term. Common inclusions are the Oracle Database in its Enterprise Edition, a selection of database options, management packs, and sometimes middleware. Anything outside the named list is licensed under normal terms, which means deploying it can create exposure even while the ULA is active.
The named product list, not the Oracle price list, defines your unlimited right. Map every deployed product against that list before you do anything else.
The Oracle Database is the heart of most ULAs, typically the Enterprise Edition. Certification of the database rests on processor counting with core factors across the servers where it runs, including production, test, and disaster recovery instances deployed within the term. Knowing exactly which edition is in scope matters, because Standard Edition and Enterprise Edition are licensed and counted very differently.
Database options and management packs are licensed separately from the database itself, and they are the area where scope is most often misread.
If an option or pack is named in your ULA, it certifies with the database. If it is not named but is switched on somewhere in the estate, that use is a compliance exposure rather than covered deployment. Many audits begin with an option that was enabled by default and never licensed.
Some ULAs extend to middleware such as WebLogic Server, and Java may appear in its own agreement. Java SE is now licensed on an employee metric rather than processors, which changes the certification math entirely and deserves its own analysis. Treat any middleware or Java inclusion as a distinct workstream within the exit.
A services firm believed its ULA covered all Oracle use. A scope review found Diagnostics Pack and Tuning Pack enabled on dozens of databases but absent from the named list. Catching this before certification let the firm disable the unlicensed packs and document the position, removing a finding that could have run to seven figures at list. Figures are indicative and depend on the specific contract language.
You can only certify perpetual entitlement for products inside the ULA scope, so the named list sets the ceiling on what you keep. It also defines your risk surface, because anything deployed but not covered is exposure. A precise reading of the list, reconciled against what is actually running, is the foundation of a complete and defensible count.
Start by reconciling your deployed estate to the named product list, then read the wider context in the Oracle ULA certification guide. To go deeper, see the Oracle ULA certification guide for 2026 and when a ULA is the right deal.
No. A ULA covers only the products named in the agreement. Anything not listed is licensed normally and can become an audit finding if deployed. The named product list, not the Oracle catalogue, defines your unlimited right.
Yes. Options such as Partitioning, Advanced Security, and RAC, and management packs such as Diagnostics and Tuning, are licensed separately from the database. If they are named in the ULA they certify with it; if they are not, their use is a compliance exposure.
Directly. You can only certify perpetual entitlement for products inside the ULA scope. A precise reading of the named list is the first step in knowing what you can count and where the risk sits.
Book a confidential assessment and we will reconcile your deployed estate to your named product list and show you the count and the risk.