Open source risk in the procurement process.

Most open source risk is discussed as a problem of your own code. It is also a problem of what you buy. Open source risk in the procurement process is the exposure that transfers to you when a vendor product, a managed service, or an embedded platform depends on open source that can relicense. The vendor may run Elasticsearch behind its analytics, ship Terraform inside its deployment tooling, or cache on Redis without ever naming it in the contract. When one of those components changes terms, the vendor must respond, and the cost of that response can reach you through price, support, or a forced migration you did not choose. Procurement is the one moment where you can ask the question and price the answer before the leverage shifts. After signing, the same question is a renegotiation.

Why a vendor relicense becomes your exposure

The recent wave of changes showed how a single upstream move ripples outward. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License as of August 2023. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021. Redis moved to a source available model as of March 2024. Each of those components sits inside countless commercial products. A vendor that embedded one of them inherited the change, and had to relicense commercially, migrate to a fork such as OpenTofu, OpenSearch, or Valkey, or rework its architecture. Every one of those responses has a cost, and a vendor under pressure will look for ways to pass it on. If your contract is silent on who carries that cost, the default answer is often you. Source available is not open source, and the restrictions these licenses add are what turn a vendor's dependency into your renewal surprise.

The open source questions to put into diligence

Good procurement diligence sees the dependency tree, not only the product surface. Ask the vendor for a software bill of materials and treat it as a deliverable rather than a courtesy. Ask which components carry source available or restrictive licenses, naming the families directly so the answer is specific. Ask who absorbs the cost if an embedded component relicenses, and how the vendor monitors its own dependencies for changes in license state. A vendor that can answer these questions has done the work and is a safer dependency. A vendor that cannot is carrying exposure it has not mapped, which means you would be too. The structure of a thorough review is set out in our open source due diligence checklist, and the inventory that supports it is covered in maintaining an accurate SBOM.

Contract terms and an intake gate that hold

Diligence finds the exposure. The contract is where you contain it. Useful terms include a current software bill of materials as an ongoing deliverable, a warranty that the vendor holds the rights it grants you, a notice obligation if a key dependency relicenses, and clear language on who pays for remediation if it does. The drafting and enforceability of any clause is a question for your own counsel, and we recommend involving them early. Procurement also needs an intake gate so these questions are asked every time rather than only on the large deals, which is the work of an open source policy that catches a relicense at intake and the approval workflows your teams will actually use. The whole frame sits in our pillar on open source governance and SBOM. Our role is to help you ask and size the risk on the buyer side, not to interpret the terms, which belongs with counsel.