Oracle recently released an update to the policy document that outlines the rules for licensing their core technology software in what they term “Authorized Cloud Environments” and the rest of us know as the main hyperscale cloud computing providers. This includes AWS, Azure, and (newly) GCP. Any organizations using Oracle software in a cloud environment should keep careful track of this document as it in most cases governs the licensing rules for Oracle software that clients should adhere to if they wish to avoid a costly surprise in an Oracle licensing audit.
What has changed?
The latest update to the document, the June 12th, 2024, update, contains very little change from the previous version. The main change is to make it explicit that Google Cloud Platform (GCP) is covered by the document and provide additional examples to clarify GCP licensing scenarios. This is a welcome change for customers wanting to run Oracle software in GCP as previously it was difficult to do.
What is this document?
For those unfamiliar with this document and its import, a brief history lesson may be in order. Oracle software, such as their popular RDBMS platform, has traditionally been licensed on a Named User or Processor metric. Because the Named User metric also ties back to processors with per-processor minimums, being able to identify the number of physical processors and cores in any server running Oracle software has always been a key to staying license-compliant and avoiding unpleasant Oracle licensing audit scenarios. With the rise of public cloud computing Oracle customers faced the unpleasant reality that they may not be able to identify which physical processors corresponded to their Oracle workloads and the implied ambiguity, coupled with Oracle’s reputation for aggressively enforcing licensing via painful audits, left a lot of customers looking for alternative software as they contemplated moves to the cloud. Fearful of customers jumping ship to their competitors, Oracle published the document which provides alternative licensing rules that can be used in AWS, GCP, and Azure to license Oracle software by virtual CPU (vCPU) metrics instead of physical processor metrics.
Why does it matter?
This document has offered a reliable way for organizations using Oracle software in a public cloud environment to license by vCPU. While not covering all Oracle software, the included list covers most software that customer may want with the noticeable exclusion of the Oracle Real Application Clustering features for the Oracle database. The document is explicitly non-contractual, but House of Brick has extensive experience with Oracle respecting and honoring the terms of the document during license audit. The only issue of concern to many organizations is that Oracle can and will update the document every few years, and typically the updates are to the benefit of Oracle and not their customers. Thus, tracking changes in this document is vital to organizations relying upon it for licensing Oracle software in a cloud environment.
What are the key clauses to note in this document?
The document is relatively short and straightforward, but there are a few traps for the unwary that aren’t very clearly called out in the document. The first of these is found in the footer which states:
This document is for educational purposes only and provides guidelines regarding Oracle’s policies in effect as of June 12, 2024. It may not be incorporated into any contract and does not constitute a contract or a commitment to any specific terms. Policies and this document are subject to change without notice. This document may not be reproduced in any manner without the express written permission of Oracle Corporation
While that looks boilerplate legalese the implications are quite important. By explicitly stating that the document is non-contractual it means that the contractual language in an Oracle Master Agreement (OMA) or specific language in ordering documents trumps it every time. This document is only “policy” and while Oracle has been frequently seen to assert that their policy is binding on clients it is most assuredly not. This document contains some nice rights for Oracle customers but is not strictly required to use Oracle software in a cloud environment.
The next clause of interest is the explicit exclusion of the Oracle core factor table:
When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.
It is well within Oracle rights to exclude the normal contractual licensing rules when offering an alternative, so this is an understandable if a bit painful exclusion. The core factor table typically allows on-premises x86-64 servers to count every two cores as one license. The omission of it in the cloud means that 2 hyperthreaded vCPU, equivalent to one x86-64 processor core, is one processor license. The exclusion, by Oracle, of the processor core factor table from this document is the source of Oracle’s often cited “doubling” of licensing costs when moving to the cloud.
Another important piece of verbiage that’s easily missed is found in the first sentence of the second paragraphs which includes the phrase:
customers are required to count the maximum vCPUs of an instance type as follows
The “maximum vCPUs” is critical as it precludes reducing the number of vCPUs on cloud compute instances using features such as AWS Optimize CPU or similar. Disabling vCPUs does not reduce licensing requirements and thus is inadvisable. When architecting cloud solutions for Oracle software, it is important to look at all the available compute instances from a cloud provider to find the right mix of vCPU, available RAM, and disk I/O to find a solution that optimizes both performance and licensing.
There’s quite a bit of verbiage in the latter half of the document about licensing Oracle Standard Edition (SE) or the SE1/SE2 variants which are normally licensed by processor sockets in on-premises environments. While this section stretches on for paragraphs, it really boils down to a limitation that every four vCPU counts as a virtual processor “socket” for licensing Oracle SE/SE1/SE2. The current Standard Edition database offering from Oracle, Oracle Database SE2, is limited to a maximum of 8 vCPU when licensing by the metrics offered in this document. It should be noted that the section on Standard Edition licensing makes no mention of hyperthreading, so disabling hyperthreading to get the maximum performance from each vCPU is desirable with Oracle Database SE/SE1/SE2.
The last bit, which is a touch puzzling, is the mention of ULA certification at the end of the document. This section reads
Licenses acquired under unlimited license agreements (ULAs) may be used in Authorized Cloud Environments, but customers may not include those licenses in the certification at the end of the ULA term.
House of Brick is unsure why Oracle felt this was worthy of inclusion as ULA agreements are contracts (or amendments to contracts) on their own. As previously discussed, this policy document is explicitly non-contractual and thus cannot influence or impact the rules for ULA certification. This language should be disregarded entirely unless it is also in the governing ULA contract that an organization has with Oracle.
