bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin


Alias
aliasSWE-041
Tabsetup
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned1. The Requirement


Div
idtabs-1

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.


applicable
f1
gp
h0
ascansc1
anscasc1
bnsc1
csc*
bsc1
esc*
cnsc1
dnsc0
dsc*
dnsc0
ensc0



Div
idtabs-2

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.



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.

Div
idtabs-3

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

Term
SOWSOW


Div
idtabs-4

4. Small Projects

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


Div
idtabs-5

5. Resources


refstable

toolstable


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)."
Div
idtabs-6

6. Lessons Learned

1. Norris

sweref
281
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".

sweref
281
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

Term
GOTSGOTS
sweref
315
315


...