Progress in U.S. Government Information Technology by Michael Erbschloe - HTML preview

Open Source Initiatives

The Federal Source Code Policy is designed to support reuse and public access to custom-developed Federal source code. It requires new custom-developed source code developed specifically by or for the Federal Government to be made available for sharing and re-use across all Federal agencies. It also includes an Open Source Pilot Program that requires agencies to release at least 20% of new custom-developed Federal source code to the public.

By making source code available for sharing and re-use across Federal agencies, we can avoid duplicative custom software purchases and promote innovation and collaboration across Federal agencies. By opening more of our code to the brightest minds inside and outside of government, we can enable them to work together to ensure that the code is reliable and effective in furthering our national objectives. And we can do all of this while remaining consistent with the Federal Government’s long-standing policy of technology neutrality, through which we seek to ensure that Federal investments in IT are merit-based, improve the performance of our government, and create value for the American people.

Section 7.7 of the Federal Source Code Policy states that:

Progress on agency implementation of this policy will be primarily assessed by OMB through an analysis of each agency’s internal Government repositories, public OSS repositories, and code inventories on Code.gov, as well as data obtained through the quarterly Integrated Data Collection (IDC), quarterly PortfolioStat sessions, the IT Dashboard, and additional mechanisms [..]

Generally, OMB's approach to assessing agency progress in meeting the Federal Source Code Policy's requirements can be broken into two categories:

1. analysis of agencies' enterprise code inventories, individual code repositories, and open sourced code, with a
2. comparison of that information against overall operational and financial data already collected by OMB.

OMB will provide additional information about its assessment mechanisms over time.

OMB will regularly review each agency’s enterprise code inventory to ensure that the agency is satisfying the requirements of the Source Code Policy. This review will include both the agency’s internal Government repositories and public open source repositories to ensure that each agency’s enterprise code inventory is properly reflected on – and easily discoverable through – this website.

OMB collects agency data through a number of existing mechanisms, including quarterly PortfolioStat sessions and the Integrated Data Collection. Much of this data is publicly available on ITDashboard.gov. OMB will use this data and other relevant information to better understand the overall impact of the Source Code Policy over time.

18F: An open source team

18F, a digital services delivery team within the General Services Administration, develops in-house digital solutions to help agencies meet the needs of the people and businesses they serve. This requires flexibility in how we code, with a focus on lowering costs for the American people, while improving their interactions with the U.S. Government.

The default position of 18F when developing new projects is to:

1. Use Free and Open Source Software (FOSS), which is software that does not charge users a purchase or licensing fee for modifying or redistributing the source code, in 18F projects and contribute back to the open source community.
2. Develop work in the open.
3. Publish publicly all source code created or modified by 18F, whether developed in-house by government staff or through contracts negotiated by 18F.

Using FOSS allows for product customization, advances interoperability between tools, and improves the overall quality of the final product. Other benefits include:

1. Flexible usage. The benefits of using FOSS compel 18F to meet user needs by modifying existing or creating new FOSS. FOSS is particularly suitable for rapid prototyping and experimentation. The testing process generates minimal costs, and the process encourages the identification and elimination of defects not recognized by the original development team.
2. Community involvement. Publicly available source code enables continuous and broad peer review. Whether simply publishing the completed code or opening the development process, the practice of expanding the review and testing process to a wider audience—beyond the development team—ensures increased software reliability and security. Developing in the open also allows for other opinions to help adjust the direction of a product to maximize its usefulness to the community it serves.
3. Cost-savings. The ability to modify FOSS enables 18F to respond rapidly to changing missions and markets. Support and maintenance of open source code—as opposed to more burdensome usages of proprietary software—provides a real cost advantage where multiple copies of software are required, or when the user base grows. The total cost of ownership is shared with a community, rather than solely 18F.
4. Reusability. The code 18F creates belongs to the public as a part of the public domain. The code we work on was paid for by the American people, but the end-product is not the only way they should be able to interact with their government. By coding in FOSS, the government helps populate a larger commons that cities, states, businesses, and individuals can participate in. This creates real economic value by lowering the burden of replicating similar work or by allowing the private sector to build off of and create new businesses around code developed at 18F.

