Death, Taxes and Oracle Compliance Audits

Death, Taxes and Oracle Compliance Audits

Peter Goldthorp, Dito. June 2022

Benjamin Franklin rarely spoke on the subject of Oracle license compliance audits

“In this world nothing can be said to be certain, except death and taxes and Oracle license compliance audits.”

Oracle license compliance audits

Okay, Benjamin Franklin probably did not say that in 1789 but he might have done if he was alive today. It’s an established pattern at Oracle. Start with an expensive list price and offer steep discounts to close the sale. Allow the customer to download and install software with few checks on license compliance (license keys, etc). Return to the customer a few years later and audit their usage. Identify items that are out of compliance. Negotiate new contracts using the full list price for each item as a start point.

License compliance audits are a major revenue driver for Oracle. It’s not unusual for customers to find themselves negotiating with Oracle over how to pay for software that they never intended to buy. Honest errors can have expensive consequences. A developer may make use of a database feature without realizing it is licensed as an extra cost option or an IT director may order replacement hardware for an end of life server that has more cores than the original. Compliance audits can be hugely disruptive and their findings expensive.

One good thing about Oracle audits

There is however, one good thing about them. Oracle will notify you before they conduct one. They don’t have direct access to your on premises environment. They need your cooperation to audit it. Each Oracle contract has a provision that allows Oracle to audit the customer’s environment. This provision will include a notice period of 30, 45 or 60 days. This defines an amount of time that Oracle is contractually obliged to provide the customer to prepare for an audit¹.

Many Oracle customers like the separation from Oracle they can achieve by running their workloads on-prem or in a colocation facility. A large number would like to reduce or eliminate Oracle license costs and see migration to the cloud as an opportunity to do that.

Migrating 1990’s software to the cloud

Migrating to the cloud does provide an opportunity to remove Oracle dependencies but not overnight. While many workloads can “lift and shift” to the cloud with minimal effort, Oracle workloads present unique challenges. They often require certified hardware plus expensive licensing and support agreements. Oracle databases are often associated with legacy systems that need to be rewritten to take full advantage of cloud resources. They typically follow design patterns from the 1990’s or early 2000’s. These assumed the software would run on dedicated hardware for years with minimal changes. The database may act as an integration layer for multiple sub-systems, a pattern referred to as a monolithic architecture.

Cloud native applications follow a different design pattern. They utilize containerization, fast deployment methods, on-demand computing power, and automation. Compute resources are allocated to a task on demand and returned to a pool when no longer needed. This requires the sub-systems in a monolithic application to be refactored as microservices. Microservice best practice calls for each service to maintain its own data store. Different services have different data storage requirements. For some, a relational database is the best choice. Other services might need a document store or NoSQL database.

For transactions processing applications with Oracle databases at the backend, companies should consider the full set of cloud migration options: from application rewrite, SaaS alternatives, or moving to cloud native databases like BigQuery and CloudSQL. Modernizing the existing IT architecture will require time and effort and also the need to keep the Oracle databases running during the transformation period. During this time the monolith and its cloud native replacement will need to coexist. Business critical systems need to be kept running. This means continuing to run the old systems while developing or implementing new ones. In many cases the simplest way to do this is to run both systems in the cloud while working on the transition. This can be complicated by Oracle’s licensing policies which are skewed to favor Oracle’s cloud.

Bring your own license (BYOL) to the cloud

Bring Your Own License or BYOL is a term used by cloud service providers to identify services that do not include a software license in the price. The customer must purchase a separate license or transfer one that they already own. This is an attractive option for many Oracle customers. Canceling current Oracle licenses can be expensive. For example, early termination of an Oracle Unlimited License Agreement (ULA) may incur costs of between 30 and 50% of the original contract value².

When it comes to selecting the cloud provider for Oracle workloads, it’s also important to consider if the provider can host your Oracle workloads with the licensing and support you need and also support the required version of Oracle to be compatible with your application and service level requirements.

BYOL to AWS (or Azure)

