Oracle License Types Explained: Full Use, ASFU, ESL, ULA, PULA and More

Why Oracle License Types Matter

Understanding Oracle license types is not an academic exercise — it directly determines how much you pay, what you can legally deploy, and how exposed you are during an Oracle audit. Oracle's licensing framework distinguishes between what you are licensing (the metric), how many users or processors are involved, and what restrictions govern the use. Getting any of these wrong creates compliance gaps that Oracle's License Management Services (LMS) team is specifically trained to find.

Oracle support fees increase by 8% per year compounding — meaning that a licence estate valued at €1 million in support today will cost €1.47 million per year within five years if left unchecked. The type of licence you hold determines your negotiating leverage and your ability to contain those increases. This guide covers every major licence type currently in use across Oracle's technology and applications portfolio.

1. Full Use (FU) Licences

Full Use is Oracle's standard, unrestricted perpetual licence. It grants the licensee the right to use the software for any internal business purpose, deployed on any hardware the organisation owns or controls. There are no application restrictions, no OEM ties, and no limits on the number of systems — only the metric (Processor or Named User Plus) limits how much you can deploy.

Full Use licences are the most flexible Oracle licences available, but they are also the most expensive list-price product. Because they carry unlimited internal-use rights, organisations that later merge or acquire other entities must carefully review whether those new entities fall within the definition of the original contracting entity. Oracle's definition of "you" in a Full Use agreement typically refers to the legal entity and its subsidiaries at the time of signing — post-merger entities added later may require separate licences.

Perpetual vs. Term Full Use

Full Use licences are available as both perpetual and term arrangements. A perpetual licence is purchased with a one-time fee and, provided annual support is maintained, it never expires. A term licence grants usage rights for a defined period — commonly one, two, or three years — and must be renewed or replaced at expiry. Oracle has been moving enterprise customers toward term licences in recent years, particularly in the context of cloud migration discussions, though perpetual licences remain the dominant model in technology deployments.

2. Named User Plus (NUP) Licensing

Named User Plus (NUP) is a per-user metric that counts every individual authorised to access the Oracle software, plus every device that can access it without a human user behind it. The "Plus" in the name refers to the inclusion of automated access — robots, batch processes, and device connections must all be counted, not just human logins.

NUP is typically the better economic choice when the number of users is small and stable, and when users can be enumerated. The critical rule that Oracle auditors check first is the minimum NUP per processor requirement: for Oracle Database Enterprise Edition, you must license at least 25 Named User Plus licences per processor, regardless of actual user count. A database running on a single-processor server with just three users still requires 25 NUP licences for EE.

When NUP Is More Cost-Effective Than Processor

The crossover point between NUP and Processor licensing depends on the edition and the number of cores. For Oracle Database Enterprise Edition on an Intel Xeon server with a 0.5 core factor, a 4-core processor requires 2 processor licences. At approximately $47,500 per processor licence (list price), two processor licences cost $95,000. At roughly $950 per NUP licence (list price), the crossover is 100 users — meaning fewer than 100 users makes NUP cheaper, while more than 100 users pushes you toward Processor licensing. Always apply Oracle's current list price and any negotiated discount to your specific environment.

3. Processor Licensing

Processor licensing is based on the number of CPU cores on the servers where Oracle software is installed or running. It is the most common metric for large-scale, multi-user deployments where counting individual users is impractical. The licence count is calculated by multiplying the number of physical cores by Oracle's Core Processor Licensing Factor for that CPU type.

The Core Factor Table

Oracle publishes a Core Processor Licensing Factor (also called the core factor table) that assigns a multiplier to each processor family. Most modern Intel Xeon and AMD EPYC processors carry a factor of 0.5, meaning two physical cores equal one Oracle Processor licence. IBM POWER processors typically carry a factor of 1.0, and Oracle's own SPARC processors have varying factors. Oracle's Ampere-based cloud instances (OCI) carry a 0.25 factor when licensing via BYOL in OCI.

The core factor table applies only to on-premises deployments and to Oracle Cloud Infrastructure (OCI) BYOL. For AWS, Azure, and Google Cloud, the rule is simpler: 2 vCPUs equal 1 Processor licence when hyper-threading is enabled. This cloud rule can create significant licence exposure when organisations migrate high-core-count workloads to cloud VMs with large vCPU counts without first right-sizing.

4. Application Specific Full Use (ASFU) Licences

