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.