On August 8, 2016, the U.S. Office of Management and Budget (“OMB”) promulgated an Open Source Software (“OSS”) policy via the Memorandum for the Heads of Departments and Agencies, M-16-21 (“Memorandum” or “M-16-21”). The high-level purposes of the Memorandum are to promote reuse of federal contractor and employee custom-developed code, and to improve the quality of such software through public participation. To these ends, the Memorandum has two major directives: (1) all custom-developed code must be broadly available for reuse across the federal government subject to limited exceptions (e.g., for national security and defense) and (2) under a three-year pilot program, federal agencies are required to release at least 20% of their custom-developed code to the public as OSS. The intent here is to enable continual quality improvements to the code as a result of broader public community efforts. As discussed below, the requirement to release custom-developed code as OSS may effectively reduce the creator’s ownership rights, and have economic impacts on both the value of ownership and pricing when bidding on government contracts.

Current Agency Responses

As of this writing, at least three federal agencies have responded to the Memorandum: National Aeronautics and Space Administration (“NASA”), General Services Administration (“GSA”) and Social Security Administration (“SSA”).

• The NASA response memorandum of November 6, 2016, states that NASA will i) publish an inventory of its source code projects by December 6, 2016, ii) release 20% of its code as OSS each year, iii) incorporate the Memorandum’s requirements in all new procurements by July 2017, and iv) develop NASA licensing clauses for use with contractor-developed code by October 2017.¹

• On November 3, 2016, GSA published an instructional letter to establish its M-16-21 policies to i) maintain an “open first” policy requiring justification for non-OSS code, ii) use an automated publication process to release code, iii) release OSS through a public-facing version control platform, iv) generally apply M-16-21 mandates to its contracts, and v) exceed the M-16-21 20% OSS release goal.

• On November 6, 2016, SSA published its OSS and Federal Code Reuse Policy, which supports M-16-21 with regard to obtaining unlimited rights in contractor-developed custom-developed code, and making such code available for government-wide reuse. SSA seems somewhat less committed to making its custom-developed code available to the public, and did not cite compliance with the 20% rule. SSA will establish an OSS office that will determine whether particular code should be released. SSA is also concerned, however, that the released code could expose sensitive SSA regulations or policies, expose personally identifiable information, or potentially lead to fraud.

Software Reuse

A primary intent of the Memorandum is to promote software “reuse” so that redundant code efforts may be avoided. The promotion of software reuse has been prevalent in the federal government for at least 30 years during my tenure as a code developer for the Department of Defense (“DoD”). This policy of reuse has faced a number of obstacles. In general, custom-developed code is just that – “custom” – and is not generally applicable to products or requirements other than the ones for which it was developed. Very often, programs will attempt to reuse software modules only to realize that the cost of modifying or retrofitting the custom products for reuse in a new mission is greater than the cost of straight development. This, of course, is especially true if the preexisting custom-developed code is poorly architected and/or poorly documented. Even when custom code is designed for reuse in the form of generic library utilities, the “not invented here” mentality among program managers and programmers is very strong and may impede this initiative. It may be exceedingly difficult to “force” a program manager to reuse preexisting software. The Memorandum’s policies may, however, help overcome these issues by (1) raising awareness of the existence of the custom-developed code via a new Internet portal that the government will establish (www.code.gov) and (2) allowing that custom-developed code to be modified further by any government agency that wants to use it. OSS concepts have proved to be successful in the commercial world, and that culture is spreading to the government software development community.

Licensing Issues

The Memorandum mandates that agencies must procure “unlimited rights” in custom-developed code, including, at a minimum, rights to government-wide reuse and rights to modify the code. With these rights, agencies must make custom-developed code broadly available across the federal government. This is not a new concept. Most government defense contracts for acquisition of custom-developed code already include an unlimited rights clause for software that is developed at government expense (e.g., DFARS 227.7103, Noncommercial items or processes). But while it is one thing for a contractor to grant unlimited rights to the government, it is a different matter to expose the contractor’s proprietary source code to the public. A contractor would need to grant the government the right to sublicense the contractor’s source code to the public under a special OSS license.

The Memorandum also does not make clear who will then control the code baseline. In commercial OSS products, the copyright owner can control the “official” code baseline (e.g., via GitHub) and decide what public changes will be incorporated. In this case, the contractor may have to cede this control to the government, which will reduce the value of any residual copyright ownership in the software creator. Ownership of one’s creation is a cornerstone of American copyright law, which seems to be in tension with a forced OSS license policy.

