Copyleft licenses require that derivative works of the licensed code be distributed under the same license terms, but they come in two meaningfully different strengths: strong copyleft (GPL, AGPL) extends that requirement to any work that links against or incorporates the code, while weak copyleft (LGPL, MPL) confines the requirement to the licensed component itself, letting you link it into a proprietary application without that application inheriting the copyleft terms. Confusing the two is one of the more common and consequential open source licensing mistakes engineering teams make — and it's exactly what a copy left license policy needs to get right before it ever reaches a dependency review.
What makes a copyleft license "strong"?
Strong copyleft licenses, most notably the GPL family, define "derivative work" broadly enough that statically or dynamically linking your code against a GPL-licensed library generally makes your combined program a derivative work subject to the same license. In practice, this means if you link a GPL-licensed library into a proprietary application and distribute that application, you're expected to release your application's source code under the GPL too — the copyleft "infects" the combined work, not just the original library. This is why companies with strict proprietary-software models treat any GPL dependency, even a small utility library, as something that needs explicit legal review before it goes anywhere near a shipped product.
What makes a copyleft license "weak," and why does linking matter so much?
Weak copyleft licenses like the LGPL draw a line specifically at linking: modifications to the LGPL-licensed library itself must be shared under the LGPL, but an application that merely links against an unmodified LGPL library — especially via dynamic linking — is not considered a derivative work of the library and can remain fully proprietary. This distinction exists specifically to let libraries (rather than full applications) use copyleft to protect the library's own code while still being usable inside commercial, closed-source products, which is exactly the use case the LGPL was designed for — the GNU C Library (glibc) is LGPL precisely so proprietary software can link against it without becoming GPL-licensed itself.
Where does the Mozilla Public License fit on this spectrum?
The MPL is also weak copyleft, but it draws its boundary at the file level rather than the link level: modifications to MPL-licensed files must be shared under the MPL, but you can combine MPL files with proprietary files in the same project (even the same compiled binary) as long as the MPL-covered files themselves remain under the MPL and their modifications are disclosed. This file-level boundary is more permissive for combining code within a single codebase than the LGPL's linking-based boundary, which is part of why the MPL is popular for components meant to sit inside larger, otherwise-proprietary products — Mozilla's own Firefox codebase and many corporate open-source contributions use it for exactly this reason.
Why does the strong/weak distinction matter more than the copyleft/permissive distinction for many companies?
Because a company that has already decided it's comfortable using some copyleft-licensed code still needs a very different review process for GPL versus LGPL dependencies — the GPL dependency requires checking distribution and linking patterns carefully because the obligation can extend to your own code, while the LGPL dependency's obligation is largely confined to the library itself. Treating all copyleft licenses as equally restrictive leads to two bad outcomes: either blanket-banning LGPL dependencies that would have been perfectly safe to use, slowing engineering down for no real legal benefit, or under-scrutinizing GPL dependencies because "copyleft" sounds like one uniform risk category when it isn't.
Does the AGPL fit into this strong/weak framework?
The AGPL is strong copyleft — everything the GPL requires, plus an additional network-use trigger that extends the obligation to software offered as a hosted service, not just software that's directly distributed. It's worth keeping separate in any license policy specifically because its trigger condition (network interaction, not distribution) differs from the GPL's, which means a company that's fine with GPL dependencies used only internally can still have real AGPL exposure the moment that same code is exposed to users over a network.
How should engineering teams actually operationalize this distinction?
License policy needs to encode strong-vs-weak as a real decision variable, not just flag "copyleft: yes/no" — an SCA tool or license scanner that lumps LGPL in with GPL under a single "copyleft" bucket will either over-block safe dependencies or, worse, under-communicate the real risk difference to whoever is reviewing the flag. Most policies also need a broader category for OSS licenses generally — permissive (MIT, Apache 2.0), weak copyleft, and strong copyleft each need a different review path, not one flat "open source: check with legal" rule regardless of type of license. The dependency graph is also where most of the actual risk hides: direct dependencies get reviewed, but a GPL-licensed transitive dependency three levels deep in a Java or npm dependency tree is exactly the kind of thing that slips past manual review and only gets caught by tooling that walks the full graph, the same category of coverage gap SCA is meant to close.
How Safeguard Helps
Safeguard's SCA engine classifies license findings by copyleft strength, not just presence, so legal and engineering teams can apply different review thresholds to GPL/AGPL-class findings versus LGPL/MPL-class findings across the full transitive dependency graph, catching the license risk that actually matters instead of flooding review queues with equally-weighted alerts.
FAQ
Is the LGPL considered copyleft?
Yes, but it's weak copyleft — modifications to the LGPL-licensed component itself must be shared, but an application that merely links against it can remain proprietary.
Can I use a GPL library in a closed-source commercial product?
Generally not without releasing your combined application's source under the GPL too, if you distribute the product — strong copyleft licenses extend the obligation to the combined work in most linking scenarios.
Is the Mozilla Public License the same as the LGPL?
Both are weak copyleft, but they draw the line differently — the MPL applies at the file level, while the LGPL's boundary is based on linking, which makes the MPL somewhat more flexible for mixing licensed and proprietary code in one codebase.
Why do some companies ban all copyleft licenses instead of distinguishing strong from weak?
It's usually a simplification to reduce legal review overhead, but it often over-blocks safe weak-copyleft dependencies unnecessarily — a more granular policy that distinguishes strong from weak copyleft gives engineering more flexibility without increasing real legal risk.