NAO 201-118: SOFTWARE GOVERNANCE AND PUBLIC RELEASE POLICY

Issued 11/22/2024; Effective 9/11/2024;

SECTION  1.  PURPOSE.

  1. To ensure all appropriate mission-oriented software developed by NOAA Federal employees or with Federal funds and products produced therefrom can be released to the public, following consistent protocols across NOAA.
  2. To enable community development of software where appropriate, in the interests of transparency, quality, and efficiency.
  3. To ensure quality of software, both regarding finalized products and as a part of the ongoing development process.
  4. To ensure compliance with law and best practices for software development and public release, in particular with respect to Intellectual Property issues, while
    1. Retroactively addressing all such issues for existing software as needed; and
    2. Addressing such issues up-front for newly developed software.
  5. To educate NOAA personnel with-respect-to requirements, policies and best practices for software governance and public release.

SECTION  2.  AUTHORITIES.

  1. Stevenson Wydler Technology Innovation Act of 1980, 15 U.S.C. § 3701 et seq.: Finds that inventions and “computer software … should be made accessible” to state and local governments and private industry and authorizes Federal laboratories to enter into cooperative research and development agreements.
  2. Bayh-Dole Act of 1980, 35 U.S.C. § 200 et seq.: Addresses the allocation of patent rights for inventions developed by non-governmental entities using Federal funds.
  3. Federal Technology Transfer Act of 1986, 15 U.S.C. § 3710: Requires agencies to strive to transfer federally owned or originated technology to state and local governments and the private sector.
  4. NOAA Administrative Order (NAO) 201-103A: Requires disclosure of any NOAA technology which may be considered an invention to the Technology Partnerships Office prior to public disclosure.
  5. Executive Order 12591, Facilitating Access to Science and Technology (1987): Requires all U.S. Government agencies to encourage and facilitate cooperation among Federal laboratories and state and local governments, academia, and the private sector and transfer technology by delegating authority to Federal laboratories to license, assign, or waive rights to intellectual property developed by the laboratory.
  6. NAO 216-105B, Policy on Transition of Research to Application (2016): Addresses process for identifying, transitioning, and coordinating research and development output to operations, applications, and commercialization, for all NOAA-funded activities, and requiring transition plans.
  7. NAO 202-735D-2, Scientific Integrity (2021): Recognizing the importance of transparency, traceability, and integrity to NOAA’s science, requires the free flow of scientific information and public access to information and data supporting scientific findings, where consistent with privacy and classification standards, and other legal authorities restricting such disclosure.
  8. Executive Order 10096, Providing for a uniform patent policy for the Government with respect to inventions made by Government employees and for the administration of such policy (1985): Providing for a uniform patent policy for the U.S. Government with respect to inventions made by Government employees and for the administration of such policy.
  9. 2 C.F.R. § 200.315: Addresses the allocation of Intellectual Property Rights and other intangible property in works developed by grantees and cooperative institutes using Federal funds, including software.
  10. Freedom of Information Act (FOIA), 5 U.S.C. § 552: Requires U.S. Government agencies to make information, which could include software, available to the public, subject to limited exceptions.
  11. Weather Research and Forecasting Innovation Act of 2017, as amended by the National Integrated Drought Information Reauthorization Act of 2018, 15 U.S.C. § 8512: Requires NOAA to create a community global weather research modeling system that is accessible by the public.
  12. Learning Excellence and Good Examples from New Developers Act (LEGEND), 15 U.S.C. § 8512a: Generally requires NOAA to make operational and certain developmental and experimental numerical models and associated data assimilation of the Earth’s system or its components that are developed, in whole or in part by NOAA or with Federal funding, available to the public under an open license, and to periodically review innovations made by non-NOAA employees.
  13. OMB M-16-21, Federal Source Code Policy (2016): Requiring agencies to make at least 20 percent of their custom created software available to the public as open-source software (OSS) as a pilot project, and strongly encouraging agencies to make as much software available as possible, with exceptions due to Export Asset Regulations or International Traffic in Arms Regulation controls or other exceptions in the national interest.
  14. OMB Circular A-130, Managing Information as a Strategic Resource (2016): Consistent with the Federal Acquisition Regulations, requires contracts for custom software development to include contractual provisions that reaffirm the right to reuse the software throughout the Federal Government.
  15. 17 U.S.C. § 101 et seq.: Basic provisions of U.S. copyright law, providing the basis for claims of copyright over software and generally denying copyright protection to any work of a U.S. Government employee within the United States.
  16. Paperwork Reduction Act, 44 U.S.C. § 3506(d): Requires agencies to “ensure that the public has timely and equitable access to the agency’s public information.”
  17. Information Quality Act, 44 U.S.C. § 3516 note: Requires agencies to ensure and maximize the “quality, objectivity, utility, and integrity of information” disseminated to the public per the Paperwork Reduction Act, consistent with OMB guidelines and agency-developed guidelines.
  18. Guidelines for Ensuring and Maximizing the Quality, Objectivity, Utility and Integrity of Information Disseminated by Federal Agencies, as updated by OMB M-19-15 Improving Implementation of the Information Quality Act (2019): Defines “reproducibility standard” for influential scientific information, requiring public release of data and models used to create such information.
  19. National Oceanic and Atmospheric Administration Information Quality Guidelines (last revised November 2021): Includes models in the definition of “scientific information,” and includes standards for utility, integrity, and objectivity to ensure the quality of such scientific information.
  20. Federal Risk and Authorization Management Program (FedRamp) authorization of the use of GitHub for software code management by the Federal Government, as outlined on the GitHub and Government1 website, providing a standardized approach to security authorizations for Cloud Service Offerings.

