Software licensors as government contractors

Author:

 

Publication August 22, 2018

Software licensors who license their commercial software to the US government may be interested in two recent developments: a ruling by the Armed Services Board of Contract Appeals, construing the terms of a CiyaSoft Corporation software license agreement; and the new disclosure obligations to the Secretary of Defense if the software code has been reviewed or accessed by a foreign government, as a result of the 2019 National Defense Authorization Act (HR 5515).

CiyaSoft license matter

Appeals of CiyaSoft Corp. Under Contract No. W91B4L-10-P-14785, ASBCA nos. 59519 and 59913 (Armed Servs. Bd. of Contract Appeals, June 27, 2018)

A. Background

CiyaSoft licenses translation software, including software that translates English into Dari and Pashto, and vice versa—clearly of interest to the Army personnel stationed in Afghanistan. The government had previously licensed CiyaSoft products, but the contract officer who purchased the software licenses at issue had never purchased software for the government prior to this order. When the government awarded the contract, it sent its standard contract terms and the purchase order for 20 copies to CiyaSoft.

Those readers who are familiar with government contracting are probably aware that the Federal Acquisition Regulations (FARs) contain a few provisions specifically relating to the government’s acquisition of software. Among other provisions, the FARs include the government’s policy to acquire commercial software pursuant to the license customarily provided to the public, to the extent consistent with federal law. (FAR § 12.212) With respect to “clickwrap” or “shrinkwrap” licenses, FAR § 52-212-4(u)(ii) permits such agreements but prohibits indemnification provisions, which would violate the federal Anti-Deficiency Act, 31 U.S.C. § 1341.

Once CiyaSoft received the government’s purchase order for 20 copies of its translation software, CiyaSoft decided on its own to delete the online registration requirement for each user, in order to facilitate use on secured government computers that had no Internet connections (and in Afghanistan where Internet connections can be problematic). Deleting this registration requirement meant that users could make and install multiple copies of the software. Therefore, to help track the software, CiyaSoft modified the software to include a unique version number and the contract number on each copy of the software. CiyaSoft also included a new term in the license agreement it shipped with the CDs: that the government had to provide to CiyaSoft a list of software activations.

CiyaSoft provided the license agreement to the government in three ways:

  1. The full license was included in the box containing the 20 CDs of the software. The license agreement included both the activation list requirement as well as a statement that each CD could be used for one software installation only;
  2. a shorter version of the license was included with each CD, which did not include the activation-list requirement, but did include the single-installation limitation; and
  3. a “clickwrap” license agreement that each user had to agree to in order to activate the software. This license contained neither the activation-list requirement nor the single-installation restriction.

In accordance with the purchase order terms, CiyaSoft did not ship the software to the contract officer, but instead to another Army officer, presumably located in Afghanistan. Soon after the CDs were delivered in October of 2010, CiyaSoft began seeing multiple registrations for the same product ID number, and began receiving technical support requests from non-registered users. CiyaSoft tried contacting the contract officer, but he was first on leave and then transferred.

In November of 2013 (three years later), CiyaSoft wrote to the Army, expressing concern about violations of the license agreement, and requesting the names of people and organizations that may have used the software pursuant to the agreement. The government responded that it had conducted a preliminary review and had not found anyone using the software.

In January of 2014, CiyaSoft again wrote to the Army, this time stating that it was considering legal action for breach of contract. The government responded that it conducted a thorough review and found no copies of the software.

In April of 2014, CiyaSoft filed a claim with the then-current contract officer, claiming breach of contract, copyright infringement, and patent infringement. CiyaSoft claimed $17 million in damages, based upon an estimated 37,000 translators/interpreters working for the government and a claim that 10% of those individuals had obtained the CiyaSoft software.

B. The contract officer determination

The contract officer denied the claim in June of 2014. CiyaSoft filed a notice of appeal in August. In defending the appeal, the government argued that the license agreement was not part of the government contract, and that CiyaSoft had not proven that the government had breached the government contract. (The Armed Services Board of Contract Appeals noted that the patent infringement claim was dismissed due to the board’s lack of jurisdiction over patent claims.)

C. The Armed Services Board of Contract Appeals

1. Was there an enforceable agreement?

With respect to the license agreement, the appeals board referred to the government’s policy of accepting commercial license terms, except for violations of federal law. The appeals board found that, if “assent to terms of a contract is largely passive, as is usually the case with software license agreements, courts have often based the decision of whether to enforce the contract on whether a reasonably prudent officer would be on ‘inquiry’ notice of the terms at issue.”

