License Agreements, Audits & Digital Transformation: Some observations on managing the legal risks

Modern business processes are based on technological solutions, which are generally provided in three models: 

(a) solutions installed on client’s environments (on-premises), 

(b) outsourcing model, and 

(c) cloud model. 

Each of these license and service models is based on specific legal arrangements. The license and service agreements are based on producers’ templates, often several hundred pages long, frequently amended (sometimes several times a year) and, worse still, using poorly defined terms and structures.

In this context, the management of legal risk presents considerable challenges, not only for lawyers, but also for the entire organisation. The lack of strategy and risk management can result in, among other things, additional fees imposed from an audit. In this article we offer some insights on how to manage those risks better based on experiences of negotiating carrying out licensing audits over the past few years. 

The Main Audit Challenges

The main challenges faced during an audit relate to ambiguous contractual terms and the unilateral and broad interpretation of agreements by the auditors. Many model license/cloud agreements use highly imprecise definitions: see, for example, the definition of “processor” and “user” within Oracle agreements and the definition of “usage” or “trade” within SAP agreements. There is also the liberal interpretation of certain metrics or architectural solutions by auditors, typically based on the producer’s guidelines and which are not even part of the agreement (Oracle’s partitioning policy is such an example).

In order to properly manage these audits and agreements, it is worth examining:

(a) The technical point of view: demonstrating broad knowledge of architecture, interfaces, installed software and equipment. In most cases, Software Asset Management (SAM) type devices are used along with dedicated solutions (such as in terms of JAVA, specific solutions tracking the usage are needed);

(b) The legal perspective: compiling all contract documentation, including agreements held, amendments to those agreements, in-person arrangements, e-mail correspondences and notes taken during negotiations. Compiling such documentation is often much more difficult with older systems since the more a system ages, and the larger an organisation becomes, the more challenges it will face. This is especially true in the current age of mergers and takeovers in which several agreements are needed for just one solution;

(c) Access to knowledge of regulations, audit practices and a software producer’s data policy. Such knowledge is usually held by specialised law firms or consulting companies with practical, but not necessarily legal information provided by IT services providers, such as Gartner;

(d) And finally, having an organisational policy related to a license audit.

Audit Procedure

There is a lack of official data concerning the number of audits conducted or the fees collected from these audits, but a few cases show the substantial scale of these audits. In the British case of SAP v Diageo, the amount at issue exceeded £54 million; in a SAP s Ab InBev arbitration, fees exceeded $600 million; and in cases from the Polish market that we know of, a record claim exceeded EUR 100 million. Almost every year we have claims exceeding EUR 10 million.

It is also not clear when an audit will be initiated. Gartner suggests that an audit might be triggered by, among other things:

• implementation of specific system architecture (virtualisation, integration)
• mergers, acquisitions, and divestiture of companies
• a lack of license fee payments
• discontinuation of the service
• using so-called third-party support
• or even submitting a tender (RFP) for competitive solutions.

An audit consists of five elements

1. a letter announcing the audit
2. meetings and pre-audit agreements
3. audit procedures
4. an audit’s initial and final report
5. post-audit negotiations.

Based on our knowledge and experience, we have the following key recommendations and findings:

• It must be verified who carries out the audit. Often it is an external auditing company or one of the vendor’s own companies (for example, software producers now conduct their own audits: Oracle through its Romanian branch and SAP through its German H.Q.). The auditor will not necessarily be a party to the license agreement, which makes it important to ensure the given auditor’s continuous authorisation. When it comes to international corporations the audit could be unique and entirely exclude audits of local subsidiaries.
• The audit’s scope must be verified. Producers usually define the scope too broadly and vaguely. In any case, the auditor should present an accurate list of products, agreements and orders that will be audited. This is an important matter as the intermingling of data from the producer’s and client’s databases could bring to light valuable information.
• It must be determined which text controls the audit. Very often the auditor will base the audit on the vendor’s most current licensing policies while the client will base it on the older licensing policy which is contained within the wording of the original agreement. In extreme cases, this difference in text can lead to contrasting audit results.
• The audit procedure must be established, though this often meets with resistance from the auditor. The audit agreement shall describe, among other things:

– the scope of requested information which must be examined in terms of trade secrets and highly sensitive information (for example, banks cannot transfer data relating to bank secrecy) 

– the tools that will be used to extract information (including the right of the client to examine the safety of these tools)

– access to specific systems (normally, there is no basis on which the data can be extracted from systems other than the audited ones such as from Active Directory) 

– and finally, the timetable and required resources. 

• The non-disclosure agreement (NDA) shall constitute a separate agreement, and if necessary, another distinct agreement that will determine the method of data transfer (often user logs or similar material).
• It is very important to describe the channels of communication between the client and the auditor. All the inquiries and the sharing of information should go only to the as a coordinator of the audit Also, the auditor should not be allowed to freely communicate with anyone. Our experience has shown that such communication results in the sharing of false and unverified information, which can result in the loss of time and money to verify and explain this information.
• The findings, amounts, and dates should be approached cautiously. In general, the first audit reports are very broad and the calculation of fees is questionable (for example, based on price list that doesn’t cover discounts). The entire process of agreeing on findings and the implications of the audit can take anywhere from a few weeks to several months.

Audit Allegations

Under-licensing is rarely obvious. There are three main reasons for this. First, is a lack of precision within the agreement and a unilateral approach to its interpretation. Second, is the complexity of the client’s system architecture, which is difficult to assess in terms of licensing (the infamous problem of indirect use / digital access and virtualisation). Third, the auditors lack of consideration towards a particular client’s agreements (particularly towards arrangements agreed during negotiations). Even if such arrangements are not legally binding, they often express the parties’ intentions and are taken into consideration in the final evaluation.

Particular attention should be paid to whether an allegation of under-licensing is based on the content of the agreement or the producer’s policy. A good example of this is Oracle’s allegations of under-licensing relating to the use of their virtual environments since they are usually based entirely on the producer’s guidelines and not the content of the agreement.

It must be stressed that the software producers’ rhetoric can be very aggressive, including the threat of terminating the service or license and occasionally the suspension of a sale. An interesting occurrence is the use of under-licensing allegations or the threat of an audit in order to push the sale of a producer’s services, for example cloud computing as in the case of City of Sunrise v Oracle. In that case, a firefighter pension fund, as part of a class action investor lawsuit, sued Oracle for misrepresenting cloud product (IaaS, PaaS, SaaS) sales. Specifically, the plaintiffs claimed that Oracle inflated the amount of cloud subscription sales it obtained by adopting an aggressive sales tactic of utilising software license audits to engineer cloud product sales. Sometimes, such actions result in a strong response from clients (see: Mars Inc. or City of Sunrise Firefighters’ Pension Fund cases). Practice however shows that the matter usually resolves itself in business and legal negotiations.

In preparation for negotiations, it is necessary to analyse which under-licensing allegations are well founded (perhaps a simple lack of named user license), which are met with scepticism (such as indirect use issues), and which are unfounded (allegations concerning virtualisation). Such classifications allow for the creation of a negotiation strategy since the second and third groups usually determine the final sum of damages. In any case, we recommend that any settlement resulting from the negotiation process describes amongst other things, a client’s system architecture as this helps to avoid identical allegations in future audits.

What Next?

Many in the sector feel that that the intensity of audits and the scope of license requirements is growing (as the JAVA case shows). The newest trends are the optimisation of service cost or an overlapping of on-premise and cloud environment licenses (in particular cloud migration and the “bring your own” license model).

With an eye towards legal security and expenditures, consideration should be given to:

• the implementation of SAM systems
• development of a list of rights continuously updated by both new orders and changes in a producer’s terms and conditions
• implementation of a formal procedure for audits, including draft agreements for auditors, information classification, etc.
• establishment of a license team, which should be periodically trained in matters concerning the producers’ conditions
• and the carrying out self-audits that are generalised or targeted towards a given problem (virtualisation, JAVA, indirect access).

Marcin Maruta is co-founder and managing partner at Maruta Wachta law firm and expert in the field of new technologies law. Marcin has over 25 years of experience in advising technology clients with particular emphasis on optimisation and license audits. 

Karolina Alama is an Associate at Maruta Wachta in the new technologies law department. Karolina is a lead lawyer in the cloud and licensing projects run for law firm’s clients.