Page History

{alias:SWE-041}
{tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned}

{div3:id=tabs-1}

h1. 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.

h2. {color:#003366}{*}1.1 Notes{*}{color}

NPR 7150.2 does not include any notes for this requirement.

h2. 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.


{applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=*|cnsc=1|dsc=*|dnsc=0|esc=*|ensc=0|f=1|g=p|h=0}
{div3}
{div3:id=tabs-2}

h1. 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.

{panel}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. {panel}


{div3}
{div3:id=tabs-3}

h1. 3. Guidance

     a. Include this requirement in the 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|SWE-027] contains extensive information on open source software, 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 {term:SOW}language to satisfy this requirement. See [SWE-038|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|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=2210&s=1C] and an associated NASA Open Source Agreement which covers this situation.


{div3}
{div3:id=tabs-4}

h1. 4. Small Projects

SWE-041 is equally applicable to small projects and has legal ramifications that can't be ignored.
{div3}
{div3:id=tabs-5}

h1. 5. Resources

# [Release of NASA Software|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=2210&s=1C], NPR 2210.1C, 2010
# [NASA Engineering and Program/Project Management Policy|http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPD&c=7120&s=4D], NPD 7120.4D, 2010
# [NASA Space Flight Program and Project Management Requirements|http://nodis3.gsfc.nasa.gov/npg_img/N_PR_7120_005D_/NM_7120-81_.pdf], NPR 7120.5D (NM-7120.81), 2009.
# "Mission \--Critical Development with Open Source Software: Lessons Learned", Norris, J.S., Kamp, P.; [IEEE Software|http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2004.1259211], 2004
# "Running Open Technology Development Projects", John Scott, Dr. David A. Wheeler, Mark Lucas, and J.C. Herz; [Software Tech News|http://www.softwaretechnews.com/], Feb., 2011


{refstable}{refstable}

{toolstable}


{div3}
{div3:id=tabs-6}

h2. 6. Lessons Learned

1. Norris {sweref:281} indicates that it might seem counterintuitive, 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 open source software 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". {sweref:281}

2. [Scott {sweref:315}," 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 (OGOTS) or OSS project. An easy way to do this is to simply fund the conversion process for the contractor(s)."


{div3}
{tabclose}