Page History
...
| id | tabs-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.
...
| f | 1 |
|---|---|
| g | p |
| h | 0 |
| ansc | 1 |
| asc | 1 |
| bnsc | 1 |
| csc | * |
| bsc | 1 |
| esc | * |
| cnsc | 1 |
| dnsc | 0 |
| dsc | * |
| ensc | 0 |
...
| id | tabs-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. |
| Div | ||
|---|---|---|
| ||
3. Guidance a. Include this requirement in the Request for Proposal (RFP) for all systems which include software to be delivered to NASA. 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. |
| Div | ||
|---|---|---|
| ||
4. Small ProjectsSWE-041 applies to all projects regardless of size and has legal ramifications that can't be ignored. |
...
| id | tabs-5 |
|---|
5. Resources
...
| toolstable |
|---|
...
| id | tabs-6 |
|---|
6. Lessons Learned
...
However, the problem he discusses below indicates the need for knowing whether OSS is included in the project.
...
