Enforcing a software copyright depends on good source code version control. This is because enforcing a software copyright depends on being able to produce the version of software whose copyright is alleged to be infringed. In Indyne, Inc. v. Abacus Technology Corp., No: 6:11-cv-137-Orl-22DAB (M.D. Fla. June 1, 2012), the defendant’s motion for summary judgment of noninfringement was successful because the plaintiff could not satisfy the requirement of producing the version of software alleged to be infringed.
The plaintiff in this case had used its Program Information Management System (“PIMS”) software to deliver information technology services to NASA. The plaintiff registered version 2 of the PIMS software in 2008, claiming a publication date of 2003, but had not retained a copy of version 1, or of version 2 as it existed in 2003. In fact, “by the time of its registration in 2008, [the plaintiff] only had some version adulterated by years of government contracts and customizations and no clear roadmap by which to decipher what portions were paid for by which parties and what alterations were made.” The plaintiff had registered version 2 only after the defendant, having replaced it as NASA’s contractor, copied certain PIMS-related files.
In deciding the defendant’s summary judgment motion, the court did not decide whether the plaintiff had registered a valid copyright, because the court found dispositive the defendant’s argument that the plaintiff was “incapable of producing an intact and original version of the August 29, 2003 PIMS V.2 for purposes of proving substantial similarity between its allegedly copyrighted work and the code allegedly copied by” the defendant. Copyright infringement requires proof of copying, which in the Eleventh Circuit is determined according to the abstraction-filtration-comparison test of Computer Assocs. Int’l v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992). That test abstracts and then filters source code to provide a “golden nugget” that can be compared to allegedly copied code. Here, the court agreed “that no substantial similarity test can be performed because InDyne cannot prove what parts of the PIMS V.2 code presented are protectable due to the fact that the August 2003 PIMS V.2 and PIMS V.1 no longer exist.”
The court rejected the plaintiff’s argument “that it does not bear the burden of showing what is protectable in order to establish a copyright infringement case but may defeat summary judgment by showing sufficient proof that will allow a jury to do so.” The plaintiff had the burden of showing that the Altai test could be satisfied, which it could not meet because it could not produce the allegedly infringed code. The plaintiff argued that it was able to produce 64% of the code, but neglected that in the case it relied on “the court was presented with the original registered code as of the date of publication and that the plaintiff [there] was able to identify the changes made from earlier unregistered codes.” The plaintiff here was able to do neither of those things; it could not produce the code as it existed as of the alleged date of publication in 2003, nor could it identify changes.
One might think that the facts of this case are unusual, but my own experience teaches that they are not. Software vendors and contractors all too often do not securely maintain their software, much less do they practice good version control. It is of course important to update software copyright registrations at least as significant new versions are released, but it is just as important to retain copies and records of specific versions that have been deployed.