Ambiguity is one of the worst fears of a contract drafter. Despite good intentions, invariably contract terms will be capable of being understood in more than one way, or are simply doubtful, equivocal, uncertain or absent. A seminal treatise on “The Language of the Law” began: “The law is a profession of words.” Unsurprisingly then, one of the law’s most important functions is to resolve interpretative problems created by the use of ambiguous language in contracts; however, by the time a court is deciding the issue, costly litigation may have taken years. In a recent case in Pennsylvania, parties to a software development and license agreement confronted this unfortunate truth, and both left unsatisfied. See Apacheta Corp. v. Lincare, Inc., No. 16-2030, 2017 WL 5901085 (E.D. Pa. Nov. 30, 2017). In this case, a dispute over software deliverables led to litigation in which the court denied both parties’ motion for summary judgment because the ambiguity in the underlying agreement created an issue of fact as to what the developer was required to deliver, and if the developer made a sufficient delivery, its entitlement to damages.

Facts and Procedural Background

Plaintiff Apacheta Corp. is a software development company. It entered into a multi-stage development agreement (the agreement) with defendant Lincare, Inc. Apacheta would develop software to manage Lincare’s medical equipment delivery system. Specifically, Lincare hired Apacheta in part to develop software that would integrate Lincare’s “Active Directory.” The first phase of the agreement involved collaborative work to develop the software, and upon approval of Lincare, would transition into the second phase wherein Apacheta would license the software to Lincare. The agreement’s initial term was three years and it contained an integration provision, as well as a right-to-cure opportunity for both parties. The right-to-cure provision afforded both parties the right to remedy any alleged breach within a 30-day written notice period. The agreement also included a “Statement of Work” (SOW) outlining the framework for the software Apacheta agreed to develop. The SOW in turn had a list of features to be incorporated into the software.