For a number of years AWS was the preferred destination for moving Oracle workloads to the cloud. Customers could transfer their Oracle Enterprise Edition licenses to virtual machines or its Relational Database Service (RDS) using an Intel CPU core factor. Oracle Enterprise Edition licenses are based on CPU cores. Oracle applies a “core factor” to each processor core to determine the required number of processor licenses. This core factor is multiplied by the number of cores to determine the required number of licenses. For most chipsets the core factor is less than 1. The core factor for an Intel CPU is 0.5 so a 12-core machine requires 6 Oracle processor licenses.

In January 2017 Oracle published a policy document for “Authorized Cloud Environments” It stated “When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.” It went on to identify a license requirement for cloud environments equivalent to a core factor of 1. This effectively doubled the license requirement for running Enterprise Edition on AWS or Azure (Amazon Elastic Compute Cloud (EC2), Amazon Relational Database Service (RDS) and Microsoft Azure Platform are the only environments referenced in the document)

Oracle Cloud is not subject to the policy document.

BYOL to Oracle Cloud

There are 2 ways to BYOL to OCI (Oracle Cloud Infrastructure). The first is to use IaaS (Infrastructure as a Service) to provision an environment using Oracle’s Compute, Network and Storage Cloud Services. Then install the software on it. Once installed you are responsible for managing the software in the same way you did on premises. License terms are similar to on premises terms. For example, Enterprise Edition licenses can be transferred under terms equivalent to a core factor of 0.5.

The second approach is to use Oracle’s PaaS (Platform as a Service). These are managed service offerings like the Autonomous Database and DBaaS. Many services are offered with 2 separate rate cards. One covers the license included cost and another for BYOL. The BYOL rate can be attractive for customers who received a discount when they purchased their license. It’s not necessarily cheaper if you paid full price³.

Both approaches introduce a license management problem. Oracle’s contracts allow them to audit your usage of Oracle Cloud. “Information collected by Oracle…may also be used…for license management purposes.” OCI customers lose many of the protections they enjoyed while running on premises. OCI contracts include a requirement to provide advanced notice of an audit but Oracle already has your data and a contract that allows them to use it for license management purposes.

Oracle wants its customers to migrate to OCI. They are offering attractive deals to entice customers to their cloud. These are worth exploring for organizations that plan to maintain their Oracle footprint and are happy to increase their dependency on them. OCI is not a good choice if your long term goal is to reduce or eliminate Oracle dependencies.

BYOL to Google BMS

Google Bare Metal Solution (BMS) offers another BYOL option for running Oracle workloads. It is a service offering from Google that provides bare metal servers in a colocation facility. Customers sign a 1, 2 or 3 year commitment to lease hardware from Google. Google purchases the hardware and installs it in a colocation facility managed by a third party. BMS hardware costs are fixed for the duration of the lease⁴. Customers retain full control over the environment, the software installed on it and who has access to it.

Installing software in a colocation facility is standard practice and how many Oracle customers run their workloads today. When Oracle workloads are transferred to BMS the license terms and conditions do not change². Existing licenses can be transferred “as-is”. BMS hardware uses Intel processors documented in Oracle’s Core Factor Table. An Oracle core processor licensing factor of 0.5 can be applied. This avoids the license penalty Oracle imposes on AWS and Azure implementations. The following table lists the number of processor based licenses required for each BMS server type².

Server name	CPU cores	vCPUs	Sockets	Memory	CPU platform	EE License Requirement	SE2 License Requirement
o2-standard-16-metal	8	16	2	192 GB	Intel Xeon Gold, 5200 series, 3.8 GHz	4	2
o2-standard-32-metal	16	32	2	384 GB	Intel Xeon Gold, 6200 series, 3.2 GHz	8	2⁵
o2-standard-48-metal	24	48	2	768 GB	Intel Xeon Gold, 6200 series, 3.0 GHz	12	2⁵
o2-standard-112-metal	56	112	2	1.5 TB	Intel Xeon Platinum, 8200 series, 2.2 GHz	28	2⁵
o2-highmem-224-metal	112	224	4	3 TB	Intel Xeon Platinum, 8200 series, 2.7 GHz	56	N/A
o2-ultramem-672-metal	336	672	12	18 TB	Intel Xeon Platinum, 8200 series, 2.7 GHz	168	N/A
o2-ultramem-896-metal	448	896	16	24 TB	Intel Xeon Platinum, 8200 series, 2.7 GHz	224	N/A