1 https://government.github.com/fedramp/

SECTION  3.  SCOPE.

  1.  This administrative order describes the Software Governance and Public Release Policy. The main drivers for developing this NAO are:
    1. There is no single NOAA policy governing the development, quality assurance, support, documentation and public release of software products;
    2. Law and policy that directs NOAA to release software to the public unless otherwise prohibited;
    3. The requirement to document such released software; and
    4.  NOAA’s acceptance of community modeling and software development as an effective business model for both research and operations.
  2. This NAO applies to software developed and used in support of NOAA’s mission, whether it is developed or modified in whole or in part by Federal employees, by entities with Federal funding (contractors and grantees), or by other third parties, in all its stages of use and development, including software where development predates this NAO. This NAO does not apply to unmodified OSS or commercial off-the-shelf software such as productivity software, operating systems, and compilers.
  3. This NAO does not define how NOAA decides which software to use, develop, and/or support (or discontinue). It only addresses aspects of software management and policies after NOAA has made such a decision.
  4. This NAO addresses principles and policies. Procedures to implement these will be gathered in an accompanying handbook.

SECTION  4.  DEFINITIONS.

  1. Software: A set of instructions that enables a computer to perform a specific task, as opposed to the physical components of the system (hardware). For the purpose of this NAO, it encompasses terms such as algorithms or source code, their compiled executables, and portions of, modifications to, and additions to the same.
    1. New Software: Software that is newly created after the release of this NAO without any prior existence in the form of algorithms, code, or code units.
    2. Existing Software: Software that was already in use by NOAA prior to the release of this NAO, or which was substantially complete and functional prior to the start of NOAA’s involvement in its use or development.
    3. Retired Software: Software that is no longer under active support, and is no longer actively used to achieve NOAA’s mission requirements.
  2. Community Development: Development that occurs in an environment using software repositories with clearly defined pathways for taking contributions from developers, subject to an agreed-upon set of rules established by a community. The community may include multiple individuals, organizations and affiliations, from all sectors such as public, private and academia.
    1. Open development: Open development is providing free access to source code and contributions subject to transparent guidelines.
    2. Closed development: Closed development implies restricted source code access.
  3. Software Release:
    1. Releasing (action, verb) software implies that the code is made available to the public or within a specified community. This NAO deals with releasing software to the public only.
    2. A Software Release (noun) is a specific version of the software that has been released. The noun form of “release” is not used elsewhere within this NAO, but is discussed in the accompanying Handbook.
  4. Documentation: A description of software that is adequate for a knowledgeable person who was not involved in its original development to understand what the software is doing, its requirements and dependencies, how it has been evaluated for quality assurance, and how to use the software.
  5. Quality Assurance (QA): Procedures taken to ensure that software gives results that are substantially correct when used as intended and applied to data or conditions within the reasonable scope of applications within NOAA, and that any unintended changes in results between versions of the software will be detected. QA may include testing to ensure portability and consistency of results across computing platforms. Tests to evaluate the impact of contributions from developers are part of QA.
  6. Intellectual Property: Creations of the mind, such as a creative work, an invention, or a distinctive indicator of a product’s source, that may be protected by certain intangible property rights. Four common types of intellectual property are patents, trademarks, copyrights, and trade secrets.
    1. Public Domain: A work of authorship is in the “public domain” if it is not under copyright protection. Works in the public domain may be used freely without permission.
    2. Patent: A patent is a property right granted to an inventor “to exclude others from making, using, offering for sale, or selling the invention throughout the United States or importing the invention into the United States” for a limited time in exchange for public disclosure of the invention when the patent is granted. Software may be considered to be an invention that is eligible for patent protection.
    3. Copyright: An intellectual property right that protects original works of authorship that have been tangibly expressed. Software is generally subject to copyright protection.
    4. Trademark: A word, phrase, symbol, or design, or a combination of these elements, that is used in commerce and identifies and distinguishes the source of one party’s goods from those of others.
    5. License: Permission to take certain actions or carry out particular activities that would otherwise be unlawful or infringing. For example, a copyright owner may grant a license to another party, allowing that party to use the copyright owner’s copyrighted materials.
  7. Transition: In NOAA, transition is commonly used to describe the movement of a technology from research to development to one or more end uses (e.g., Operations, Applications, Commercialization), see NAO 216-105B.2
  8. Digital Object Identifier (DOI): A string of alphanumeric text and symbols to permanently identify electronic content including publications of scientific journal articles or letters, datasets, or versions of software.