Active involvement from the open source community is integral to the success of open source code. 18F will be an active contributor to FOSS projects that it or its clients utilize.

Code written entirely by 18F staff will be dedicated to the public domain. In addition, any contracts 18F enters into, where others will develop software on 18F’s behalf, will ensure that all results are dedicated to the public domain. In general, all discussion in this document about the licensing of work of 18F’s contractors means that 18F will ensure that their contracts guarantee those terms.

18F encourages contributions to its open source projects, whether it be code, commentary, bug reports, feature requests, or overall strategic direction.

Forks or clones of our code repositories are free to be re-distributed. This means code created by 18F can be integrated into work that is under a more restrictive license, even those that are not considered open source licenses.

This changes when 18F code repositories include code that was not created by 18F and carries an open license. Code previously released under an open source license and then modified by 18F or its contractors is considered a “joint work” and must be released under terms permitted by the original open source license.

The public can use the code as the basis of wholly proprietary and commercial systems. 18F would appreciate that users of our code disclose its lineage, but 18F maintains no legal right to require disclosure. Notifications that the work is used in a new system are always greatly appreciated.

As previously mentioned, most work generated at 18F falls within the U.S. public domain.

For international colleagues, 18F also permanently waives all copyright and related rights worldwide to code created by 18F or its contractors.

The default LICENSE file for projects acknowledges that our work is in the US public domain, and uses CC0 to waive copyright internationally.

The default CONTRIBUTING file informs contributors that their contributions will be licensed under the same terms.

However, certain projects will require the usage of licensed open source software not created by 18F. Some open source licenses make source code available under different terms and conditions. These terms and conditions specify how the code may be used, modified, or shared. When users modify 18F code, they should review and understand the terms of the open source license in question.

Each project may need to modify or extend the above LICENSE and CONTRIBUTING files as needed for its own circumstances.

There is a misconception that FOSS that is distributed to the public should not be integrated or modified for use in sensitive systems. On the contrary, FOSS is often preferred for use in sensitive systems, due in part to its increased auditability. In other words, security in FOSS must be designed never to rely on obscurity in how the code works.

In addition, while open source licenses permit the user to modify FOSS for internal use without obligating them to distribute source code to the public, when the user chooses to distribute the modified FOSS outside the user’s organization, then the code is subject to whatever license it carries.

The only conditions where code shall not be developed and released in the open are:

• The U.S. Government does not have the rights to reproduce and release the item.
• The public release of the item is restricted by other law or regulation, such as the Export Administration Regulations or the International Traffic in Arms Regulation.

These decisions will be made as needed by the 18F DevOps team, which will lead an interdisciplinary team to review the conditions under which code will not be made available publicly. Any further exemptions will be rare, documented publicly, and the result of compelling interest.

If an existing solution cannot be found in the open source community, 18F may consider other options, including creating an open source solution itself. Ultimately, the software that best meets the needs and mission of 18F should be used.

The IRS posted information on IRS.gov about Use of Federal Tax Information (FTI) in Open Source Software. Open source software is an attractive option for organizations looking to employ inexpensive or “free” solutions into their environments. This desire must be tempered by a thorough understanding of the pros and cons associated with the use of these applications. Using this information, organizations can make a risk-based decision as to whether or not they should use this type of software.

Open source software is ubiquitous and is relied upon by major organizations throughout the world. Organizations such as Linux Foundation, Apache Software Foundation and Mozilla develop open source software solutions that are considered the industry gold standard.

This software consists of or resides on everything from graphics cards and central processing units (CPU) to workstations, web browsers, web servers, server clusters, firewalls, routers, intrusion prevention systems and everything from smartphones to massive virtualized computing environments. Without open source software, it is possible that our current computing environment would not be nearly as mature as it is today.