BMS servers can be configured using the Oracle Linux Virtualization Manager (OLVM) hypervisor. This can be used to limit the Enterprise Edition license requirement for a server. It allows a subset of the cores on a server to be isolated for Oracle use. An Oracle white paper published in 2019 describes the process for doing this.

Google’s BMS colocation data centers allows companies to connect their Oracle database workloads to Google Cloud with less than two millisecond latency. This allows for full access and integration with GCP services. Bare metal servers are available with as few as 8 cores, or all the way up to 448 cores with 24 terabytes of DRAM, all to handle the most demanding workloads.

Google Bare Metal Solution allows you to continue using existing Oracle licenses on a BYOL basis while evaluating, designing, developing and implementing cloud native alternatives. It provides a dedicated hardware environment with similar features to the one the legacy software was designed to run on. BMS servers are enterprise grade. They can run Oracle Database RAC, In-Memory database instances and other features that are not supported on managed services like AWS RDS. Examples include calling OS commands from stored procedures, many stored procedure packages, Flashback database, Data Vault, Data Guard and Golden Gate.

When it comes to your Oracle license support costs, using Google BMS can mitigate additional licensing costs to migrate Oracle workloads to a cloud environment. Moving Oracle workloads to BMS also enables you to eventually migrate off Oracle, leading to significant savings in support and licensing costs. Oracle license audits may still occur while you are developing a cloud native replacement. Oracle will still need your cooperation to conduct them. You’ll still know when they are about to happen.

Learn More

Oracle’s License Management Services (LMS) team may attempt to push the customer into waiving this requirement see Fear & Loathing in Denver – Oracle Audit Used to Drive Cloud Revenue ↩
The official word on licensing comes from the customer’s contract with Oracle. Dito recommends engaging a 3rd party Oracle license compliance firm for licensing questions. This is particularly true when migrating licenses covered by a ULA to a cloud environment. Dito can help arrange free Oracle license consulting from Palisade Compliance, an Oracle license compliance consultancy founded by ex-Oracle License Management Services leaders ↩ ↩² ↩³

Sample evaluation:

At the time of writing the unit price for the Autonomous Database TP edition was $1.3441 per hour without a license or $0.3226 per hour for BYOL.
BYOL discount: $1.3441 - $0.3226 = $1.0215/hour
Enterprise Edition annual support and maintenance cost (list price): $10,450
BYOL cost: $10,450 /(365 * 24) = $1.1929/hour

Also need to parse the fine print

  If you run Oracle Database Enterprise Edition and the required options listed below,
  then your BYOL requirements are as follows:

  - For 1 to 16 OCPUs of Oracle Autonomous Database for transaction processing and mixed workloads:
      - For each supported Processor license of Oracle Database Enterprise Edition
      plus Options: Multitenant, you may activate up to 2 OCPUs of the BYOL cloud service.
      Active Data Guard is required if you enable Autonomous Data Guard.
      - For every 25 supported Named User Plus licenses of Oracle Database Enterprise Edition
      plus Options: Multitenant, you may activate 1 OCPU of the BYOL cloud service.
      Active Data Guard is required if you enable Autonomous Data Guard.
  - For 17 OCPUs or more of Oracle Autonomous Database for transaction processing and mixed workloads:
      - For each supported Processor license of Oracle Database Enterprise Edition
      plus Options: Multitenant and Real Application Clusters, you may activate
      up to 2 OCPUs of the BYOL cloud service.
      Active Data Guard is required if you enable Autonomous Data Guard.
      - For every 25 supported Named User Plus licenses of Oracle Database Enterprise Edition
      plus Options: Multitenant and Real Application Clusters, you may activate
      1 OCPU of the BYOL cloud service.
      Active Data Guard is required if you enable Autonomous Data Guard.

↩

Networking and GCP related costs will vary with usage ↩
Consider using OLVM to partition the server since each Oracle Database Standard Edition 2 database may use a maximum of 16 CPU threads at any time ↩ ↩² ↩³