Application Specific Full Use (ASFU) licences are issued to Independent Software Vendors (ISVs) and passed to end customers as part of a bundled application. An ASFU licence permits the end user to run Oracle Database (or other Oracle technology) only in direct support of the ISV's specific application. You cannot use an ASFU-licensed database for any other purpose — running reports, connecting other tools, or loading non-ISV data against an ASFU database creates an unlicensed use position.

ASFU licences are deeply discounted relative to Full Use (often 80–90% below list price) precisely because their use is so tightly restricted. The risk arises when organisations consolidate databases onto ASFU-licensed servers, or when DBAs begin using the ASFU database for operational scripts or reporting unrelated to the named application. Oracle audits routinely uncover ASFU misuse, and the remedy is typically a full-price Full Use licence purchase.

5. Embedded Software Licence (ESL)

The Embedded Software Licence (ESL) is the most restrictive Oracle licence type. It applies when Oracle technology is embedded invisibly inside a third-party product — the end customer does not operate or interact with the Oracle software directly; it simply runs as a hidden component of the vendor's solution. ESLs are licensed to the ISV (not the end customer), and the end customer typically has no visibility of the licence terms or metrics.

The compliance risk with ESLs is significant: if an end customer begins using Oracle functionality beyond what the ISV's product exposes — for example, by connecting a BI tool or querying the embedded database directly — they may inadvertently create a Full Use licence requirement. Organisations that discover ESL-based Oracle databases in their estate during an audit are advised to immediately scope the actual use against the ISV's contractual definition before engaging Oracle.

6. Unlimited Licence Agreement (ULA)

An Oracle Unlimited Licence Agreement (ULA) is a time-bound contract — typically two to four years — under which the customer pays an agreed upfront licence fee and annual support, and in return may deploy unlimited quantities of the specified Oracle products during the term. At the end of the ULA, the customer undergoes a certification process: they declare to Oracle the total number of Processor or NUP licences deployed across all covered products. That certified number becomes the customer's perpetual licence entitlement going forward.

The Critical ULA Principle: Maximise Deployment Before Certification

The ULA structure creates a powerful economic incentive: every additional deployment made during the ULA term is free. Support fees under a ULA are fixed regardless of how much you deploy — you pay the same annual support whether you deploy 100 Processor licences or 10,000. This means organisations under a ULA should systematically maximise their deployment of covered products before the certification date, because every deployment reduces the effective per-licence cost paid and increases the perpetual entitlement certified out of the agreement.

Oracle's Q4 window (March to May, as Oracle's fiscal year ends 31 May) is when the vast majority of ULAs are signed and certified. Oracle sales teams are highly motivated to close ULA certifications before 31 May, which creates negotiating leverage for customers who are well-prepared but can also create pressure to certify early before maximum deployment has been achieved.

7. Perpetual Unlimited Licence Agreement (PULA)

A PULA is a variant of the ULA where the unlimited deployment right is granted in perpetuity — there is no certification date and no expiry. Once signed, the customer may continue deploying the covered products indefinitely without any licence ceiling. PULAs are exceptionally rare and are typically negotiated only by very large organisations with significant Oracle spend as leverage. The price premium over a standard ULA is substantial — often double — reflecting the permanent nature of the commitment.

From a compliance management perspective, a PULA eliminates the certification risk that exists with a standard ULA but introduces other risks: Oracle may push to renegotiate or restructure the PULA at contract renewal, and the products covered by a PULA are typically limited in scope. An organisation that expands into new Oracle products not covered by the PULA must still licence those products through standard channels.

8. Oracle Cloud Services (OCS) — Subscription Licences

Oracle Cloud Services (OCS) encompasses Oracle's portfolio of SaaS, PaaS, and IaaS subscription offerings. Unlike perpetual licences, OCS subscriptions grant usage rights only for the duration of the subscription term. When the subscription lapses, all rights to access and use the service cease. Oracle's SaaS products — including Oracle Fusion Cloud ERP, HCM, and SCM — are exclusively available as OCS subscriptions.

For organisations migrating from on-premises applications to Oracle Cloud, it is critical to understand that OCS subscriptions do not provide perpetual licence rights to the underlying technology. A customer who cancels their Oracle Fusion Cloud subscription and attempts to run the application on-premises would require separate on-premises perpetual licences — a scenario Oracle is unlikely to support without significant commercial negotiation.

Oracle Has No Enterprise Agreement