One of the most highly touted reasons for using open source software is the fact that it may be inexpensive or “free.” One of the big questions regarding how this software can be provided at low or no cost is answered by understanding that these applications have several sources:

• College or university departments that have a team of software development students or researchers focused on a specific topical area.
• Not-for-profit organizations consisting of paid and volunteer developers (e.g., Mozilla, Apache). Many times, these organizations are supported both financially and with development personnel, by traditional vendors that rely on this software as well.
• Developers (individuals or small teams) with an interest and expertise in a topical area (e.g., tcp wrapper – Wietse Venema).

The reason for providing this background information is that it is important to understand the organization residing behind or supporting the continued development of the application under consideration. Depending on the application and the organization that stands behind it, there may be a tremendous amount of support for evaluating the software.

An example of this is OpenSSL. When the Heartbleed vulnerability was identified, developers immediately worked to assist with remediation efforts. Patches were available within 24 hours of the vulnerability being officially registered.

There are some areas of concern to consider regarding the use of open source software:

• It may be unknown whether the developers follow security best practices when developing their software. In comparison, many vendors have developed strict security development lifecycle models for their proprietary products. It may be difficult to determine whether an organization developing an open source application adheres to a mature development methodology that incorporates security principles.
• The security programming skills and vulnerability testing expertise, associated with the development of the application may be unknown, unacceptable or unable to meet IRS Publication 1075, Tax Information Security Guidelines for Federal, State, and Local Agencies (Pub 1075) requirements for secure software development, deployment and maintenance.
• Support for open source software is not always provided because it may not be backed by a vendor. Per Pub1075, Section 9.3.15.10, Unsupported System Components (SA-22), all system components must be supported.
• Training for the proper implementation and maintenance of this application may not be available to operations staff.
• Open source software maintainers may be slow to respond to identified flaws in their applications with a security fix; however, this may be no different than with closed source software developers.
• Open source software does not always integrate NIST-validated, FIPS 140-2 compliant encryption modules for the protection of federal tax information (FTI).

When deciding to procure open source software, IRS recommends that the agency pursue a conservative approach and seek organizations that will provide assurance that a secure development lifecycle is employed and that software support for the application being considered for use is available. This may include the use of a third-party vendor that specializes in supporting this application, but is separate from the primary development organization. As mentioned above, this may be required if direct support from the software developer is not an option.

Any agency considering the use of FTI in open source software must adhere to the following considerations:

• Software that will transmit FTI must encrypt the FTI using a FIPS 140-2 compliant encryption module that has been validated through the NIST Cryptographic Module Validation Program (CMVP).
• Software must be supported, by a vendor or organized community.
• Pub 1075 Section 9.3.5.10 states that open source software may be installed on FTI systems if it is:

• Legally licensed software,
• Approved by the agency’s IT department and
• Adheres to a secure configuration baseline checklist either from the U.S. Government (e.g., DISA STIG) or industry (e.g., Center for Internet Security).

This Department of Commerce (the Department) Source Code Policy is being issued to promote software code reuse by making custom-developed Federal source code available across the Department and to other Federal agencies. It supports the requirements of OMB Memorandum M-16-21, “Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software". This policy requires agencies to develop plans to release at least 20 percent of new custom-developed source code as Open Source Software (OSS) when commissioning new custom software.

The objectives of this policy are to:

• Provide guidance to the Department on considerations that must be made prior to acquiring any custom-developed code;
• Require the Department obtain appropriate Government data rights to custom-developed code, including at a minimum, rights to Government-wide reuse and rights to modify the code, and that such custom-developed code be made broadly available across the Federal Government, subject to limited exceptions; and
• Establish requirements for releasing custom-developed source code, including securing the rights necessary to make some custom-developed code releasable to the public as OSS under this policy’s new pilot program.

Authorities

• National Defense Authorization Act 2015 (FlTARA) (Title VIII, Subtitle D. H.R. 3979);
• Clinger Cohen Act 1996, (USC Title 40 Chapter 113 11301-11303.);
• M-15-14: Management and Oversight of Federal Information Technology, Office of Management. & Budget, Executive Office of the President, June 10, 2015;
• M-16-21: Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software, Office of Management & Budget, Executive Office of the President, August 8, 2016.