2 www.noaa.gov/organization/administration/nao-216-105b-policy-on-research-and-development-transitions

SECTION  5.  TIERS OF SOFTWARE.

  1. Tiers: Software in NOAA has a broad range of intended uses. For the purpose of this Administrative Order, NOAA identifies the following broad categories (“tiers”) of intended and/or active use within NOAA, ordered to align with the policy areas described in section 7 (e.g., Quality Assurance and Documentation). The tier assignment for software packages does not need to be static and may change during its life cycle. Software types provided in brackets are intended as examples only.
  • Tier 0: Trivial software for individual use (e.g., a custom calculator in spreadsheet software).
  • Tier 1: Simple software for one-time publicly visible use (e.g., plotting scripts for a publication).
  • Tier 2: Software for daily or one-off use (e.g., internal monitoring software, web visualization software, supporting academic papers) but with a limited scope of outputs, simple interactions with other software, and minimal consequences of failures. Tier 3: Software tools for repeated use: developmental. This software is generally developed as a product intended for repeated use or public release (e.g., development of simulation models and development of retrieval algorithms for observing systems).
  • Tier 4: Software tools for repeated use: mature. Software systems similar to tier 3, mature enough, for instance, applied research, or broad public distribution.
  • Tier 5: Software with active full support of its end-to-end components (e.g., simulation software used and supported by a broad community, such as weather, ocean, climate, fisheries, and navigational advisory models).

