Licensing Oracle on VMware - Everything You Should Know

Is licensing Oracle on VMware complicated?​

It’s really not. When it comes to running Oracle technology products on VMware virtualized infrastructure, there are many conflicting reports about what is allowed, and what will cause the customer undue financial risk from an Oracle audit. Most of these Oracle on VMware directions, whether delivered innocently or with intent to benefit from misinformation, are not valid. What this means is that most opinions on the subject are not compatible with the customers’ actual Oracle license agreements.


It is imperative that customers understand what is in the actual Oracle software license agreement, and structure their usage and product governance accordingly. House of Brick specializes in understanding the actual contractual obligations of customers, and how to force Oracle to comply with the contract(s).

What is the most important document to understand about Oracle licensing?

The Oracle license agreement. The license agreement is what governs product usage; other statements outside of the agreement do not.


  • The newer license agreements are issued under an Oracle Master Agreement (OMA). A template of this agreement can be found in Oracle’s contract repository.
  • Older license agreements may have been called Oracle License and Services Agreement (OLSA), or Software License and Services Agreement (SLSA).
    • The older agreements tended to have all contractual language contained in the single agreement file.
    • The newer OMAs are largely a template of boilerplate language for various purchase types (i.e., Hardware, Programs, Cloud, etc.).
      • The more specific definitions, and license rules have been moved to externally referenced documents, or to the Ordering Document outlining the particular purchase details.

Is there anything that can prevent Oracle from introducing new, more restrictive terms at will?

The Entire Agreement clause. Each Oracle software license agreement contains an integration clause entitled, “Entire Agreement.” Integration clauses are standard in most legal agreements, but it has particular bearing on the topic of installing and licensing Oracle technology products on VMware virtualized infrastructure.

In the license agreement located in Oracle’s document repository, the Entire Agreement clause is in Section 9.  It states:

You agree that the Master Agreement and the information which is incorporated into the Master Agreement by written reference (including reference to information contained in a URL or referenced policy), together with the applicable order, are the complete agreement for the Products and/or Service Offerings ordered by You and supersede all prior or contemporaneous agreements, proposals, negotiations, demonstrations or representations, written or oral, regarding such Products and/or Service Offerings.”

Based on this contract language, anything that is not included in the Master Agreement or product order, or specifically referenced by those two documents, is not part of the binding agreement. This also excludes verbal or even written representations by Oracle sales personnel before or during the sales process.

What are the Oracle documents that are actually contractual?

In order to establish the rules for how Oracle technology products should be licensed on VMware infrastructure, we need to explore the various documents referenced by the Master Agreement. Here are the key documents that comprise the scope of the applicable terms and conditions. We show where the reference to the document is found, and if it is external, a link to where it can be found:


Important things included in Technical Support Policies


  1. License Set definition
  2. Matching Service Levels definition
  3. Process for Reinstatement of Oracle Technical Support
  4. Pricing Following Reduction of Licenses or Support Level (repricing remaining support after terminating support on certain licenses).
  • Program Documentation
    • Program documentation is specific to which products are ordered in the Ordering Document (e.g., Database Enterprise Edition).
    • While most product documentation can be found at the Oracle Help Center site other documents may also be considered Program Documentation according to the definition in the OMA. This might include My Oracle Support (MOS) notes published regarding the technology, support, installation, or licensing of particular products. MOS notes are not public documents, but each Oracle customer has access to these notes by logging on to the My Oracle Support portal.

What are examples of non-contractual documents?

We’ve already covered the documents that are contractual, but here are some of the documents that are not part of your contract that frequently come up in discussions with Oracle. Oracle publishes many documents that are intended to be educational resources, although Oracle also attempts to use them to restrict or grant additional privileges. Oracle has no right to restrict privileges based on non-contractual documents.


However, sometimes Oracle makes extra-contractual grants of additional rights that are not contained in your contract, via non-contractual documents. In our experience, and as a result of consultation with law firms, you can safely on extra-contractual grants of rights as long as they exist in the documents.


We frequently see Oracle try to use this document to restrict clients’ means of limiting their Oracle processor-based liabilities. The argument is usually along the lines of “the only technologies Oracle recognizes for partitioning are documented in the Partitioning Policy”. Oracle does, via this same policy, grant you the extra-contractual right to leverage certain partitioning methods (i.e. LPARs) to limit the number of processors you need to license.


Colloquially known as Oracle’s “cloud policy”, this document grants you the right to license certain Oracle products on a vCPU basis in AWS and Azure.


A framework for Oracle technology hosting and proprietary application hosting.


Is there a summary of the Oracle documents that I may encounter when considering a VMware deployment?

The following table is provided as a helpful reference to which documents published by Oracle are contractual, and which are non-contractual. For those non-contractual documents, we also list whether they grant extra-contractual privileges, or whether they attempt to restrict the customer’s privileges in a non-contractual way.


Oracle Document Contractual Grants Privileges Attepts to Restrict Privileges
Oracle Master Agreement (or other license agreement name)
Ordering Document
License Definitions and Rules
Technical Support Policies
Program Documentation

What does the license agreement allow a customer to do?

The license agreement, including the contractual ordering document, defines how the purchased products are to be licensed. Each ordering document will list the product(s) purchased and will designate other critical information, including:



  • Term of the license (perpetual or 1-year term)
  • License metric (Processor or Named User Plus)
  • The quantity purchased
  • Full-use or Limited-use
    • If Limited-use, the ordering document will include a description of the limit. This information is typically not included in subsequent support renewal documents.