Another licensing issue involves custom code that may be developed wholly or in part by government employees. As codified at 17 USC § 105, copyright protection is not available for any works prepared by an officer or employee of the federal government as part of that person’s official duties, and such works are thus in the public domain, which means it is not possible to license such works under an OSS license. Thus, publishing such custom-developed code may be tantamount to releasing the code to the public under no licensing rights or restrictions. The NASA Version 1.3 OSS license works around this limitation by making the U.S. government a third-party beneficiary of the license terms where the employee is presumably the licensor. Thus, the government may be able to enforce the terms of the license even though it cannot itself hold a copyright.

What Type of OSS License?

Broadly, there are two popular types of OSS licenses: copyleft and permissive. Copyleft licenses are “protective” in that they require that derivative works of the OSS also be open source products, and the original copyleft license must be applied to these derivative works. In contrast, permissive licenses place no restrictions on the licensee, and thus under such licenses, the licensee may create derivative works that are proprietary and may be marketed and licensed for a fee so long as the original licensor is identified in the derivative works. NASA has stated that it prefers the use of permissive licenses, although its own Version 1.3 OSS license is currently copyleft.

The type of license that becomes the prevailing by-product of the Memorandum remains to be seen. Copyleft seems to be consistent with OMB’s goal of keeping the software improvements available to the public to improve quality. The trend in commercial industry, however, is toward permissive because of license compatibility issues. As OSS is typically produced as a derivative work of other preexisting OSS code, license compatibility between the various component code licenses becomes a significant issue. The terms of one component license may not be compatible with the terms of others. Permissive licenses have fewer compatibility issues because there are essentially no substantive restrictions that are placed on derivative works.

Contract Considerations

This will affect the terms of custom-developed code contracts with the government, and perhaps the price. Contractors are basically being asked to give up more rights in their products than in the current regime, and may be effectively forced to put their source code into the public domain. When contractors grant unlimited rights in software to the government, they still retain rights to further license the software to other governments or to the commercial sector. But under the Memorandum, contractors lose that economic asset, and thus may want to increase their proposal pricing to protect against the inevitable diminution in value of their intellectual property.

Proprietary Libraries

The Memorandum does not extend to licensed proprietary object code modules. Usually, companies do not release the source code of generic or specialized libraries that are not custom-developed code, and which may include “background IP” and trade secret information. Issues undoubtedly will arise, however, when custom-developed code intended as OSS depends on the use of proprietary libraries and will not operate properly in the absence of the proprietary licenses. Such custom-developed code will not really be reusable as intended by OMB, unless paid licenses are also obtained for the proprietary libraries. The reality is that very little custom-developed code will be “stand-alone,” since dependencies on generic libraries are ubiquitous. If those libraries are proprietary, this may frustrate the government’s intent in the Memorandum.

Observations and Practical Tips

The Memorandum is undoubtedly important to all government contractors that develop software, because their ownership rights in software works will be reduced. New FAR and DFARS provisions will likely be drafted for incorporation in contracts, and such regulations will continue the requirements for the government to gain unlimited rights in software, but also extend those rights so that the government may publish such software as OSS. These FAR and DFARS clauses will not, of course, be subject to the bilateral negotiation that is commonplace in the commercial world. Clients should thus understand that while they will still “own” the software they develop for the government, there may be little practical economic value in such ownership.

Further, the OSS license terms under which software suppliers will be required to release custom-developed code will be determined by the government (and presumably include the government as a third-party beneficiary). If permissive OSS licenses are used, suppliers should understand that it is even possible for competitors to make private derivative works of custom-developed code. Such derivative works may then be excluded from any OSS requirement and may be licensed for profit.

When bidding on and negotiating government contracts, creators of custom-developed code may need to increase the price of their work to compensate for the loss of ownership rights, and may need to take steps to protect proprietary components of such work. Any code that was previously developed with private funds should be carefully excluded from source code deliverables, if such code is to remain proprietary. Such proprietary components may need to be separately packaged and licensed as object code libraries to preserve ownership rights. These object code libraries would thus not be considered to be custom-developed code, and would be excluded from the requirement to release their underlying source code as OSS.

¹ NASA currently releases the majority of its OSS under its own license, NAOSA Version 1.3 (discussed further below).