Publicly Releasing Open Source Software Developed for the U.S. Government

This article summarizes when the U.S. federal government or its contractors may publicly release, as open source software (OSS), software developed with government funds.  This article is intended for non-lawyers, to help them understand the basic rules they must follow.

Before going further, a few definitions and warnings are necessary.  In this article, the term “government” means the U.S. federal government.  “You” means the government organization or contractor who wants to release software to the public as OSS.  “Releasing to the public as OSS” means (1) releasing the software source code to the general public (such as through a public website) and (2) giving its users the freedom to use it (for any purpose), study it, modify it, and redistribute it (modified or not)^[1].  Note that these freedoms can be given by releasing the software under an OSS license,^[2] or by releasing it without any copyright protection.  This article is not legal advice, and variations of specific facts can produce different results.  Also, note that government contracting is very different from commercial practices; do not presume that commercial practices apply.

To determine if you can release to the public some software developed with government funds as OSS, you must answer the following five questions:

1. What contract applies, what are its terms, and what decisions have been made?

First, find the contract and find what terms apply, particularly which data rights clauses apply.  Most contracts use one of a small set of standard data rights clauses, but you need to find out which clauses apply, and if the contract grants exceptions.  If the clause text is different (e.g., older) than the clauses discussed here, or makes an exception, then the contract (if legal) governs.  Also, determine what data rights decisions have been made by the contracting officer.

2. Do you have the necessary copyright-related rights?

The following table shows the default copyright-related rights for common circumstances.  The first row is a special case, where a federal employee develops the software as part of his or her official duties.  Later rows discuss the typical impact of common data rights clauses from the Federal Acquisition Regulation (FAR) or the Department of Defense FAR Supplement (DFARS) (but note the dates):

These are the general rules, but you must examine your specific circumstances to determine exactly what you can do.  There are details in the FAR and DFARS clauses not emphasized here, and the contract can change from these defaults to something very different.  Some contracts will use different versions of the FAR and DFARS clauses, so check to see if there are any relevant differences.  Note that some other agencies (like NASA) have FAR supplements, which are not covered here.

The table above only applies to software that was either (1) developed by a government employee as part of his or her official duties or (2) developed by a government contractor (directly or indirectly) as part of a government contract.  Such software may include or depend on other software, such as commercial software, that does not meet these criteria.  When a system includes commercial software, the commercial license applies to those components, and everyone must comply with their license terms.  Commercial software includes any software that is used for at least one non-governmental use and has been sold, leased, or licensed to the general public (per 41 USC §403 and DFARS 252.227-7014(a)(1)), so nearly all publicly-available OSS is commercial software.  Commercial software with minor modifications is still considered commercial software.

In many cases the contractor receives copyright.  When there are multiple contractors or suppliers (e.g., a lead integrator and subcontractors), the legal arrangements between the organizations determine which contractors/suppliers are legally allowed to assert copyright.  Lead contractors do not necessarily receive copyrights from their subcontractors and suppliers.  Note that the government can receive and hold copyrights transferred to it, per 17 USC §105.

In many cases the government is not the copyright holder but has unlimited rights (see rows B, D, E, and I).  If the government has unlimited rights, it has essentially the same rights as a copyright holder for purposes of releasing the software as OSS^[3].  Thus, it can release the software under any OSS license it chooses, including the GNU General Public License (GPL) and Lesser GPL (LGPL)^[4].  When the government has unlimited rights but is not the copyright holder, there are a few actions it cannot take, e.g., the right to transfer or assign rights, and standing to sue in court over copyright infringement^[5].  However, for the purposes here these are technicalities; the key point is that the government can release the software as OSS, under any OSS license it chooses, once it receives unlimited rights.

The government should be extremely wary of receiving less than unlimited rights for software or systems it paid to develop.  For example, some contractors will intentionally embed components over which they have exclusive control, and then design the rest of the system to depend on those components.  When the government has less than unlimited rights, it risks creating a dependency on a contractor, rendering competition for that system meaningless^[6] and in some cases putting military capability at risk.^{[7] [8]}

Some have misunderstood U.S. law and policy as requiring the government to mindlessly accept proposals which give less than unlimited rights for systems developed though government funding.  It is true that 10 U.S.C. §2320(a)(2)(F) states that “a contractor or subcontractor (or a prospective contractor or subcontractor) may not be required, as a condition of being responsive to a solicitation or as a condition for the award of a contract, to … sell or otherwise relinquish to the United States any rights in technical data [except in certain cases, and may not be required to ] refrain from offering to use, or from using, an item or process to which the contractor is entitled to restrict rights in data”^[9].  However, this is not the whole story.  “If the Government has properly required certain data or software in a solicitation, it is entitled to certain rights in accordance with the statute and an offer failing to propose at least those rights could be held unacceptable.”  What is more, the government may (and should) evaluate proposals “on the basis of data rights and giving higher ratings to offerors willing to provide more than the bare minimum rights”^[10]

Under many of the FAR (but not DFARS) clauses, if the government agrees to allow contractors to assert copyright, the government loses many of its rights, forever, to software that the government paid to develop (see rows B, C, L, and M).  This loss of rights can be quite detrimental to the government.  What’s more, it creates a difficult decision for a contracting officer to make, as the contracting officer must anticipate all possible future uses to make a good decision (something that is difficult in practice).  The usual DFARS clause (252.227-7014) avoids this problem; in this clause, typically the government ends up with unlimited rights to software it paid to develop (in some cases after a delay), and the contractor has copyright, enabling both parties to take actions such as releasing the software as OSS.

Here are a few notes about specific clauses:

• Under FAR 52.227-14 (rows B and C), the government can grant a contractor the right to assert copyright, at which point the contractor gains rights but the government permanently loses rights.  Per FAR 27.404-3(a)(2), the government should grant this request only “when [that] will enhance appropriate dissemination or use.”  Government officials should not grant this automatically, as doing so dramatically reduces the government’s rights to software that the government paid to develop.  The government could choose to grant this permission on condition that the software be immediately released to the public under some specific OSS licenses (with the license agreed upon as part of the condition for release).  In such a case, public release as OSS would be used as a method to enhance dissemination and use.  Deliverables can include data not first produced in the performance of the contract, per (c)(2), but in this case it is not clear to this author if the government can release software as OSS.
• Under DFARS 252.227-7014 (rows D-G), the contractor normally gets copyright.  The government gets the same rights as a copyright holder (via unlimited rights) if (1) the software was developed exclusively with government funding or (2) the funding was mixed and five years have passed after the relevant contract or contract modification that caused its development was signed.  The government should beware of situations where the contractor attempts to deliver software that vitally depends on some component that they developed entirely at private expense.  Such a dependency can inhibit any future competition for maintenance, as by default the government only has restricted rights to such components.
• Under DFARS 252.227-7018 (rows H-J), the government typically gets unlimited rights to software not exclusively developed at private expense, but only after five years after the project has completed (note that this is a different starting time than DFARS 252.227-7014).  Amendment I can remove this right as long as the product is “reasonably available to the public for purchase.”
• FAR 52.227-17 (rows L-N) is, according to FAR 27.409(e), to be used for software for the “government’s internal use” or where “there is a need to limit distribution” or to “obtain indemnities for liabilities.”  However, purposes change; software originally developed for the “government’s internal use” may become software that should be publicly released as OSS.  This document simply describes what is allowed, rather than the expectations of the original contract authors.
• DFARS 252.227-7020 (rows O-P, the special works clause) is discussed in DFARS 227.7106.  That discussion does not specifically mention software, but the -7020 clause can be used for software.  DFARS 227.7106(2) says it can be used for “a work” and is not just limited to “technical data.”  This clause should be used if the government must own or control copyright.  For example, it might be appropriate if the government wishes publicly release OSS and be able to (1) directly enforce copyright in court, and/or (2) provide indemnification.