Contents
Key takeawaysWhat an ESL isWhat an ESL forbidsWhat a breach costsWho Oracle auditsChecking your exposureWhen to buy ASFU or Full UseWhat we have seenWhat to do nextFAQAn Oracle embedded license allows an ISV to ship Oracle technology inside its application at a deep discount, usable only by that application. The discount lasts until someone connects a reporting or integration tool straight to the database.
- Cheap because narrow. ESL rights typically cost 70 to 90 percent below Full Use list because only the embedding application may use the Oracle component.
- The ISV holds the license. You inherit embedded rights through the ISV's end user license, and the royalty sits in the ISV's agreement with Oracle rather than on any price list.
- One connection breaks it. In about 7 of 10 embedded engagements we reviewed, a reporting or integration tool was wired straight into the database.
- Breaches reprice at list. Oracle can require Full Use at list for the deployment, and the true up in our reviews ran 5 to 10 times the original ESL price.
- Paper decides the argument. Roughly half of customers could not produce the embedding agreement that defines their rights.
- Fence it technically. Block direct paths at network and credential level, and license any second use on ASFU or Full Use before deployment.
What is an Oracle embedded software license (ESL)?
An Oracle Embedded Software License (ESL) allows an independent software vendor (ISV) to ship Oracle technology inside its own packaged application at a restricted, application specific price. The ISV buys the license from Oracle, you inherit it with the product, and the Oracle component may be used only by that embedding application.
The price reflects the restriction. ESL rights typically cost 70 to 90 percent below Full Use list, and most customers never see a separate Oracle line item on the ISV's invoice. Support runs the same way: the ISV holds a Support Provider Support Identifier (SPSI) with Oracle, and you raise issues with the ISV.
How does an ESL compare with ASFU, Full Use and OEM embedded licenses?
The price falls as the permitted use narrows. ESL and ASFU are both restricted, with different distribution models, and Full Use is the unrestricted price every restricted grant reprices toward after a breach. Our guide to Oracle license types also covers the hosting grants.
| License type | Who holds it | Use scope | Who administers the database | The audit trap |
|---|---|---|---|---|
| ESL, embedded | The ISV buys it, you inherit it | Inside one application only | The application itself | Direct database access |
| ASFU, application specific | You, bought through the ISV | Full database, one named application | Your DBAs | Use beyond the named application |
| Full Use | You, direct from Oracle or a reseller | Any application, any workload | Your DBAs | Unlicensed options and cores |
| OEM embedded | The ISV, under its agreement | Redistribution scope | Set by the OEM agreement | Distribution beyond the grant |
To tell the first two apart, look for an Oracle ordering document and a Customer Support Identifier (CSI) in your own name. If you hold both and your DBAs administer the database, you most likely hold ASFU. If you hold neither and your DBAs still log in, you may already be outside an ESL.
The ASFU license guide covers the sibling grant, which allows full database access inside one named application.
Why is there no ESL price on the Oracle price list?
No ESL line exists on the Oracle Technology Global Price List, and no ESL part number can be looked up. The royalty schedule sits inside the ISV's own distribution agreement with Oracle, which is why the embedding agreement is your only written statement of rights.
One Oracle ESL distribution agreement, signed in 2008, became public in 2009 when the ISV filed it with the US Securities and Exchange Commission. It gave the ISV two ways to pay Oracle:
- Per program. 20 percent of the Technology price list fee for each embedded program, which is 80 percent below Full Use list.
- Per application. A percentage of the ISV's own application price, taken from Oracle's Embedded Product and Royalty Matrix.
Terms vary by ISV and year, but Oracle and the ISV still set the discount between them, and you inherit the result.
How to Negotiate an Oracle OCI Deal: The Discount Is Set. The Deal Is Not.
What does an Oracle ESL forbid you to do?
You cannot use the Oracle technology outside the embedding application, in any form. The ESL terms reach you through the ISV's end user license, and the published agreement shows how narrow they are.
- No direct access. Users reach the database only through the application. SQL*Plus, SQL Developer, a BI connector or an ODBC driver pointed at the schema all count as direct access.
- No ad hoc SQL outside the application. Ad hoc reports are allowed only when they run inside the application and never expose the underlying schema to the user.
- No data transfer through Oracle APIs. End users may not use Oracle supplied APIs to move data. The ISV must provide predefined interfaces unique to its application for that, which is the route an approved export should take.
- No second application. The database serves the embedding application and nothing else, so a schema for another product is out of scope.
- No separate installation, administration or upgrade. The application installs and configures the Oracle programs, performs all administration functions, and delivers database upgrades as part of the application package.
- Internal use only. The end user license must limit use to the scope of the application package and your internal business operations, and it restricts transfer to another company.
Each breach converts restricted use into Full Use exposure. Any relaxation of that scope belongs on ASFU or Full Use paper, priced before deployment rather than after an audit notice.
How do ESL breaches happen in practice?
The breach is almost never a decision. A reporting analyst points a BI tool at the database because the data is there. An integration platform gets credentials because a project needed a feed, and a DBA runs ad hoc queries because that is what DBAs do.
The connections we find most often are these:
- A BI or reporting connector reading tables directly, often set up by a business analyst.
- An integration or ETL job pulling a nightly extract for a data warehouse.
- A monitoring agent logging in with its own database account.
- A database link from one of your Full Use Oracle databases.
Each act is invisible until an audit maps the connection log against the named application. VirtualBox catches companies the same accidental way, with a free base and a paid component.
Oracle CIO Guide
License types, audit timing and conversion costs for restricted use grants, in one download.
Get the white paper →What happens if you breach ESL restrictions?
Oracle can require conversion to Full Use at list price for the whole deployment. Because the original discount was so deep, the true up lands at a multiple of what the Oracle component first cost, and the deeper the discount, the larger that multiple. That is why embedded deployments are worth auditing from Oracle's side and worth fencing from yours.
A worked example of an ESL conversion
Say an application ships with Oracle programs whose Full Use list value, counted on the server it runs on, is $200,000. The ISV's ESL price for those programs sits somewhere in the observed discount band. The table shows a Full Use conversion demand against three points in that band.
| ESL discount below Full Use list | ESL price | Full Use at list | Conversion as a multiple of the ESL price |
|---|---|---|---|
| 70 percent | $60,000 | $200,000 | 3.3 times |
| 80 percent | $40,000 | $200,000 | 5 times |
| 90 percent | $20,000 | $200,000 | 10 times |
At 80 to 90 percent below list, the license alone reproduces the range we saw in reviews. At 70 percent the multiple starts lower, but support on the new Full Use licenses and any options found in the same review add to it.
You may not know your ESL price, because it is folded into the application fee. Ask the ISV to state the Oracle component in writing, or you cannot test whether a conversion demand is proportionate.
Who can Oracle audit under an ESL, the ISV or the customer?
Both ends of the chain are reviewable. Oracle audits the ISV's royalty compliance directly, and the ISV's agreement gives Oracle a route to the customer's use boundary.
In the published agreement, Oracle could audit the ISV's duplication and distribution of the programs on 45 days written notice, no more than once a year. The ISV also had to audit its end users when Oracle asked and report the findings. Its end user license had to permit that audit and name Oracle as a third party beneficiary.
- What the auditor looks for. Use beyond the embedding application, read from connection logs and accounts against the named application.
- What happens next. Any finding runs through the normal sequence in our Oracle audit guide.
What will Oracle or the ISV say, and how should you answer?
- "Any tool connected to the database makes this Full Use." Ask which connection, from which host, on which dates, and which clause of the embedding agreement it breaches. A finding has to be tied to the paper you hold.
- "The ISV has confirmed you need to convert." Ask the ISV for that position in writing, with the clause it relies on. An ISV may repeat Oracle's view before reading its own agreement.
- "Conversion is at list, for everything on the server." Ask for the calculation, and separate the programs a connection reached from those it did not. Offer ASFU or a scoped Full Use purchase for the real second use, and blocked connections for the rest.
- "Backdated support applies as well." Ask what start date the claim assumes and what evidence sets it. Your connection inventory, with the date each tool was added, is what limits that period.
Why we disagree that ESL compliance is the ISV's problem
A common view, often repeated by the ISV's own sales team, is that an embedded license is the ISV's contract and therefore the ISV's risk. We disagree. The restrictions reach you through the end user license, the ISV must audit you when Oracle asks, and the breaches we reviewed typically started with a connection made by the customer's own staff.
Treat the boundary as yours. Keep the embedding agreement in your contract file, and add one rule to your architecture review: no tool, feed or account touches the embedded database unless the application provides it.
How do you check your own ESL exposure?
Map the connections rather than the installs. The defense is paper plus architecture: the embedding agreement on file with the named application identified, and documented isolation showing who connects to the embedded database and with what tools.
What should you check on paper?
- The embedding agreement. Obtain a copy from the ISV and file it where your audit response team can find it. It is the only document that defines what you may do with the Oracle component, and the one most often missing when an audit asks.
- The named application. The license type and the named application are written into the ordering document, and that clause defines the entire exposure. Confirm the exact name, and whether modules you bought later fall under it.
- The end user license. Read the Oracle terms that flow down to you: scope, internal use, audit rights and transfer.
What should you check in the architecture?
Run the technical check from the network side, or ask the ISV to run it. Logging into an ESL database yourself with SQL*Plus to see who else logs in is itself direct access.
- Network flows. List every host that reaches the database listener, by default on port 1521, and match each one to the application servers. Any other source is a connection to explain.
- Tool configurations. Search BI, ETL, integration and monitoring tools for connection strings that name the embedded database's host or service.
- Accounts and sessions. Ask the ISV, through its support process, for the account list from DBA_USERS and the session list from V$SESSION grouped by PROGRAM and MACHINE. Accounts the application did not create are the finding.
- Database links. Query DBA_DB_LINKS on your own Full Use databases for links that point at the embedded one.
Then block every direct path at the network and credential level. A written policy does little against an analyst who already holds a password; a firewall rule and a locked account stop the connection.
When should you license ASFU or Full Use instead of relying on the ESL?
License the second use case before deployment. If the business needs reporting, integration or a second application on that data, ASFU or Full Use paper priced calmly costs far less than a conversion priced under audit.
How does the right license change with your situation?
| Situation | What fits | Why |
|---|---|---|
| A self contained application, no reporting beyond its own screens | Stay on the ESL | The discount is real as long as nothing else connects |
| Business users want the application's data in a BI tool | Use an export or interface the application itself provides, confirmed in writing by the ISV; otherwise price Full Use | A direct read breaches the ESL, and ASFU covers the database only in support of the named application |
| Your DBAs need to administer or tune the database | ASFU through the ISV | The ESL requires the application to perform all administration |
| A second application or a warehouse feed on the same database | Full Use | Both ESL and ASFU stop at the named application |
| Migration to a hosting provider or public cloud | Written confirmation from the ISV first | Your rights come from the ISV's agreement, which may not cover that deployment |
| Acquisition, divestment or a change of legal entity | Review the transfer clause with the ISV before the transaction closes | The end user license restricts transfer of the Oracle programs, with at most narrow exceptions for mergers |
What have we seen in recent ESL and ASFU reviews?
I ran or benchmarked roughly 15 to 25 restricted use license reviews between 2024 and 2025. In none of them was the money in the original purchase. It was in what somebody plugged into the database afterward, almost always by accident.
- About 7 in 10 embedded engagements. A team had connected a reporting or integration tool directly to the embedded database.
- 40 to 60 percent of the wider ESL and ASFU work. Use had crept beyond the licensed application through a BI connector, an integration platform or a monitoring agent, each wired in by someone solving a problem.
- 5 to 10 times the original ESL price. That was the cost of the true up once a breach was established.
- Roughly half of customers. They could not produce the embedding agreement when the audit asked for it.
The outcomes split cleanly between what won and what paid. The embedding agreement plus documented isolation won the argument in the 2024 and 2025 reviews, because the paper defined the rights and the architecture proved the boundary held. A license true up only paid for the mistake, at the rate the original discount had set up.
Customers who cannot produce their embedding agreement have conceded the definition of their own rights before the audit starts.
That is why a restricted use review starts at the filing cabinet and only then turns to the database.
What to do next
- This week. Locate the embedding agreement and the ordering document, and file both with your license records.
- Confirm the name. Check the application named in the ordering document against what you actually run, including modules added later.
- Map the connections. Inventory every host, tool and account that reaches the embedded database, using network data and the ISV's support process.
- Block direct paths. Close listener access from anything other than the application servers, and lock accounts the application did not create.
- Price the real need. Where reporting, integration or a second application is required, get ASFU or Full Use quotes before the work starts, and ask the ISV to fix an ASFU upgrade price while there is no finding.
- Get help before you answer. If Oracle or the ISV has already raised the question, our Oracle practice runs the review with you.
Frequently asked questions
What is an Oracle ESL license?
A restricted use license that an ISV buys from Oracle and builds into its own product. You receive the Oracle technology only as part of that application, usually with no separate Oracle line on the invoice, and you cannot use it on its own for anything else.
What can you not do with an Oracle ESL?
You cannot use the Oracle technology outside the embedding application. That rules out connecting your own reporting or integration tools to the database, running ad hoc SQL outside the application interface, and serving a second application from the same database. Any of these turns restricted use into Full Use exposure.
What is the difference between ESL and ASFU?
The ESL belongs to the ISV, and you inherit rights inside one application with no direct database access. ASFU is your own license, bought through the ISV, with full database access for one named application. ASFU costs more and flexes slightly further, and its trap is use beyond the named application, as direct access is the ESL's.
What happens if you breach ESL restrictions?
Oracle can require conversion to Full Use at list for the deployment, and support on the new licenses usually follows. Hold the claim to the programs the connection reached and the period it existed, so date each connection before you reply. A blocked path plus a priced ASFU or Full Use offer for the real need gives you a counter proposal.
Why does the embedding agreement matter?
It is the only document that defines your rights over the Oracle component. Isolation evidence only helps against a written boundary, so without the agreement the architecture defends nothing. Ask the ISV for a copy at purchase, when it is keenest to close the sale.
How do you audit your own ESL exposure?
Start with connections rather than installs. Confirm the application named in the ordering document, list every host and tool that reaches the database listener, and match each to the application servers. Have the ISV pull account and session lists, since logging in yourself is direct access.
Can you use SQL Developer or Enterprise Manager on an ESL database?
Not as an end user. ESL terms require all access and administration to run through the application, so your staff connecting with SQL Developer, SQL*Plus or Enterprise Manager is direct access. If your DBAs need to administer or tune the database, the right grant is ASFU or Full Use.
Does an Oracle ESL cover moving the application to the cloud?
Only if the ISV's terms allow it. Your ESL rights come from the ISV's agreement with Oracle, so hosting at AWS, Azure or a service provider needs the ISV's written confirmation that its grant permits that deployment. Get it before the migration plan is approved.