Is Oracle’s “Processor” licensing definition technically flawed?

In a word: Yes.

Oracle's "Processor" definition requires customers to license all cores on all processors where Oracle programs are "installed and/or running". The "running" part is easy to understand. The "installed" part isn't. After all, who has ever heard of a program being "installed" on a processor? On a disk or storage - yes. But "installed" on a processor? This may seem trivial at first glance, but in our experience, customers have gotten into a lot of compliance trouble when Oracle's auditors interpret this definition in creative ways. This may also significantly impact customers using NUP licensing since NUP licensing has a minimum license dependency on the "Processor" metric.

Background.

Oracle's "Processor" license metric has not changed much in almost 20 years. The current definition, per Oracle's License Definitions & Rules, page 22, is as follows:

"Processor: shall be defined as all processors where the Oracle Programs are installed and/or running. Programs licensed on a processor basis may be accessed by Your internal users (including agents and contractors) and by Your third party users. 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 on the Oracle Processor Core Factor Table which can be accessed at https://oracle.com/contracts. All cores on all multicore chips for each licensed Program are to be aggregated before multiplying by the appropriate core processor licensing factor and all fractions of a number are to be rounded up to the next whole number. When licensing Oracle Programs with Standard Edition2, Standard Edition One or Standard Edition in the product name (with the exception of WebCenter EnterpriseCapture Standard Edition, Java SE Subscription, Java SE Support, Java SE Advanced, and Java SE Suite), a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket."

Requiring a customer to license all cores on processors where Oracle programs are running is understandable and reasonable. However, the definition makes no technical sense when it requires customers to license processors where Oracle programs are installed. Technically, Oracle programs are never installed on processors; they are installed on disks or other long term storage. Let's discuss this in more detail.

Bits and Bytes.

At a very high level, Oracle programs - like most software - are installed in persistent forms of storage like magnetic disks, SSDs, and their shared or distributed storage incarnations. To run the Oracle programs, the bits and bytes of the Oracle programs are loaded into volatile memory (RAM) before being loaded up on the CPU-level caches and are threaded into execution pipelines. This execution process leads them to be "running". The overall process is of course much more involved, but the key concept is that Oracle programs - including binaries and data structures - reside on (i.e., are "installed" on) disks or other storage. They are never "installed" on processors. 

Clearly, the Oracle "Processor" definition is technically flawed. As a consequence, the contractual validity of this definition can (and ought to) be challenged by customers, especially when customers encounter Oracle sales and audit personnel who are exploiting this ambiguity unfairly.

Splitting Hairs.

I'm sure some readers may counter my argument with:

"Yes, but isn't it the same thing? Isn't it obvious that the definition is just referring to all processors that have access to installed Oracle programs? We know Oracle programs are not installed on Processors - that's common sense. The definition is implying that any processors that are somehow connected to installed Oracle programs require licensing".

I see the point, but that's not what the definition strictly states. There is clearly a disconnect between the common sense response and the strict definition of the "Processor" license metric. This disconnect allows Oracle auditors to pursue aggressive and unreasonable findings. The implications can vary from minimal to profound, as I shall now discuss.

The Implications.

Let's discuss a few scenarios to assess the impact of this observation.

Scenario - Standalone servers.

On standalone servers, the implication will be minimal. If an Oracle program was installed on a standalone server, then it must have been run or executed in some way. I am sure there are unlikely or edge scenarios where even this statement can be disproved, but I'm confident this would generally be the case. The installation process alone would result in license requirement based on the "running" aspect of Oracle programs as installing would require running of at least some of the Oracle program components. The fact that the Oracle programs are then subsequently present on the disk or otherwise considered "installed" has no implication.

Scenario - Standard servers using standard images with Oracle programs.

Let's expand the standalone servers scenario and consider situations where Oracle programs may be present on a server (or desktop/laptop) where the Oracle programs may not have been installed or otherwise never have been executed. Instead, the Oracle programs may be present as simply part of a standard installation image.

Firstly, as part of good SAM hygiene, this should not happen. Software distributed via standard images should be routinely cleansed and programs not required should be wiped. Unneeded programs should not exist on systems.

That said, in the case of Oracle programs, would this imply a license requirement? Based on the "Processor" definition, the program is clearly not running (unless there is evidence to the contrary, that the program may have run previously). The presence of the program does not - contrary to what Oracle auditors may say - mean they were installed on the "processors". As I mentioned, there is not such thing as Oracle programs being "installed" on processors.

Oracle Java would be a great candidate for the above scenario. It is often widely distributed as part of standard images even when the end user never uses it. The program is installed on the disk, not installed on the processor, and likely never in a "running" state.

Scenario - Virtual environments and shared storage.

This is where the implications become serious and very material. It's not uncommon for Oracle auditors to require customers to license entire VMware clusters or VCenters on the argument that if Oracle programs are installed in a way where other servers are connected to the same shared storage, then technically Oracle considers the Oracle programs to be "installed" on all processors on all such servers, including servers that are not actually running the Oracle programs. This may, and often does, inflate the license requirement several fold. Contractually, Oracle's argument is baseless.

Firstly, no reasonable and technically proficient person would consider such Oracle programs to even be "installed" across all the servers accessing the share storage. Logically, an "installed" program would be readily available for execution. Shared virtual storage does not automatically imply this.

Secondly, and more relevant to this post, such programs could certainly not be considered to be installed on all processors across all the servers accessing the shared storage because, as I stated above, there is no such thing as an Oracle program being installed on a "Processor".

So while Oracle may pursue an unreasonable course on this topic, customers should be well versed in the intricacies of the contractual language and use it to their advantage.

Scenario - DR servers.

This is a common area for customers to get in to compliance trouble. Oracle typically requires customers to license DR servers where the Oracle programs are considered "installed" on the processor and available to CPU resources. The cases of clustered failover and backup to disk are exceptions (under stringent conditions - a topic for another post).

The above approach means that per Oracle, cases where customers are simply mirroring disks from production to DR, or replicating from production to DR, the DR server(s) - that is, all processors on these DR servers - require full licensing. The reason being that Oracle considers such Oracle programs to be "installed" on the processors on the DR servers. Now, if these programs were in fact "running", for example in the case active or "hot" DR or standby scenarios where the Oracle programs are in fact "running", the argument is reasonable.

However, in cases where the Oracle programs are not "running" on the DR servers, and the Oracle processes have never been initiated on the DR servers' CPUs, Oracle argument for licensing them is technical and contractually flawed. That said, if there is routine DR testing where DR servers in fact bring up the Oracle programs and run them, then based on the "running" term, they reasonably need to be licensed. Note that this would arise due to the "running" term and not the "installed" term.

I am certain there are many other scenarios we can consider. If you have any scenarios in mind, I'd be glad to hear about them and see if I can provide any thoughts.

Summary.

To sum up, customers should:

1. Be well versed in the intricacies of their Oracle agreements.
2. Have a clear understanding of where their Oracle programs are running and where Oracle may consider them "installed".
3. Not hesitate in pushing back firmly against unreasonable positions and conclusions by Oracle sales and/or auditors.
4. Not make any concession to Oracle that inflates the license requirement and/or places unreasonable operational burdens on their IT personnel to separate or segregate their storage environments to satisfy flawed licensing language.

As always, if you any questions about Oracle license compliance and optimization, feel free to contact us for a complimentary consultation. Contact Us.