On January 23, 2017, Oracle stirred up a storm in its user community by announcing a significant change to its licensing policy in third party cloud environments. With this unilateral pronouncement, Oracle effectively doubled the price of moving traditional on-premise Oracle licenses to Azure and AWS. This policy updated a prior version of the policy that was similar, except that the old policy did not negate the Core Factor table. In this post, we will take a closer look at the policy, it’s implications, and how to deal with it in a methodical and contractually defensible way.
It’s a “policy”, not a contract.
Before starting at the beginning of the document, I will start at the very end – the small-font footer. It reads, in part, as follows:
This document is for educational purposes only and provides guidelines regarding Oracle’s policies in effect as of January 23rd, 2017. It may not be incorporated into any contract and does not constitute a contract or a commitment to any specific terms.
Put simply, the policy document is contractually meaningless. Oracle has made it explicitly clear that it may not be incorporated into an agreement. Even if the above disclaimer was not included in the document, it would still be contractually meaningless. Your signed contract is the only authority on your licensing commitment with Oracle. In my experience, I have not come across any Oracle agreements (OLSAs, OMAs, ULAs, etc.) that include any language similar to what is stated in the policy.
So, is this policy document entirely inconsequential? It depends (more on that later). But having a firm understanding of the document, and its implications, is important. Given that Oracle is pushing its own cloud agenda aggressively, any existing Oracle customer moving to other vendors ought to have a good understanding of Oracle’s view of things. It’s an important first step to effective planning and methodically dealing with Oracle if (when?) this topic comes up.
Let’s go over the key points of the policy.
1. Approved Vendors
The policy seems to apply to “Approved Vendors” – Amazon Web Services and Microsoft – only. Their cloud offerings – AWS’s EC2 and RDS, and Microsoft’s Azure, are referred to as “Authorized Cloud Environments”. It’s not clear if there are any obvious benefits to being an “approved vendor” (other than being targeted by this policy), or if there are any disadvantages to not being an “approved” vendor. Contractually, there is no reason to believe that moving your Oracle on-premise licenses to other cloud vendors like Google Cloud Platform would constitute any violation or result in license compliance issues. Unfortunately, I have heard from many customers that have fallen for this FUD (fear, uncertainty, doubt) tactic and have been led to believe that deploying their existing Oracle licenses into un-“approved” vendor environments somehow results in a license compliance issue.
2. The Core Factor…and its elimination.
The single most controversial part of the policy is the elimination of the processor core factor that is used in calculating “Processor” license requirements. The policy states:
For the purposes of licensing Oracle programs in an Authorized Cloud Environment, customers are required to count as follows:
- Amazon EC2 and RDS – count two vCPUs as equivalent to one Oracle Processor license if hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyper-threading is not enabled.
- Microsoft Azure – count one Azure CPU Core as equivalent to one Oracle Processor license.
When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.
Given that the Core Factor for most multi-core chips is 0.5, it normally reduces the Processor license requirement to half the number of cores. By not applying the Core Factor, per Oracle, customers need twice as many Processor licenses in the cloud to cover the same number of cores as on-premise. For further details on cores, virtual cores, and hyper-threading in cloud environments, refer to this article. What makes this aspect of the policy especially unusual, to say the least, is that it appears to negate a contractually defined component. Applying the Core Factor Table is part of the contract (in the “Processor” definition). One wonders what the motivation was for Oracle to issue a policy that goes contrary to contract language.
Separately, for socket-based programs like Database Standard Edition, SE1, and SE2, Oracle has revised its position from the prior policy and reduced the number of virtual cores that equate to an occupied socket. Arbitrarily, 4 vCPUs in AWS and 2 virtual cores in Azure correspond to an occupied socket. Note that in the older cloud licensing policy, it was 4 virtual cores corresponding to an occupied socket. In AWS, that was 8 vCPUs (due to hyper-threading) and 4 virtual cores in Azure. Consequently, this also reduces the maximum number of AWS vCPUs and Azure virtual cores where SE, SE1, and SE2 programs may run.
3. Exclusion from Unlimited License Agreement (ULA) certifications.
The other very significant edict relates to ULA certifications. Per the policy, while customers may deploy their ULA programs in AWS and Azure, they may not include these numbers in their ULA certifications. The document states:
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.
As a result, a large company with substantial Oracle deployments in AWS and/or Azure stands to leave tremendous value on the table due to not being able to include those deployments in the certification. Instead, those deployments will effectively become compliance liabilities requiring immediate purchase or uninstallation. This part of the policy is clearly very challenging and intimidating for the large enterprise customers that have come to rely on Oracle’s ULAs as a means of licensing their large and/or high growth environments. It’s important to note that Oracle’s previous policy on cloud licensing also had this exclusion for ULA certification.
4. Policy for Oracle VM in AWS EC2 environments.
A section in the old policy read, in part, as follows:
Amazon has implemented Oracle VM EC2 instances in accordance with the practices defined in the Oracle policy document…From an Oracle product licensing point of view, this means that each virtual processor is equivalent to a physical core, and the standard Oracle Processor metric definition applies.
This section of the old policy was very reasonable. Perhaps too reasonable – the new policy has completely removed this section. I am not aware if AWS has made any changes to its implementation, or if this was yet another arbitrary change to the policy from Oracle’s side.
Back to the important question – is this policy inconsequential?
Many years ago, Oracle issued a licensing policy for virtualized environments. The net effect of the policy was that it made it a lot more difficult and expensive to run Oracle software in non-Oracle virtualization technologies like VMware and Hyper-V. This policy was, and still is, just a “policy” and contractually meaningless. However, this has not prevented Oracle from aggressively pursuing this policy and extracting what must be significant compliance revenue from unsuspecting customers. You had to be savvy customer with a firm grasp on Oracle contracts and agreements to run Oracle in VMware and survive an audit unscathed. Even a successful lawsuit against Oracle has not prevented it from still pursuing its virtualization policy (Oracle & VMware: Part I – Mars Vs. Oracle).
I’d venture a guess and say that Oracle has a lot more riding on the “cloud wars” than it did on the virtualization front over the last decade or so. Oracle is pushing its current customer base to its cloud, and license audits are an effective supporting tool. This policy appears to strengthen the auditor’s hand.
A Methodical Approach
Whether or not this policy is inconsequential depends on… you, the customer. Understanding your contracts and having a well thought out game plan is important. Below are some of the key points to keep in mind as you develop your Oracle-in-the-cloud strategy:
- As yet another reminder, this document is a policy and should have no role in your discussions with Oracle.
- Ensure you understand all of your relevant licensing metrics as they are defined in your contract, including the “Processor” metric.
- Consider limiting and strictly controlling information your company shares with Oracle sales and auditors, especially details around cloud and virtualization.
- For whichever cloud vendor you consider, make sure you have a firm grasp on differentiating between vCPUs, virtual cores, hyper-threading, etc.
- Remember that counting cores and processors correctly is only one aspect of maintaining compliance in the cloud.
- There are several things to keep in mind regarding ULA certifications. Firstly, there is no contractual reason to not count cloud deployments in your ULA certification. Secondly, for the ULA certification, you are not required to share any environment details, server names, virtualization configurations or cloud deployment details with Oracle. The certification process does not entitle Oracle to anything other than a signed piece of paper with usage quantities. Do your ULA certification homework carefully; you should not let Oracle turn a ULA certification into essentially an audit (Oracle ULAs – Lost Value and Compliance Risks).
The above are just some of the key points to keep in mind as you move to the cloud and navigate your way around Oracle’s cloud policy.
On a final note, you have to wonder how one can do business with an entity that issues contractually meaningless “policies”, and then updates them as and when needed without a clear explanation as to why the changes are being done. As I have stated previously, like any other Oracle customer, you should consider all cloud options and let the decision making be driven by best-fit and how things fall in line with your strategic plan, and not be driven by arbitrary dictates in the form of “policy” pronouncements from Oracle – announcements that attempt to limit your cloud options.
Over the next few posts, we will take a closer look at Oracle compliance and cost considerations in AWS RDS, AWS dedicated hosts and dedicated instances. Stay tuned.