Quest software audit goes to court

Best practice

Quest software audit goes to court

In December 2019, Fairview Health Services, a non-profit organisation, informed Quest that they wouldn’t be renewing support for their “Active Roles” licenses; this move seemingly prompted Quest to launch an audit.
The reconciliation summary from Quest found the customer to be under-licensed…by 69,064 licenses, with an audit total came to $4,183,178.85. The available court documents state that:

“Fairview attempted, without success, to replicate and verify both Quest’s number of allegedly over-deployed licenses and its calculation of the resulting fees.”

which gives a clear indication of where this case is going.

The issues

There are three primary issues at play:

• which of the various agreements actually governs the parties’ current relationship?
• the meaning of some of the contractual terms found within the parties’ various agreements
• what amount, if any, Fairview would owe Quest based on the applicable contract terms

Fairview had a total of 38, 081 licenses, having originally purchased 18,1010 licenses of Active Roles in 2004/2005 and have added licenses at several points over the subsequent years, with all licenses covered by maintenance. The most recent agreement states that the maintenance services are “subject to the terms of the agreement under which the licenses covered by the Maintenance Services were purchased”. The bulk of the licenses were purchased under a 2004 Software License Agreement (SLA).

Quest contend that, when Fairview updated to the latest version of Active Roles on 2016, they accepted the 2015 Software Transaction Agreement (STA), a “click to accept” agreement that came with version 6.9. The 2015 STA contains a clause which states:

“If Customer’s deployment of the Software or, if applicable, use of the SaaS Software is found to be greater than its purchased entitlement to such Software, Customer will be invoiced for the over-deployed quantities at Dell’s then current list price plus the applicable Maintenance Services and applicable over-deployment fees”

Fairview point out that the 2004 SLA states:

“subject to the terms of the agreement under which the licenses covered by the Maintenance Services were purchased”

meaning the above clause doesn’t apply to them. The 2004 SLA also goes on to say that the agreement can’t be:

“modified or amended except by a writing executed by a duly authorized representative of each party” and that “No other act, document, usage or custom shall be deemed to amend or modify this Agreement.”

They say that, if the 2015 STA was seen by anyone, it would’ve been an IT staff member who wasn’t authorized to enter into agreements on behalf of Fairview.

Audit Process

It’s a similar story to that seen with Nike a few years ago. The customer allowed Quest to run their scripts directly on their infrastructure and to have immediate access to the data. It transpired that Quest’s tools were designed to include any accounts that COULD have accessed Active Roles, rather than looking only at those that DID.

Fairview claim that “Quest’s audit tools have been intentionally designed for the bad faith purpose of over-estimating the extent of Fairview’s (and potentially other licensees’) deployment of licensed software, providing a claimed basis for Quest to make an inflated demand for payment of over-deployment fees contrary to the terms of the parties’ agreements.”

“What tools will be used?” and “what do the tools do?” are two questions that you should always ask, and get answers to, before any scanning of your infrastructure takes place.

All about the terms

Following their scans, Quest claim that Fairview have a total of 107,145 user accounts – despite the organisation having a little under 35,000 staff.

Quest refer to the licenses as “enabled user account licenses” – a term only defined in the Quest product guide. The 2015 STA incorporates the terms in the product guide, but the 2004 SLA doesn’t – meaning, in Fairview’s opinion at least, the metric definition isn’t applicable in this case.

The Quest Product Guide defines it as:

“Enabled User Accounts are all the user accounts in the domain(s) to be managed by the Software, including, but not limited to, users’ logon
accounts, secondary accounts tied to users, administrative accounts, service accounts, test accounts, and iNetOrgPerson objects. The license quantity for Software licensed by this License Type must be at least the total number of accounts (regardless of account type) in the domain(s) or other logical group of accounts with which the Software is to be used”

Quest included four (4) distinct domains within their over-deployment report; two (2) of these were test and development accounts which are excluded under the terms of that original 2004 SLA. Furthermore, the product guide states that “enabled user accounts” are those that are “managed by the Software” – and the test & dev accounts are not. According to Fairview, many of the remaining accounts highlighted by Quest neither use the software nor are managed by it – again excluding them from the count.
None of the documents defines what being “managed by the software” means – the customer claims that Quest cannot be allowed to rely on this ambiguity to its advantage.
The customer believed that, based on the language in the agreements, active use of the software was needed in order for a license to be required. Quest’s audit tools found various accounts that didn’t fit that description i.e. test user accounts created with tools such as Active Directory or SailPoint, despite the fact that the account never used, and was never managed, by the Active Roles software.

Money

To reach the total of $4,183,178.85, Quest determined a fee of $60.57 per over-deployed license – this was a combination of base unit cost, four (4) years of back interest, and four (4) years of back maintenance. Fairview claim that none of this is permitted by the terms of their original 2004 SLA and that Quest are only able to simply charge them the cost of any additional licenses. Even what that price would be is contested – as the 2015 agreement allows for the “then current price” while the 2004 agreement does not, which Fairview interpret as meaning they would only be liable for the price as negotiated at the time of that 2004 agreement.

What are they asking for?

Fairview are asking the court for declaratory judgments with relation to:

• Which contract is applicable?
• Does an over-deployment of licenses equal a breach of contract?
• Which accounts should be included in the audit totals?
• Can Quest charge more than just the license unit cost?

all questions which are relevant in the vast majority of audits.

Conclusion

This case highlights some recurring themes when a Quest software audit goes to court – in fact, these apply to pretty much every software vendor – and many of them centre around the same two points:

• what do the terms in the contracts mean?
• which contract applies?

One may well assume that everyone involved knows exactly what is being purchased but that is not always the case. Perhaps the metric is defined quite loosely – perhaps to give the vendor more flexibility in audit situations – or perhaps what your organisation is going to do with the software isn’t exactly what was envisioned when the metrics were defined; this latter option is particularly likely where technological advances such as cloud or RPA (Robotic Process Automation) are coming into play.

Knowing which contract applies is equally key – and can be equally difficult. In an ideal world, every time software is purchased, an organisation will review the contractual terms – taking note of what has changed, have the terms become more restrictive, are things that were previously allowed no longer permitted etc. Does a newer contract apply only to licenses purchased after a certain date or is the vendor looking to incorporate all your existing licenses under these new terms?

The point made by Fairview that anyone who saw the 2015 agreement wouldn’t have been authorised to accept the new terms is an interesting one. Typically, these click through agreements ask you to certify that you are authorised to accept them – if a non-authorised person clicks through, where does that leave the customer organisation? Speaking to your legal team and understanding your company standpoint on this will help prepare you for these conversations should they arise.

All in all, contracts rarely contain all the answers and even more rarely are they so clear that both sides immediately agree on the points. Reviewing contracts should be done in conjunction with several stakeholders including legal, procurement, ITAM, and architects – just because a clause is legally sound doesn’t mean that it works for your planned use of the software!

Can’t find what you’re looking for?