An independent guide for ISVs, OEMs, and end customers navigating Oracle’s most restrictive — and most misunderstood — licence type.
Oracle’s Embedded Software License (ESL) is the most restrictive — and least expensive — licence type in Oracle’s commercial framework. It allows an ISV or OEM partner to embed Oracle technology (typically Oracle Database or Oracle Middleware such as WebLogic) inside a third-party application, where Oracle runs entirely in the background. End users never interact with Oracle directly. They interact with the ISV’s application, which happens to use Oracle as a hidden infrastructure component.
Think of it this way: an ESL makes Oracle invisible. The ISV’s application installer silently deploys Oracle as a component. The end customer may not even realise Oracle Database is running — they simply use the vendor’s application. Oracle is an engine embedded in a machine, not a standalone product the customer manages.
ESL is essentially an OEM (Original Equipment Manufacturer) licence. Oracle grants the ISV deeply discounted licence rights — typically around 90% off list price — in exchange for severe usage restrictions. The ISV then bundles Oracle with their application and resells the combined solution to end customers. End customers cannot purchase ESL licences directly from Oracle.
This model creates a three-party relationship with distinct compliance responsibilities. The ISV holds the Oracle agreement and manages licence allocation. The end customer receives Oracle usage rights through the ISV’s product, not through a direct Oracle contract. And Oracle itself audits the ISV, not the end customer, for ESL compliance.
For the complete framework of all Oracle licence types, see our guide to Oracle Licence Types: Full Use, ASFU, ESL, and PAH.
“ESL is the licence type I see most frequently misunderstood — not by ISVs, who negotiate the terms, but by end customers who inherit the restrictions without fully understanding them. The most dangerous assumption is treating an embedded Oracle database like a standard database you can query, integrate, or extend. The moment you connect an external tool to an ESL instance, you’ve broken the licence.”
🔎 Not sure whether your Oracle deployment is ESL, ASFU, or Full Use? We’ll clarify your licence position.
Learn More →ESL licensing permits Oracle to operate strictly behind the scenes for the ISV’s application — nothing more. Understanding exactly what is and isn’t permitted is critical for both ISVs designing their solutions and end customers deploying them.
Oracle may only support the ISV application’s predefined features. The embedded Oracle database can store data, process transactions, and generate internal reports — but only as those functions are designed into the ISV’s application. If the ISV’s CRM stores customer records in Oracle, that’s allowed. If someone wants to run an ad-hoc SQL query against that same database for a different purpose, that’s a violation.
All Oracle interaction must pass through the ISV’s application interface. No end user — and no administrator at the customer’s organisation — should log into Oracle directly. There are no Oracle database usernames or passwords for the customer. No SQL*Plus. No SQL Developer. No TOAD. The database is secured so that only the ISV’s application code accesses it.
The Oracle installation must be silent and component-based. When the ISV’s application is installed, Oracle should be deployed automatically as part of that process. The end user should not be making configuration decisions about the Oracle component during installation.
Limited internal reporting is permitted — within the application. If the ISV’s application includes a built-in reporting module that reads from Oracle, that’s covered by the ESL. But connecting an external reporting or analytics tool — Power BI, Tableau, Crystal Reports, or any third-party BI platform — directly to the Oracle database is prohibited.
ESL restrictions exist to ensure Oracle is never used beyond the ISV’s intended footprint. These are not guidelines — they are contractual boundaries, and violating them can trigger a licence breach that requires purchasing Full Use licences at list price.
| Restriction | What It Means | Why Oracle Enforces It |
|---|---|---|
| No direct SQL access | No user or admin may connect to Oracle via SQL tools | Prevents ESL from becoming a general-purpose database |
| No external BI or reporting tools | Power BI, Tableau, SSRS, etc. cannot connect to the ESL database | Ensures all data access stays within the ISV application |
| No third-party integrations | Other applications cannot read from or write to the ESL database | Maintains the “embedded only” scope |
| No custom development | No custom PL/SQL, stored procedures, or schema modifications by the customer | Oracle is the ISV’s component, not the customer’s platform |
| No repurposing | The ESL Oracle instance cannot be used for any workload other than the ISV’s application | Prevents licence arbitrage through discounted ESL pricing |
| One application per ESL | Each ESL covers one specific ISV application package | An ISV with multiple products needs separate ESL agreements |
Connecting an external BI or reporting tool directly to an ESL Oracle database. This happens constantly — a well-meaning DBA or analyst hooks up Power BI to “just pull some reports” without realising the Oracle instance is ESL-licensed. That single connection transforms a compliant ESL into a licence breach that Oracle will price at Full Use rates.
For a detailed comparison with ASFU restrictions, see Oracle ASFU License: Application Specific Full Use explained.
Our independent Oracle licence assessment identifies whether your Oracle instances are properly covered by ESL, ASFU, or Full Use entitlements — and flags any violations before Oracle’s audit teams find them.
Oracle provides ESL licences exclusively to ISV or OEM partners through the Oracle PartnerNetwork (OPN). End customers cannot purchase ESL directly from Oracle. The ISV signs an OEM/ESL agreement, purchases Oracle licences at the ESL discount, bundles them with their application, and resells the combined product.
Pricing is set by the ISV. The ISV buys Oracle at approximately 90% off list, then sets whatever price they choose for the bundled solution. The end customer may not even see the Oracle component as a separate line item.
The ISV defines the functional boundaries. Through the Application Package Registration Form (APRF), the ISV describes to Oracle exactly what the application does and how Oracle is used within it. The ESL licence then covers only that described usage.
Support is typically delivered by the ISV. One distinctive aspect of ESL is that Oracle technical support is not required on those licences. The ISV provides first-line support for the entire solution, including the Oracle component.
The end customer owns the licence but cannot manage it. The end customer is the licence owner on paper, but has no right to access, modify, or extend the Oracle software. All licence management, patching, and version control is handled by the ISV.
A manufacturing ISV embedded Oracle Database in their factory automation software under an ESL agreement. Over three years, they added customer-facing analytics features that allowed end users to run custom reports against the Oracle database — functionality not described in the original APRF. When Oracle audited the ISV, they found the expanded functionality violated the ESL terms. The ISV faced a requirement to purchase Full Use licences for all affected deployments — across 200+ customer sites.
$3.2M in compliance exposure — resolved through renegotiation to $890K
Under this model, the ISV licences Oracle using standard metrics — Named User Plus (NUP) or Processor — but receives approximately 90% off Oracle’s list price. The ISV must still count users or processors at each customer deployment. All standard Oracle licensing rules apply, including virtualisation policies.
Under the royalty model, Oracle takes a percentage (typically around 10%) of the ISV’s price list for each sale. The ISV does not need to count users or processors — the royalty payment covers the licence. This model eliminates the virtualisation licensing complexity because there is no processor-based counting to dispute.
| Factor | Standard Metrics (NUP/Processor) | Royalty-Based |
|---|---|---|
| Discount level | ~90% off list price | ~10% of ISV price list per sale |
| User/processor counting | Required | Not required |
| Virtualisation rules | Standard Oracle rules apply (VMware = full cluster licensing) | Not applicable (no processor metric) |
| Best for | ISVs with predictable, small deployments | ISVs deploying at scale across many customer sites |
| Oracle Support required | No | No |
“The royalty-based model is significantly more advantageous for ISVs deploying to hundreds or thousands of customer sites, especially where VMware is involved. Under standard metrics, every customer running the embedded Oracle on VMware could require licensing the entire cluster. The royalty model eliminates that exposure entirely. I’ve seen ISVs save millions by switching from standard metrics to royalty-based ESL.”
Covers Oracle’s partner programme mechanics, ISV/OEM deal structures, discount benchmarks, and the negotiation dynamics that determine ESL, ASFU, and PAH pricing outcomes.
Download White Paper →Oracle’s four licence types serve fundamentally different use cases. Choosing the wrong one creates compliance exposure that Oracle’s audit teams are specifically trained to find.
| Factor | ESL (Embedded) | ASFU (App-Specific) | Full Use | PAH (Hosting) |
|---|---|---|---|---|
| Scope of use | Embedded features only | Single ISV application | Any application or purpose | Hosted service for external customers |
| End-user Oracle access | None — completely hidden | Limited — through ISV app only | Full — unrestricted | None — through hosted service only |
| Direct SQL access | Prohibited | Prohibited | Allowed | Prohibited for end customers |
| Custom development | Prohibited | Prohibited | Allowed | ISV-controlled only |
| External integrations | Prohibited | Very limited | Unlimited | ISV-controlled |
| Oracle Support required | No | Yes | Yes | Yes |
| Typical discount | ~90% off list | ~50–60% off list | Negotiable (0–40%) | Negotiable (similar to ASFU) |
| Sold by | ISV/OEM only | ISV/OEM only | Oracle or resellers | ISV/OEM only |
| Audited by Oracle | ISV is audited | ISV is audited | End customer is audited | ISV is audited |
For detailed guidance on each type, see our guides to Oracle ASFU licensing, Oracle PAH licensing, and the complete Oracle Licence Types framework.
📋 Need help determining which Oracle licence type covers your deployment? We resolve licence type disputes every week.
Oracle Advisory Services →The Oracle component powers a single, narrow function. Factory automation software that uses Oracle to store sensor data. A medical imaging system that uses Oracle for record management. An ATM management platform that embeds Oracle for transaction processing. In each case, Oracle is a hidden engine, not a user-facing platform.
The application has fixed, predictable workflows. ESL works when the ISV’s application does not change substantially over time and end customers do not customise it.
Cost is the primary concern. At ~90% off list, ESL is dramatically cheaper than any other Oracle licence type. For an ISV deploying to thousands of customer sites, the pricing difference between ESL and ASFU is enormous.
End users need any form of database access. Even limited reporting against the database moves beyond ESL territory. If users will run reports through anything other than the ISV’s built-in interface, you need ASFU or Full Use.
The application is likely to grow or integrate. If there’s any possibility that the application will need to integrate with other systems — ERP, BI, data warehouse, CRM — ESL’s restrictions will be violated almost immediately.
The deployment model is hosted/SaaS. ESL is for on-premises embedded deployments. If the ISV hosts the application for multiple customers as a SaaS offering, they need PAH licensing instead.
We advise ISVs and OEMs on Oracle ESL, ASFU, and PAH negotiations — including APRF scope definition, pricing model selection (standard metrics vs royalty), and contract structuring that protects your flexibility as your product evolves.
ESL compliance requires strict discipline from both the ISV and the end customer. The most common violations are not malicious — they’re the result of well-meaning people who don’t understand the boundaries.
A customer’s database administrator discovers an Oracle instance on their network and connects to it with SQL Developer for “routine maintenance.” Under ESL, this is a violation. The customer should not have Oracle credentials. All database management should be handled by the ISV’s application or the ISV’s support team.
This is the single most common ESL violation. An analyst connects Tableau, Power BI, or even Excel via ODBC to the embedded Oracle database. The moment that external tool queries the database, the ESL scope is exceeded. Oracle will classify the deployment as requiring Full Use licensing.
Over time, an ISV adds new features — analytics dashboards, custom query builders, integration APIs — that go beyond what was described in the original Application Package Registration Form. If Oracle audits the ISV and finds the current functionality doesn’t match the APRF, all deployments could be reclassified.
An end customer installs a second application on the same Oracle database that’s ESL-licensed for a different ISV product. One ESL covers one application. Sharing the database with another application violates the licence.
Standard software asset management tools detect Oracle installations but can’t distinguish between ESL, ASFU, and Full Use. When a SAM scan flags an “unlicensed” Oracle database, the customer’s IT team may panic and take actions (like purchasing unnecessary Full Use licences) that are costly and unnecessary. Maintain clear records of which Oracle instances are ESL-covered.
A healthcare ISV deployed their patient management system with an embedded Oracle Database under ESL to 85 hospital sites. At 12 sites, hospital IT teams independently connected Crystal Reports to the Oracle database for custom clinical reporting. When Oracle audited the ISV, those 12 sites were reclassified as Full Use deployments.
$1.8M compliance exposure across 12 sites — negotiated down to $640K with our support
When Oracle’s LMS initiates an audit — whether of your organisation or your ISV partner — every response matters. This playbook provides defence methodology, evidence standards, and settlement benchmarks.
Download White Paper →Oracle audits the ISV, not the end customer. ESL licences are held under the ISV’s Oracle agreement. Oracle’s audit rights target the ISV — they will examine how the ISV has distributed and managed those licences across customer deployments.
But the end customer is not risk-free. If the end customer violates the ESL terms (by connecting external tools, allowing direct database access, etc.), they are breaching their agreement with the ISV. The ISV, in turn, is breaching their agreement with Oracle. The ISV can — and will — pass on any compliance costs to the end customer.
Oracle knows how to detect ESL violations. Oracle’s LMS audit scripts will identify any direct connections to the database that come from outside the ISV’s application. They will also detect enabled options or packs, unusual schema modifications, and any evidence that the database is being used for purposes beyond the registered application.
Keep records of all ESL-covered installations. End customers should maintain documentation that identifies every Oracle installation covered by an ISV’s ESL agreement. When your organisation undergoes a standard Oracle audit, you’ll need to demonstrate that certain Oracle instances are ESL-covered through a vendor relationship — not part of your own licence estate.
For comprehensive audit defence strategies, see our Oracle Audit Defense Service and our Oracle licensing assessment case studies.
We’ve defended ISVs facing Oracle OEM audits and end customers caught in the crossfire. Our team of former Oracle licensing executives understands exactly how Oracle’s LMS team approaches embedded licence reviews.
A critical and frequently overlooked fact: Oracle’s standard virtualisation licensing rules apply to ESL deployments. Just because the licence is embedded doesn’t mean Oracle’s policies on VMware, Hyper-V, or cloud environments disappear.
If the ISV uses the standard metrics pricing model (NUP or Processor with 90% discount), then every Oracle licensing rule applies at the end-customer site — including Oracle’s position that VMware is soft partitioning, which requires licensing all physical cores in the cluster.
This creates a serious cost amplification problem for ISVs. An ESL Oracle database running in a single VM on a 4-host VMware cluster could theoretically require licensing all cores across all four hosts. At ESL pricing, the cost is still manageable. But if the ESL is violated and Oracle reclassifies the deployment as Full Use, the VMware full-cluster licensing requirement applies at full price — a potentially catastrophic financial exposure.
The royalty-based ESL model avoids this entirely. Because royalty-based ESL doesn’t use processor or NUP metrics, there are no cores to count and no virtualisation rules to apply.
For cloud deployments, the same logic applies. If an ESL application is deployed on AWS, Azure, or GCP using standard metrics, Oracle’s cloud licensing vCPU counting rules apply. See also our Oracle licensing VMware audit strategies and Oracle licensing on Hyper-V guides.
Under standard metrics ESL, every customer running the embedded Oracle on a shared VMware cluster inherits Oracle’s full-cluster licensing requirement. An ISV deploying to 500 customer sites where VMware is standard could face massive aggregate compliance exposure. The royalty-based ESL model eliminates this risk entirely. If you’re an ISV on standard metrics ESL with VMware-heavy customers, evaluate switching to royalty-based pricing.
For organisations looking to reduce Oracle support costs on non-ESL deployments, third-party support can deliver 50–70% annual savings. Complete business case methodology and Oracle response playbook.
Download White Paper →Document every ESL-covered Oracle installation — maintain a register of which Oracle instances are embedded components of which ISV products, with APRF references
Verify licence type with each ISV — confirm whether the Oracle component is ESL, ASFU, or Full Use, and obtain written confirmation of the licence type and scope
Block direct database access — ensure no Oracle credentials exist for end-user or customer DBA access to ESL instances; lock down network access to the database
Prohibit external tool connections — implement technical controls preventing BI tools, ETL tools, or any third-party applications from connecting to ESL Oracle databases
Tag ESL instances in your SAM tools — mark ESL-covered Oracle installations as “vendor-managed / embedded” so they’re excluded from your own Oracle licence compliance counts
Review ISV APRF scope — if you’re the ISV, ensure your current application functionality matches what’s registered in the APRF; update it if features have been added
Assess virtualisation exposure — if using standard metrics ESL, document the VMware/Hyper-V host configurations at each customer site; consider switching to royalty-based pricing
Audit embedded usage annually — conduct internal reviews to ensure no drift has occurred (new integrations, direct access, expanded functionality)
Train technical teams — ensure DBAs, developers, and IT staff understand that ESL Oracle databases cannot be accessed, queried, or integrated outside the ISV application
Plan for growth — if the ISV application is expanding or integration needs are emerging, proactively evaluate upgrading to ASFU or Full Use before compliance is breached
✅ Want us to review your ESL compliance position? Free consultation, no obligation.
Book a Meeting →Whether you’re an ISV negotiating an embedded agreement, an end customer unsure about your licence type, or facing an Oracle audit that involves OEM-licensed components — we can help. No vendor bias. Just honest advice from former Oracle licensing executives.
Full-scope advisory
Compliance review
Expert protection
Better deals and terms
Certification & exit
Transition advisory
Risk-free savings
120+ expert guides