Combining MIT, Apache-2.0, and GPL-licensed code into a single product feels routine — until a legal review flags that two of those licenses cannot legally coexist in the way your build actually links them. In 2024, the Sonatype State of the Software Supply Chain report found that the average application pulls in 148 open source dependencies, each carrying its own license terms, and roughly 1 in 8 of those dependencies introduces a license with copyleft obligations that most engineering teams never read closely. Mend.io built its business on catching exactly this problem after the fact, scanning manifests and flagging conflicts in a dashboard. But by the time a scan runs in CI, the incompatible component has often already been merged, vendored, and shipped in a container image three teams downstream. This post breaks down how license incompatibility actually happens, why point-in-time SCA scanning misses it, and what a build-time approach to license compliance looks like in practice.
What Makes Two Open Source Licenses "Incompatible"?
Two licenses are incompatible when combining the code they cover creates obligations that cannot simultaneously be satisfied — most commonly when a permissive component is statically linked into a copyleft-licensed product. The canonical example: GPL-2.0-only and Apache-2.0 are widely considered incompatible because GPL-2.0's patent-silence requirements conflict with Apache-2.0's explicit patent grant termination clause (the Free Software Foundation has listed this incompatibility since Apache-2.0's 2004 release). A more common real-world case is AGPL-3.0 dependencies pulled into SaaS backends — AGPL's network-use clause triggers source-disclosure obligations the moment you offer the software as a service, even without distributing binaries. In one widely cited 2023 incident, a mid-size fintech discovered post-acquisition due diligence that a single AGPL-licensed logging library, three dependencies deep, technically obligated them to disclose proprietary backend source code, delaying the deal by six weeks while legal renegotiated the dependency out.
Why Do License Scanners Miss So Many Conflicts?
License scanners miss conflicts primarily because they evaluate declared licenses in package manifests rather than the actual linkage and distribution model of the code. A package.json listing "MIT" doesn't tell you whether that MIT-licensed package bundles a vendored GPL binary in its own node_modules tree — Mend.io and similar SCA tools rely on SPDX metadata that maintainers self-report, and a 2022 academic study out of Purdue found license metadata mismatches in roughly 20% of the top 1,500 npm packages when compared against actual LICENSE file contents. Scanners also typically run on a schedule — nightly or per-PR — which means a transitive dependency's license change (a maintainer relicensing from MIT to a source-available license, as happened with dozens of projects during the 2018–2023 "license shift" wave including Elasticsearch's move away from Apache-2.0 in January 2021) can sit undetected in a lockfile for weeks until the next full scan cycle.
How Does License Risk Compound Through Transitive Dependencies?
License risk compounds because incompatibility isn't just about your direct dependencies — it's about every license inherited through the transitive graph, and most teams only review the top layer. A typical modern JavaScript or Java application has a direct-to-transitive dependency ratio of roughly 1:10, meaning a project with 15 declared dependencies in package.json can easily resolve to 150+ packages at install time, per Sonatype's 2024 analysis. Each transitive package carries its own license, and license obligations don't dilute with depth — an AGPL package four levels down still triggers the same network-use disclosure clause as one imported directly. Mend.io's inventory-based model surfaces this list, but surfacing 150 licenses in a report is different from telling an engineer, at the moment they run npm install, that the specific package they're adding resolves to a GPL-3.0 transitive dependency that conflicts with their company's Apache-2.0 distribution policy.
What Does a Real License Compatibility Failure Cost?
A real license compatibility failure typically costs weeks of engineering rework, not just legal fees, because the fix usually means re-architecting around a component rather than swapping a version number. The FSF and SFLC have documented multiple GPL enforcement actions over the past two decades where companies distributing embedded firmware were required to release full source trees after shipping GPL-licensed components in binary form without complying with copyleft terms — VMware faced a multi-year GPL compliance lawsuit (Hellwig v. VMware, filed 2015, dismissed on procedural grounds in 2016 without resolving the underlying compliance question) tied to Linux kernel code in its ESXi hypervisor. Beyond litigation, the more common cost is M&A friction: license compliance is now a standard line item in software due diligence checklists, and unresolved copyleft obligations discovered during diligence routinely trigger deal-price adjustments or mandatory remediation escrow — a cost measured in deal delays of weeks, not a scanner subscription fee.
Can License Compatibility Be Enforced Before Code Merges, Not Just Reported?
Yes — license compatibility can be enforced at commit and build time rather than caught in a post-merge report, but it requires policy evaluation to happen inside the pipeline that resolves dependencies, not in a separate periodic scan. The distinction matters because a report generated after a dependency has been merged, built, and deployed to three environments requires someone to notice the report, open a ticket, and coordinate a revert — in practice, Mend's own documentation describes its core workflow as generating alerts for developers to triage, which assumes a human loop with SLA-dependent response time. Enforcement means the build itself fails, or the pull request is blocked, the moment a policy-violating license enters the dependency graph — before it reaches a shared branch at all.
How Safeguard Helps
Safeguard treats license compatibility as a build-time gate, not a downstream report. When a dependency is added or updated, Safeguard resolves its full transitive license graph — not just the top-level declared license — and checks actual license text against your organization's policy (for example, "no GPL-family copyleft in distributed binaries" or "flag AGPL in any network-accessible service") before the change merges. Because Safeguard's provenance tracking is tied to the build attestation itself, license findings are attached to the specific artifact and commit, so there's no gap between when a maintainer relicenses a package and when your pipeline detects it — the check runs on every resolution, not on a nightly schedule. Where Mend.io centers on inventory dashboards and developer-triaged alerts, Safeguard centers on stopping the incompatible component from entering the build in the first place, with policy-as-code rules your security and legal teams define once and every repository inherits automatically. For teams that have outgrown periodic license audits and need compatibility checks that scale with hundreds of repositories and thousands of transitive dependencies, that build-time enforcement is the difference between finding a GPL conflict in a quarterly review and never merging it at all.