The ITAM Review

News, reviews and resources for worldwide ITAM, SAM and Licensing professionals.

VMware Contracts Deconstructed: Order of Precedence

This article on VMware contracts was contributed by Barry Pilling, Managing Partner at Cortex Consulting.

VMware contracts


A comment on my previous article regarding VMware’s CPU metric change has prompted some thought – and this post. It was a great point about VMware contracts and the ELA taking precedence over all other software terms, and it occurred to me that it was worthwhile deconstructing VMware’s agreements to correctly interpret the chain and order of precedence. Understanding how the agreement and all its constituent parts fit together is key to understanding VMware licensing and your rights.

Enterprise License Agreement (ELA)

Most organisations will have an ELA at some point if they choose to licence VMware products. There are advantages and disadvantages to it, depending very much on your business, but possibly the two biggest of the former are global deployment rights and the opportunity to negotiate in (or out as the case may be) favourable (or unfavourable) terms. The most important things to understand about an ELA from the contractual point of view are:

  • It is basically a glorified VMware Order Form
  • Once the ELA period has begun, its terms cannot be altered without a contractual amendment
  • It incorporates (usually in a schedule) VMware’s standard EULA for on-premise software – assuming you’ve transacted for on-premise software, of course
  • The EULA incorporates the terms of the Product Guide (May 2020 at the time of writing)

The order of precedence

Now we understand that – let’s examine in more detail an important clause from the ELA itself – the order of precedence:

“The terms and conditions of this ELA shall prevail over any additional or conflicting terms in any purchase order Customer issues to VMware or any other terms for the Offerings.”

The key word here is “Offerings”. This is a catch-all word VMware uses to mean anything that you are being offered, as a customer, through the ELA that will appear in Exhibit A, the ELA Schedule. This could include software, support services, token-based purchasing programs (like the EPP), cloud or professional services, or training credits. What you should be careful of is to not fall into the trap of believing that this clause gives the ELA control over the terms of the standard EULA – it doesn’t; the ELA will always contain wording somewhere to the effect that “Customer’s use of the Software is subject to the End User Licence Agreement”, which is almost always embedded into a schedule of the ELA and, if it isn’t, you will find a link directing you to it on VMware’s website.

Speaking of the EULA, we should also look at some important clauses that are very telling with regards to contractual precedence.

Contract clause 1

Firstly, the EULA’s own order of precedence statement (clause 12.9):

“In the event of conflict of inconsistency among the Product Guide, this EULA and the Order, the following order of precedence shall apply unless otherwise set forth in an enterprise licence agreement: (a) the Product Guide, (b) this EULA and (c) the Order.”

You can see here a very clear statement of the emphasis VMware places on the Product Guide. Thinking back to the previous article, you can already see its importance. Because VMware has changed the definition of the CPU metric, which is found in the Product Guide, this clause in the EULA gives VMware the right to force that change on to ELA customers. Of course, as the clause states, it is perfectly possible that you, as a customer, have negotiated in an exception to this order in your ELA. But such exceptions are rare and, in over a decade of working with customers on theirs, I’ve never seen one. It’s also worth noting at this juncture that the Product Guide contains a very similar order of precedence term.

Contract clause 2

The second clause to look at it in the EULA is the definition of “Order” which, according to clause 1.10:

“means a purchase order, enterprise licence agreement, or other ordering document…that references and incorporates this EULA…”

Again, it is clear to see VMware’s intent here – the “Order” referenced in the order of precedence clause above very obviously includes the ELA which, as I said earlier, is just a glorified Order Form.

Contract clauses 3 & 4

The next pieces of the puzzle from the EULA relate to the Product Guide itself and are found in the following clause, 1.11, which defines the “Product Guide” as:

“the current version of the VMware Product Guide at the time of Your Order, copies of which are found at…”

and the General Licence Grant in clause 2.1, which includes the statement “…and subject to the provisions of the Product Guide”.

Here VMware is telling you that your software usage is subject to the terms of the Product Guide and the one that applies is the one that was in force when you placed the order. However, the applicable version of the Product Guide changes the moment you install a new release – even if that’s just a maintenance release – of the software. This is included in the document itself, in clause 1.3 “Applicable Version of the Product Guide”:

“VMware may provide You with Maintenance Releases, Minor Releases or Major Releases under a support and subscription contract. If You install a release that VMware provides to You, then the version of the Product Guide published at on the date that You install the release applies to that release.”


Bear in mind that VMware’s support offering is automatically included in an ELA for your entire installed base and, at some point, you will install updates to products sold on the CPU licence metric; especially when you consider that vSphere 7 now has the capability to self-patch if configured. The moral of the story, unfortunately, is that unless you had extraordinary foresight and negotiated a term into your ELA obviating the standard order of precedence, you will be caught by the VMware CPU metric definition change even if you are mid-ELA. There is literally no way round it unless you don’t have support and are content to run your VMware estate on legacy versions without patches forever.

About Rich Gibbons

Rich has been in the world of IT and software licensing since 2003, having been a software sales manager for a VAR, a Microsoft licensing endorsed trainer, and now an ITAM analyst looking at software licensing and cloud.

A Northerner renowned for his shirts, Rich is a big Hip-Hop head, and loves travel, football in general (specifically MUFC), baseball, Marvel, and reading as many books as possible. Finding ways to combine all of these with ITAM & software licensing is always fun!

Connect with Rich on Twitter or LinkedIn.

One Comment

  1. PetrS. says:

    Perfect piece, Rich! Thanks for sharing valuable information.

Leave a Comment