Understanding Oracle License Types

Oracle offers two primary license models: Perpetual and Subscription. Perpetual licenses grant the right to own the software forever, with a one-time upfront cost plus annual support fees of 22 percent of the net license fee. These support fees increase at 8 percent annually and are mandatory. Subscription licenses, by contrast, involve annual or multi-year terms with no perpetual ownership rights. When the subscription expires, your right to use the software expires unless you renew. Understanding which model you hold is critical for budgeting, compliance planning, and negotiation strategy.

The distinction matters enormously. Perpetual licenses represent long-term assets; subscription models represent operational expenses. Your mix of perpetual and subscription licenses shapes your entire compliance posture. Many enterprises carry both types simultaneously, creating a blended licensing position that requires careful tracking.

Primary Oracle License Metrics

Oracle uses two primary metrics for software licensing: Processor and Named User Plus (NUP). Processor licensing, also known as Per Core licensing, charges based on the number of processors or cores on which the software is installed and used. Each core counts as one unit, but Oracle applies a core factor that varies by processor type. This core factor is not intuitive and represents one of the largest sources of licensing disputes between Oracle and customers.

Named User Plus licensing counts the named users who access the software, with minimum thresholds that vary by product. For Oracle Database Enterprise Edition, the minimum is 25 Named User Plus per processor core. Middleware products such as Oracle WebLogic Server typically require 10 NUP per processor. Understanding which metric applies to your products is foundational; deploying a NUP-licensed product with processor metrics creates immediate compliance exposure.

Oracle Core Factor Table: The Real Cost Driver

The Oracle Core Factor Table is the hidden lever that determines your true licensing cost. Intel and AMD x86-64 processors carry a core factor of 0.5, meaning each physical core counts as 0.5 license units. SPARC processors vary widely depending on the generation. IBM POWER processors carry factors from 0.75 to 1.0 depending on the model. Modern AMD EPYC systems consistently carry 0.5 factors, while Intel Xeon Scalable processors also carry 0.5.

The trap is subtle. A 32-core Intel Xeon processor carries 16 license units (32 cores × 0.5 factor). The same server with a SPARC T7 processor might carry 8 license units or 32 license units depending on the generation. Oracle has been aggressive in auditing core counts, and enterprises frequently undercount cores on virtual machines, cloud deployments, and multi-socket servers. Always validate your core count against the Oracle Core Factor Table; one miscount can create a six-figure compliance gap.

The CSI: Your License Support Identifier

A Customer Support Identifier (CSI) is a unique number that links your support entitlements to your contracts. Oracle uses the CSI to identify which products you own, which support plan you maintain, and which licenses are covered. During an audit, Oracle verifies that your deployed software matches your registered CSI.

CSIs are critical but frequently lost or missing. Many enterprises cannot locate their original CSI documents or never registered their CSI with Oracle's My Oracle Support portal. When an audit begins, Oracle uses your CSI to quickly pull your contract history, support status, and entitlements. If your CSI is missing or unregistered, the audit becomes significantly more difficult; you must then produce physical ordering documents to reconstruct your license position. Protecting and maintaining your CSI is among the simplest and most effective audit-defence measures.

Ordering Documents: The Legal Record

Your Ordering Document is the legal record of what you own. It specifies the products, license units, metrics, support status, and purchase date. Oracle enforces a strict policy: if a product is not listed on your Ordering Document, you do not own it. Ordering documents are the foundation of your defense during an audit.

Many enterprises have lost or cannot locate their ordering documents. If you purchased Oracle software 10, 15, or 20 years ago, your original ordering documents may have been archived or discarded. If Oracle audits you and you cannot produce an ordering document, Oracle will assume you do not own the license. This is not negotiable. Archive and protect every ordering document you receive; consider storing digital copies in a secure, redundant location outside your email system.

Oracle License and Services Agreement (OLSA)

All Oracle software usage is governed by the Oracle License and Services Agreement (OLSA). This agreement defines your rights, restrictions, and obligations. The OLSA specifies that "installation and use" of Oracle software triggers the licensing obligation. This phrase is crucial: merely installing Oracle software, even for testing or evaluation, creates a licensing requirement. You cannot justify an undeployed installation as non-licensed.

The OLSA also defines minimum purchase requirements, restrictions on mixing license types, and auditing rights. Oracle's auditing rights are broad and enforceable. Under the OLSA, Oracle may conduct audits at any time, require you to cooperate, and charge you for the audit cost if you are out of compliance. Understanding the OLSA is non-negotiable for enterprises managing Oracle risk.

Support Costs: 22 Percent Plus 8 Percent Annually

Support for perpetual Oracle licenses costs 22 percent of the net license fee per year. This is fixed, but it increases at 8 percent annually. On a $1 million perpetual license, support begins at $220,000 per year. In year two, it rises to $237,600. In year ten, it reaches $434,500. Over twenty years, cumulative support costs exceed $6.5 million on that single $1 million purchase. Support escalation is invisible to many enterprises until a renewal cycle arrives and the bill shocks the finance team.

Support also carries hidden mechanics. If you fall out of support, Oracle charges penalties to bring you current before you can renew. If you are several years behind on support, the catch-up cost can exceed the license cost itself. Never let your support lapse unexpectedly; the financial and compliance consequences are severe.

Oracle ULA and PULA Programs: Fixed Fees, Unlimited Deployment

