Open source software in agencies: policy, licenses, and support

Reference article · 5 min read

Open source components are in nearly every system an agency runs, whether or not the agency has a written policy about them. They arrive inside commercial products, inside custom code a vendor writes under contract, and inside utilities staff install to get their work done. A policy does not decide whether to use open source. It decides how the agency knows what it has, who is responsible when something breaks, and who approves a component before it reaches production.

The questions surface in the same order: what the license allows, what is in the delivered code, where support comes from, and who signs off. The answers are part legal and part operational, so the policy usually needs the IT organization, purchasing, and counsel to agree before it is issued.

License families and why the difference matters

• Permissive licenses. MIT, BSD, and Apache 2.0 permit use, modification, and redistribution with few conditions, mainly attribution and preserving the license text. Apache 2.0 adds an express patent grant, one reason agencies often prefer it.
• Copyleft licenses. The GPL family requires that when you distribute the software or a derivative work, you offer corresponding source under the same terms. LGPL and the Mozilla Public License are narrower, reaching the licensed library or files rather than an entire application.
• Network copyleft. The AGPL extends the obligation to software offered to users over a network, not only to copies that change hands. A hosted application built on AGPL components can trigger source obligations with no copy handed to anyone.

Whether an obligation is triggered usually turns on whether distribution occurred. Running software internally generally does not. Giving a copy to another jurisdiction, a contractor, or the public may. These determinations depend on the facts, so send them to counsel.

The common risk is quieter than a license violation: a vendor embeds a copyleft library in custom code the agency expects to own and reuse, and the agency's options turn out narrower than anyone discussed at award. That is far cheaper to prevent than to unwind.

Tracking a bill of materials

A software bill of materials lists the components in a system, their versions, and their licenses. SPDX and CycloneDX are the common formats, and federal guidance, including minimum-element work from NTIA and CISA, has made SBOM delivery a frequent contract requirement. Points worth settling:

• Require an SBOM at delivery and with each release, not once at go-live.
• Store SBOMs where the security team can query them, so that when a widely used component has a serious vulnerability the agency can quickly tell whether it is affected.
• Include license fields, not only names and versions, so one artifact serves both security and licensing review.
• Say what happens when a component reaches end of life or loses its maintainer.

Support and indemnification when there is no vendor

Open source licenses disclaim warranties. No one owes the agency a fix, so support has to be arranged deliberately.

• Commercial distributions. Vendors package widely used open source with support, security backports, and a defined lifecycle. The agency pays for the obligation, not the software.
• Integrators and maintainers. Firms and individual maintainers sell support contracts for specific components.
• Internal capability. For small components, staff can carry maintenance themselves, a real cost that belongs in the budget.
• Indemnification. Intellectual property indemnity comes from the party the agency contracts with, so it should cover the whole delivered work, not only the lines the vendor wrote.

An approval path staff can follow

1. The requester records the component, version, license, and intended use.
2. The license is checked against the agency's list. A common structure pre-approves permissive licenses for internal use, routes copyleft to a named reviewer, and sends network copyleft and unfamiliar licenses to counsel.
3. Security review covers known vulnerabilities, project activity, and update plans.
4. The support plan is stated: commercial subscription, support contract, or internal ownership.
5. The approved component goes into the inventory, and that record feeds the SBOM.

A path that takes weeks gets bypassed, and bypassed components go untracked.

Publishing code the agency developed

Publishing agency-developed code can reduce duplicated spending across jurisdictions, but several steps belong before the first push.

• Rights. Confirm the agency holds them. Contractor-developed code is owned according to the contract, and many leave ownership with the vendor.
• Copyright and licensing. Whether a government body can assert copyright in its own work varies. Federal government works are generally not subject to domestic copyright protection, and state and local rules differ. Counsel should choose the license or dedication.
• Security review. Scan for credentials, keys, internal hostnames, and configuration describing the network. Version control history retains what deleting a file does not remove.
• Records. Source code may already fall under the public records law, but answering a request and running a public repository are different decisions. Confirm whether an exemption applies, particularly for code protecting critical systems.
• Maintenance. Decide who answers issues, who reviews outside contributions, and where security reports go. A repository with no listed contact is a liability.

What to ask vendors and put in the contract

• A complete SBOM with each delivery, in SPDX or CycloneDX.
• A representation that no component license conflicts with the agency's intended use, including reuse by other public entities.
• Notice and written consent before copyleft components enter deliverables the agency will own.
• Intellectual property indemnification covering the full delivered work.
• Remediation timelines that apply to third-party components, not only to vendor-written code.
• Source escrow or repository access, so the agency can maintain the system if the relationship ends.

Guidance here changes, so confirm current expectations with the official source and with counsel. HQT builds and maintains custom software for public agencies, including documenting what a delivered system contains and what its licenses require.

Frequently asked questions