Increasingly, companies are considering outsourcing datacenter workloads to third-party hosted or cloud environments. Software publishers like Oracle are not only publishing guidance on how to count licenses that are installed in a third-party cloud environment, Oracle is also offering its own cloud solutions to customers. Although moving the Oracle products to third-party cloud environments may result in initial hardware savings, failing to understand the licensing rules for these environments can ultimately lead to costly licensing mistakes.
Licensing Oracle in the Microsoft or Amazon Clouds
The primary concern related to licensing Oracle in non-Oracle cloud environments is how many licenses a customer needs to cover the installations in the third-party’s cloud.
In early 2017, Oracle issued a policy statement dedicated to helping customers better understand how to license Oracle products when the customers access the products via Amazon’s or Microsoft’s cloud services. You can review Oracle’s policy at http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf . Oracle’s policy document describes these environments as “Authorized Cloud Environments.” Oracle identifies Microsoft’s Azure and Amazon’s Elastic Compute Cloud (“EC2”) and Amazon’ Relational Database Services (“RDS”) as the only Authorized Cloud Environments. This policy applies to a number of Oracle products, including but not limited to the BI Suite, all editions of Database, Hyperion, and WebLogic.
According to the policy, customers are required to license Authorized Cloud Environments 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.
Because no other approved cloud vendors are identified in the policy, if a customer is currently accessing Oracle products via the cloud in non-Microsoft, non-Amazon, or non-Oracle environments, that customer should carefully review its licensing terms to determine whether installing in that third-party cloud environment is allowed. Because the published guidance is vendor-specific as outlined above, it may be difficult to determine how to count cores or CPUs on non-approved cloud environments.
Those who are already familiar with calculating the required Oracle licensing for processor-based products may be wondering which of the core factors from the Core Factor Table would apply to the Authorized Cloud Environments. Oracle’s answer is clear – “the Oracle Processor Core Factor Table is not applicable” to any licenses used for products accessed via Authorized Computing Environments. This could have a potentially significant impact on Database Standard licensing, in particular, because Oracle has indicated that Database Standard can only be licensed on up to 16 Amazon vCPUs or 8 Azure CPU Cores.
Additionally, Oracle instructs customers that for any product that contains Standard Edition One, Standard Edition 2, or Standard Edition in the product name, that four Amazon vCPUs count as one socket and two Azure CPU Cores also count as one socket.
Importantly, Oracle also limits the availability of support services to customers using larger Authorized Computing Environments. Both Basic Limited and Premier Limited Support are not available to customers using Authorized Computing Environments containing more than 8 Amazon vCPUs or 4 Azure CPU Cores.
For customers who want to use their Oracle Unlimited License Agreements (“ULA”) to license their Authorized Computing Environments, Oracle expressly grants permission in the policy to use ULA licenses for cloud instances of Oracle products. However, at the end of the ULA term, ULA customers may not include these licenses used for cloud products in their certifications. If a customer is not able to certify the use of unlimited licenses at the end of the ULA term, those licenses are not included in the customer’s license inventory after the expiration of the term.
If a company began a ULA using on-premises deployments and then outsources a large portion of its Oracle products to a third-party cloud, the ramifications could be significant. The company will not be able to certify the use of any of its ULA licenses used in the third-party cloud, and will potentially have to purchase new licenses at the end of the ULA to cover the cloud environment. It is therefore critical to understand the interplay between the ULA and Authorized Computing Environments.
As is often the case with Oracle, licensing in the cloud may be allowed, but it is not necessarily advisable. Customers should also consider what, if any, attention they should pay to the fact that the policy is not expressly incorporated into their agreements with Oracle.
Licensing Oracle in the Oracle Cloud
For customers considering moving some or all of their Oracle products into Oracle’s cloud, the most common concern is whether all of the customers’ use cases are covered by the standard agreements. Oracle typically licenses its cloud environment using Oracle’s Cloud Services Agreement (“CSA”). It is critical for customers contemplating a move to Oracle’s cloud to review the CSA and determine whether the terms contained in the CSA are appropriate, given how the customer intends to use the products.
Many customers struggle with several of the provisions in the CSA, including the limitation of liability, indemnification, and the protection of the customer’s content sections. Although it is always essential for customers to understand these provisions in their licensing agreements, it is now particularly important because sensitive corporate data may reside on Oracle’s cloud. The customer must balance the nature and the value of the data residing on Oracle’s cloud with the protections Oracle is willing to give.
Customers are also often concerned about the number of cross-references in the CSA to other Oracle documents. They complain that it is difficult to keep track of requirements that are not contained within the agreement itself.
Finally, it is often difficult to find an opportunity to address a customer’s concerns about the terms of the CSA. There is frequently pressure to complete a transaction by a particular date, and customers don’t always realize that it can take several weeks or months to meaningfully communicate with Oracle about the CSA. In any transaction involving a CSA, customers should ensure that their transaction timeline includes sufficient time to review the proposed documents, identify concerns, and discuss those concerns with the appropriate Oracle team before there is a crisis to complete the transaction.
Customers who are moving their Oracle products to third-party cloud environments, including Microsoft, Amazon, and Oracle need to take the following steps:
- Understand how the customer will use Oracle products in third-party clouds;
- Compare Oracle’s relevant licensing policies for each of the contemplated cloud environments;
- Calculate the true cost of moving to the cloud, including any ULA benefits that may be lost; and
- Ensure that the customer does not run afoul of the requirements in its Oracle licensing agreements.
Julie leads a team of attorneys in representing a defending clients in legal matters relating to information technology. Her practice focuses on complex litigation ranging from privacy and network security, data breach notification and crisis management, intellectual property disputes, service provider negligence claims, and content-based injuries such as copyright and trademark infringement in software, the Internet and all forms of tangible media.
Her focused practice has made Julie a trusted resource in her field, often invited to submit papers on present topics including data breach notification, security incident response, and defending against regulatory and consumer class actions.