Oracle Unlimited License Agreements (ULA) and Program ULAs (PULA) offer a different pricing model. Under a ULA, you pay a fixed fee for a defined term—typically three years—and deploy as many license units as you want. The support fee is fixed during the ULA term regardless of how many products you deploy. This creates a powerful incentive: every additional deployment during the ULA term is free. Many enterprises fail to maximize their ULA deployment, leaving millions of dollars in unrealized value on the table.

The critical date is the certification date. At the end of your ULA term, Oracle requires you to certify how many license units you deployed. Only the certified deployment carries over to your perpetual licenses. Any additional deployment you did not certify is unlicensed. Enterprises that underestimate their deployment during the ULA term and fail to certify correctly create significant compliance gaps. Before your ULA certification date, conduct an exhaustive inventory of all deployed Oracle software and certify aggressively. Every additional unit you certify is one fewer perpetual license you must purchase at renewal.

License Position: The Gap Analysis

Your license position is the difference between what you own and what you deploy. A positive license position means you own more than you use; a negative license position means you use more than you own. Tracking your license position is essential for three reasons: audit defense, cost control, and budgeting.

Many enterprises maintain inaccurate license position data because they lack real-time visibility into their deployments. Virtual machine sprawl, cloud migrations, and development environments deployed without procurement visibility create blind spots. Conduct an annual inventory of all Oracle deployments and compare it to your licensing records. The gap you identify represents either audit exposure or cost reduction opportunity.

Oracle Has No Enterprise Agreements—Correct Terms Explained

A common misconception: many enterprises refer to their Oracle contracts as "Enterprise Agreements." Oracle does not offer Enterprise Agreements. Oracle's contract types are: ULA (Unlimited License Agreement), PULA (Program ULA), OCS (Oracle Cloud Services), and individual product licenses with support. If someone claims you have an "Oracle Enterprise Agreement," they are using incorrect terminology that may mask your actual contract type. Always verify your actual contract document and use Oracle's correct terminology. This distinction matters during audits; mischaracterizing your contract can weaken your compliance position.

Oracle LMS and GLAS: How Audits Work

Oracle conducts audits through two channels: License Management Services (LMS) and Glib Advisory Services (GLAS). Both target the same objective: verify that your deployed software matches your licensing. LMS audits are typically triggered after contract expiry or when Oracle believes you are non-compliant. GLAS, rebranded from Oracle's previous advisory services, may approach you during renewal negotiations as a "friendly" audit.

Oracle's audit process begins with a document request. Oracle asks you to provide your ordering documents, CSI registration records, and a configuration of all deployed Oracle software. Oracle then reconciles your deployment against your licensing. If Oracle finds undeployed licenses, it may offer a credit during renewal. If Oracle finds under-licensed deployments, it will demand payment for all unlicensed units, often with penalties and back-dated support.

The audit scope is broad. Oracle examines not just production deployments but also development, test, and contingency systems. Oracle also scrutinizes license reassignment between servers, which may be prohibited depending on your license type and agreement terms. Prepare for audits by maintaining a current inventory of all deployed Oracle software, protecting your ordering documents and CSI records, and understanding exactly what licenses you hold.

How to Locate Your Oracle Licenses

Locating your Oracle licenses requires multiple data sources. Begin with your Oracle Store history and invoices—these show what you purchased and when. Next, contact My Oracle Support (MOS) portal and use your CSI to access your account. MOS displays your registered contracts, support status, and some product listings. Your CSI number itself is the key to unlock Oracle's records; if you have lost yours, request it from your Oracle account manager or search your email for original contracts.

Physical ordering documents are irreplaceable. Retrieve them from your procurement system, finance records, or email archives. If you cannot locate an original document, request a copy from Oracle. Finally, conduct an internal IT inventory of all deployed Oracle software using tools like Oracle Universal Installer logs, database discovery scans, or enterprise asset management systems. Match your internal inventory against your contracts to identify gaps.

Common Gaps in License Information

Many enterprises discover critical licensing gaps only during an audit. The most common gaps are lost ordering documents, missing or unregistered CSI numbers, unlicensed software options (such as Oracle Net Manager or Advanced Security), deployments on cores with wrong core factors, Named User Plus minimums not met, and software installed during evaluation periods but never formally licensed. Conduct a pre-audit self-assessment. Identify and remediate gaps before Oracle does.

Need an Independent Oracle Audit Assessment?

Redress has assessed Oracle licenses at 500+ enterprises. We identify compliance gaps, licensing opportunities, and audit defense strategies before Oracle LMS arrives.
Learn More →

Preparing for Oracle Compliance Success

Compliance with Oracle licensing requires discipline, documentation, and ongoing vigilance. Assign clear ownership of your Oracle licensing responsibility. Protect your ordering documents and CSI records. Maintain an annual inventory of deployed software and reconcile it to your contracts. Understand your core factor calculations and Named User Plus minimums. Monitor your support renewal dates to avoid lapses. And before any audit, engage an independent advisor to identify gaps and build a defense strategy.

Oracle licensing is not a one-time exercise. Software deployments change constantly. New products are introduced, old systems are decommissioned, and cloud migrations create new licensing questions. Stay informed about Oracle licensing changes and conduct periodic reviews of your position. The investment in compliance discipline pays enormous dividends when Oracle audits arrive.

Stay Current on Oracle Licensing Changes

Oracle licensing rules, support pricing, and audit triggers evolve continuously. Subscribe to Redress Compliance for quarterly Oracle licensing updates and audit defense strategies.