Oracle's licensing model is among the most complex in enterprise software. The rules around virtualisation, cloud deployment, processor counting, named user minimums, and Java subscriptions are genuinely difficult to navigate — and Oracle's own account teams have a financial interest in the interpretation that maximises licence consumption. This complexity creates fertile ground for myths that, once embedded in an organisation's assumptions, persist through procurement cycles and audit responses until they collide with Oracle's LMS team.
These are the ten myths we encounter most frequently, and the facts that replace them.
Myth 1
"Oracle is licensed per virtual CPU — so we just count the vCPUs assigned to our VM."
Fact: Oracle classifies VMware as soft partitioning. Under Oracle's official policy, soft partitioning does not limit the number of processor licences required. If your Oracle software can run on any host in a VMware cluster — including via vMotion or DRS — Oracle requires you to licence all physical cores across all hosts in that cluster, applying the core factor table. A single Oracle VM in a 20-host cluster means all 20 hosts' physical cores must be licensed. This is the single most common source of multi-million-dollar Oracle audit claims in VMware environments.
Myth 2
"A ULA means unlimited Oracle software of all types."
Fact: An Oracle Unlimited License Agreement (ULA) provides unlimited deployment rights only for the specific Oracle products named in the ULA contract. The unlimited right does not extend to other Oracle products, even those from the same product family. An organisation with a ULA covering Oracle Database Enterprise Edition does not have the right to deploy Oracle Real Application Clusters, Oracle Advanced Security, or Oracle Partitioning without specific inclusion of those products in the ULA contract. Deploying non-ULA products and including them in the ULA certification count is an audit risk that creates precisely the compliance exposure the ULA was intended to eliminate.
Myth 3
"Oracle Java SE is free — everyone has always used it without paying."
Fact: Oracle's January 2023 licensing change fundamentally altered Java SE commercial use terms. Under the current model, any organisation using Oracle JDK in a commercial environment is required to hold an Oracle Java SE subscription. The subscription is priced per employee — all employees in the organisation — not per Java installation or per active user. Oracle's pre-2019 Java SE licensing was more permissive, and some organisations have valid perpetual licences under older terms, but the default position for commercial Oracle JDK use from January 2023 onwards is that a subscription is required. Oracle Java SE subscriptions escalate at approximately 8 percent per year.
Concerned about Oracle licensing exposure in your environment?
Our independent assessment identifies real risks — not just theoretical ones. Buyer-side only.
Myth 4
"Perpetual licences mean no ongoing costs."
Fact: Oracle's perpetual software licences grant the right to use the software indefinitely. They do not include ongoing Oracle support, patches, or updates. To access Oracle's patch pipeline, technical support, and product updates, organisations must separately pay Oracle Premier Support — calculated at 22 percent of the net licence purchase price per year, with an 8 percent annual escalation. Organisations that let Oracle support lapse retain the right to use the software but lose access to security patches and bug fixes. Reinstating lapsed Oracle support requires payment of all back-support fees to bring the contract current — Oracle does not allow organisations to reinstate without paying the missed support periods.
Myth 5
"Running Oracle in a public cloud means Oracle handles the licensing."
Fact: Cloud providers host the infrastructure — they do not licence Oracle software on your behalf except for specific licence-included offerings. If you bring your own Oracle licences (BYOL) to AWS, Azure, or Google Cloud, you remain responsible for Oracle software licences in exactly the same way as on-premises deployments. Oracle's BYOL policies are cloud-specific and impose limitations on which instance types can be used without licensing all cores in the physical host. Oracle Database on AWS, Azure, and GCP in BYOL configurations is subject to Oracle's partitioning policies — soft partitioning restrictions apply in the same way as in on-premises VMware environments for most cloud configurations. Only Oracle Authorised Cloud Environments — currently AWS, Microsoft Azure, Google Cloud, and Alibaba Cloud under specific configurations — allow per-OCPU or per-vCPU licensing rather than full physical host licensing.
Myth 6
"The core factor table favours modern Intel and AMD processors, so newer hardware reduces our licence count."
Fact: Oracle's core factor table assigns a 0.5 factor to Intel and AMD multi-core processors, meaning you need 0.5 Oracle processor licences per physical core. This factor has been beneficial to customers using Intel and AMD hardware compared to older processor types. However, the factor does not reduce with hardware generation — a modern Intel or AMD processor still requires 0.5 processor licences per core regardless of the generation. Where customers can genuinely reduce licence counts is through Oracle-approved hard partitioning technologies (Oracle VM, IBM LPAR, Solaris Zones, BIOS-level core disabling) that physically restrict the cores Oracle software can access. Soft partitioning technologies — including VMware, Hyper-V, KVM, and most cloud hypervisors without specific Oracle authorisation — do not limit the licensing scope.
Myth 7
"Named User Plus licensing is always cheaper than processor licensing for Oracle Database."
Fact: Named User Plus licensing requires a minimum of 25 NUP licences per processor (as calculated using the core factor table). For Oracle Database Enterprise Edition on a 2-socket server with 16 cores per socket and an Intel core factor of 0.5, the processor licence count is 16 processor licences. The NUP minimum is 16 × 25 = 400 Named User Plus licences. If the actual user population is fewer than 400, the NUP metric may appear cheaper per-licence — but the minimum floor often makes processor licensing more economical in practice. The calculation must be run for the specific hardware, core count, and user population before any conclusion can be drawn about which metric is more cost-effective.
Need clarity on your Oracle licensing obligations?
Our licensing assessments have identified over $200M in misallocated Oracle spend across 500+ engagements.
Myth 8
"Oracle has an Enterprise Agreement similar to Microsoft EA or SAP ELA that covers all products."
Fact: Oracle does not offer an Enterprise Agreement equivalent. Oracle's broad commercial frameworks are the Unlimited License Agreement (ULA), the Perpetual Unlimited License Agreement (PULA), Oracle Cloud Services (OCS), and the Customer Support Identifier (CSI) structure. None of these provide broad organisation-wide rights to all Oracle products in the way that Microsoft's Enterprise Agreement or SAP's Enterprise License Agreement operates. A ULA provides unlimited deployment rights only for specifically named products for a fixed term. A PULA provides perpetual unlimited rights for named products with no term limit. Both require certification at exit to establish the perpetual licence count. Conflating Oracle's agreements with Microsoft or SAP's equivalent frameworks leads to systematic over-deployment of Oracle products without appropriate licence coverage.
Myth 9
"Oracle's support fees only go up by about 3 to 4 percent per year."
Fact: Oracle's standard support contracts include an 8 percent annual escalation clause. This is not a general inflation-linked adjustment — it is Oracle's standard commercial term. An organisation paying €2 million per year in Oracle Premier Support today will pay €4.3 million per year in a decade on the same licence estate, purely due to contract escalation. Over a ten-year horizon, cumulative support spend on a static €2 million annual baseline exceeds €29 million. The 3 to 4 percent figure sometimes circulates because Oracle occasionally offers negotiated multi-year pricing caps for large accounts — but these are exceptions, not the default, and they typically apply for limited periods before reverting to the standard 8 percent escalator.
Myth 10
"Oracle can only audit us once every X years under the contract."
Fact: Oracle's standard licence agreements typically contain audit rights that allow Oracle to audit a customer's compliance at any time with reasonable notice — commonly defined as 45 days. There is no standard contractual limitation restricting Oracle to one audit per year or once per multi-year cycle. Some organisations negotiate audit frequency limitations as part of larger commercial agreements, but these are explicit contractual provisions that must be agreed and documented. The absence of such a negotiated provision means Oracle's audit rights are broad and can be exercised at Oracle's discretion. Oracle's LMS team prioritises targets based on intelligence from sales teams, partner reports, usage data from Oracle's own products, and public information about technology deployments — and will exercise audit rights when they believe a compliance conversation is likely to result in incremental revenue.
What These Myths Have in Common
Looking across these ten myths, a pattern emerges. Most of them are directionally correct in a simplified version of the world — virtualisation does reduce physical hardware requirements, cloud providers do handle some licensing aspects, Oracle's perpetual licences do last forever — but they fail at the boundary conditions where Oracle's licensing rules are specifically designed to create additional obligations.
Oracle's licensing framework is not merely complex — it is asymmetrically complex. The rules that generate additional licence obligations are precisely specified and strictly enforced. The rules that might reduce obligations (hard partitioning, authorised cloud environments, legacy licence coverage) are narrowly defined and require active management. An organisation that understands the obligation-generating rules but not the obligation-reducing mechanisms is systematically over-paying. An organisation that understands neither is systematically non-compliant.
The organisations that navigate Oracle licensing most effectively treat it as a discipline requiring continuous expertise — not a one-time exercise at procurement. They maintain a current understanding of Oracle's published policies, engage independent advisory for major licensing decisions, and run proactive compliance assessments before audit notifications arrive.
Oracle Licensing Intelligence
Quarterly updates on Oracle licensing changes, audit trends, and myth corrections from our ex-LMS advisory team.