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

by Dr. David A. Wheeler

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 section is intended for non-lawyers, to help them understand the basic rules they must follow.

This article was previously published in the Journal of Software Technology (aka Software Tech News), Vol.14, No.1, February 2011. It is part of “Open Technology Development (OTD): Lessons Learned and Best Practices for Military Software”, and thus is released under the Creative Commons Attribution ShareAlike 3.0 (CC-BY-SA) License. A one-page summary of this paper is available from MIL-OSS, and the MIL-OSS 2011 conference had a presentation on releasing OSS.

Before going further, a few definitions and warnings are necessary. In this section, 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)¹. Note that these freedoms can be given by releasing the software under an OSS license,² or by releasing it without any copyright protection. This section 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 questions:

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

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

3. Do you have the necessary other intellectual rights³ (e.g., patents)?

4. Do you have permission to release to the public (e.g., classification and export control)?

5. Do you have the materials (e.g., source code) and are all materials properly marked?

Each of these questions is explained below, followed by a discussion of who can make certain decisions.

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⁴. Thus, it can release the software under any OSS license it chooses, including the GNU General Public License (GPL) and Lesser GPL (LGPL)⁵. 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⁶. 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⁷ and in some cases putting military capability at risk.^{8 9}

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”¹⁰. 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”¹¹

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.

3. Do you have the necessary other intellectual rights (e.g., patents)?

You need to make sure that you have any other necessary intellectual rights. Most importantly, determine if there are any relevant patents, and if so, what the rights to them are.

Other potential issues are trademark, trade dress, government seals, and trade secrets. Trademark issues, if relevant, can often be easily addressed by simply removing the trademark marking. If the contractor has granted copyright or unlimited rights to the government, then the government already has the rights to release that information to the public and is thus not barred from public release by trade secret law.

4. Do you have permission to release to the public?

In particular, for public release the material must not be restricted by:

• Classification. Classified data cannot be legally released to the public. Where this is not obvious, a classification review may be required.

• Distribution statements. A government contracting officer may require certain clauses be included in data (including software) to limit its release; contractors must obey these clauses or cause them to be rescinded.

• Export controls. The Export Administration Regulations (EAR) are issued by the Department of Commerce), and the International Traffic in Arms Regulations (ITAR) are issued by the Department of State. These prohibit the unlicensed export of specific technologies for reasons of national security or protection of trade. Note that cryptography can invoke export control issues.

Export controls can be particularly confusing, and the penalties for failing to comply with them can be stiff (including large fees and jail time). Thus, here are some basics about export control:

