Introduction
Open Source Software (OSS) is software that is freely licensed to the public to use, copy, modify, and distribute. The source code is openly shared to encourage people to voluntarily improve the design of the software. CMS has been an active consumer of and contributor to OSS on several IT projects. This chapter provides guidelines for the CMS project teams that wish to use and contribute to OSS libraries and packaged OSS for their internal consumption or for development of new and custom software.
Several CMS business units and offices have been actively developing open source projects as part of IT modernization efforts at the agency. CMS has many active open source communities, such as its Developer APIs like Blue Button, the CMS Design System, and hundreds of other repos across many CMS organizations. CMS has embraced Open Source development projects and is looking forward to releasing software to promote its reuse.This policy will help CMS achieve the goals outlined in the OMB directive M-16-21 for Federal agencies, as well as in the 2024 SHARE IT Act.
This CMS policy is a living document, and changes to this policy are handled via issues and pull requests in the CMS GitHub repository, https://github.com/CMSgov/cms-open-source-policy.
Scope
The guidance in this chapter is limited to using OSS within the CMS environment and does not address practices that are generally applicable to software engineering efforts. Moreover, the guidance complements and incorporates CMS’s existing policies, standards, and procedures, including those described in other parts of the CMS TRA, such as Cybersecurity Security Services. The TRB manages and approves the use of OSS licenses in accordance with TRA guidance and its prescribed function within the CMS TLC.
Additional references used in this chapter:
Wikipedia, Free and open-source software
Digital.gov, Requirements for achieving efficiency, transparency, and innovation through reusable and open source software
DoD Chief Information Officer, DoD Open Source Software FAQ
Acquisition.gov, FAR Subpart 27.4 - Rights in Data and Copyrights
OWASP, Vulnerability Scanning Tools
Overview
OSS Overview
Open Source Software is computer software whose source code is developed in an open and collaborative way and made available (in a human-readable format) with a copyright license that complies with the Open Source Initiative's Open Source Definition (OSD). The Open Source Initiative (OSI) established the following criteria for OSS, all of which must be met to comply with OSD:
- Software is free to be re-distributed
- Source code is available with software
- Derived work is allowed
- Integrity of author’s source code is maintained
- Contains no discrimination against persons or groups
- Contains no discrimination against fields of endeavor
- License must be distributed
- License must not be specific to a product
- License must not restrict other software
- License must be technology neutral
The backbone of OSS is community sharing of ideas and collaborative development of code to serve a common purpose. Some of the key enablers of OSS development are version control systems, mailing lists, wikis, and blogs that help developers collaborate to develop code. Copyright licenses make the resulting software code available to users to use, change, and improve the software, and to redistribute it in modified or unmodified forms.
History of OSS at CMS
CMS is interested in two basic types of OSS—open source frameworks/libraries and open source solutions (CMS Open Source Software (OSS) Thoughts for a Strategy, CMS, March 2010). Open source frameworks / libraries are standalone pieces of code that may have dependencies on other software and are used or embedded as part of a larger software development effort. Examples include the Spring Framework and Apache Struts, both of which are open source application frameworks for Java development, and Hibernate and myBatis, which are persistence frameworks that provide mappings between Structured Query Language databases and objects in Java.
Open source solutions are open source applications that may be part of a larger software distribution, can operate standalone, and serve a single function or set of functions. Open source solutions may come with vendor support. Examples include Linux, an open source operating system; Apache HTTP Server, an open source Web server; and Oracle Glassfish and RedHat JBoss, open source application servers.
CMS uses open source frameworks and libraries and a small set of open source solutions. Since 2014, CMS seeks to expand its use of OSS to include additional open source solutions.
Benefits of OSS within the CMS Ecosystem
OSS provides many advantages, as demonstrated in the commercial industry and the government sector. If used thoughtfully, OSS offers the potential for cost reduction, timelier delivery, and improvement of the overall capabilities of a system. Specifically, OSS can:
-
Offer considerable savings in software purchasing cost and greater efficiency in repurposing and enhancing existing software. OSS has inherent flexibility in its purpose and adds value to its use.
-
Minimize vendor lock-in through open standards and flexibility in the choice of solutions. This is evident of the cost-saving nature of OSS applications.
-
Enable transparency of software implementation to support extension of software (through supported plug-in mechanisms) while also ensuring robustness of design and implementation
-
-
CISA Development Guide OSS Policy, “Publicly available source code enables continuous and broad peer review. Whether simply publishing the completed code or opening the development process, the practice of expanding the review and testing process to a wider audience—beyond the development team—ensures increased software reliability and security. Developing in the open also allows for other opinions to help adjust the direction of a product to maximize its usefulness to the community it serves.”
-
Help keep the enterprise abreast of technology developments and facilitate the early adoption of emerging technology
CMS is committed to meeting the needs of its IT development community by optimizing best practices and creating innovative approaches for rigorously evaluating and enhancing existing software development processes. CMS incorporates OSS as part of its IT development practices to realize the many benefits and capabilities of OSS.
Inbound Open Source
Considerations for Adoption of OSS
Although there are tangible benefits to OSS, the process of realizing these benefits may significantly change how CMS uses IT. For example, adopting OSS alters the Agency’s development and acquisition of software and how the Agency’s IT departments conduct business.
A common misconception about OSS is that it is cost free. The nature of cost with OSS differs from commercially licensed software. Although licensing costs may be minimal to none, CMS must consider the total cost of ownership, as various costs are involved including evaluation, maintenance, installation/ configuration, integration, and support/ operations. One important contributor to OSS cost is the absence of a “productized” solution. Many OSS products do not offer comprehensive documentation, easy installation and upgrade of utilities, friendly migration tools, and Graphical User Interface (GUI) configuration tools. Therefore, operations and maintenance (O&M) can be complex and expensive for some OSS products. To overcome this gap, the enterprise adopting an OSS solution must possess the necessary skills or have access to third-party vendors who provide IT support services for that specific OSS solution.
Another key OSS consideration is managing the adoption of OSS within the enterprise. Free software and full access to the source code of OSS present unique challenges for the enterprise. Individuals might download and install OSS without sufficient oversight. Therefore, the enterprise must carefully manage open source adoption and assess OSS for use across the enterprise, using the inbound review checklist. Criteria for assessing solutions must include the open source software’s maturity, total cost of ownership, licensing implications, alternative solution evaluations, and security & risk review. CMS requires that OSS be managed to the same standard as COTS software. The business owner is responsible to perform due diligence.
Procuring OSS
CMS focuses on OSS solutions that can be used “out of the box,” like a COTS product. This has two implications:
- That there will be third-party vendor support for the OSS solution (e.g., to install, configure, integrate, operate, and maintain the software)
- That the OSS solution will require no customization, extension, or modification
It is important to evaluate the total cost of ownership when adopting an OSS solution as various costs are involved including evaluation, maintenance, installation/ configuration, integration, and support/ operations. Contractors using open source frameworks and libraries are responsible for (a) ensuring that the OSS works properly within the CMS environment, and (b) that their staff is well versed in configuring and subsequently operating the software. One major consideration is that the OSS license for a package may encumber any modifications to the source code.
The contractor’s responsibility extends to monitoring the community behind the OSS product for new versions and patches, and support for older versions. Furthermore, contractors will monitor the community to ensure it continues to offer substantial support for the OSS product. The contractor should coordinate with the TRB to understand how and where CMS currently uses OSS today, and to identify lessons learned from successful implementations and resolution of issues involving OSS. This knowledge will shape the contractor’s use of OSS and may also influence CMS’s policy regarding OSS.
The TRB is responsible for approval of OSS licenses. The TRB will rely on the guidance in this chapter to assess the potential adoption of and approval for specific OSS.
Open Source Software Customization and Contribution for CMS
As CMS expands the adoption of OSS, it is possible that specific OSS will require extensions or customization for use within CMS’s environment. In some rare cases, the customization may be specific to CMS’s needs and remain internal to CMS. Because internal forks and patches are costly to manually maintain and accumulate technical debt, projects must provide detailed justification for managing OSS extension and customization exclusively within CMS.
CMS Open Source Strategy
OMB Memorandum M-16-21, Federal Source Code Policy: Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software, encourages the use and publication of open source in the federal government.
The Source code Harmonization And Reuse in Information Technology Act or the SHARE IT Act of 2024, ensures that “custom-developed code (i.e., source code that is produced under an agency contract, funded exclusively by the federal government, or developed by federal employees as part of their official duties) and certain technical components of the code such as architecture designs and metadata are (1) owned by the agency, (2) stored at no less than one public or private repository, and (3) accessible to federal employees under certain procedures. Agency contracts for custom-development of software must acquire and exercise rights sufficient to allow government-wide access, sharing, use, and modification of any custom-developed code. The act does not apply to source code that is classified, developed primarily for use in a national security system, or developed by an element of the intelligence community. An agency's office of the chief information officer may exempt source code from being shared or made publicly accessible to protect individual privacy.”
The CMS Open Source Program Office created a detailed guide, Enabling Reuse of Federal Source Code that provides full technical documentation on the subject, mostly in the context of GitHub. Guidance for other repositories are planned.
Outbound Open Source
Contribution of Open Source to the community
CMS may consider release of internally developed software as open source, including software that is an extension to an existing OSS project or software that CMS may want to use to initiate a new OSS project.
Appropriate considerations for developing and contributing OSS to the community include defining policies and processes to release software as open source, guidance for continued development, ground rules for engaging the larger community to contribute to the project, assessment of alternative copyright licensing strategies, and publishing project metadata to support agency-wide software inventory and reuse as per the SHARE IT Act. Theseoutbound checklists outline these processes.
Alongside the software, agencies are required to publish metadata on all custom-developed code after July 22, 2025, which is not subject to exemptions as per the 2024 SHARE IT Act. All repositories must store their metadata in a code.json file.
Employee participation in OSS projects used by CMS is often in the Government’s interest. It is typically a legitimate use of government resources when the Government uses the software in question, either directly, as a component of a larger government system, or as a component of underlying government infrastructure.
Government employees may contribute to existing OSS projects (including being the primary maintainer) as part of their official duties, so long as they consult with their supervisor first to ensure a common-sense approach for contributions that preserve Operations Security (OPSEC) and further the Government's interests. Contractors may contribute to OSS projects at government expense when the government task monitor authorizes such activity as being in the Government’s interest, subject to the scope and provisions of the contract.
Creating a separate, CMS-specific version of any OSS project, for any reason, increases support risk and should be avoided whenever possible. Creating such a CMS-specific fork creates risk by requiring separate maintenance, reducing access to software capabilities from the OSS community, and may require the agency to assume full management responsibility of the software’s source code, thereby increasing costs.
CMS encourages upstream contributions to OSS projects. Any improvements or new capabilities added to an OSS project whether it be code, commentary, bug reports, feature requests, or overall strategic direction should be contributed back to the upstream open source project via pull/ merge request, in accordance with the processes used by that project.
Open Source Licensing
For CMS projects using OSS, each CMS business owner is responsible for assuring that CMS’s use of the open source is compliant with its license. For a CMS-released OSS project, the CMS business owner is responsible for selecting an appropriate license model. In either case, the TRB is responsible for approval of OSS licenses.
Be aware of licensing issues and select a licensing model considering the difference between “permissive” and “non-permissive” licenses, warranty/ guarantee limitations, attribution, and trademark/ IP protections and its impact on the choice of license.
The CMS default LICENSE file for projects acknowledges that CMS work is in the U.S. public domain, and uses Creative Commons Zero International 1.0 (CC0) to waive copyright internationally. The Open Source Initiative maintains a list of licenses that the project team may optionally use. In addition to obtaining TRB approval, the Office of General Counsel must review any proposed open source modification or creation.
Other useful descriptions of Open Source Licenses include tl;drLegal's verified license resource page, the Wikipedia Comparison of Free Software Licenses, and Civic Commons’ Choosing a License.
OSS Consideration and Applicability
Project teams at CMS are requested to conduct market research and analyze commercial and other open source alternatives that may meet their business need before venturing into OSS development. To help make this decision, a project team may use the three-step software solution analysis outlined at Digital.gov’s Requirements for achieving efficiency, transparency, and innovation through reusable and open source software, and supplemented by BR-OSS-2, BR-OSS-3, BR-OSS-4, and the CMS OSS Policy.
The CMS OSS Policy will guide project teams that venture into custom code development and intend to release as OSS. If the project teams seek to release as OSS, they should consult the outbound review checklists first. If they have any further questions or need support, they can reach out to the Open Source Program Office via Slack or email. If a team has questions about contractual requirements or legal questions, they can reach out to the Office of the Acquisition & Grants Management (OAGM) to understand the contractual requirements, policies and legal issues.
CMS contractors who develop software for CMS business use are covered by the procurement clauses that assign the copyright of the CMS-funded custom designed software to CMS and prohibits the contractors from reselling it to other federal government agencies. Due to the variety of CMS IT and non-IT contracts, it is the project team’s responsibility to perform all due diligence for their specific contract in consultation with the OAGM.
TRA 2025 Release 1 • General Distribution / Unclassified Information