Discuss | Edit | View PDF of Policy

Source Code Policy

Introduction

The U.S. Government is committed to improving the way Federal agencies buy, build, and deliver information technology (IT) and software solutions to better support cost efficiency, mission effectiveness, and the consumer experience with core Government programs. Each year, the Federal Government spends more than $9 billion on software through more than 50,000 transactions.1 A large portion of Government software—including proprietary, open source, and mixed source options—is commercially-available “off the shelf” (COTS) software2 that is developed and owned by either private vendors or an open source provider, requiring no additional custom code to be written for its use in the Federal Government.3

However, when Federal agencies are unable to identify an existing Federal or COTS software solution that satisfies their specific needs, an agency may choose to develop a custom software solution on its own or pay for its development. When agencies procure custom-developed code, they are not always in a position to make their new code broadly available for Federal Government-wide reuse.4

In some cases, agencies may have difficulty establishing under the terms of the contract that the software was produced in the performance of a Federal Government agreement. Furthermore, even when agencies are in a position to make their code available on a Government-wide basis, they do not routinely make their source code discoverable and usable to other agencies in a consistent manner. These shortcomings can result in duplicative acquisitions for the same code and inefficient spending of taxpayer dollars. This policy seeks to address these challenges by laying out steps to help ensure that new custom-developed Federal source code be made broadly available for reuse across the Federal Government.5 This is consistent with the Digital Government Strategy’s “Shared Platform” approach, which enables Federal employees to work together—both within and across agencies—to reduce costs, streamline development, apply uniform standards, and ensure consistency in creating and delivering information.6 Enhanced reuse of custom-developed code across the Federal Government can have significant benefits for American taxpayers, such as reducing Federal vendor lock-in,7 decreasing duplicative costs for the same code, increasing transparency across the Federal Government, and minimizing the challenges associated with integrating large blocks of code from multiple sources.

While the benefits of enhanced Federal code reuse are significant, additional benefits can accrue when code is also made available to the public as Open Source Software (OSS). Making code available with an OSS license can enable continual improvement of Federal code projects when a broader community of users implements the code for its own purposes and publishes bugs and improvements. A number of private sector companies have already shifted some of their software development projects to an open source model,8 in which the source code of the software is made broadly available to the public for inspection, improvement, and reuse. In fact, several Federal agencies and component organizations also have already begun publishing custom-developed code under open source licenses or in the public domain, as discussed further below. Moreover, the Administration made a commitment, as part of its Second Open Government National Action Plan,9 to develop an Open Source Software policy that, together with the U.S. Digital Services Playbook,10 will support improved access to custom code developed for the Federal Government. This policy fulfills that commitment in an effort to improve U.S. Government software development and make the Government more open, transparent, and accessible to the public. Just as the Administration’s Open Data Policy11 contributed to the creation of valuable and successful private businesses and services based upon open data released by the Government,12 improving access to taxpayer-funded source code can help facilitate similar results predicated on OSS.

Footnotes

  • 1Building on Progress: Improving the Way the Government Buys IT, Office of Management and Budget, Executive Office of the President, December 21, 2015. https://www.whitehouse.gov/blog/2015/12/21/building-progress-improving-way-government-buys-it ↩
  • 2For purposes of this policy, the term “COTS” also generally encompasses commercial item solutions.↩
  • 3See “Appendix A: Definitions” for definitions of many of the technical terms used in this section and throughout this policy.↩
  • 4Additional contract guidance will be available through Project Open Source.↩
  • 5Limited exceptions may apply. See “Exceptions” section for additional information.↩
  • 6Digital Government: Building A 21st Century Platform To Better Serve The American People, Office of Management and Budget, Executive Office of the President, May 23, 2012. https://www.whitehouse.gov/sites/default/files/omb/egov/digital-government/digital-government.html↩
  • 7“Vendor lock-in” refers to a situation in which the customer depends on a single supplier for a product and cannot easily move to another vendor without sustaining substantial cost or inconvenience. Vendor lock-in can potentially raise costs and reduce innovation within that service, and it can result in reduced competition on future related software acquisitions.↩
  • 8For example, Microsoft has released the .NET software framework–used by millions of developers to build and operate websites and other large online applications–under an OSS license (see https://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx). Additionally, Apple Computer, Inc. made the Swift programming language–used to develop applications on Apple operating systems such as OS X and iOS–available as OSS (see https://developer.apple.com/swift/blog/?id=34). A third example is Google’s recent decision to open source its artificial intelligence system TensorFlow, which is utilized by applications such as Google Search, Google’s voice recognition application, and Google Translate (see https://googleblog.blogspot.com/2015/11/tensorflow-smarter-machine-learning-for.html)↩
  • 9The Open Government Partnership: Announcing New Open Government Initiatives as part of the Second Open Government National Action Plan for The United States of America. September, 2014. Page 2. https://www.whitehouse.gov/sites/default/files/microsites/ostp/new_nap_commitments_report_092314.pdf↩
  • 10The Digital Services Playbook consists of key “plays” drawn from successful practices from the private sector and Government that, if followed together, will help Government build effective digital services. It encourages agencies to “default to open” and seek contracts that specify that “software and data generated by third parties remains under [the U.S. Government’s] control, and can be reused and released to the public as appropriate and in accordance with the law. It also requires an explanation “[i]f the codebase has not been released under an open source license.” https://playbook.cio.gov.↩
  • 11Open Data Policy-Managing Information as an Asset. May 9, 2013. https://www.whitehouse.gov/sites/default/files/omb/memoranda/2013/m-13-13.pdf↩
  • 12See https://data.gov/impact for examples of Federal open data being used in various methods and industries.↩