Licensing Oracle Software in a Third Party’s Cloud
Many companies would like to know whether and to what extent their existing Oracle software product licenses entitle them to use that software in a third-party cloud-hosting environment – such as Amazon Web Services’ (AWS’s) Elastic Compute Cloud (EC2) environment – and, if so, whether that usage would be subject to different license metrics or other restrictions that would not apply to the use of that software in their own datacenters.
Oracle’s standard license agreements typically do allow licensees to use their software licenses to support deployments of that software on a third-party’s servers. Standard contract language typically includes something like the following:
You may allow Your agents and contractors (including, without limitation, outsourcers) to use the Programs and deliverables for Your internal business operations and You are responsible for their compliance with the General Terms and this Schedule P in such use.
In many instances, the question is not whether a company may use its licenses within AWS’s EC2 environment, but rather how many licenses are required in order to support that usage.
Oracle’s standard licensing rules – which usually are incorporated by reference in the Ordering Documents used to memorialize the acquisition of Oracle product licensing, include the following definition:
Processor: shall be defined as all processors where the Oracle programs are installed and/or running…The number of required licenses shall be determined by multiplying the total number of cores of the processor by a core processor licensing factor [specified by Oracle on its website].
The SLSA and Ordering Documents do not explicitly address how to apply that definition in a virtualized computing environment, where a server with a certain number of virtual cores may run – or may have the ability to run – on one or more physical hosts. However, a reasonable interpretation of the above language is that only the physical cores actually used by a VM running an Oracle product, and not all physical cores within the larger virtualization environment, must be licensed for that product.
However, Oracle has published a “policy” document on its website, titled “Oracle Partitioning Policy | Topic: Server/Hardware Partitioning” (the “Partitioning Policy”). The Partitioning Policy purports to elaborate upon Oracle’s standard requirement that licenses be purchased in connection with “processors where the Oracle programs are installed and/or running,” to require that all physical processor cores on all hosts in certain virtualization environments be licensed for an Oracle product that is used anywhere within those environments (even on a single virtual server running on a single physical host within a multi-host environment). Our understanding is that the technology AWS uses to provide the AWS EC2 environment is not among the technologies identified in the Virtualization Policy that Oracle has approved for avoiding the all-processor-cores requirement that the policy otherwise would purport to apply.
In addition, Oracle also has published a separate “policy” document on its website, titled “Licensing Oracle Software in the Cloud Computing Environment” (the “Cloud Policy”). The Cloud Policy purports to apply to the usage of Oracle products in AWS’s EC2 environment (among a couple other cloud environments), and it specifies that certain kinds of licenses for Oracle products deployed in AWS EC2 environments where processor hyper-threading is enabled essentially have one-half the value of the same kinds of licenses for the same products, when those products are deployed in a licensee’s own datacenter.
While Oracle’s license agreements and Ordering Documents typically do incorporate by reference certain supplemental or ancillary policies (such as Oracle’s technical support policies, which are explicitly referenced), they most commonly do not reference either the Virtualization Policy or the Cloud Policy. Furthermore, there is nothing in most license agreements or Ordering Documents that would allow Oracle to unilaterally amend the parties’ agreements merely by publishing a policy on its website.
The principal risk associated with complying with the Cloud Policy is that Oracle could decide in the future to change the policy, potentially resulting in increased licensing costs for affected Oracle product deployments. If the Cloud Policy is not incorporated in the agreements with Oracle, there is nothing that would prevent Oracle from taking such action in the future. Therefore, it would make sense to have written confirmations (1) that the current Cloud Policy will apply to usage of any and all licensed Oracle products in the AWS EC2 environment, (2) that if Oracle subsequently releases a more favorable version of the Cloud Policy, that policy, and not the current policy, will apply going forward, and (3) that if Oracle subsequently releases a less favorable version of the Cloud Policy, that policy will not apply unless and until the licensee either materially increases its usage of Oracle products in the AWS EC2 environment or explicitly agrees to accept the new policy.
Our experience is that Oracle licensing is fraught with challenges and potential pitfalls, and we strongly urge business contemplating any virtualized or third-party-hosted usage of Oracle software to work with counsel and knowledgeable licensing consultants in an effort to mitigate the risk of compliance exposure.
