Engineering judgement and a consideration of possible impacts to the software development activity need to be used/made when determining that software is MOTS, legacy, or heritage.
3.4 Open Source Software
Open Source Software is considered a form of off-the-shelf software. Even if most of the software on a NASA project is developed in-house, it is common to find embedded Open Source Software within the code. It is often more efficient for a software engineer to use widely available and well tested code developed in the software community for common functions than to "reinvent the wheel."
3.4.1 What is Open Source Software?
3.4.2 Planning ahead for the inclusion of Open Source Software
Whether Open Source Software is acquired or developed by NASA or a NASA contractor, a usage policy should be established up front to avoid any possible legal issues that may arise. This policy may be developed in conjunction with advice from the Software Release Authority (even if you do not plan to release the software) and/or your Center's IP Legal Counsel.
3.4.3 Releasing NASA code containing Open Source Software
When software is released to another NASA Center, NASA project or external organization, it is important to inform the receiving party of any licenses and restrictions under which the software is released. It is important to note that additional software required to "run" the released software is not part of the software release. For example a web application that runs under the Apache Web Server does not need to include the Apache Public License as part of the relevant licenses.
Software releases are also performed when software is submitted for Space Act Awards, such as the NASA Software of the Year Award. For more information on software releases one should contact the Software Release Authority at the NASA Center at which the software is being or was developed.
There are requirements and processes associated with software releases. See NPR 2210.1C, "Release of NASA Software."
A cautionary item from NPR 2210.1C, paragraph 18.104.22.168 is worth repeating here: "If a proposed release of Open Source Software includes the release of external Open Source Software, care shall be taken to ensure that the pertinent license for such external Open Source Software is acceptable. For example, at least one widely used external open source license does not currently include an indemnification provision and further requires that all software distributed with that external Open Source Software be distributed under the same license terms. Therefore, except for an Approved for Interagency Release or Approved for NASA Release, both the Center Office or Project that is responsible for the software and Center Patent or IP Counsel shall review and approve any proposed distribution of Open Source Software that includes external Open Source Software."
Caution: Open Source Software may itself contain other Open Source Software!
3.4.4 Identifying and using high pedigree Open Source Software in NASA code
Going back to the NPR 7150.2, requirement 2.3.1.e, which states: "The software component is verified and validated to the same level of confidence as would be required of the developed software component." To achieve this level of confidence, it is recommended that software developers use only Open Source Software (and COTS, GOTS MOTS, legacy as well) software that has a high pedigree, i.e. a gold standard. Such Open Source Software will typically have the following characteristics:
3.4.5 Procurement of software by NASA – Open Source Provisions
A cautionary item from page 9 of NPR 2210.1C, "Release of NASA Software,"
"Open Source Software Development, as defined in paragraph A.1.8, of NPR 2210.1C, may be used as part of a NASA project only if the Office or Project that has responsibility for acquisition or development of the software supports incorporation of external Open Source Software into software. In addition, the Office or Project responsible for the software acquisition or development shall:
3.5 Embedded Software
Embedded software applications written by/for NASA are commonly used by NASA for engineering software solutions. Embedded software is software specific to a particular application as opposed to general purpose software running on a desktop. Embedded software usually runs on custom computer hardware ("avionics"), often on a single chip.
Care must be taken when using vendor-supplied board support packages (BSPs) and hardware-specific software (drivers) which are typically supplied with off-the-shelf avionics systems. BSPs and drivers act as the software layer between the avionics hardware and the embedded software applications written by/for NASA. Most CPU boards have BSPs provided by the board manufacturer, or third parties working with the board manufacturer. Driver software is provided for serial ports, USB ports, interrupt controllers, modems, printers, and many other hardware devices
BSPs and drivers are hardware dependent, often developed by third parties on hardware/software development tools which may not be accessible years later. Risk mitigation should include hardware-specific software, such as BSPs, software drivers, etc.
Many BSPs and drivers are provided by board manufacturers as binary code only, which could be an issue if the supplier is not available and BSP/driver errors are found. It is recommended that a project using BSPs/drivers maintain a configuration managed version of any BSPs with release dates and notes. Consult with avionics (hardware) engineers on the project to see what actions, if any, that may be taken to configuration manage the BSPs/drivers.
Consideration should also be given to how BSP/driver software updates are to be handled, if and when they are made available, and how it will become known to the project that updates are available?
Vendor reports and user forums should be monitored from the time hardware and associated software are purchased through a reasonable time after deployment. Developers should monitor suppliers or user forums for bugs, workarounds, security changes, and other modifications to software that, if unknown, could derail a NASA project. Consider the following snippet from a user forum: