Government Body Builds an Open Source Policy and OSPO

Situation

A national government body delivered a large portfolio of public services through software built and operated by several internal teams and a rotating set of contractors. Open source was everywhere in that estate, adopted project by project over many years without a central record. No single group owned the question of which licenses governed the software, and no policy existed to decide which licenses were acceptable in the first place. Procurement reviewed vendors, security reviewed vulnerabilities, but the license posture of the open source itself sat between the seams, owned by no one.

The trigger

The relicensing wave forced the question into the open. When HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License as of August 2023, and as the Server Side Public License moves at MongoDB, Elastic, and Redis became widely discussed, the body's leadership asked a direct question. Which of these projects do we run, and what changed for us. No one could answer with confidence. For a public sector organization accountable to auditors and to the public, an unowned and unmapped dependency on software with shifting terms was not acceptable. The decision was made to govern open source deliberately rather than absorb each change as a surprise.

Approach

We began with the inventory, because policy without a map is guesswork. Working across the internal teams and contractors, we built a dependency map that recorded the license state of each component, direct and transitive, and flagged everything sitting on source available or commercial terms. That gave the body its first complete picture of what it actually depended on. The map confirmed that the genuine exposure was concentrated in a small number of widely used infrastructure tools, which made the problem tractable rather than overwhelming.

With the map in hand, we helped the body stand up an open source program office, a small central function to own policy, approval, and inventory going forward. We drafted an open source policy set to the body's risk tolerance, including a license allowlist that named acceptable license families and flagged source available and strong copyleft licenses for review. We wired an intake gate into the way teams adopted new dependencies, so that a future relicensing event or a new component on restrictive terms would be caught at the point of adoption. Throughout, we kept the legal interpretation of specific license terms with the body's own counsel, while we supplied the inventory, the policy structure, and the operating model.

Outcome

The body moved from a position where no one owned open source license risk to one where a named office did. The open source program office became the single point of accountability, with a current inventory, a clear policy, and an intake gate that stopped unvetted dependencies entering the estate. The relicensed infrastructure tools that had prompted the work were reviewed against the new policy, contained where the exposure warranted it, and documented so that the body could answer an auditor with evidence rather than assurances.

The lasting change was preventive. Before the engagement, each relicensing event would have arrived as a fresh emergency that no one was positioned to handle. After it, the office caught new components at intake and reviewed license changes as a routine part of operations. The body had turned a recurring surprise into a managed process, and the cost of the next relicensing event dropped from an unbounded scramble to a known piece of work.

Lessons for buyers

Three lessons carry across to any organization, public or private. First, ownership is the foundation. License risk that belongs to no one will surface at the worst possible moment, in an audit rather than at intake. Naming an office to own it changes everything that follows. Second, policy needs a map underneath it. An allowlist written without an inventory governs an estate you cannot see, so the dependency map comes first. Third, the gate is what makes governance durable. A one time cleanup decays. An intake gate wired into how teams ship keeps the estate clean as it grows and catches the next relicensing event automatically.

This work was delivered through our open source governance and policy service, which sets policy, approval gates, and license allowlists, and our open source license risk assessment, which produced the underlying dependency map. For the wider context, see the governance and SBOM pillar and the open source license risk pillar.