Oracle uses four distinct licence types — each balancing flexibility, cost, and usage restrictions differently. Full Use provides unrestricted internal deployment. ASFU ties Oracle to a single ISV application. ESL embeds Oracle invisibly inside a product. PAH permits hosting Oracle-based services for third parties. Choosing the wrong type is one of the most common — and expensive — Oracle compliance mistakes. This guide provides the complete breakdown for ITAM professionals.
Unrestricted internal use. Any application, any workload, any number of internal and external users. Maximum flexibility — highest cost.
Highest costApplication Specific Full Use. Oracle tied to one named ISV application. Cannot be repurposed. Significant discount — limited flexibility.
Medium costEmbedded Software Licence. Oracle runs invisibly inside a vendor's product. No direct access permitted. Deepest discount — zero flexibility.
Lowest costProprietary Application Hosting. Permits Oracle use to host a service for third-party customers. Provider holds licence — negotiated pricing.
Variable costOracle's licensing models are designed for different deployment scenarios. Each type balances flexibility against cost — the more restricted the usage, the lower the price.
| Licence Type | Flexibility | Key Restriction | Typical Scenario |
|---|---|---|---|
| Full Use | Highest — any project or system | Minimal (standard Oracle terms; internal business use only, not for resale or hosting) | Enterprises licensing Oracle for broad internal deployment |
| ASFU | Moderate — one specific application | Tied to that application; cannot be repurposed for other uses | End customers of ISVs/OEMs getting Oracle bundled with vendor software |
| ESL | Low — embedded component only | Feature-limited to the ISV's application; no standalone Oracle functionality | ISVs embedding Oracle in a product (end user doesn't manage Oracle) |
| PAH | Variable — only for the hosted service | Must be used only to host the designated proprietary application | Oracle partners offering SaaS or hosted solutions to clients |
"The licence type is one of the most overlooked aspects of Oracle compliance — and one of the most consequential. We regularly find enterprises where an ASFU or ESL database has been quietly repurposed for additional workloads over the years. The DBA doesn't know the licence is restricted. The project manager doesn't know the database came from an ISV deal. The ITAM team doesn't have visibility because the licence was purchased through a vendor, not Oracle directly. And then the audit letter arrives. Getting the licence type right from the start — and maintaining governance around it — prevents six- and seven-figure compliance exposures."
— Fredrik Filipsson, Co-Founder, Redress ComplianceA Full Use licence allows an organisation to use Oracle software for any number of internal applications or purposes. It imposes no application-specific ties — the company can deploy Oracle in any system (databases, middleware, applications) as needed. Both internal and external users (such as customers interacting with the company's systems) are covered, provided the Oracle software supports the licensee's business operations.
Because of this wide-open flexibility, Full Use licences are the most expensive. In return, the organisation doesn't have to worry about hitting functional limits or violating usage terms when integrating Oracle across various projects. Full Use is licensed under Oracle's standard metrics — Processor or Named User Plus.
| Attribute | Description | Impact |
|---|---|---|
| Scope | Unrestricted internal use — any application or workload | Very versatile — one licence covers many needs |
| Users | Internal and external users allowed (for the licensee's business) | Supports broad user base and multiple use cases |
| Features | Complete functionality of the Oracle product is available | All features, options, and integrations can be used (subject to separate option licensing) |
| Pricing | Highest cost — no ISV/OEM discounts | Significant investment — justify with broad Oracle usage |
| Restrictions | Standard Oracle contract terms only | Must still adhere to general licensing rules — no unauthorised hosting or third-party use |
An ASFU licence is sold by an ISV or OEM together with their software. It permits Oracle usage only within the confines of that vendor's application. The end customer is listed as the licence owner, but Oracle's usage is contractually bound to the ISV's product — you cannot use the Oracle database or middleware for anything other than running that one application.
The advantage is cost: Oracle is heavily discounted in ASFU deals since the usage is limited. However, if the business later wants to use the Oracle environment for a different purpose or integrate it with additional systems, they would violate the ASFU terms. Any expansion requires purchasing a proper Full Use licence or obtaining Oracle's approval to upgrade.
| Attribute | Description | Impact |
|---|---|---|
| Scope | Oracle use tied to one defined application (application-specific) | Limited flexibility — not a general Oracle environment |
| Users | Only the ISV application's users/features access Oracle | Prevents direct database use by other software or users |
| Access | No direct Oracle access outside the vendor's application interface | Custom queries, third-party tools, and direct DB connections are prohibited |
| Pricing | Lower cost — special ISV bundle discount | Cost-effective for that application's needs only |
| Restrictions | Strict — cannot use Oracle for anything outside the vendor's solution | Misusing it beyond scope breaks compliance and triggers need for full licensing |
⚠️ The ASFU creep trap: The most common ASFU violation occurs gradually. A DBA connects a reporting tool to the Oracle database "just for one report." A developer adds a small integration that reads data directly from the ASFU instance. Over months, the ASFU database becomes a de facto general-purpose environment — entirely non-compliant. Oracle's audit scripts will identify these additional connections.
An ESL licence is used when Oracle technology is hidden inside another vendor's product. The end customer does not operate the Oracle software separately — it's a component of the overall solution. The Oracle database or engine is installed silently alongside the application, and the customer interacts only with the vendor's application interface. No direct access to Oracle is provided or permitted.
ESL licences are the most restrictive and the least expensive. Oracle provides deep discounts (often 80–90%) because it expands Oracle's reach via OEM products while strictly controlling usage. The customer gets a cheaper solution, but has zero flexibility with the Oracle component. Extending the ESL licence for any other purpose is not possible — a new Oracle licence must be acquired.
| Attribute | Description | Impact |
|---|---|---|
| Scope | Oracle embedded in one solution — no general access | Extremely narrow usage — Oracle functions only within the ISV's application |
| Visibility | Oracle is invisible — runs in the background, managed by the ISV's product | Customer doesn't need Oracle expertise but has no control over the Oracle component |
| Access | Absolutely no direct interaction with Oracle permitted | DBAs cannot log into the database, run queries, or connect any external tools |
| Pricing | Lowest cost — deep OEM discount (80–90% off list) | Makes the overall solution significantly more affordable |
| Restrictions | 100% confined to the packaged application | Any attempt to use Oracle beyond the application is unlicensed use. ESL cannot be converted to Full Use |
Restricted licence types (ASFU and ESL) are among the most common audit findings. This whitepaper reveals the hidden risks and how to address them proactively.
Download Whitepaper →A PAH licence allows a company to use Oracle software to offer its own application as a service to others. Normally, Oracle licences forbid using the software to process third-party data or provide commercial services. A PAH agreement grants an exception: an Oracle partner (the service provider) can run a specific, named proprietary application on Oracle infrastructure for multiple end customers.
The provider holds the Oracle licence, and all Oracle software stays on the provider's side. End customers access the service through the provider's application interface and never directly interact with Oracle databases or servers. PAH is typically negotiated to be cost-effective for multi-customer models — but usage is strictly confined to the application defined in the contract.
| Attribute | Description | Impact |
|---|---|---|
| Scope | Oracle usage for hosting one proprietary application for third parties | Not for general use — strictly for the SaaS or service offering specified |
| Users | External end customers (via the provider's app); provider's team manages Oracle | Allows multi-client services on Oracle without each client needing a licence |
| Licence holder | The service provider holds the Oracle licence — not the end customer | End customers don't need their own Oracle licences and cannot take Oracle on-premises |
| Pricing | Variable — negotiated contract, often discounted for scale | More cost-effective at scale than individual Full Use licences per customer |
| Restrictions | Severe — only for that application; cannot be transferred or repurposed | The provider must ensure no other usage. Any expansion requires additional licensing |
"PAH is the licence type that organisations most frequently get wrong — because they don't know it exists. We regularly see companies using standard Full Use licences to host applications for external clients. That's a direct contract violation. Oracle's standard licence terms explicitly prohibit third-party use. If you're building a SaaS offering on Oracle, you need PAH — and the terms need to be negotiated carefully because Oracle's standard PAH contracts include restrictions on scope, geography, and pricing that can significantly impact your service economics."
— Fredrik Filipsson, Co-Founder, Redress Compliance| Factor | Full Use | ASFU | ESL | PAH |
|---|---|---|---|---|
| Flexibility | Highest — any internal use | Medium — one specified application | Low — within the ISV's product only | Medium — broad but only for the hosted service |
| Primary use | General-purpose internal deployment | One specific vendor-provided application | Deeply embedded OEM component | Powering a SaaS or hosted service |
| Access | Full direct access for licensee's IT | Only via the vendor application | No customer access — application uses Oracle internally | Only provider's admins; clients use app front-end |
| Cost level | High (no discounts) | Lower (significant ISV discount) | Lowest (deep OEM discount, 80–90% off) | Variable (negotiated, cost-effective at scale) |
| Key restriction | Internal use only; no third-party hosting | Exclusive to named application | Locked to ISV product; cannot be repurposed | Strictly for the defined hosted app |
| Licence holder | The enterprise itself | End customer (obtained via ISV) | End customer (bundled invisibly) | The service provider |
| Can be upgraded? | N/A — already the broadest type | To Full Use (requires purchase) | Cannot be converted — new licence required | N/A — separate commercial model |
| Scenario | Best Fit | Rationale |
|---|---|---|
| Multiple applications or databases needed? | Full Use | Provides broad rights for any number of internal systems. The only option when Oracle is used across multiple workloads |
| Using Oracle with one specific ISV app? | ASFU | Oracle is needed for only that application — ASFU covers it at lower cost. Ensure you won't need to expand |
| Oracle embedded in a vendor product? | ESL | Oracle usage is entirely within one sealed product. ESL is ideal — and cheapest — for this model |
| Hosting an app for external customers (SaaS)? | PAH | The only legal way to use Oracle for third-party services. Standard licences explicitly prohibit this |
| Unclear or evolving requirements? | Full Use (safer) | If there's any chance the Oracle environment will be used for additional workloads, Full Use prevents compliance risk. The cost premium is insurance against audit exposure |
| Mistake | Why It Happens | Resulting Problem |
|---|---|---|
| Using ASFU Oracle for additional workloads | The DBA treats the Oracle instance as a normal database once installed. The ASFU restriction isn't communicated to the IT team. Reporting tools, integrations, or custom queries are connected over time | Compliance breach — the additional usage is unlicensed. Oracle's audit identifies the connections and demands Full Use licensing for the entire environment, with back-support fees |
| Licence too restrictive for needs | Cost-focused procurement selects ESL or ASFU without projecting future use cases. The ISV recommends the cheapest option without explaining restrictions | Outgrowing the licence — emergency re-purchase required, often at higher prices during an audit. No ability to convert ESL to Full Use |
| Hosting on standard licences | Organisation launches a SaaS offering using Oracle without realising standard Full Use licences prohibit third-party use. PAH requirement is unknown | Contract violation — potential for severe penalties if Oracle audits or discovers unapproved hosting. Must retrofit PAH licensing retroactively |
| Poor licence type documentation | The ITAM team doesn't record which Oracle instances are Full Use vs ASFU vs ESL. Licences were purchased years ago through different ISV channels | Governance gap — no one knows which databases are restricted. Usage gradually drifts beyond permitted scope without anyone flagging the risk |
| Assuming ESL can be upgraded | Organisation plans to expand ESL usage later by "upgrading" the licence. Oracle doesn't offer ESL-to-Full-Use conversion | A completely new Full Use licence must be purchased. The ESL licence has no trade-in value, and the organisation has two sets of costs |
Restricted licence types are a key audit finding area. This playbook covers how to prepare, defend, and minimise financial exposure across all Oracle licence categories.
Download Whitepaper →| Recommendation | Detail |
|---|---|
| Define usage before purchase | Outline exactly how you plan to use Oracle — which applications, how many users, internal vs external use — and choose the licence type that matches. Don't let cost alone drive the decision |
| Document licence boundaries | Map each Oracle instance to its licence type and allowed usage. Label databases clearly — "ASFU – used only for X application" or "ESL – embedded, no direct access." This prevents accidental misuse |
| Educate your teams | Ensure DBAs, developers, and project managers understand the restrictions of your Oracle licences. If you have ESL or ASFU, everyone must know they cannot use that Oracle environment for anything outside its intended scope |
| Monitor and reassess periodically | Regularly review Oracle deployments and upcoming projects. If changes are planned (expanding an application, integrating new tools, moving to a service model), reassess whether current licences still cover those uses |
| Control access technically | For ASFU and ESL instances, implement technical controls that prevent unauthorised connections. Restrict database listener access, limit user accounts, and monitor for unexpected connections |
| Audit before Oracle audits | Conduct internal licence audits that specifically verify licence type compliance. Check whether any ASFU or ESL databases have additional connections, reporting tools, or integrations beyond their permitted scope |
| Plan ISV relationships carefully | When acquiring software from ISVs that bundle Oracle, understand exactly what licence type is included (ASFU vs ESL), what it permits, and what it prohibits. Get this in writing from the ISV before purchase |
| Negotiate PAH terms proactively | If building a SaaS offering on Oracle, engage with Oracle early to negotiate PAH terms — scope, geography, pricing model, and growth provisions. PAH contracts are heavily negotiable and terms vary widely |
Not sure which licence types your Oracle instances are running under? Our independent assessment identifies every Oracle deployment, verifies licence type compliance, quantifies exposure, and develops a remediation plan — before Oracle's audit team does.
From licence type optimisation to ULA negotiations to audit defence — the 10 strategies that consistently deliver the best outcomes for enterprises dealing with Oracle.
Download Whitepaper →Full inventory of every Oracle deployment — databases, middleware, applications — with licence type verification, compliance assessment, and cost optimisation.
Learn More →Expert defence against Oracle LMS and GLAS audits — protecting your position on licence types, restricted-use terms, and compliance findings.
Learn More →Independent advisory for Oracle purchases, licence type upgrades, PAH negotiations, ULA deals, and renewal strategies.
Learn More →