The intent of this requirement is to provide NASA the required 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.
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 USB flash 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) possession of the electronic, modifiable version of the source code and related documentation (see SWE-040 and SWE-077) 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 may be resisted by contractors. It often occurs that vendors reuse their own source code in producing NASA funded software on new projects. Some contractors also prefer to restrict code access to its website where internal access controls can be applied. 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.
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. See SWE-077 for a list of Software Operations, Maintenance, and Retirement deliverables.
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 suppliers 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, modified off the shelf (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.
Data rights are addressed in the FAR requirements; projects should ensure that the correct data rights FAR requirements are included in any acquisition activity.