The appeals board found that the contract officer had a duty to inquire as to the license agreement terms, and found that the contract included the full license agreement shipped with the software. The appeals board also held that the government could be bound by a software license agreement it had neither negotiated nor seen prior to receipt of the software, as long as the terms were consistent with those customarily provided by the vendor and did not violate federal law.

The government argued that CiyaSoft’s changes to the software—deletion of the online registration requirement and inclusion of the version and product ID numbers—mean that this software was not consistent with the software the vendor typically offered commercially. The appeals board disagreed, finding that the changes did not “affect the core purpose of the software” and were “non-material.”

2. Elements of a breach of contract claim

In order to assert a breach of contract claim, the appeals board found that CiyaSoft had to prove four elements:

  1. A valid agreement existed between the parties;
  2. an obligation or duty existed on the part of the government arising out of the contract;
  3. a breach of that obligation or duty; and
  4. damages caused by the breach.

As described above, the appeals board found that CiyaSoft had established the first element, a valid agreement. With respect to the second element, the board found that the long and short versions of the license agreement contained a duty to use the software on only one computer, and the long version also contained a duty to provide a list of activations. Therefore:

We hold that in the circumstances of contract for a single-use software license, an implied duty exists that the licensee will take reasonable measures to protect the software, to keep it from being copied indiscriminately, which obviously could have a deleterious effect on the ultimate value of the software to the licensor.

CiyaSoft also claimed that the government had breached the agreement by failing to maintain a point of contact during the period of the agreement. The appeals court agreed that this claim could also be the basis for a breach of contract claim:

It is self-evident that a party’s performance of a contract could require communication with the other party to the contract and that failure to facilitate same, by maintaining a point of contact, could be a breach of the implied duty of good faith and fair dealing through a lack of cooperation.

Nevertheless, the appeals board found that CiyaSoft had not proven a breach of these implied duties. The board found that there was no evidence that CiyaSoft’s difficulties in reaching the contract officer were proof of a breach of the implied duty. In addition, the board ruled, CiyaSoft had never proven what the government actually did with the software, and there was no evidence that more than 17 unaccounted-for copies of the software were installed.

The appeals board did, however, find that the government breached the obligation to install only one copy per computer, when CiyaSoft showed the same copy was installed on two computers, and the registration was linked to the same government email address. In addition, the government did not contest CiyaSoft’s claim that it failed to provide a list of activations.

As a result, the appeals board ruled that CiyaSoft had been damaged by multiple installations “by depriving it of the license fees the government would have had to otherwise pay to obtain a valid copy of the software.” In addition, the lack of the activation list “may have damaged” CiyaSoft by “undermining its ability to have proven that more copies of the software than were licensed were used by the government.”

Therefore, the appeals board sustained CiyaSoft’s breach of contract claim, and remanded the matter back to the parties for resolution of the amount of damages due CiyaSoft.

2019 National Defense Authorization Act (HR 5515)

Formally known as the John S. McCain National Defense Authorization Act for Fiscal Year 2019, this 1,254-page bill passed Congress on August 3, 2018 and was signed by the President on August 13, 2018, to become Public Law 115-232. Of particular interest to software licensors who deal with the federal government’s defense agencies are Sections 1638, 1639, and 1640, relating to “obligations to foreign governments.”

The new law prohibits the Department of Defense from using any “product, service, or system relating to information or operational technology, cybersecurity, an industrial control system, a weapons system, or computer antivirus provided by a person if that person discloses to the Secretary of Defense” whether that “person” has allowed a foreign government to review or access the code for the product or service or is under any obligation to do so “as a condition of entering into an agreement for sale or other transaction with a foreign government or with a foreign person on behalf of such a government.” In addition, if that “person” is a US “person” or an affiliate, that “person” also needs to disclose whether that person has sought or holds a license under EARs or ITARs. These disclosures are expressly exempt from FOIA or similar state laws.

The government will also be revising its procurement contracts to add a clause requiring that the information described above be disclosed during the term of the agreement, including “any mitigation measures taken or anticipated.” Those mitigation measures will be determined by the Secretary of Defense and can include conditioning the procurement agreement “on the inclusion of enforceable conditions or requirements that would mitigate such risks.” Within two years, the Secretary of Defense must develop a third-party testing standard for commercial off-the-shelf software and services “to use when dealing with foreign governments.”

Takeaways

Software licensors that sell to government customers may wish to review their standard license terms, to see how indemnification and implied claims are handled. Software licensors that are government defense contractors—even if they only sell to US customers—should consider checking with their supply chains for compliance with the new disclosure obligations. Note that the new law’s condition of requiring disclosure to a foreign government as a condition for entering into an agreement for sale or other transaction apparently means that traditional open source software would be excluded.


Recent publications

Subscribe and stay up to date with the latest legal news, information and events...