Preventing and Predicting Software License Disputes
Software licenses are critical enablers of entrepreneurship and product excellence. Yet they are also common sources of litigation between erstwhile partners. Licensing disputes arise when inartful drafting combines with the peculiarities of software and its distribution to complicate the computation of royalties. Good licensing practices are thus a critical aspect of business strategy. Understanding some common pitfalls of licensing can confer both offensive and defensive strategic benefits.
Commercially viable software packages are complex products containing many components. Licensing plays a critical role in their development and marketing. Only the largest software companies can develop systems entirely in-house, and even they often choose to license utilities or add-ons. For small consumer-facing companies, licensing offers a cost-effective way to improve performance or to enhance product lines. And licensing allows even smaller companies to focus on niche technologies, profitably developing products unlikely to interest end users—but quite likely to enhance the products and/or offerings of others.
Software licenses are thus critical enablers of entrepreneurship and product excellence. Yet they are also common sources of bitter litigation between erstwhile partners. Licensing disputes often arise when inartful contract drafting combines with the peculiarities of software and software distribution to complicate the computation of royalties. Fortunately, many of these disputes conform to predictable patterns. Software counsel who learn the issues likely to arise as their licenses age and evolve will improve their prospects of avoiding costly litigation. This article provides an overview of these issues.
Sources of Dispute
The Complexity of Software Products
Software engineering design typically begins with a modular schematic outlining the functions necessary for a product to operate, and showing the integration of those functions into a coherent system. It then implements each functional requirement as a standalone component before integrating them into a working product. Along the way, the engineering team may choose to license selected functional components from third-party developers.
Although this high-level description of software engineering differs little from other types of engineering design, two features unique to software pose immediate complications: seamless integration and costless replication. The boundaries between products, or even between a module’s “inside” and its “outside” are far blurrier in software than in most other contexts. And anyone who licenses a single copy of software suitable for integration also possesses the technical capability to produce nearly infinite copies at nearly zero cost.
These features immediately complicate royalty calculations. Questions concerning whether or not a particular software product contains a licensed software or algorithmic technology, and if so how much of the licensed product is “being used,” are necessarily more contentious than corresponding questions in other industries.
The challenge of drafting a sufficiently precise software license combines the difficulties facing all contract drafters with the unique complexity of software products and the speed of technological (and terminological) change in software. Parties negotiating contractual relationships typically spend more time and resources negotiating terms than ensuring that the contractual language reflects those terms accurately and unambiguously. The complexity of software products can add even further ambiguities. The not-infrequent disputes about the location and/or the quantity of the licensed technology place a premium on delineating the technology’s boundaries and on determining the basis for a copy count.
Furthermore, terminology tends to change more quickly in computing and software than in legal drafting, thereby complicating the challenge of maintaining linguistic integrity through contractual continuations and revisions. By the time a dispute arises, technical words may no longer mean precisely what they meant at the moment of drafting; insights into technological history and development are often necessary to disentangle ambiguities and resolve disputes.
Distribution and Revenue Models
Every new configuration of computing infrastructure gives rise to new models of software distribution—which, in turn, give rise to new business models for software sales. Licenses negotiated contemplating software sold on physical media may have unanticipated consequences when applied to software sold by download, leased from an Application Service Provider (ASP), or circulated freely to generate service business (to name but a few of the distribution models currently in use throughout the software industry).
The types of licenses available under any generation of technology are thus likely to vary greatly. This evolution and variance is wonderful from the perspective of technological development, but potentially problematic from the perspective of contractual obligation. Because while it is one thing for a software company to experiment with different distribution, revenue, and tracking models with its own products, it is a different matter for it to conduct similar experiments with products belonging to a third party. As a result, mechanisms for calculating and tracking royalty-bearing components may restrict a software company’s ability to experiment with the distribution and revenue models that it feels are most appropriate given the state of technology. Alternatively, they may vary their distribution, tracking, and revenue models in ways that impede compliance with their contractual obligations. Such a decision, while rational from a business perspective, may create significant gaps in the data necessary to compute royalties—and thus serve as a focal point in subsequent licensing disputes.
Royalty-bearing licenses invariably require prodigious record keeping, and in anything other than a very small organization, numerous groups and divisions must communicate effectively before accurate royalty assessment is even possible. At a bare minimum, Engineering must explain its understanding of the licensed technology and enumerate all products that incorporate it; Sales must verify its understanding of the sorts of licenses available, and align its understanding of “products” with the engineering view; Legal must confirm that the Engineering and Sales views of products and obligations match those delineated in the licenses; and Accounting must demonstrate its understanding of potentially complicated royalty formulas. Any discrepancies among these groups’ interpretations of obligations, products, formulas, or product counts can lead to inaccurate royalty calculations.
On top of these general bookkeeping challenges, the typical approach to royalty-bearing licenses adds an interesting asymmetry to the relationship: in nearly all cases, licensees (i.e., buyers) maintain internal records and provide licensors (i.e., sellers) with summary reports and royalty checks. Licensors who question these royalty reports rarely have much recourse short of ordering a third-party audit—a potentially expensive proposition likely to sour an ongoing business relationship. Should the parties ever find themselves in litigation, however, the atmospherics will invert the asymmetry, as even common errors that led to underpayments may appear more significant than corresponding errors leading to overpayments.
The Bottom Line
Though most software licenses provide licensors with some right to audit the licensee’s books, relatively few licensors avail themselves of this right while their relationships are flourishing. When royalties fall off and the relationship appears imperiled, however, licensors do order audits that invariably find at least some underpayment and some gaps in the data. While sound economic techniques for gap filling often exist, some circumstances can lead to widely divergent assessments of the amounts due. In such cases, costly litigation may prove hard to avoid.
Prevention and Defense
Alternatives to Royalty-Bearing Licenses
Licenses that base royalties on either sales volume or revenues align many of the incentives of the licensor and licensee. They also tie compensation to metrics rooted in actual performance rather than in projection; fixed fee purchases of any sort require both parties to forecast the value of a product still in development. Royalty-bearing licenses thus reduce negotiations to the allocation of actual revenues, and defer compensation until after their arrival. They also, however, bear high transaction costs, including all of the difficulties outlined above as well as the possibility of contentious litigation.
Software counsel who fail to incorporate projected transaction costs into their calculations may choose sub-optimal forms of contracting, despite the numerous ways to acquire rights in a technology that do not involve royalties. Outright acquisitions of software, algorithms, code, or even companies are all effective and popular approaches, as are fees fixed on some basis other than units sold or revenues received. Each of these approaches presents its own upsides and downsides, but each warrants consideration before adopting a royalty-based license as an inertial default.
Drafting is an art form that benefits from experience and expertise. Careful analysis of all applicable legal and technical terms, coupled with a detailed, sequestered definitions section can make a world of difference in subsequent litigation—as well as during contract renewal and revision discussions. At the same time, however, such drafting can raise the costs of contracting. Once again, a bit of attention to expected transaction costs may help inform parties as to where such an investment is warranted.
Royalty calculations, as noted above, require coordination among the licensor’s legal, engineering, sales, and accounting teams. Of course, royalty calculations are hardly the only reasons to maintain healthy communications among these groups, and there is relatively little downside to ensuring that internal communications are effective. Still, moderate communication improvements are often possible given focus. Licensing discussions can provide such a focus.
Record keeping is prone to honest errors. Licensees who catch their own errors typically correct them, and where necessary make up any inadvertent underpayments—a good faith requirement without which the entire notion of a royalty-bearing license would make little sense. Licensees who catch errors that cut against them also correct such errors, and typically reduce their future payments by an appropriate amount. Licensees, however, typically provide scant explanation for their corrections, for the simple reason that they are rarely required to do so. It is quite common for royalty reports to contain only summary statistics and a check for a bottom-line amount, with little in the way of explanatory text or annotation. Licensors typically accept the bottom-line payment without paying undue attention to individual line items unless and until the relationship sours. Should the relationship sour to the point of litigation, however, errors and corrections provide likely subjects for argument and analysis. Licensees may help prevent such disputes by providing some explanation of all errors immediately upon correction.
Merger and Acquisition
Every acquisition arrives with its share of headaches. Royalty-bearing software licenses may be among them. Because contractual wording can reflect cultural differences, even the merger of two software companies that both took meticulous care to draft only consistent licenses may result in an internally inconsistent merged system. Terms in different contracts drafted at different times within the context of different license cultures may mean different things. Licensing practices that one company favored may be disfavored by the other. And all of that is aside from the typical cultural challenges inherent in integrating engineering, sales, and accounting personnel under unified protocols.
Of perhaps even greater significance, however, the merging of two product lines can alter longstanding relationships throughout the industry. License partners of the acquired organization may suddenly find themselves negotiating with strangers. License partners of either side may discover that their longstanding partner just merged with their own direct competitor—creating understandable unease about the long-term health of their relationship. Numerous contracts may require immediate renegotiation. Royalty-bearing software licenses, as particularly complex contracts, are likely to pose particularly complex questions.
All economic decisions rest upon projections and calculations of expected costs and benefits. Most of the preventative steps outlined above entail at least some up-front costs. The decision to incur such costs makes sense only if it reduces overall expected costs, including the cost of litigation times the likelihood of litigation. Once litigation has started, similar calculations may guide litigation and settlement strategy. As in all such matters, early attention to maximum exposure can help direct strategic discussions.
Software licenses, and in particular royalty-based software licenses, are prone to litigation. This article covered some of the common causes of such disputes, as well as some steps that counsel can take to avoid prolonged, costly lawsuits. Such “software licensing hygiene,” however, also serves an important social and economic purpose far greater than the avoidance of litigation. Royalty-bearing software licenses are critical to the health of the software industry. Good contracting practices promise the best way to ensure their continued use—and to reduce their potential for misuse as bludgeons in resolving commercial disputes.
ABOUT THE AUTHOR: Bruce Abramson
Bruce Abramson, Ph.D., J.D., has written several books and monographs, and has contributed over forty articles to the scholarly literature of Computer Science, Business/Management, and Law. He may be reached at bda at bdabramson dotcom.
Copyright Bruce Abramson, JD, PhD
More information about this article at Bruce Abramson, JD, PhD
Disclaimer: While every effort has been made to ensure the accuracy of this publication, it is not intended to provide legal advice as individual situations will differ and should be discussed with an expert and/or lawyer.For specific technical or legal advice on the information provided and related topics, please contact the author.