SAP v Diageo in 2017 highlighted how customers can face unexpected charges where their licensed software interacts indirectly with other systems .Kemp IT Law partner, Deirdre Moynihan, looks at market developments since then and, in a world of tight budgets, how to avoid extra charges.
Contractual language to define the scope of permitted software use and to determine charging basis may have been agreed years ago. That language now finds itself applied to new technologies and interfaces in a way that was unanticipated when the agreement was signed. Increasingly, providers are scrutinising customers’ use of their software to ensure that use is in accordance with the terms of the licence and that the charges paid by the customers reflect actual usage of the software. This calls for a combined complex and nuanced legal and technical analysis to establish whether or not day-to-day use of the software is compliant with the permissions and restrictions of the applicable license.
SAP v Diageo: case summary
This trend for heightened scrutiny of customer compliance with licence terms is the background to the 16 February 2017 judgment of Mrs Justice O’Farrell in a case between SAP UK Limited (“SAP”) v. Diageo Great Britain Ltd (“Diageo”).
Briefly, the facts are as follows:
- From May 2004, Diageo was licensed to use various SAP products, including mySAP ERP (“SAP ERP”) and SAP Process Integration (“SAP PI”). SAP ERP provides a suite of enterprise resource planning functions for managing operations, finance and HR. SAP PI facilitates communication between different SAP systems or between a SAP system and a non-SAP system. The licence to access and use the software – directly or indirectly – was on a Named User basis. Fees for SAP ERP were calculated by reference to various fees for categories of Named User. Fees for SAP PI were calculated on the volume of messages processed by SAP PI. Diageo paid SAP between £50 million and £61 million by way of licence and maintenance fees for the period up to November 2015.
- In 2011/2012, Diageo used a system that enabled customers to place and review orders and manage their accounts directly with Diageo rather than (as previously) through a call centre (”Connect”) and a platform provided by Salesforce.com to develop an iPad app for the management of customer visits and calls (“Gen2”). Connect and Gen2 interacted with SAP ERP via SAP PI. Messages were passed back and forth between Connect or Gen2 and SAP ERP a few times a day when the SAP ERP was polled for information by Connect or Gen2.
- SAP claimed that Connect and Gen 2 “used” or “accessed” the SAP systems “directly” or “indirectly” and that Diageo owed additional licensing and maintenance fees totalling in excess of £54million. Diageo contended that SAP PI was a “gatekeeper” for the other SAP applications and that no extra fees were due.
In a trial on liability – but not the amount of damages – the English High Court ruled in favour of SAP:
- On the plain and obvious meaning of the words in the licence only ‘Named Users’ (as defined) were authorised to access and use SAP ERP, and the extent of their permitted access and use then depended on their user category set out in a schedule to the agreement. Although the terms “access” and “use” were not defined in the licence, “the plain and obvious meaning of “use” in the context of the Agreement is application or manipulation of the mySAP ERP software. The plain and obvious meaning of “access” in the context of the Agreement is acquiring visibility of, or connection to, mySAP ERP software.”
- As regards the Connect customer software: o The interactions between the SAP ERP and Connect amounted to “indirect” access to the SAP ERP on the basis that each stage of the order process carried out through Connect involved transmissions between Connect and the SAP ERP and that Diageo’s customers (who were not ‘Named Users’ for the purposes of the SAP ERP) accessed or used SAP ERP indirectly through SAP PI when using Connect.
o SAP PI was not a “gatekeeper” for access to other SAP applications. The charges for the SAP PI were in addition to, not instead of, named user charges for the underlying applications.
o The court distinguished the Connect system from the previous system (in which Diageo Named Users would place orders in the SAP ERP) on the basis that there was no interaction between Diageo’s customers and the SAP ERP when orders were placed via the call centre – Diageo Named Users were interacting with the SAP ERP in that situation. Using Connect, however, involved access or use by Diageo customers of the SAP ERP indirectly through the SAP PI.
o No ‘Named User’ category in the schedule applied to the type of access created by Connect to the SAP ERP as the Connect users “[did] not have access to source or object code. They [did] not have access to the functionality provided by mySAP ERP in support of the wider operation of Diageo’s business. They [accessed] business process functions and information from the database for the purpose of ordering products and managing their own personal accounts only.”
o The amount of any additional licence fees due to SAP would need to be assessed during the damages phase of the trial.
• For Gen2 the court reached a similar conclusion.
• Therefore, SAP was entitled to charge Diageo for the access and use of the SAP ERP.
• The issues at trial focussed solely on the terms of the agreements between Diageo and SAP. No claims of copyright or database right infringement were brought against Diageo and no claims based on representations as to the scope of the licence were brought against SAP.
SAP’s new digital access model
Following the decision and discussion and consultation with customers and industry, SAP launched a new digital pricing model for the “use” of its software.
This new model gives customers the option to move to a new licensing and pricing model catering for:
• Direct/Human access, chargeable based on named human users; and
• Indirect/Digital Access, access via third party, Internet of Things (IoT), bots and/or other digital access: licensed based on number of transactions/documents processed by the SAP software. “Use” under the new model is defined broadly, as illustrated by Figure 1. Figure 2 shows the differences between the legacy and new digital access models.
Although SAP’s stated intention when introducing the new digital access model is to “make it easier and more transparent for customers to use and pay for SAP software licenses”, the new model remains complex and requires significant analysis to assess whether legacy customers should move to the new licensing model. Neither does the new pricing model reduce the requirement to critically assess whether the actual or intended use is permissible under the terms of SAP’s complex Software Use Rights. Casting a critical and circumspect eye over the relationship between the Ts&Cs and actual use is key – particularly as providers and customers grapple with the fast pace of technological development and the move towards cloud based, customisable, and interoperable IT systems easily accessed via APIs or browser interfaces.
Figure 1: https://news.sap.com/wp-content/blogs.dir/1/files/DA_Offer_External-Master_V11_050619.pdf
Figure 2: https://news.sap.com/wp-content/blogs.dir/1/files/DA_Offer_External-Master_V11_050619.pdf
We therefore continue to recommend that particular attention is paid to the language used in Ts&Cs and how it may apply to different use cases or access rights. Customers should carefully review at the outset of the contract the nature and extent of the rights granted under any licence and the methodology applicable to the calculation of licence and maintenance fees. In these times of rapid technological change, customers should also consider putting in place a structured process to ensure that their use cases across the organisation continue to map to the licence grant and charging clause across the licence lifecycle. The issues for the software provider are the obverse – ensuring a genuine understanding by customers of licence scope and charging terms and backing up the primary contractual obligations with workable audit rights to verify compliance. For both sides, contractual terms dealing with the following issues should be express, precise and clear so that each party is aware of its obligations:
- types of user – what categories of employees and/or contractors require access?
- nature of access – is it direct log-in via user ID or access via a plug-in, API or other specified indirect method?
- type of access – is it merely pulling information from the customer’s database within the provider’s offering? does it involve use of the
- functionality provided by the software? If the latter, exactly what functionality is involved?
- scope of licence – what rights are granted to each category of users? Is this linked to the nature and type of access?
- will the contract software interact with other systems in a way that could give rise to licence scope or charging issues for the contract software or
- the contracts governing the other systems? This will become important as systems built around Artificial Intelligence (AI) and Robotic Process Automation (RPA) increasingly interact with each other indirectly, automatically and without direct human intervention.
- how are the charges calculated? How frequently can the provider increase the charges?
- what rights does the provider have to audit or verify the customer’s use of the software? How frequently can it exercise these rights? In what circumstances should an audit be permitted?
- what changes does the customer intend to make to its IT estate over the life of the contract? Will any of these require changes to the rights granted by the provider and oblige the customer to increase amounts payable to the provider? Can any of these costs be reduced or will they ultimately be passed on to the end customer?
- in what circumstances and on what terms can a customer terminate its licence? how easy is it for the customer to migrate from the incumbent system/software to that offered by a new provider if the charges payable to the incumbent provider increase dramatically? Will the costs of termination and transition be less than the increased costs payable to the incumbent provider?
- pricing model – how does the provider price use? Are there different pricing models for different use types? What’s best value for the customer? How are legacy on premise license fees factored into any move to cloud-based deployments and indirect access subscription-based models?
The analysis is not simply a matter of the legal team reviewing the Ts&Cs – a proper, measured and informed analysis requires a cross functional team of lawyers, software engineers, IT and other relevant business groups. It’s also not a once-off analysis at a single point in time – changes to use will need to be assessed against the existing use rights to ensure that no additional fees are payable.
This blog was first published as part of the white paper which you can read in full here: Algo IP: Rights in Code – 2020 Update