Skip to main content

NASA's Earth Science Data Systems (ESDS) Program requires that all software developed through research and technology awards (i.e., Research Opportunities in Earth and Space Science [ROSES] or unsolicited proposals) or other government-funded development is to be made available to the public as Open-Source Software. This includes all software developed with ESDS funding used in the production of data products as well as software developed to discover, access, analyze, visualize, and transform NASA data. This policy does not apply to commercial off-the-shelf software.

The ESDS Open-Source Software Policy was developed to complement and extend the NASA Earth Science Division’s (ESD) long-standing Data and Information Policy. This policy has been updated to align with NASA’s Scientific Information Policy for the Science Mission Directorate (SPD-41a), which defines the commitment of NASA's Science Mission Directorate (SMD) to free and openly available software to enhance the discoverability, accessibility, sustainability, and reproducibility of NASA science while maximizing benefits to society.

Definition of Open-Source Software

SPD-41a defines software as computer programs, including source and object code, that provide users some degree of utility or service. Scientific software is software that provides users with some degree of scientific utility or produces a scientific result or service. This does not include software developed only for preliminary analysis, plans for future research, or communication with colleagues.

Open-Source Software is defined as software that can be accessed, used, modified, and shared by anyone. It is often distributed under licenses that comply with the definition of “Open Source” provided by the Open Source Initiative or meet the definition of “Free Software” provided by the Free Software Foundation.

Scope of the Policy

This policy is derived from that defined in SPD-41a that applies to all SMD-funded scientific activities, directing all scientific information and software generated from such grants, cooperative agreements, contracts, etc. to be released in an open and accessible manner. Solicitations referencing this policy require a proposed plan for committing their software as Open-Source Software.

Policy Exceptions

Software that is subject to specific laws, regulations, or policies that would prevent the release of this information is exempt from this policy. The relevant laws, regulations, and policies that generate exceptions include, but are not limited to:

  • patent and intellectual property laws including the Bayh-Dole Act
  • the Export Administration Regulations (EAR)
  • the Health Insurance Portability and Accountability Act (HIPPA)
  • the International Traffic in Arms Regulations (ITAR)
  • the Freedom of Information Act (FOIA)
  • NASA STD 1006.1 Space System Protection Standard
  • NASA NPR 2810.7 Controlled Unclassified Information, and the Federal laws and regulations governing classified information or security requirements

Also exempt from the release is restricted software, which is defined as software that shall not be released due to an existing Federal law or guidance, NASA policy, or security concern. This includes software supporting security requirements described in STD-1006. For Mission software, projects should engage with the software release authority to determine status. Examples of software that may be restricted are command related software, instrument control, authentication, or communication software. For further guidance on what may be considered restricted or not, please see Appendix F of SPD-41a.

License Requirement

Permissive licenses guarantee the free use, modification, and redistribution of software while still permitting proprietary derivative works (Open-Source Initiative). This policy strictly requires “permissive” licensing when no other restrictions exist; thus, only permissive licensing shall be accepted and used for Open-Source Software development. In contrast, an example of a "restrictive" license is the GNU General Public License.

Additionally, the permissive licenses (i.e., Apache License 2.0, the BSD 3-Clause “Revised” License, and the MIT License) must have broad acceptance in the Earth science Open-Source Software community.

Possible restrictions that may prevent release under a permissive license include software governed by incompatible licenses or inclusion of restricted computer software. Investigators are encouraged to seek specific advice from the Chief Science Data Office or Intellectual Property Counsel if there are questions about restrictions.

Software Management Plan

The Open Source Software Development Plan Guidelines serve as a starting point for tailoring a project’s specific software management plan. Not all elements may be applicable or appropriate for every project. Some program elements may have the Software Development plan as a separate section from the Open Science and Data Management Plan (OSDMP). Please refer to the specific solicitation.

For some activities, such as those focused on education, a software management plan may not be required. However, the policy is still applicable to any relevant scientific software produced during those activities.

Solicitations referencing this policy will require that proposals include a plan for committing their software as Open-Source Software. All software components developed as part of the proposed work must identify a permissive, widely accepted Open Source Software license and be developed within a public repository hosting service, to begin at the inception of the proposed work.

Repository Requirement

This policy requires that all developed code be delivered to a publicly-accessible repository service that is widely recognized by a large, active Open Source Software community and used by developers of Earth science data and tools. Repositories designated as appropriate for archiving of SMD-funded scientific information shall align, to the extent practicable, to the National Science and Technology Council document Desirable Characteristics of Data Repositories for Federally Funded Research (PDF).