• More information about export control regulations under the EAR are provided by the U.S. Department of Commerce Bureau of Industry and Security (BIS) (http://www.bis.doc.gov/ licensing/). In particular, see their pages on “Export Control Basics” and “Licensing Guidance.” Any item (including software) that is sent from the US to a foreign destination, including to any foreign national, is an export – even if the item originally came from outside the US. Certain U.S. exports/re- exports require a license from BIS. A key is knowing whether the item you are intending to export has a specific Export Control Classification Number (ECCN) as listed in the Commerce Control List (CCL), available on the EAR website. In addition, a license is required for virtually all exports and many re-exports to embargoed destinations and countries designated as supporting terrorist activities.

• Similarly, more information about the export control regulations under the ITAR, which implements the Arms Export Control Act (AECA), are provided by the U.S. Department of State Directorate of Defense Trade Controls (DDTC) (http://www.pmddtc.state.gov). In particular, see their page on “Getting Started.” The US regulates exports and re-exports of defense items and technologies, so if what you wish to export is covered by the U.S. Munitions List (USML), a license from DDTC is required. You may file a commodity jurisdiction request (CJ) to determine whether an item or service is covered by the U.S. Munitions List (USML) and therefore subject to export controls related to AECA and ITAR.

The Department of Defense (DoD) does not have authority to grant export control licenses. A contractor may be liable if he or she relies on a DoD official’s permission for export control, because in most cases the DoD does not have this authority. Note that even when an export-controlled release of software is granted, it is often contingent on not releasing the source code, making such “releases” useless for open technology development among all parties.

However, if the DoD determines that something it has purview over is releasable to the public, it is no longer subject to export control. This is because 15 C.F.R. 734.3(b)(3) says that “The following items are not subject to the EAR . . . Publicly available technology and software....” Similarly, 22 CFR 125.4 (13) notes that technical data is exempt from ITAR export controls if it is “approved for public release (i.e., unlimited distribution) by the cognizant U.S. government department or agency or Office of Freedom of Information and Security Review.” Thus, if software is intended to be released to the public, having the cognizant U.S. government department or agency (such as the DoD) approve its public release is often the best way to fully comply with export control regulations.

5. Do you have the materials (e.g., source code) and are all materials properly marked?

The government and upper-tier contractors should ensure that they receive all material, including source code, that they are entitled to. It is all too common to have the right to the source code or related materials, yet not have it and thus be unable to exercise your rights. Source code is necessary for potential OSS release, and it is also necessary to enable competition for future software maintenance bids. Both the government and contractors should make sure that they do not lose the source code, but instead treat it as valuable data (e.g., by creating multiple backup copies in different locations).

Under DFARS 252.227-7014, the definition of “computer software” includes not only “computer programs” but also “source code, source code listings... and related material that would enable the software to be reproduced, recreated, or recompiled.” Thus, a delivery of developed software is supposed to include source code by default. Also, (b)(1)(i) and (b)(2)(i) state that the government has rights to software (whether it was a deliverable or not) if its funds were used.

Source code should only be accepted if is ready for use. Material should only be considered acceptable as source code if it is the preferred form of the work for making modifications to it. Source code should not be accepted if it is just a printout or electronic images of a printout. It should not be accepted unless it is easy to automatically rebuild, e.g., a “make” or similar simple command should be sufficient to recreate an executable. Build documentation should be included with any deliverable, including information on what is required to rebuild it.

It would be best if the source code also included the historical record (e.g., a complete record of each change, who made it, and when), in an electronic form adequate for transfer to another configuration management system. Ideally, the government should have sufficient access to the software engineering environment (SEE) of the contractor, so that the government could monitor changes as they are made.

Ensure that the source code and other materials are marked appropriately. Companies may include restrictive markings on materials, and if those markings are inappropriate, then the markings need to be fixed. Government contract clauses include processes for fixing incorrect markings; follow them. Government and upper-tier contractors need to promptly challenge improperly marked materials due to time limits. For example, contracts using DFARS 227.7203-13 include, in item (d)(3)(i), a challenge time limit of three years after either the final payment or the delivery of software, whichever is later. Also, improper markings tend to be copied into other materials; fixing markings early greatly reduces the effort to fix them later.

Who has authority?

Unfortunately, it is not always obvious who in government or the various contractors can make these decisions. It would be best if the government and contractors could clarify roles, policies, and procedures. In the meantime, the following may be helpful:

• As noted above, when there are multiple contractors or suppliers, 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. By U.S. law (17 USC §201), “Copyright... vests initially in the author or authors of the work... In the case of a work made for hire, the employer or other person for whom the work was prepared is considered the author [and holds the copyright] unless the parties have expressly agreed otherwise in a written instrument signed by them.”

• The 2009 DoD OSS memo does clarify who in the DoD can determine when it should release software as OSS, and under what conditions. It says that “Software items, including code fixes and enhancements, developed for the Government should be released to the public (such as under an open source license) when all of the following conditions are met:

  (1) The project manager, program manager, or other comparable official determines that it is in the Government’s interest to do so, such as through the expectation of future enhancements by others.

  (2) The Government has the rights to reproduce and release the item, and to authorize others to do so. For example, the Government has public release rights when the software is developed by Government personnel, when the Government receives "unlimited rights" in software developed by a contractor at Government expense, or when pre-existing OSS is modified by or for the Government.

  (3) The public release of the item is not restricted by other law or regulation, such as the Export Administration Regulations or the International Traffic in Arms Regulation, and the item qualifies for Distribution Statement A, per DoD Directive 5230.24 (reference (i)).”

• Some organizations do not have a review process for software source code but do have a process for reviewing documents. In these cases, it may be appropriate to submit the source code to the document review process. This is especially relevant for classification review.

Final notes

If the government and relevant contractors intend to release software as OSS, it’s best if that is explicitly stated ahead of time. For example, OSS could be identified as the planned software maintenance philosophy per DFARS 227.7203-2(b)(1). However, since many contracts do not discuss releasing software as OSS, it’s important to understand the default rules for commonly-encountered cases.

If software is released to the public as OSS and it becomes “customarily used by the general public or by nongovernmental entities for purposes other than governmental purposes,” then that software becomes commercial software. This is by both law (41 USC §403) and regulation (e.g., DFARS 252.227-7014(a)(1)). It does not matter if the software was originally developed with government funds, or not. Thus, releasing software as OSS can be a commercialization approach.

The U.S. government and its contractors have released many programs as OSS. I hope that this material helps you understand how you can release software as OSS in a manner consistent with laws, regulations, and contracts.

The publication of this paper does not indicate endorsement by the Department of Defense or IDA, nor should the contents be construed as reflecting the official positions of those organizations.

Footnotes