Definitions

• Software: Refers to (i) computer programs that comprise a series of instructions, rules, routines, or statements, regardless of the media in which recorded, that allow or cause a computer to perform a specific operation or series of operations; and (ii) recorded information comprising source code listings, design details, algorithms, processes, flow charts, formulas, and related material that would enable the computer program to be produced, created, or compiled. Software does not include computer databases or computer software documentation.
• Custom-Developed Code: Custom-developed code is code that is first produced in the performance of a Federal contract or is otherwise fully funded by the Federal Government, including code, or segregable portions of code, for which the Government could obtain unlimited rights under Federal Acquisition Regulations (FAR) Pt. 27 and relevant agency FAR Supplements. Custom-developed code also includes code developed by agency employees as part of their official duties. For the purposes of this policy, custom-developed code may include, but is not limited to, code written for software projects, modules, plugins, scripts, middleware, and APIs; it does not, however, include code that is truly exploratory or disposable in nature, such as that written by a developer experimenting with a new language or library.
• Mixed Source Software: A mixed source software solution incorporates both open source and proprietary code.
• Open Source Software (OSS): Software that can be accessed, used, modified, and shared by anyone. OSS is often distributed under licenses that comply with the definition of "Open Source" provided by the Open Source Initiative (https://opensource.org/osd) and/or that meet the definition of "Free Software" provided by the Free Software Foundation.
• Proprietary Software: Software with intellectual property rights that are retained exclusively by a rights holder (e.g., an individual or a company).
• Source Code: Computer commands written in a computer programming language that is meant to be read by people. Generally, source code is a higher level representation of computer commands as they are written by people and, therefore, must be assembled, interpreted, or compiled before a computer can execute the code as a program.

Scope

This policy is effective immediately, applies to all projects that commission development of custom software within the Department to include all Operating Units, with the exception of software covered in Section 6 of OMB 16-21, as deemed appropriate by the Department Chief Information Officer. The requirements outlined herein do not apply retroactively (i.e., they do not require that existing custom-developed code be retroactively made available for Government-wide reuse or as OSS).

Policy

1. Ensure appropriate alternatives analysis has been conducted before considering the acquisition of existing commercial solution or a custom-developed solution (build vs. buy vs reuse analysis).
2. When commissioning new custom software, at least 20 percent of new custom-developed code must be released as Open Source Software.
3. Each Operating Unit must register all new custom source code in the Department Software Code Inventory. This code inventory will be made available to all other Federal agencies through an enterprise code inventory system. This code inventory will also be discoverable at the Federal level through the Federal code inventory Code.gov (https://www.code.gov).
4. Source code must include documentation that describes the function, input and output of the module, security, and any other information relevant to its reuse.
5. Operating Units must obtain sufficient rights to custom-developed code to fulfill both the Government-wide reuse objectives and the open source release objectives.
6. Operating Units must incorporate the Three-Step Software Solutions Analysis as defined in section 3 of OMB M-16-21. 7. Update/correct any policies that automatically treat OSS as noncommercial software.

Responsibilities

• Program/Project managers must comply with this policy from project inception through completion, including the registering all custom-developed code in the DOC Code Inventory.
• Heads of Operating Units and Office of the Secretary Staff Offices shall ensure compliance with the policy across their entire organization.
• Operating Unit CIOs shall:

• Assist users to determine what code is reusable;
• Collect statistics on compliance with this policy annually; and
• Review and approve exemptions from this policy.

• The Office of Chief Information Officer has responsibility for issuing CIO policy implementing OMB source code policy and establishing and managing the Department’s software code inventory system as well as the interface to the Federal Code.gov system.
• The Office of Acquisition Management (OAM) has responsibility for issuing acquisition policy to ensure contracting officers incorporate language in solicitations and contract documents sufficient to obtain appropriate Government data rights to custom-developed code in compliance with the Open Source Software initiative.

Exemptions

Source code developed for National Security Systems (NSS), as defined in 40 U.S.C. § 11103, is exempt from the requirements of this policy. For NSS, agencies shall follow applicable statutes, Executive Orders, directives, and internal agency policies.

Requests for exemptions from requirements of this policy must explain why compliance is unachievable and be approved in writing by the Department CIO or OU CIO. Exemptions from the policy may be requested when:

• The sharing of the source code is restricted by law or regulation, including-but not limited to-patent or intellectual property law, the Export Asset Regulations, the International Traffic in Arms Regulation, and the Federal laws and regulations governing classified information;
• The sharing of the source code would create identifiable risk to the detriment of national security, confidentiality of Government information, or individual privacy;
• The sharing of the source code would create an identifiable risk to the stability, security, or integrity of the agency's systems or personnel;
• The sharing of the source code would create an identifiable risk to agency mission, programs, or operations; or
• The CIO believes it is in the national interest to exempt sharing the source code.

Agency Compliance

Agencies are required to perform various tasks in order to satisfy the objectives of the Federal Source Code Policy. Currently, agencies are evaluated on whether they've completed three tasks:

1. Updated agency policy: Agencies must update their policies to be consistent with the Federal Source Code Policy.
2. Completed code inventory: Agencies must inventory all new custom code created after August 2016 (notwithstanding exceptions enumerated in the Federal Source Code Policy).
3. Completed open source objective: Agencies must open source at least 20% of all new custom code created after August 2016.

Agencies are evaluated as fully compliant (green), partially compliant (yellow), or non-compliant (red) with the tasks outlined above. An agency's overall compliance is green only if they are green in all categories.

Department of Agriculture

Partially compliant

Agency policy is being updated for consistency with the Federal Source Code Policy.

Agency has open sourced less than 10% of their custom developed code.

Agency has inventoried less than 50% of new custom code.

 

Department of Commerce

Partially compliant

Agency policy is consistent with the Federal Source Code Policy.

Agency has open sourced less than 10% of their custom developed code.

Agency has inventoried less than 50% of new custom code.

 

Department of Defense

Non-compliant

Agency policy has not been reviewed for consistency with the Federal Source Code Policy.

Agency has open sourced less than 10% of their custom developed code.

Agency has inventoried less than 50% of new custom code.

 

Department of Education

Partially compliant

Agency policy is consistent with the Federal Source Code Policy.

Agency has open sourced greater than 20% of their custom developed code.

Agency has inventoried less than 50% of new custom code.

 

Department of Energy

Fully compliant

Agency policy is consistent with the Federal Source Code Policy.

Agency has open sourced greater than 20% of their custom developed code.

Agency has inventoried 100% of new custom code.

 

Department of Health and Human Services

Partially compliant

Agency policy is consistent with the Federal Source Code Policy.

Agency has open sourced less than 10% of their custom developed code.

Agency has inventoried less than 50% of new custom code.

 

Department of Homeland Security

Partially compliant

Agency policy is consistent with the Federal Source Code Policy.

Agency has open sourced less than 10% of their custom developed code.

Agency has inventoried less than 50% of new custom code.

 

Department of Housing and Urban Development

Partially compliant

Agency policy is consistent with the Federal Source Code Policy.

Agency has open sourced less than 10% of their custom developed code.

Agency has inventoried 100% of new custom code.

 

Department of Interior

Non-compliant

Agency policy has not been reviewed for consistency with the Federal Source Code Policy.

Agency has open sourced less than 10% of their custom developed code.

Agency has inventoried less than 50% of new custom code.

 

Department of Justice

Partially compliant

Agency policy is consistent with the Federal Source Code Policy.

Agency has open sourced less than 10% of their custom developed code.

Agency has inventoried less than 50% of new custom code.

 

Department of Labor

Partially compliant

Agency policy is consistent with the Federal Source Code Policy.

Agency has open sourced greater than 20% of their custom developed code.