SECTION  6.  PRINCIPLES.

  1. Laws and policies require NOAA, in most cases, to publicly distribute software that is used for its mission, generally with exemptions for classified or proprietary third-party software, or software whose release is otherwise restricted by law (see Section 2, Clause 12). This requirement applies to all software that NOAA develops for its mission, either within NOAA, or with external partners, including software that is wholly or predominantly developed outside of NOAA.
  2. NOAA benefits from using software that is developed and maintained by a large and diverse community. These benefits are established in the initial report of the Unified Modeling Task Force (now Unified Modeling Committee) under the NOAA Research Council (Link, et al. 2017, https://repository.library.noaa.gov/view/noaa/14156).3 Such an approach benefits research, operations, and transitions between the two, as well as other transitions, such as to commercialization.
  3. In order to achieve the benefit of community-developed software, NOAA must adhere to the same software standards and best practices for quality assurance and documentation that it expects from its outside collaborators.
  4. Effective community modeling for both NOAA and the broader community requires identification of and adherence to best practices within the confines of laws and policies relevant to software used and (partially) developed by Federal employees or with Federal funding. This is enabled by:
    1. Tiering of software. Not all software is equal. NOAA defines different tiers to find a balance between the additional work required to release high-quality software to the public, and the benefit of high-quality software releases to enable and leverage community contributions to software for better serving NOAA’s mission.
    2. Public release requirements. Tiering allows for defining minimum levels of QA, documentation and support of software identified for various internal use and for public release.
    3. Intellectual Property (IP) consideration. For all software NOAA uses and co-develops, IP ownership issues need to be addressed before software can be released publicly or transitioned into operations. To avoid potentially significant legal issues at this stage, IP ownership and accompanying rights must be addressed clearly and proactively prior to software development.
  5. The public benefits from open access to the software developed by NOAA employees and with NOAA funding. Such access increases transparency, promotes confidence in NOAA science, and encourages new and innovative uses of such software by researchers and entrepreneurs.
  6. Intellectual property rights inherently exist for all software products developed and codeveloped in the execution of NOAA’s mission. These rights will drive if and how software may be distributed and licensed. A detailed discussion of these issues can be found in the handbook.
  7. Intellectual property rights and attribution may be further communicated through the issuance of a DOI on software publicly released by NOAA.
  8.  Retirement of software by NOAA is an essential part of NOAA software management, in particular with respect to discontinuing support and maintenance, and is required for software that is no longer supported or being maintained. Procedures for software retirement are discussed in the Handbook.

3 https://repository.library.noaa.gov/view/noaa/14156

SECTION  7.  POLICY.

  1. Quality Assurance (QA)
    1. Required levels of QA increase with the tier of software considered. A general description of the minimum required level of QA for each software tier is described below, but specific requirements will be defined in the accompanying Handbook. QA provisions will include guidelines for software security screening.
      1. Tier 0 software requires no QA.
      2. Tier 1 software should have basic QA needed to guarantee proper function for onetime use.
      3. Tier 2 software should have QA in its initial development environment. Formal regression testing is recommended but can be done in an ad-hoc manner for individual platform transitions.
      4. Tier 3: NOAA strongly recommends that full QA is developed side-by-side with the corresponding development of tier 3 developmental software. If tier 3 software is developed by a team, NOAA requires: i) that basic code management and coding standards are established as the team starts its work; and ii) that appropriate testing is developed together with the software so that impacts of individual code modifications on the entire software package can be assessed in a mostly automated manner.
      5. Tier 4: Software used and developed by NOAA can only be identified as mature tier 4 software if all QA elements defined for Tier 3 are also mature. NOAA recommends that required fundamental regression testing be augmented to provide a hierarchical testing framework, by including unit testing and tests of the scientific quality and integrity of the system in representative applications. It is noted that tests other than regression and unit testing are particularly important for simulation software, and might not be relevant (and hence not required) for other software types.
      6. Tier 5: NOAA QA requirements are effectively the same as for tier 4. NOAA strongly recommends the development of hierarchical testing as outlined in Section 7.A.01.e.
    2. NOAA generally encourages industry-standard QA for all software used and developed by NOAA, even if this is not required here.
  2. Support and Documentation
    1. Based on the software tiers defined in Section 5.01, NOAA will specify required levels of documentation and support in the accompanying Handbook. Requirements generally increase with the tier of software considered.
    2. Tier 0 software does not require documentation or support.
    3. Tier 1 software should have limited documentation, sufficient to understand the scope and purpose of the software, or its elements. Tier 1 software does not require support.
    4. Tier 2 software should have documentation sufficient for porting of the software to new computers with minimal consultation of the software developer(s). Tier 2 software does not require support.
    5. Tier 3 software requires full documentation to enable its use by an experienced user, porting to new computers, and general third-party development and modification. Support consists of implementation of code management and regression testing principles as outlined in Section 7.A.01.d.
    6. Tier 4 software requires full documentation to enable its use by a user with relevant subject knowledge. Support consists of an emerging community in which NOAA actively participates, and which starts to include community support elements as identified in the following paragraph.
    7. Tier 5 software requires full documentation of all uses to which it is applied by NOAA. NOAA uses and contributes to an active community with features such as developmental support (e.g., helpdesk, community self-help fora, etc.), formal and active training (e.g., recurring hands-on training opportunities), and community engagement (e.g., recurring workshops or sessions of established conferences).
  3. Disclosure Requirements
    1. To meet the requirements of the authorities identified in Section 2 of this Order, it is NOAA policy that all newly developed software or existing software at tier 3 or higher, or previously undisclosed, must be disclosed prior to public release. Associated procedures are described in the Handbook.
    2. Software disclosure will be made to the NOAA Technology Partnership Office.
    3. Refer to the Handbook for this Order for software disclosure procedures.
  4. Software Release and Intellectual Property Rights
    1. Software developed by NOAA or with NOAA funding specifically for its mission will be developed and publicly released as OSS unless legally prohibited or superseded by formal, written agreements between NOAA and an external entity. Tier 0, 1, and 2 software do not require public release (but still may be subject to release under FOIA).
      1. The software will be publicly released under an open license, at no cost and with no restrictions on copying, publishing, distributing, transmitting, citing, or adapting, unless legally prohibited. Consult the Handbook for specific license guidance.
    2.  For software jointly developed, modified or added upon in collaboration between Federal employees and any entity external to NOAA (including contractors, grantees, cooperative institutes, private entities, interagency partners, international partners, Cooperative Research and Development Agreement partners, individual contributions via Github, etc.), steps must be taken to ensure that the development results in intellectual property rights that enable the software to be publicly released as open source software. Consult the Handbook for appropriate guidance and draft text to include in contracts or agreements.
    3. For software that originated outside of NOAA, Federal employees may use, develop, modify (including adding to) it without altering the existing license, provided that it is subject to an open source license consistent with the spirit of this NAO, or when such contribution has been otherwise determined to be in the interest of NOAA. Consult the Handbook for appropriate guidance and draft text to include in contracts or agreements.
      1. Note that new software developed individually or jointly by Federal employees would be released under an open license, but preexisting software would continue to be licensed under the open source license applied previously by the developer of the preexisting software.
    4. For software development initiated after the effective date of this NAO, including new contributions to existing software, the above items in this section will be addressed before the software development has started. Consult the Handbook for appropriate guidance.
    5. For software released before the effective date of this NAO, the intellectual property rights shall be reviewed for compliance with this NAO.
    6. NOAA may apply for trademark protection for software developed by NOAA or with NOAA funding. Consult the Handbook for appropriate guidance.
    7. NOAA may mint a DOI on specific versions of publicly available software and further DOIs be incrementally reissued on subsequent versions of the modified software.

