GOVERNANCE AND SBOM

License compatibility management.

License compatibility management is the discipline that keeps incompatible open source licenses from colliding inside your software. Done well, it catches a conflict at intake. Done poorly, it surfaces the conflict in an audit or a deal. This article sets out how to run it as a control rather than a cleanup.

License compatibility management answers a deceptively simple question: can the licenses in this software lawfully be combined and shipped together? The answer is rarely simple, because modern software is a deep tree of dependencies, most of them pulled in transitively, and each carries its own license. A permissive component at the top can sit on a copyleft component three layers down. A dependency that was compatible last quarter can relicense and become incompatible this quarter. When nobody is checking at the point components enter the build, these conflicts accumulate quietly until something forces them into the open. The goal of compatibility management is to make the check routine, automatic, and early.

Why license conflicts happen

Conflicts are not usually the result of a bad decision. They are the result of no decision. A developer adds a library to solve a problem, and that library quietly brings a dozen transitive dependencies, each with a license nobody examined. Most of the time nothing breaks, which is exactly why the habit forms. The trouble appears when a strong copyleft license, which can require you to release source under the same terms when you distribute, ends up combined with code you intended to keep proprietary. Or when a license forbids a combination your product depends on. Because the licenses entered through the back door of a transitive dependency, the conflict is invisible until someone looks, and by then it is shipping.

How relicensing changes the picture

The relicensing wave added a dimension that older compatibility tools were never built for. Compatibility used to be a static property: two licenses either combined or they did not, and the answer held. Now a component you cleared can change its license under you. As of August 2023 HashiCorp moved Terraform and related tools to the Business Source License. As of March 2024 Redis moved to a Server Side Public License model. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021. A component that was compatible and freely combinable can, after a relicense, carry a competitive use restriction or a copyleft style condition your policy never anticipated. Compatibility management therefore has to be continuous, not a one time clearance, because the licenses themselves are now moving targets. The deeper pattern is covered in the governance and SBOM pillar.

The foundation: see the whole tree

You cannot manage compatibility you cannot see. The foundation is a current software bill of materials that captures the full dependency tree, direct and transitive, with the license of each node recorded. Software composition analysis tools generate and maintain this map. Without it, compatibility management is guesswork, because the conflicts hide in exactly the transitive layers a shallow scan misses. With it, every license in your software is visible and attributed, which turns an unknowable question into a checkable one. Keeping that map current is the single most important investment, because a stale map gives false confidence, and false confidence is worse than none. Automating the inventory is the practical first step, covered in open source inventory automation.

Encode the rules as policy

A map is necessary but not sufficient. The map tells you what licenses are present. Policy tells you which combinations are acceptable for your use. Write down which license families are allowed, which are conditional, and which are prohibited, and define how source available licenses such as the Business Source License and the Server Side Public License are treated, since they need their own category. This policy is what converts the raw inventory into decisions. It is also what makes the control consistent, because without it every compatibility question becomes a fresh debate, and the answer drifts with whoever is asked.

Gate it early, in the build

Compatibility management only works if it runs before the conflict ships. Place the check at intake, when a new dependency is proposed, and again in the build pipeline, where the full resolved tree is known. An incompatible combination should fail the build with a clear message, the same way a failing test does, so the developer sees it immediately and the conflict never reaches production. Catching a conflict at intake costs minutes. Catching it in an audit costs a remediation project and a difficult conversation. The whole value of the discipline is in moving the discovery from late and expensive to early and cheap. Wiring the check into the way developers already work is what makes it stick, which is the subject of open source approval workflows for developers.

The buyer side view

We help you stand up compatibility management as a working control. We build the inventory so the full tree is visible, set the policy that defines acceptable combinations including the source available category, and wire the gates into intake and the build so conflicts fail fast. We are paid only by you, so the policy reflects your risk tolerance rather than any tool vendor's defaults. Whether two specific licenses are compatible for your use is a legal question, and we work alongside your own counsel on it rather than in place of it.

COMMON QUESTIONS

Questions buyers ask.

CONTAINMENT

Catch the conflict at intake, not in the audit.

Confidential open source governance and policy support. Independent, buyer side, paid only by you.

Not ready to talk? Read the free open source license risk guides first.