Dave Welch (@OraVBCA), CTO & Chief Evangelist

Update – July 26, 2019:
VMware KB 51491 originally published vSphere 5.5 Extended Support as available for one year only, through September 19, 2019. VMware Corporation has affirmed to us that since our original publication of this blog post, the availability of vSphere 5.5 Extended Support was changed to two years — through September 19, 2020. We have updated our blog post’s title and body text accordingly. That said, if you bought 5.5 Extended Support primarily out of concern for Oracle licensing, we strongly suggest you have better things to do with your money than continue to pay this fee.

I imagine those reading that title will be divided into two groups:

– Those that paid the vSphere 5.5 extended support fee out of fear of Oracle licensing consequences, and

– Everyone else that’s wondering what this article is really about.

This Micronauts post lists the vSphere 5.5 Extended Support fee at $300,000. I suppose the extended support fee acts as an incentive to upgrade to vSphere 6.x. If an organization’s vSphere 5.5 Extended Support was motivated by Oracle licensing concerns, I’m confident that’s dirty money that VMware didn’t want. As vSphere 5.5 only allowed vMotion within a vCenter, these VMware users licensed an entire vCenter for Oracle, thus avoiding the argument with Oracle. But now that vSphere 5.5 Extended Support expires September 19, 2020, and vSphere 6.x is designed to allow live migration anywhere on the planet, what are these organizations to do? Might agreeing to non-standard terms with Oracle resolve the issue?

My 17 January 2016 Mars v. Oracle blog post and the supporting links in it made clear there is no obligation to go along with Oracle’s attempt to redefine “installed” and to license the prospect of movement to additional vSphere servers. In that post, I called out b.lay’s Richard Spithoven for his assertion that IP owners could determine the rights with which end users use their software, and ITAM’s Martin Thompson for his concern over our advising licensees to take a gutsy approach with Oracle. I wrote: “How arrogant of any of us to ever have assumed to stand on our contractual privileges.” Thompson posted the comment: “Excellent analysis, thanks.” Yet ITAM’s posting of Spithoven’s 5 September 2018 article “Oracle on VMware – adding non-standard terms to your Oracle agreement” has had me wondering if Thompson changed his mind. Spithoven’s article literally glamorizes the idea of Oracle on VMware customers amending their Oracle agreements with non-standard terms.

Data Intensity’s 23 August 2018 post arrived at similar conclusions. But as Spithoven’s article is more detailed, let’s use it as the foundation for our analysis. Quoting from Spithoven’s article:

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 http://oracle.com/contracts. (Emphasis is Spithoven’s.)
…

As you can see, the contractually agreed Processor license metric definition refers to the Processor Core Factor Table, which can be found at: http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf. This Processor Core Factor table only states the different physical CPUs that can be part of a (physical) server on which the virtual servers and/or the Oracle programs are installed and/or running.

No argument. Spithoven continues:

Based upon this Processor definition and the related Processor Core Factor table, Oracle will explain that both parties have contractually agreed that the required number of licenses is based upon the (physical) cores of the servers on which the Oracle programs are “installed and/or running”.

The installation of the software itself determines the licensing event, independent of the fact whether the software is actually used (running).

Agreed. Spithoven continues:

This is Oracle’s contractual basis for any licensing dispute around the licensing of Oracle software on VMware.

And with that quantum leap, Spithoven takes off with an assertion of the need for vSphere version-specific processor counting methods:

VMware’s vSphere technology provides different functionalities, depending on the specific version used. Due to the different functionalities offered, different ways of counting the required number of licenses are applicable.

Stop right there.

Let’s illustrate the issue with a common configuration. Take the example of a vSphere VM “1” with Oracle executables that were installed into a VMDK that was created with the default parameters. No Oracle executables are presented to VMs on this (or other hosts) through any other method. Our VM “1” and others like it are confined to ESXi host A using the boundary tooling of your choice. For our example, we’ll pick DRS Host Affinity Must rules. Say ESXi host B in the same cluster has VMs on it, none of which are Oracle program VMs. Someone please show us Oracle executables in an installed state at a command prompt of any VM on ESXi host B. You can’t do it without reconfiguring the environment.