What do the different licensing metrics mean?

For Oracle technology products (database, middleware, legacy Java subscriptions, etc.), the licensing metric is either Processor or Named User Plus.


The definition of “Processor” is required to determine what needs to be licensed for both the Processor and Named User Plus metrics. This definition is found in the License Definitions & Rules document:



  • Processor: shall be defined as all processors where the Oracle Programs are installed and/or running.
  • The threshold for requiring a license is that it is installed, whether that software is running or not.

NUP licenses have a per-Processor minimum number of licenses that must be applied, so they are Processor dependent as well.



The agreement does not allow for other metrics, such as vCPU, which is discussed further below. The license agreement also has no provision for requiring licenses for cores and servers where the software is not yet installed, but may or may not be in the future. This is the key to refuting Oracle claims that all VMware hosts, regardless of whether they have Oracle software installed on them or not, must be licensed. We explore this further in the following sections.


Does the Oracle agreement cover every situation?

Any legal agreement cannot, of course, describe every possible condition that a party to that agreement may or may not encounter in the course of their interaction. It therefore describes the conditions under which the parties must behave in order to remain compliant with the terms of the agreement.

If the agreement is silent on something, does that mean that I can go ahead and do whatever I want?

Not necessarily. If the agreement is silent on a topic, but doing that thing causes you to breach the agreement, then you are not allowed to do it.

An example of this is licensing by virtual CPU (on-premises or in the cloud). The agreement is silent on that practice, but counting virtual CPUs for licensing breaks compliance with the Processor license metric that is contractually defined as the physical processor cores on which the software is “installed and/or running.”

Oracle’s cloud licensing policy is a non-contractual document, but as described above, it grants the use the right to count vCPUs for licensing under certain conditions.

  • Because these grants of permission are non-contractual, Oracle may (and has) change them at any time.
  • Thus, there is certain risk inherent in basing business decisions on these non-contractual statements.

What are some examples of topics that the Oracle agreement is silent on?

The following list contains popular topics in which the Oracle license agreement is silent. These often confuse VMware customers:


  • Server Virtualization
  • Container Virtualization
  • Hard Partitioning and Soft Partitioning
  • Automatic workload relocation or live migration (e.g., vmotion)
  • vCPU’s
  • Clustering
  • Core disablement
  • Network isolation
  • Storage isolation
  • Cloud usage

Does our VMware architecture have to receive Oracle approval?

If your deployment is in full compliance with the license agreement, then the particular methods of your deployment cannot be restricted by silent (or non-contractual) means. An example of this is running in an on-premises VMware cluster.


If the virtual machines running an Oracle product are in a cluster, and all the cores on all the physical hosts in that cluster are licensed for that Oracle product, then the contract is silent on how the cluster should be configured, or the virtual machines contained. Contrary to Oracle sales or LMS assertions, there is no contractual definition for how a virtual machine must be isolated or contained. We simply default to where it is “installed and/or running” and not on what it might or might not do in the future.

But what about the possibility of a virtual machine moving out of the cluster?

If a virtual machine running an Oracle product moves to an unlicensed host, then it is not in compliance with the license agreement. It is therefore critical that the customer implement some means of virtual machine containment AND monitor the VMs to ensure that they never breach that containment. If virtual machines with Oracle software installed on them are not contained, then it creates a huge potential liability for that customer.

Why would I run Oracle technology products on VMware virtualized infrastructure?

The VMware hypervisor allows customers to install a virtual layer on a physical server and then install one or more virtual servers on that single host. Most physical servers are idle for most of the time. This varies by what is running on it, but it is not uncommon for a server to be idle for 85% or more of its operating cycles. Server virtualization allows the physical resources of that host (CPU, memory, etc.) to be shared so that the resources are more fully utilized without negatively impacting the performance of the various guest virtual servers.


Since Oracle is licensed according to the physical processors in a server, it is a smart decision by the customer to get the most possible out of that expensive license investment.

How do you interpret the License Agreement for running Oracle technology products on VMware virtualized infrastructure?

Oracle tries to make this a complex topic, but it’s fairly simple. Keeping in mind Oracle’s definition of “processor”, if an Oracle product is installed on a physical server, then that server must be licensed. If no Oracle product is installed on a physical server, then there is no liability, even if the physical server is in the same VMware cluster as other physical machines that do have Oracle products installed.

In a VMware environment, we consider Oracle to be installed if, with no extra configuration steps, you can boot up a VM with Oracle installed and login. So, the VM has to be in the vSphere inventory and associated with a physical machine. Since the VM is stored on shared storage, it matters which physical server the VM is currently registered to. If the files for a VM exist on shared storage, but the VM in not in the vSphere inventory, any Oracle software in that VM is not installed, therefore no Oracle liability exists.

We have validated through experimentation and by discussing the issue with VMware engineering leaders, that a single VM will never be running on two hosts at the same time. Not even a single clock cycle. This has a license implication in that if a single host is licensed for an Oracle product, and is running only one VM, then if and when that VM moves (via manual or automated means), the Oracle software is being uninstalled and reinstalled on the target machine.

As long as the target machine has the same or lower configuration of physical cores, the license effectively follows that VM with Oracle software to the new host.