The benefits of open source software are a driving force in software development now reaching into the world of federal software acquisition. As the name implies, OSS is software that is distributed in human-readable, source code form so that any skilled programmer can understand its design and make modifications to the software.
Two major benefits are that OSS code can be readily “reused” in new contexts, and the software community may contribute bug fixes and enhancements to the software. The downside to software copyright owners is the possible loss of ownership rights, control and valuable trade secrets by releasing the source code.
The federal government recently issued its OSS policy via the U.S. Office of Management and Budget Memorandum for the Heads of Departments and Agencies, M-16-21 (“Memorandum” or “M-16-21”) published in August 2016. The memorandum aims to promote reuse of software that is custom-developed for the government, and to improve the quality of such software through public participation.
The memorandum directs that (1) all custom-developed code must be available for reuse within the government subject to limited exceptions (e.g., national security) and (2) under a three-year pilot program, federal agencies must release at least 20 percent of their custom-developed code to the public as OSS.
As of this writing, National Aeronautics and Space Administration, General Services Administration and Social Security Administration have released responses as to how they will comply with M-16-21.
Promotion of software “reuse” is a cost-saving measure intended to avoid redundant coding efforts. In practice, reuse is not always as effective as hoped if the cost of modifying or retrofitting custom products for reuse is greater than the cost of straight development. This is especially true if the pre-existing code is poorly architected and/or 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 may impede this initiative.
The memorandum’s policies may, however, help overcome these drawbacks by raising awareness of custom-developed code via a new Internet portal at www.code.gov and by directing reuse. OSS concepts have proved successful in the commercial world, and that culture is spreading to the government development community.
The memorandum mandates that agencies must procure “unlimited rights” in custom-developed code, including rights of government-wide reuse and code modification. But M-16-21 goes a step further by requiring a federal contractor’s proprietary source code be released to the public. Contractors will need to grant the government the right to sublicense the contractor’s source code to the public under a special OSS license.
There are also issues with control of 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, a contractor may have to cede control to the government, which will reduce the value of residual copyright ownership.
Ownership of one’s creation is a cornerstone of American copyright law, which seems to be in tension with a forced OSS license policy. Contractors are basically being asked to give up more rights in their products and may be effectively putting 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. But under the memorandum, contractors lose that economic asset, and they thus may increase pricing to protect against the inevitable diminution in value of their intellectual property.
Another pitfall relates to proprietary “background IP” libraries that are not released as OSS but which provide common functions upon which the OSS relies. In this case, the OSS 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 is “stand-alone,” since dependencies on generic libraries are ubiquitous. If those libraries are proprietary, this may frustrate the intent of the memorandum.
How to compensate
The memorandum is undoubtedly important to all government development contractors because their ownership rights in software works will be reduced. Software contractors 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.
Creators of custom-developed code may thus need to increase prices to compensate for the loss of ownership rights, and may need to take steps to protect particular proprietary components. Any code that was previously developed with private funds will likely be carefully excluded from source code deliverables, if such code is to remain proprietary. Such proprietary common components may be separately packaged and licensed as object code libraries to preserve ownership rights.
Robert J. Burger is special counsel with McCarter & English, LLP in matters relating to software and technology licensing transactions, SaaS/IaaS/Cloud computing, commercial and government software development contracts, encryption, security, privacy, copyright litigation and other technical matters. He has a dual career and is also a senior project consultant on software security and command/control development projects for the U.S. Army.