Repository services should implement the following criteria:

  • Common communication features
  • Issue tracking for bug reports and feature requests
  • Version control system
  • Repository browsing tools
  • Comply, as appropriate, with standards for accessibility for all electronic and information technology to people with disabilities
  • Comply, to the extent practicable, with a principle of non-discriminatory data access so that all users will be treated equally
  • Have an Authorization to Operate (ATO) from NASA. If a designated repository is externally managed and not part of NASA network boundary, then there should be a Memorandum of Understanding signed by NASA and the external party about how science information would be shared

For software developed at NASA centers, the ESDS Program recommends software be openly developed using NASA’s GitHub platform.

Software Release

To achieve reproducibility, scientific software developed using SMD funding and used in support of a scientific, peer-reviewed publication shall be released as open-source software no later than the publication date.

Shall Include:

  • Scientific software developed as part of previous work and not previously made openly available if enhancements were made as part of the SMD-funded work and the software is used in support of a scientific, peer-reviewed publication
  • Software enhancements that include new functionality adding scientific utility
  • Software developed in a proprietary or commercial software language, if allowed by the license

Shall Not Include:

  • Bug fixes or optimization of previously open software
  • Restricted software (e.g., not allowed under existing laws or regulations, patent rights) Commercial software

Note that this software release policy does not require the software to be maintained or supported. Variances to the requirements for software release may be requested from the program officer, who has the authority to approve, modify, or decline such requests. Any variances for a period longer than one year require review by the Chief Science Data Officer.

Compliance and Verification

NASA will evaluate proposals for compliance with this policy. A proposal that does not include adequate documentation to satisfy the requirements of this policy may not be selected. SMD will collect a variety of metrics intended to measure or assess the efficacy of its data systems and services to determine user satisfaction. Consistent with applicable laws, SMD will make those metrics available for review and will conduct independent reviews on SMD compliance with this policy at least once every five years.

Background: Software and Scientific Reproducibility

The overarching purpose of NASA’s Earth Science program is to develop a scientific understanding of Earth as a system. Scientific knowledge is most robust and actionable when derived from transparent, traceable, and reproducible methods. Reproducibility includes open access to the data and software used to arrive at results. Additionally, software that is developed for NASA should be open to the greatest extent possible in order to enable re-use across Federal agencies, reduce overall costs to the government, remove barriers to innovation, and ensure consistency through the application of uniform standards. Open Source Science practices also facilitate collaboration between agencies and the private sector.

Peer review of science results increasingly includes open, unfettered access to underlying data, but a lack of access to the software used to produce and analyze these data limits independent confirmation. Without access to software code, reproducibility will always be suspect due to such things as coding errors, numerical inconsistencies between the platforms running the software and the ordering of subordinate processes within the code, among other factors [Ince, et al.; Hatton; Monniaux].

Natural language descriptions of algorithms, such as Algorithm Theoretical Basis Documents (ATBDs), are inadequate to address the issues above and can be translated to code in many different ways, introducing ambiguities into the review process [Gervasi & Zowghi]. As a result, many major scientific journals broadly require open access to software to ensure the integrity of the peer review process (e.g., Science), while others empower editors and referees to include code review as a prerequisite for publication (e.g., Nature).

To best meet the aforementioned goals, ESDS established this Open-Source Software Policy. The scope of this policy addresses the open source delivery of software developed with ESDS funding in order to: (1) generate, discover, access, transform, and analyze NASA Earth science data and (2) ensure open peer review of findings based on these data in a manner consistent with guidance to increase collaboration with other agencies.

References

  • Science Journal open source policy
  • Nature open source policy
  • Open Source Initiative (OSI)
  • Ince, Hatton, Graham-Cunning, The case for open computer programs. Nature 482, 485–488 (23 February 2012) doi:10.1038/nature10836 Hatton, L. The T experiments: errors in scientific software. IEEE Comput. Sci. Eng. 4, 27–38 (1997)
  • Monniaux, D. The pitfalls of verifying floating-point computations. ACM Trans. Programming Languages Systems 30 (3). 1–41 (2008)
  • Gervasi, V. & Zowghi, D. On the role of ambiguity in RE. In Requirements Engineering: Foundation for Software Quality (eds Wieringa, R. & Persson, A) 248–254 (Springer, 2010)
  • Mattmann, C., Crichton, D.J., Hart, A.F., Kelly, S.C., Goodale, C., Ramirez, P.M., Hughes, S., Downs, R.R., and Lindsay, F. Understanding Open Source Software at NASA IN IT Professional 14(2) 29035, March 2012
  • 18F: An Open Source Team
  • Federal Source Code Policy OMB-16-21, Footnote 19
  • NASA National Aeronautics and Space Act