1. Requirements

2.6.1.3 The project shall require the software supplier(s) to notify the project, in the response to the solicitation, as to whether open source software will be included in code developed for the project.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

Classes C through E and Safety Critical are labeled with "SO if D-E." This means that for Classes D through E, this requirement applies only to the safety-critical aspects of the software.

Class G is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.

2. Rationale

Open Source Software (OSS) comes with a collection of advantages and risks. OSS can shorten software system development times. Unit and component testing may have been detailed. These work products may have been subjected to multiple instances of regression testing. On the other hand, OSS may require the use of other software or systems for proper operation. The benefits gained by using OSS may be offset by licensing restrictions.

Because this software often can be embedded within an otherwise newly developed software product, it is important for bidders and suppliers to notify NASA and all interested stakeholders, so the appropriate measures of control and verification can be developed and applied to the project. Without notification by the supplier, the existence of OSS and its licensing ramifications may not be otherwise recognized by the NASA software team.

3. Guidance

     a. Include this requirement in the Request for Proposal (RFP) for all systems which include software to be delivered to NASA.
     b. Include a clause in contracts and agreements which requires immediate notification to NASA of any change in status in the agreed to use of OSS by the supplier.

OSS is often considered for use in the early life-cycle phases of a software product development activity because of its availability and its seemingly inexpensive cost (relative to newly developed software). A software engineer often finds it more expedient to use widely available and well tested code developed in the software community for common functions than to "reinvent the wheel". Even if most of the software on a NASA project is developed by an in-house supplier, it is possible to find embedded OSS within the code.

SWE-027 contains extensive information on OSS, including embedded OSS and the use of OSS in NASA-developed software. Advantages, disadvantages and other lessons learned over the use of OSS are extensively discussed in SWE-027. The software development team must assure the inclusion of this requirement in all appropriate software acquisition activities. Consider the information on OSS in SWE-027 and how it applies to your project when developing appropriate contract SOW (Statement of Work) language to satisfy this requirement. See SWE-038 for additional guidance on software acquisition planning.

While SWE-041 doesn't address OSS released by NASA, there are related requirements in NPR 2210.1 and an associated NASA Open Source Agreement which covers this situation.

4. Small Projects

SWE-041 applies to all projects regardless of size and has legal ramifications that can't be ignored.

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

1. Norris ²⁸¹ indicates that it might seem counter-intuitive, but (his) experience indicates that using open source can often make a project more nimble because its resources are concentrated on the system's core architecture instead of specific features.

However, the problem he discusses below indicates the need for knowing whether OSS is included in the project.

"This posed a problem for the use of two components that were released under the restrictive General Public License, which requires all applications linked to the code to also be open source. Fortunately, in both cases the open source suppliers let (him) purchase a less restrictive license for a small fee, and tossed in priority technical support as part of the deal". ²⁸¹

2. Scott et al indicate another lessons learned when they discuss the fact that many government programs have existing technology that was originally funded by the government. "If the intellectual rights over those technologies are inadequate or cannot be determined, the government should consider negotiating with the appropriate integrators/vendors to release the source code under less restrictive data rights sufficient for an Open GOTS (Government Off the SHelf) (OGOTS) or OSS project. An easy way to do this is to simply fund the conversion process for the contractor(s)." ³¹⁵