bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-041 - Open Source Software Notification

1. Requirements

3.15.3 The project manager  shall require the software supplier(s) to notify the project, in the response to the solicitation, as to whether or not 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

Class

     A      

     B      

     C      

   CSC   

     D      

   DSC   

     E      

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.

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.

Early notification of the intent to use OSS is important because its inclusion in the software development product may have negative impacts on NASA's intended use of the software. It will also require legal analysis to resolve ownership, registration and licensing issues.

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 Statement of Work (SOW) 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 373 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 relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

6. Lessons Learned

1. Norris 281 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". 281

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 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)." 315

  • No labels