In this regard, US District Court Nevada Judge Hicks cited germane case law in his 13 February 2014 finding in the Oracle vs. Rimini Street matter:

The starting point for the interpretation of any contract is the plain language of the contract.  Klamatch Water Users Protective Ass’n v. Patterson , 20 F.3d 1206, 1210 (9th Cir. 1999) (“Whenever possible, the plain language of the contract should be considered first.”).

When a contract contains clear and unequivocal provisions, those provisions shall be construed to their usual and ordinary meaning.  Id. Then, using the plain language of the contract, the court shall effectuate the intent of the parties. Id. at 1210 (“Contract terms are to be given their ordinary meaning, and when the terms of a contract are clear, the intent of the parties must be ascertained from the contract itself.”).

Construing the scope of a license is principally a matter of contract interpretation. S.O.S., 5 Inc. v. Payday, Inc., 886 F.2d 1081, 1088 (9th Cir. 1989).

Plain language.

The words “installed” and “running:’ are central to the contract’s Processor definition:

• “Installed” either describes a historical activity–past tense, or software that is currently in an installed state–present tense.
• “Running” is present tense.

There is nothing prospective about your licensing obligation under the Oracle Core Technology contract.

The whole idea that the ease of hypervisor reconfiguration induces liability is preposterous. You are no more contractually liable to prospectively license ESXi host B’s VMs (from our example) than you would be liable for crossing the center line of a two-lane divided highway into present opposing traffic until actually having done so. The fact that you have the capability of crossing the millimeters-high dotted paint with a quick jerk of the steering wheel does not induce any liability in and of itself.

Oracle is no doubt thrilled with Oracle license consultancies that co-opt its non-contractual assertion. In the case of both of these organizations (who unfortunately are not alone in the Oracle license consulting arena with such statements), I’m not surprised. Data Intensity acknowledges their status as a “Certified Oracle License Partner, resulting in precise audit findings.” Similarly, I find it telling that a substantial percentage of Spithoven’s b.lay operatives’ LinkedIn profiles mention Oracle LMS in their professional history. Based on Spithoven’s Oracle on VMware licensing position and his b.lay leadership role, it would appear b.lay’s former LMS operatives have no incentive to disavow the non-contractual licensing positions of their former employer.

Spithoven’s assertion that IP owners could determine the rights with which end users use their software, would make moot the need to amend governing agreements to establish the same rights. It makes no sense.

The whole issue reminds me of Nathan Biggs’ 31 March 2017 blog post “7 Questions to Ask When Engaging an Oracle Audit Defense Consultant” I quote:

When our many audit defense clients have followed our guidance and coaching throughout the audit process, we have never had a customer that was forced to pay fees for non-contractual claims. That is a perfect track record.

None of our customers had (or have) any need to:

• Purchase vSphere Extended Support.
• Amend non-standard terms into their Oracle agreements, thereby ceding valuable contractual privileges and inviting Oracle into their operations in a way that is heretofore foreign to their agreements.

It is remarkable how relatively old House of Brick’s Mars v. Oracle and 7 Questions blog posts are. How many more years of my annual blog post “Celebrating the n Year Anniversary of the Dismissal of Mars v. Oracle” will it take before Oracle customers longing to join the Oracle on VMware market (growing exponentially since 2007) realize they have all the cards?

Pam Fulmer’s landmark 7 June 2017 blog post “VMware Virtualization and the Oracle Audit: What Every Oracle Customer Needs to Know About the “Installed and/or Running” Language of the Processor Definition” concludes with this invitation:

… if you have been audited by Oracle and have purchased additional software or paid money based upon Oracle’s assertions around VMware, you may have legal options to recoup some of those costs. 

In addition to possible monetary remedies, Oracle customers may also wish to seek legal counsel experienced in Oracle matters for advice on rescission of amendments to license agreements or contracts, where changes to the agreement were made to the customer’s detriment in reliance on Oracle’s misrepresentations.

Think whatever you may about House of Brick’s prospective economic advantage behind Nathan’s 7 Questions post. The fact is – following that advice will save you time and money, and lead to the optimization of your organization’s operations.