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).
The Oracle license agreement. The license agreement is what governs product usage; other statements outside of the agreement do not.
Â
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.
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
Â
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.
Â
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) |
Yes |
|
|
|
Ordering Document |
Yes |
|
|
|
License Definitions and Rules |
Yes |
|
|
|
Technical Support Policies |
Yes |
|
|
|
Program Documentation |
Yes |
|
|
|
No |
Yes |
Yes |
|
|
No |
Yes |
No |
|
|
No |
No |
No |
|
|
No |
No |
Yes |
|
|
No |
No |
Yes |
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:
Â
Â
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:
Â
Â
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.
Â
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.
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.
The following list contains popular topics in which the Oracle license agreement is silent. These often confuse VMware customers:
Â
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.
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.
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.
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.
House of Brick Technologies LLC © 2024
