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

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).  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 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.