Migration of unmigrated content due to installation of a new plugin
1. The Requirement
1. The Requirement
4. Small Projects
6. Lessons Learned
3.15.2 The project manager shall ensure that when an Open Source Software (OSS) component is acquired or used, the following conditions are satisfied:
The requirements that are to be met by the software component are identified.
The software component includes documentation to fulfill its intended purpose (e.g., usage instructions).
Proprietary, usage, ownership, warranty, licensing rights, and transfer rights have been addressed.
Future support for the software product is planned and adequate for project needs.
The software component is verified and validated to the same level required to accept a similar developed software component for its intended use.
It is important to understand that under copyright law, OSS is a form of commercial software that needs to be treated with the same respect as any other commercial software. For this reason, it is important to understand both the specifics of the open source license in question and how the project intends to use and redistribute any modified OSS. It is the project's responsibility for both commercial and OSS to verify that the Government receives sufficient rights in any source or executable code, libraries, or "building blocks" (Commercial Off the Shelf (COTS)/ Government Off the Shelf (GOTS) / Modified Off the Shelf (MOTS) & OSS) to meet the project's needs along with any anticipated further Government applications. This may include verifying that the license does not contain any undesired requirements or restrictions on redistribution, modification and release, etc. Seek guidance from your Center Office of Chief Counsel for help in making these determinations.
1.2 Applicability Across Classes
All software used on a project must meet project requirements and be verified and validated, including any incorporated open source software. The project must ensure that each open source software component meets NASA requirements; that all of the legal requirements for proprietary rights, usage rights, ownership, warranty, licensing rights, and transfer rights are understood and met in accordance with the project’s planned use; and that future support for the software is planned.
Open source software (OSS) 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 OSS 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."
What is Open Source Software?
In NPR 2210.1C, "Release of NASA Software"
under Appendix A, definitions, A.1.7, "'Open Source Software' means software where the recipient is free to use the software for any purpose, to make copies of the software and to distribute the copies without payment of royalties, to modify the software and to distribute the modified software without payment of royalties, to access and use the source code of the software, and to combine the software with other software in accordance with open source licenses/agreements. OSS is a subcategory of Publicly Releasable software."
Planning ahead for the inclusion of Open Source Software
Whether OSS 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 intellectual property (IP) Legal Counsel.
Procurement of software by NASA – Open Source Provisions
A cautionary item from page 9 of NPR 2210.1C, "Release of NASA Software,"
is worth reiterating here: "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 OSS into software. In addition, the Office or Project responsible for the software acquisition or development shall:
Determine the ramifications of incorporating such external OSS during the acquisition planning process specified in NASA FAR Supplement Subpart 1807.1, Acquisition Plans; and
Consult with the Center Patent or IP Counsel early in the planning process (see 184.108.40.206) as the license under which the OSS was acquired may negatively impact NASA's intended use."
Identifying the requirements to be met by the OSS allows the project:
To analyze the OSS component to ensure it is adequate for the function it is intended to fulfill.
To determine how the risk of using OSS components affects the overall risk posture of the software system.
To perform testing to ensure that the OSS component performs the required functions. Without requirements in place for the OSS components the software functionality cannot be tested.
Usage instructions are important to help ensure the purpose, installation, and functions of the OSS components are properly understood and used in the project.
Obtain Usage Rights
For OSS components, projects need to be sure that any proprietary, usage, ownership, warranty, licensing rights, and transfer rights have been addressed to ensure that NASA has all the rights necessary to use the OSS component in the project. It may be helpful to the project to work with procurement to determine the documents needed from the software developer and with the legal department to ensure any subtle nuances and issues related to obtaining this information are properly understood and addressed.
Plan Future Support
It is important to plan for future support of OSS adequate for project needs. As applicable, consider the following:
Ensure a risk mitigation plan is in place to cover the following cases:
Loss of developer support for the product.
Loss of maintenance for the product (or product version)
Loss of the product (e.g., license revoked, recall of product, etc.).
Consider joining a product users group to obtain access to defects discovered by the community of users.
Ensure a plan to provide adequate support is in place; the plan needs to include maintenance planning and the cost of maintenance.
Document changes to the software management, development, operations, or maintenance plans that are affected by the use or incorporation of OSS components.
Obtain an open source software licenses review by the Center Counsel.
Identifying and using high pedigree OSS in NASA code
To achieve the level of confidence required in NPR 7150.2, requirement 3.15.2.e, which states: "The software component is verified and validated to the same level required to accept a similar developed software component for its intended use", it is recommended that software developers use only OSS that has a high pedigree. Such OSS will typically have the following characteristics:
There should be a strong software development model including defined processes for bug reporting, which includes identification, triage, and correction.
Code modification: Review and approval to commit fixes and features to the source code.
Testing: Thorough descriptions of test cases, test runs, and test configurations.
Code review (as part of the code modification process).
Documentation: Detailed documentation should be updated.
Discussion lists for questions: This may include a wiki, mailing list, or live chat site.
Leadership: Ensures that the community works in a coordinated fashion to define target functionality for each release and overall product focus.
Usually, a high quality, established open source project will have a large number of developers. Usage of the project's product(s) will occur across multiple industries both nationally and internationally.
Metrics (e.g., number of developers) can be used to evaluate the quality of an open source project via sites that track a large proportion of OSS projects (e.g., Black Duck Open Hub
). Norms, such as what constitutes a large number of developers, change as the number of open source projects and developers grow.
The project should provide a listing of all OSS included, embedded, or modified within the piece of OSS.
OSS may provide more opportunity to perform V&V of the software to the same level of confidence as if obtained through a "development" process. Often OSS project will provide online access to detailed development and test artifacts (as described above), which may be difficult to obtain from commercial off the shelf (COTS) vendors.
Releasing NASA code containing Open Source Software
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 220.127.116.11 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!
Additional guidance related to OSS may be found in the following related requirement in this Handbook: