Detecting Open-Source License Conflicts in Practice: Five Patterns and an Engineering Playbook

Understanding one license is easy. The hard part is combinations: a modern application ships thousands of components under dozens of licenses, whose pairwise compatibility forms a complex matrix — and a single conflict can compromise the legality of distributing the whole product. This piece covers the five conflict patterns engineering teams actually hit, and how to industrialize detection and remediation — the part law-firm articles never cover but customer acceptance actually checks.

Five typical conflict patterns

One: strong copyleft inside a proprietary product. The classic and most severe: GPL code inside a closed-source deliverable. The entry point is rarely a declared dependency — it is a copied utility function, a forked-and-renamed module, an outsourcer's "borrowed" implementation. The manifest stays clean; the conflict hides at file level. Our license risk map covers the contagion logic tier by tier.

Two: open-source licenses incompatible with each other. The most famous pair is Apache-2.0 and GPLv2: Apache-2.0's patent clause conflicts with GPLv2's terms, so their code cannot merge into one derivative work (GPLv3 fixed this). Likewise CDDL vs GPL — the reason ZFS long stayed out of the mainline Linux kernel. Each license alone is "fine"; the combination is the problem.

Three: declaration doesn't match reality. A package's metadata declares MIT while GPL files sit inside — the upstream author copied someone else's code. Manifest-level tools trust the declaration; this class of conflict is only found by verifying actual files and snippets. It is not rare: in large multi-language projects, the declaration-versus-reality gap is wide enough to invalidate manifest-only audit conclusions.

Four: dual-licensed components with no recorded election. For dual-licensed components (GPL/commercial) such as MySQL client libraries or Qt, which license you distribute under requires an explicit decision and a record. Without one, audits default to the strictest interpretation — usually GPL.

Five: broken boundaries around weak copyleft. An LGPL component can be used safely — until static linking, modifying its source without releasing, or inlining extracted code into your own module punctures the "library boundary" and upgrades weak contagion into hard obligations.

Engineering the detection: three escalating layers

Layer one, manifest parsing: read declared dependencies for a fast baseline of components and declared licenses — the free CleanSource SCA Community Edition handles this. Layer two, file- and snippet-level verification: license-text recognition, copyright-header parsing and code fingerprint matching against the source itself, surfacing what exists beyond declarations and checking declaration against reality — this requires snippet-level detection. Layer three, conflict adjudication: compute conflicts automatically from a license-compatibility matrix plus your distribution mode (shipped product / SaaS / internal), output graded by severity.

The critical configuration: distribution mode as an input to the verdict. The same AGPL component is low-risk in an internal tool and critical in a SaaS — conflict talk detached from distribution mode is either false positives or false negatives.

A four-tier remediation playbook

Work upward from cheapest: Replace (a permissive-licensed functional equivalent — tools can usually recommend candidates); Isolate (process separation, dynamic linking, network interfaces — keep the contagion boundary outside your product, validated by architecture review); Comply (open-source the required portion and ship attribution files — sometimes releasing a non-core module costs far less than replacing it); License commercially (buy the commercial option of a dual-licensed component, or negotiate with the rights holder).

Record every remediation decision in the ledger: which component, what conflict, which action, who approved. That record is your evidence chain at customer due diligence and export certification.

One closing lesson

The most expensive time to start license-conflict governance is two weeks before delivery. Wire the three detection layers into CI so conflicts are intercepted the day they enter; remediation then costs a tenth of the pre-delivery scramble. Compliance is not an audit event — it is a gate that stays on.