Open Source License Compliance: How GPL and AGPL Can Destroy Your Intellectual Property

You added a logging library. You just legally obligated yourself to release your entire product as open source. This sounds extreme. It is not. It has happened to some of the largest companies in the world — and in 2024, one of them paid over €900,000 to make it go away.

The Open Source License Landscape

There are over 200 open source licenses approved by the Open Source Initiative (OSI), but most software teams only need to understand a handful of categories. The most important distinction is between permissive licenses and copyleft licenses.

Permissive Licenses: Low Risk

Permissive licenses — MIT, Apache 2.0, BSD, ISC — allow you to use, modify, and distribute open source code in proprietary software with minimal obligations. You generally just need to include the original copyright notice and, for Apache 2.0, a copy of the license. These licenses are the backbone of the open source ecosystem and carry very low legal risk for commercial software.

Copyleft Licenses: High Risk

Copyleft licenses — GPL, LGPL, AGPL, EUPL, MPL — impose a fundamental condition: if you distribute software that incorporates copyleft code, you may be required to release your modifications (and potentially your entire product) under the same copyleft terms. This is often called the "viral" or "infectious" effect.

// The Viral Effect Explained

One AGPL library buried three levels deep in your dependency tree can legally require you to release your entire application's source code under AGPL terms. Google bans AGPL internally for precisely this reason. MongoDB, Elastic, and others have weaponized this to prevent cloud vendors from offering their software as a service without contributing back.

GPL: The Original Copyleft License

The GNU General Public License (GPL), now in version 3, requires that any software that incorporates GPL-licensed code and is distributed to users must also be distributed under the GPL, with its complete corresponding source code. This applies to the entire combined work — not just the parts you modified.

The critical trigger word is "distribute." If you are using GPL software only internally — within your company, not shipping it to external users — the GPL's distribution requirements typically do not apply. The moment you distribute the software to a customer, embed it in a product, or provide it as part of a hosted service (under certain interpretations), the obligations kick in.

AGPL: The Most Dangerous License for SaaS

The GNU Affero General Public License (AGPL v3) closes the "SaaS loophole" of the GPL. Under AGPL, if you run AGPL-licensed software on a server and users interact with it over a network — for example, as a web application — you must provide the complete source code of the modified program to those users. The distribution requirement is triggered by network use, not just physical distribution.

This makes AGPL particularly dangerous for SaaS companies. Many popular databases and frameworks are AGPL-licensed:

Real-World License Violations: The Case of Orange S.A.

In February 2024, a French court ordered Orange S.A., one of Europe's largest telecommunications companies, to pay over €900,000 in damages for violating the terms of the GNU GPL. The plaintiff was Entr'ouvert, a small French company that maintained the Lasso library — a SAML/XML security library that Orange had incorporated into its products without complying with GPL terms.

Orange had been using Lasso since 2006. The legal battle lasted a decade. The financial impact included damages, legal costs, and significant reputational harm. The violation was not intentional sabotage — it was a software supply chain visibility problem. Orange's engineers used a library without fully understanding its license obligations, and no automated system flagged the issue.

This case is not unique. The Software Freedom Conservancy and the Free Software Foundation actively pursue GPL violations. The GPL Cooperation Commitment provides some protection for incidental violations, but deliberate or negligent use of GPL-licensed code in commercial products remains a significant legal liability.

Transitive Dependencies: Where 30% of Violations Hide

The most dangerous license violations do not come from libraries you consciously chose. They come from the dependencies of your dependencies — the transitive dependency graph.

When you add a library to your project, that library has its own dependencies. Those dependencies have their own. A typical Node.js project with 20 direct dependencies might have 800+ transitive packages. Any one of those 800 packages could be GPL or AGPL licensed.

Manual review of 800 packages is not feasible. Automated license scanning is the only practical solution.

# Transitive dependency risk example
your-app
  └─ cool-library (MIT)
     └─ data-processor (Apache 2.0)
         └─ fast-parser (AGPL v3) ← YOU HAVE A PROBLEM

License Compatibility: The Matrix That Matters

Not all open source licenses are compatible with each other. Combining code under incompatible licenses creates a legal conflict — and the stricter copyleft license typically wins. Key incompatibilities to know:

How an Open Source License Scanner Works

A license scanner analyzes your entire dependency graph — direct and transitive — identifies the license for each component, and flags any combinations that violate your license policy. Advanced tools also:

// Recommended Tool

Detect License Violations Before They Become Lawsuits — Use Fossity

Fossity includes a comprehensive open source license scanner that analyzes your full dependency tree — including transitive dependencies — and flags incompatible, high-risk, or policy-violating licenses in real time. Fossity's policy-as-code engine lets you define exactly which licenses are allowed, restricted, or banned for your organization, and automatically fails CI/CD builds when a violation is introduced. Stop discovering license violations after you have already shipped.

Scan for License Violations →

Best Practices for License Compliance in 2026

  1. Establish a license policy — Define which licenses are approved, restricted, and banned for your organization. Get legal counsel involved. Document it.
  2. Scan at every pull request — License compliance should be checked before new dependencies enter the codebase, not after they are deployed.
  3. Audit transitive dependencies — Your direct dependencies are only the first level. Full tree analysis is essential.
  4. Track license changes — Libraries sometimes change their license in new versions. Automated monitoring catches this automatically.
  5. Maintain attribution records — Even permissive licenses require copyright notices. Keep an automated attribution file for all open source components used.
  6. Consider commercial licenses for high-risk libraries — Many copyleft-licensed libraries (MongoDB, Elastic, iText) offer commercial licenses that eliminate the copyleft obligation. For critical infrastructure, this is often worth the cost.

Summary

Open source license compliance is not a bureaucratic formality. The Orange S.A. case, and dozens of similar cases before it, demonstrate that license violations carry real financial and reputational consequences. The copyleft viral effect means that a single poorly-chosen transitive dependency can legally contaminate your entire codebase.

The solution is automated license scanning integrated into your development workflow — not annual manual audits. In 2026, any software team that does not have automated license compliance tooling is taking on unnecessary legal risk.

// Author: Esteban C.