1. Requirements

2.6.1.4 The project shall require the software supplier(s) to provide NASA with electronic access to the source code developed for the project, including MOTS (Modified Off the Shelf) software and non-flight software (e.g., ground test software, simulations, ground analysis software, ground control software, science data processing software, and hardware manufacturing software).

1.1 Notes

Known contract requirements are addressed in the solicitations and included in the resulting contract. Additionally, if the project needs to control further use and distribution of the resulting software or requires unlimited rights in the software, e.g., right to use, modify, and distribute the software for any purpose, the project can consider having the software copyright assigned to the Government. A list of software deliverables needs to be addressed in the solicitations, if the software is being procured. The project can consult with the Center's Chief of Patent/Intellectual Property Counsel regarding required rights associated with the software. Section 3.5.4 [of NPR 7150.2, NASA Software Engineering Requirements] contains a list of Software Operations, Maintenance, and Retirement deliverables.

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

NASA requires electronic access to software source code developed by suppliers with NASA funding to enable independent evaluations, checks, reviews, and testing. This access also accommodates the longer-term needs for performing maintenance, assessing operation or system errors, addressing hardware and software workarounds and allowing for the potential reuse of the software on future NASA projects.

3. Guidance

This is a key requirement that must be addressed on all NASA software projects. Access needs to be defined up front in the Statement of Work (SOW), task agreement, or other assignment paperwork. Special care needs to be used to clearly identify this requirement in the primary contractor and subcontractor requirements. NASA needs direct insight into all software development on a project. In the context of this requirement, "electronic access" is interpreted as access that does not require a physical presence at the software supplier or contractor location. It does allow for a secure File Transfer Protocol (FTP) or secure remote web access from a NASA Center or a NASA-approved site. Sometimes due to NASA Information Technology (IT) policies or a contractor's IT policies (firewall issues), it is not possible to get direct electronic access into a contractor's development system. In such cases, as a last resort, it would be acceptable to have the contractor provide the code on a thumb drive or disk.

The intent of this requirement is to provide the NASA software development team with direct access at NASA to the source code, configuration data, software data loads, programmable logic, commercial software, legacy software, heritage software, and software related telemetry. The access includes the executable code so that NASA can perform independent assessments, reviews, analyses, and run the work products through NASA's own set of static analysis tools, as needed by the project. It allows the team to evaluate progress being made by the vendor as a part of the government's insight/oversight responsibility (see SWE-039). COTS software is not subject to this requirement, but see SWE-027 for discussions and guidance regarding embedded software.

A secondary intent for this requirement is to allow NASA to support long-term maintenance. This is a capability NASA needs to have since the initial software development vendor may leave or no longer be involved in the maintenance of the software for the project. NASA software engineers or other NASA vendors may need to do the maintenance later in the life cycle of the work products (see SWE-019 ). The possession of the electronic version of the source code and related documentation (see SWE-040, SWE-077, and SWE-078) allows for these future events.

Another reason for having the electronic access is to provide for the future reuse of the delivered software on new or follow-on projects where the software vendor is different from the original developer.

This electronic access is often resisted by contractors who want to protect what they consider to be their "crown jewels." It often occurs that vendors reuse their own source code in producing NASA funded software on new projects. The contractors also prefer to restrict access to known individuals, something it can do on its site with internal access controls. This is obviously not possible off their premises. Security features do need to be used to protect the software if it is not totally government funded. The mixing of vendor funded and NASA funded source code results in a difficult decision in the contract. See Lessons Learned No. 1130, "Evidence of Recurrence Control Effectiveness," first paragraph. The NASA software development team can eliminate these problems with sufficient language in the contract SOW regarding intellectual property rights, licensing, and copyright privileges.

Proprietary rights will need to be considered for prime contractor suppliers to ensure that intellectual property rights are not being violated between the prime contractor and suppliers in order for NASA to obtain access or right to the software acquired or developed by suppliers of the prime contractor. In many cases the suppliers and prime contractors have defined access rights but access rights also needs to be considered with the NASA customer. Proprietary rights of the supplier's are also critical for the long-term maintenance or operations of the software that may be managed in the future by NASA and not the prime contractor.   

The contract SOW clearly states when (each build release, final delivery) and for what types of software (e.g. flight, MOTS, ground) electronic access is to be provided. All NASA acquisitions that include software as a part of the acquisition need to access and determine the applicability of the Federal Acquisition Requirements ¹⁸⁶ (FAR) clause 52.227-14 Rights in Data---General.

4. Small Projects

No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.

5. Resources

6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

Computer Hardware-Software/International Space Station/Software Configuration Management. Lesson No: 1130: Although it was "grandfathered" out of NPR 7150.2 compliance, the experience regarding source code for the International Space Station (ISS) is an important caveat when establishing software supplier agreements. NASA does not have source code access for all partners' deliveries for the ISS. The partners cite their concerns that delivery of source code could compromise their contractors' proprietary data. The ISS has initiated discussions with all partners to reach agreement on what level of source code visibility is necessary to ensure adequate knowledge by the control centers for on-orbit anomaly resolution. It is not clear how much extra effort these discussions have taken ⁵⁴¹.