Open source policy: what to include.

Most open source risk does not arrive through a new adoption. It arrives when a component you already run quietly changes its license. An open source policy is the standing control that makes both moments visible: the point of adoption, where a new component enters, and the point of change, where an existing one shifts terms. A good policy is not a long document that sits unread. It is a short set of rules, gates, and owners wired into how teams ship, so the common case moves fast and the risky case surfaces for review. What you include determines whether a future move to the Business Source License or the Server Side Public License is an early alert or a late surprise.

License rules: the allowlist and the denylist

The core of the policy is a clear statement of which licenses your teams may adopt freely, which need review, and which are blocked. An allowlist of well understood open source licenses such as the MIT License and the Apache License 2.0 lets the common case proceed without friction. A denylist, or an escalation list, names the licenses that require a decision, including the source available licenses that are not approved by the Open Source Initiative. Without these lists every adoption becomes an ad hoc judgment, and a component under a restrictive license can reach production simply because no one was asked. The lists turn license posture from an opinion into a rule, and they give engineers a fast answer for the vast majority of choices. Whether a specific license belongs on the allowlist is a question to settle with your own counsel.

Approval gates at the point of intake

Rules only work if something enforces them. Approval gates put the policy at the moment a component enters, so a license that needs review cannot slip into production without a decision. The gate should be light for allowlisted licenses and firm for the rest, routing an escalation to the right owner rather than blocking work outright. The aim is a control that runs at the speed of delivery, catching the exceptions while letting the routine flow. A gate that is too heavy gets bypassed, and a bypassed gate is no control at all. We set out how to build gates developers will actually use in open source approval workflows for developers.

Monitoring components already in use

The part most policies omit is the one that matters most for relicensing risk: watching the components you already run. The recent wave of changes, with HashiCorp moving Terraform and others to the Business Source License as of August 2023, and Elastic and Redis moving to the Server Side Public License, attached new restrictions to software that was already in production. A policy that only checks licenses at adoption misses all of it. Include a rule that ties each component to its current license state and flags a change, so a relicense becomes an alert rather than a discovery made during an audit. That monitoring depends on knowing what you run, which is why the policy should require an accurate inventory, covered in maintaining an accurate SBOM.

Ownership, scope, and the SBOM link

A policy needs an owner or it ages into a document no one follows. Name the function accountable for keeping it current, whether an open source program office, a governance lead, or a cross functional committee, with legal consulted on interpretation. Set the scope clearly so it covers not only first party code but the third party and contractor code that often enters with the least oversight, which we address in third party and contractor code governance. Finally, link the policy to the SBOM, so the rules and the record of what you run point at each other rather than living apart. A policy connected to a live inventory is a control. A policy in a wiki is a wish. The full frame sits in our pillar on governance and SBOM. Interpretation of any license is a question for your own counsel.