2. Rationale

All software used on a project must meet project requirements and be verified and validated, including any incorporated open source software. The project must ensure that each open source software component meets NASA requirements; that all of the legal requirements for proprietary rights, usage rights, ownership, warranty, licensing rights, and transfer rights are understood and met in accordance with the project’s planned use; and that future support for the software is planned. 

3. Guidance

Open source software (OSS) is considered a form of off-the-shelf software. Even if most of the software on a NASA project is developed in-house, it is common to find embedded OSS within the code. It is often more efficient for a software engineer to use widely available and well tested code developed in the software community for common functions than to "reinvent the wheel."

What is Open Source Software?

In NPR 2210.1C, "Release of NASA Software" ³⁷³ under Appendix A, definitions, A.1.7, "'Open Source Software' means software where the recipient is free to use the software for any purpose, to make copies of the software and to distribute the copies without payment of royalties, to modify the software and to distribute the modified software without payment of royalties, to access and use the source code of the software, and to combine the software with other software in accordance with open source licenses/agreements. OSS is a subcategory of Publicly Releasable software."

Planning ahead for the inclusion of Open Source Software

Whether OSS is acquired or developed by NASA or a NASA contractor, a usage policy should be established up front to avoid any possible legal issues that may arise. This policy may be developed in conjunction with advice from the Software Release Authority (even if you do not plan to release the software) and/or your Center's intellectual property (IP) Legal Counsel.

Procurement of software by NASA – Open Source Provisions

A cautionary item from page 9 of NPR 2210.1C, "Release of NASA Software,"  ³⁷³ is worth reiterating here:
"Open Source Software Development, as defined in paragraph A.1.8, of NPR 2210.1C, may be used as part of a NASA project only if the Office or Project that has responsibility for acquisition or development of the software supports incorporation of external OSS into software. In addition, the Office or Project responsible for the software acquisition or development shall:

• Determine the ramifications of incorporating such external OSS during the acquisition planning process specified in NASA FAR Supplement Subpart 1807.1, Acquisition Plans; and
• Consult with the Center Patent or IP Counsel early in the planning process (see 2.4.2.1) as the license under which the OSS was acquired may negatively impact NASA's intended use."

Identify Requirements

Identifying the requirements to be met by the OSS allows the project:

• To analyze the OSS component to ensure it is adequate for the function it is intended to fulfill.
• To determine how the risk of using OSS components affects the overall risk posture of the software system.
• To perform testing to ensure that the OSS component performs the required functions. Without requirements in place for the OSS components the software functionality cannot be tested.

Obtain Documentation

Usage instructions are important to help ensure the purpose, installation, and functions of the OSS components are properly understood and used in the project.

Obtain Usage Rights

For OSS components, projects need to be sure that any proprietary, usage, ownership, warranty, licensing rights, and transfer rights have been addressed to ensure that NASA has all the rights necessary to use the OSS component in the project. It may be helpful to the project to work with procurement to determine the documents needed from the software developer and with the legal department to ensure any subtle nuances and issues related to obtaining this information are properly understood and addressed.

Plan Future Support

It is important to plan for future support of OSS adequate for project needs. As applicable, consider the following:

• Ensure a risk mitigation plan is in place to cover the following cases:

• • Loss of developer support for the product.
  • Loss of maintenance for the product (or product version)
  • Loss of the product (e.g., license revoked, recall of product, etc.).

• Consider joining a product users group to obtain access to defects discovered by the community of users.
• Ensure a plan to provide adequate support is in place; the plan needs to include maintenance planning and the cost of maintenance.
• Document changes to the software management, development, operations, or maintenance plans that are affected by the use or incorporation of OSS components.  
• Obtain an open source software licenses review by the Center Counsel.

Identifying and using high pedigree OSS in NASA code

To achieve the level of confidence required in NPR 7150.2, requirement 3.15.2.e, which states: "The software component is verified and validated to the same level required to accept a similar developed software component for its intended use", it is recommended that software developers use only OSS that has a high pedigree. Such OSS will typically have the following characteristics:

• There should be a strong software development model including defined processes for bug reporting, which includes identification, triage, and correction.

• Code modification: Review and approval to commit fixes and features to the source code.
• Testing: Thorough descriptions of test cases, test runs, and test configurations.
• Code review (as part of the code modification process).
• Documentation: Detailed documentation should be updated.
• Discussion lists for questions: This may include a wiki, mailing list, or live chat site.
• Leadership: Ensures that the community works in a coordinated fashion to define target functionality for each release and overall product focus.

• Usually, a high quality, established open source project will have a large number of developers. Usage of the project's product(s) will occur across multiple industries both nationally and internationally.
• Metrics (e.g., number of developers) can be used to evaluate the quality of an open source project via sites that track a large proportion of OSS projects (e.g., Black Duck Open Hub ⁴⁶²). Norms, such as what constitutes a large number of developers, change as the number of open source projects and developers grow.
• The project should provide a listing of all OSS included, embedded, or modified within the piece of OSS.
• OSS may provide more opportunity to perform V&V of the software to the same level of confidence as if obtained through a "development" process. Often OSS project will provide online access to detailed development and test artifacts (as described above), which may be difficult to obtain from commercial off the shelf (COTS) vendors.

Releasing NASA code containing Open Source Software

There are requirements and processes associated with software releases. See NPR 2210.1C, "Release of NASA Software." ³⁷³

A cautionary item from NPR 2210.1C, paragraph 3.2.2.2 is worth repeating here: "If a proposed release of Open Source Software includes the release of external Open Source Software, care shall be taken to ensure that the pertinent license for such external Open Source Software is acceptable. For example, at least one widely used external open source license does not currently include an indemnification provision and further requires that all software distributed with that external Open Source Software be distributed under the same license terms. Therefore, except for an Approved for Interagency Release or Approved for NASA Release, both the Center Office or Project that is responsible for the software and Center Patent or IP Counsel shall review and approve any proposed distribution of Open Source Software that includes external Open Source Software."

Additional guidance related to OSS may be found in the following related requirement in this Handbook:

4. Small Projects

This requirement applies to all projects regardless of size.

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.