The Perils of Software Licensing

Taking software licences for granted, without spelling out terms of the agreement, can cost companies a lot of money
AN ORGANIZATION that uses software recently lost a case to a software company over a licensing dispute. The organization had previously paid the software company about $100,000,000 (yes, one hundred million dollars) in licence and maintenance fees; but the software company claimed roughly another $90 million in licensing fees for what it alleged to be additional use of its software, predominantly by the organization’s customers. 
It’s a fascinating — and sobering — case, and there are important lessons to be learned from it; but first, let’s start with some basics.

Why Software Is Licensed
It is worth remembering why, over the past 40 years, software has generally been licensed to users in the marketplace, rather than copies of software simply being sold (much as printed books still are sold). There are several reasons why software publishers prefer licensing to selling copies of their product. One is that most software developers want to control (or eliminate altogether) the resale market for their software. This cannot be done if software is sold (and in the same way is why we have sales of used books; when you buy a book you cannot copy it because you didn’t buy the copyright in it, but you can transfer the book to someone else). By licensing its software the developer can better control the resale and other distribution activities of the software.

Another objective achieved by the licensing model is that the developer maintains control over how the customer uses the software. That is, the developer can require in the software licence agreement that the customer use the software only for processing the data of the customer, and cannot use the software on behalf of third parties such as clients of the customer. Again, if the developer merely sold copies of the software, it couldn’t exercise this type of control.

The Art of Software Pricing
Another advantage given to software developers by the licence model is that they can, in the licence agreement, implement some very sophisticated pricing models. And it is very interesting how pricing mechanisms have evolved over the past few decades.

Back in the 1980s, when software mainly ran mainframe computers, software licence pricing was based largely on the size of the computing power of the mainframe computer. A customer with a larger CPU paid more than a customer with a smaller CPU. When computers shifted to the “distributed” computing model, based on multiple servers (rather than on mainframes), pricing became more complicated as the algorithm shifted to a “per seat” pricing model: a price based on how many employees of the customer used or had access to the software.

This per-seat pricing model, which still exists today, has itself become quite complex, given that the developers have multiple prices based on the nature and quality of use of the software made by different types of employees. So, for example, a “full user” of some software, might attract a price of “x” dollars, and be permitted to use all the functions and features of the software. On the other hand, a "light" user might only generate a fee of 50 per cent of “x” because they access the software on a read-only basis, but can’t input data into the system.

You can see where this is going: namely, to the software licensing world that we have today, in which it can be very challenging for a large organization to keep track of the various types of users and the related fees that should be paid to the software company. Some customers, depending on the type of software and the nature of their organization, try to buy a “companywide” licence that, for a fee, allows the organization to make unlimited use of the software. But this model can come at a very high cost, so it is used rarely.

The Self-Serve Revolution
Your head might already be spinning; but wait, there’s more! Another highly complicating factor is that much software today allows your organization to permit your clients to connect with you. I’ll give you an example, from the case I mentioned above.

According to the facts of the case, traditionally this company’s customers (which were restaurant establishments) ordered product from the company by phoning a call centre of the company and placing their orders with the call centre agents. The call centre reps then accessed the organization’s enterprise resource planning (or ERP) software, which they used to generate the data and records for the product order. In this model of software use, only an employee of the company (the call centre rep) uses and accesses the ERP software; the customer ordering the product does not, as they liaise only with the call centre rep.

But then things got interesting, and complicated, when the company licensed another piece of software, called customer relationship management (CRM) software, which connected the company much more effectively and efficiently to its customers. Each customer restaurant, for example, could now go online and place its weekly order through the company’s website, using the new “self-serve” CRM software module.

When the developer of the ERP software learned that the company’s ERP software system was interacting with its CRM system, the ERP developer commenced negotiations for additional licensing fees, and when a consensual resolution was not reached, it brought litigation against the company. The ERP software developer argued that the CRM software worked in a way (by, among other, things pulling data from the company’s key databases in the ERP software, when instructed to do so by the CRM software) that made each restaurant owner that used the ERP software a user of the software developer’s ERP software as well. And there were many thousands of such customer “users” of the company: hence the claim that the company should pay another $90 million or so in licensing fees to the ERP software developer.

Indirect Access
Based on the facts (much simplified) of this case, after looking very closely at the types of ways the CRM software used by the company interacted with the software developer’s ERP software, the court came to the surprising (in my opinion) conclusion that all the restaurant staff indirectly accessing the systems of the company were in fact a category of user that attracted licensing fees.

This came as a big, and very expensive, shock to the company. They argued that their customers did not access the ERP software; rather, they merely had a link (technically, an application programming interface) to the ERP software, so that the CRM program could exchange data with the ERP program.

The court disagreed, and found for the software company. We do not yet know what the final amount of damages will be that are awarded by the court (this part of the litigation was postponed from the merits of the liability hearing), but it could be significant if the judge accepts the arguments of the software developer on that score as well.

Lessons for the Future
There are a number of useful tips to take away from this recent case. First, as a user of third-party software, you should absolutely take your software licensing (and related payment) obligations very seriously. This case is not an unusual scenario, at least in respect of the approach of the software developer to collecting fees for what it alleges is prior, non-compliant use of its software (although the financial figures are quite a bit larger in this case than in the typical software licence fee dispute).

Second, it is nowadays not a trivial exercise for software licensees simply to understand where the terms of their contract reside. Many software developers load their licences up onto websites, and usually multiple websites. And there is a plethora of forms, and cascading provisions, that purportedly apply. As a user, you should insist on having a hard copy printout of all the terms that will apply, and make the old-fashioned but sensible step of stapling together all the relevant contract terms that make up your licence. If you fail to do this at the front end of your relationship with the software developer, I can almost guarantee you will have a difficult time later on figuring out what constitutes the four corners of your applicable contract.

Third, once you have your agreement distilled into a manageable set of paper-based pages, you must, with laser-like accuracy, parse the “licensing language” so you understand clearly what fees will apply to your organization depending on what use you — and possibly others — will be making of the relevant software.

Ideally, as a software user, you will want the pricing algorithm to apply only when one of your employees actively uses and accesses the particular software. At the other end of the spectrum, you must be very careful if there are fees associated with “third parties who might derive benefit from the software directly or indirectly,” or words to that effect.

One way to achieve certainty and avoid surprises is to attach an “architecture” diagram of the specific configuration of the software you are licensing, and then have the licence agreement confirm what the entire fees are for this specific configuration of use (which may or may not include third parties in your workflow, etc.).

In short, achieving certainty around software licence terms can take some upfront investment of time, but the effort will pay dividends down the road by helping you avoid expensive disputes with your software suppliers. 

George Takach is a senior partner at McCarthy Tétrault LLP and the author of
Computer Law.