SECTION 8. RESPONSIBILITIES.

  1. NOAA Line Offices (LO) – The main responsibilities for implementing this NAO are with the LOs (Assistant Administrators or their designates). The LOs shall:
    1. Promote awareness and enforce compliance with this NAO for any software developed by the Federal employees of LO or with LO funding or other support.
    2. Develop a process to assign and clear tier assignments for software, in accordance with Section 5 of this NAO.
    3. Develop standards and processes for QA, documentation and support, coordinating this with the larger community appropriate for the software considered, to comply with the requirements of Sections 7.A and 7.B of this NAO.
    4. Develop a process regarding disclosure to comply with the requirements of Section 7.C of this NAO.
    5. Address intellectual property rights to comply with the requirements of Section 7.D of this NAO.
  2. NOAA Technology Partnerships Office (TPO) – The TPO is responsible for:
    1. The tracking and reporting of all public and transitioned NOAA software through the Disclosure process.
    2. Identifying/approving Open Source license and warranty information applied to NOAA software, in consultation with NOAA General Counsel and the Department’s Office of the General Counsel, General Law Division, as appropriate.
    3. Obtaining and maintaining all waivers of rights, assignments of intellectual property rights prior to public release of software, and for developing other documentation required for royalty-bearing licenses (only possible if software is patentable- see 5 U.S.C. § 3710c).
  3. NOAA Science Council (NSC) – The NSC is responsible for:
    1. NOAA level annual oversight of implementation of this NAO.
    2. Socializing and providing a discussion forum for the implementation of this NAO through its standing committees, in particular the Line Office Transition Manager Committee (LOTMC).
  4. The Acquisitions and Grants Office (AGO) and the Office of General Counsel (OGC), in consultation with the Department of Commerce General Counsel as appropriate, shall provide legal advice as needed and requested with respect to issues arising from implementing this NAO. AGO and OGC will ensure that all future NOAA funding opportunities, contracts, and grants are consistent with the software policies outlined in this NAO.

SECTION 9. EFFECT ON OTHER ISSUANCES.

An electronic copy of this Order will be posted in accordance with Chapter 100 of the NOAA Records Control Schedule on the NOAA Office of the Chief Administrative Officer website under the Administrative Programs’ NOAA Administrative Issuances Section.4

4 https://www.noaa.gov/organization/administration/noaa-administrative-orders

 

Dr. Richard W. Spinrad
Under Secretary of Commerce
for Oceans and Atmosphere
and NOAA Administrator
                                                       

Offices of Primary Interest:

  • All NOAA Line Offices