A point of frequent confusion: Oracle does not offer an Enterprise Agreement equivalent to Microsoft's EA or SAP's Enterprise Licence Agreement. Oracle's closest analogues are the ULA (time-bound unlimited deployment), the PULA (perpetual unlimited deployment), and OCS subscription bundles. Any Oracle sales representative who refers to a proposed deal as an "enterprise agreement" is using imprecise language — the actual contract structure will be a ULA, PULA, OCS, or CSI-based arrangement. Understanding this distinction is important for contract governance and renewal planning.

9. Customer Support Identifier (CSI)

The Customer Support Identifier (CSI) is not a licence type per se, but it is a critical component of Oracle's licensing infrastructure. Every Oracle support contract is associated with a CSI number that serves as the account identifier for downloading patches, accessing Oracle Support portals, and managing licence entitlements. When organisations acquire companies with Oracle software, reconciling and consolidating CSI numbers is essential to maintain a coherent licence position and avoid paying duplicate support on the same entitlements.

10. Bring Your Own Licence (BYOL) to Cloud

BYOL is not a separate licence type — it is a deployment model that allows customers to apply existing on-premises perpetual licences to authorised cloud environments. Oracle recognises BYOL deployments on OCI, AWS, Azure, and Google Cloud Platform (the last three were formally added to Oracle's Authorised Cloud Environments list in recent years). BYOL in OCI offers the most favourable conversion ratio: one on-premises Processor licence covers two OCPUs. On AWS, Azure, and GCP, the standard rule applies: two vCPUs equal one Processor licence.

BYOL deployments are subject to the same licence metric rules as on-premises deployments, including the prohibition on soft partitioning. An organisation that moves an Oracle Database onto an AWS or Azure VM must ensure the vCPU count is properly mapped to the available Processor licences, or it risks creating a shortfall that an audit could expose.

Common Compliance Pitfalls by Licence Type

Each Oracle licence type carries its own characteristic compliance risks. Full Use licences create exposure through virtualisation — specifically, Oracle's refusal to recognise VMware and Hyper-V as hard partitioning means that all physical cores in a VMware cluster hosting Oracle may be in scope, even if Oracle only runs on a subset of VMs. NUP licences create risk through forgotten automated connections and device access that were never declared. ASFU licences are routinely misused when organisations use the licensed database for purposes beyond the named application. ULA licences carry risk at certification: organisations that certify without maximising deployment lock themselves into a perpetual entitlement that may be lower than what the ULA investment justified.

The 8% Support Escalator Across All Licence Types

Regardless of licence type, Oracle's standard support contract increases by 8% per year. This is a contractual escalator embedded in Oracle's standard support agreement, not an ad hoc price increase. Organisations that signed large perpetual licence deals five or ten years ago and have been dutifully renewing support face substantially higher annual costs today than they budgeted for at contract inception. Strategies to manage this include third-party support (for non-cloud products), support level optimisation, and licence rationalisation before renewal.

Choosing the Right Oracle Licence Type

The optimal licence type depends on several factors: the number and stability of users, the hardware environment, the deployment horizon, the vendor relationship, and the organisation's appetite for deployment flexibility versus cost certainty. Full Use perpetual licences suit organisations with long Oracle deployment horizons and strong negotiating leverage. NUP suits controlled-access environments with stable user populations. ULAs suit organisations in growth mode that expect to expand Oracle deployments significantly during the term. ASFU and ESL are determined by the ISV relationship, not by customer preference.

For any organisation approaching an Oracle renewal or audit, the first step is to understand exactly which licence types you hold and map them against actual deployment. That mapping — often called a licence position — is the foundation for every Oracle negotiation and the primary defence in any Oracle audit. Redress Compliance provides independent licence position assessments as a starting point for all Oracle advisory engagements.

Key Takeaways

• Full Use is the most flexible but most expensive Oracle licence — internal use only, no application restrictions.
• NUP requires a minimum of 25 licences per processor for Enterprise Edition and must include all automated access.
• Processor licensing uses the core factor table (0.5 for Intel/AMD) and 2 vCPUs = 1 licence in the public cloud.
• ASFU is restricted to a named ISV application — any broader use creates a Full Use licence gap.
• ESL is invisible to the end customer — confirm what Oracle technology is embedded before an audit forces the question.
• ULA support fees are fixed regardless of deployment volume — maximise deployment before the certification date to maximise the perpetual entitlement you certify out.
• Oracle has no Enterprise Agreement — the alternatives are ULA, PULA, OCS, and CSI.
• Oracle support increases by 8% per year under the standard support contract.