License Compatibility Language

GPL v2 and Apache 2.0 are incompatible because Apache 2.0's patent retaliation clause conflicts with GPL v2's terms.

Why they're incompatible:
• Apache 2.0 §3 terminates patent licenses if a recipient files a patent lawsuit related to the software
• GPL v2 §6 requires that recipients have the same rights as everyone else — no additional restrictions
• The patent termination clause is an "additional restriction" that GPL v2 forbids
• Therefore, you cannot legally combine code under both licenses in one distributed binary

The good news — GPL v3 fixed this:
• GPL v3 was specifically designed to be compatible with Apache 2.0
• If the GPL library is "GPL v2 or later", you can use it under GPL v3 and combine with Apache 2.0
• If it's "GPL v2 only", the incompatibility remains

Practical check: look for GPL-2.0-or-later vs GPL-2.0-only in SPDX headers.

Key vocabulary:
• License compatibility — the ability to combine works under different licenses in a single distributed product
• Patent retaliation clause — a provision that terminates patent rights if a licensee sues the licensor for patent infringement
• GPL v2 only — code that can only be used under GPL version 2, not later versions
• GPL-2.0-or-later — code that permits use under GPL v2 or any later GPL version (including v3)

MIT and Apache 2.0 are both permissive licenses — they're compatible with each other and with proprietary code. The only requirement is attribution.

What "attribution" means in practice:
• Keep the original copyright notices in source files or collect them in a NOTICES / LICENSE / THIRD_PARTY_LICENSES file
• For Apache 2.0: also include any NOTICE file from the original project (§4(d))
• Show these notices in your app's "Open Source Licenses" screen, documentation, or package

What you are NOT required to do:
• Open-source your own code
• Use any particular license for your own code
• Notify the authors
• Contribute improvements back

The "dominant license" misconception:
• Permissive licenses don't "infect" your code or force a particular license on the result
• Copyleft licenses (GPL) do — but MIT and Apache 2.0 do not

Key vocabulary:
• Attribution requirement — the obligation to preserve copyright notices and license texts
• NOTICE file — an Apache 2.0 requirement: a file containing attribution notices that must be included in distributions
• License stacking — combining multiple licenses in a single product or codebase
• Permissive license compatibility — permissive licenses are generally mutually compatible because they impose minimal requirements

LGPL's "weak copyleft" is specifically designed to allow use in proprietary applications — it only requires that modifications to the LGPL library itself be shared.

How LGPL works for applications:
• LGPL §4: You may combine an LGPL library with proprietary application code and distribute the result
• Key condition: users must be able to relink the application with a modified version of the LGPL library
• "Relinkability" means: either use dynamic linking, or provide object files so the user can relink statically

What you must still share:
• Any modifications you make to the LGPL library itself → must be released under LGPL
• The LGPL library's source code (if you modified it) or a pointer to where it can be obtained

What you don't need to share:
• Your application's source code
• Your business logic, algorithms, UI
• Configurations or assets

Common use cases: Qt (LGPL option), GCC runtime libraries, GNU C Library — all designed for use in proprietary applications via LGPL.

Key vocabulary:
• Weak copyleft — copyleft that applies only to the licensed component, not works that merely use it
• Dynamic linking — loading a library at runtime rather than compiling it into the executable
• Relinkability requirement — the LGPL rule that end users must be able to substitute a modified version of the library
• LGPL §4 — the provision allowing proprietary applications to use LGPL libraries

AGPL v3 specifically targets SaaS providers — network interaction triggers the same source disclosure obligation as binary distribution in GPL.

AGPL §13 "Remote Network Interaction":
• "If you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network… an opportunity to receive the Corresponding Source"
• "Corresponding Source" can include the code that works together with the AGPL module
• The scope is debated: some lawyers argue it only covers the AGPL module; others argue it covers the entire application

Practical implications:
• Risk: if your platform is built around an AGPL library, the safest interpretation is that your entire platform may need to be AGPL
• This is why MongoDB (pre-SSPL), Elasticsearch (pre-Elastic License), and Grafana have all moved from AGPL to more restrictive licenses — to prevent cloud providers from offering their software without contributing back

Options for SaaS companies:
1. Comply: release all source under AGPL
2. Replace: use a permissively licensed alternative
3. Commercial license: negotiate a proprietary license with the author
4. Isolate: run the AGPL component as a fully separate service and communicate via API (legal grey area)

Key vocabulary:
• AGPL v3 §13 — the network use provision that closes the SaaS loophole
• Remote network interaction — users accessing software functionality via a network, which triggers AGPL's source disclosure requirement
• Corresponding Source — all source code needed to generate, install, and run the covered work
• SaaS loophole — the ability to run GPL software as a hosted service without triggering copyleft (AGPL closes this)

Copyleft propagation is the mechanism by which GPL's source-disclosure requirement spreads to works that incorporate GPL code — it applies to distribution, not to mere internal use or development.

When copyleft propagates (triggers):
• You distribute a compiled binary that incorporates GPL code
• You distribute source code that includes GPL code
• (AGPL only) You let users interact with GPL code over a network

When copyleft does NOT propagate:
• Internal use only — using GPL code in-house without distributing is fine under GPL
• Running GPL code as a CLI tool (you're using it, not incorporating it)
• Calling a GPL program as a separate process via stdin/stdout or sockets (grey area for some, clear exemption under GPL §2)

The "combined work" question:
• Tight coupling: linking GPL code into your executable → copyleft typically propagates to the executable
• Loose coupling: calling GPL code as a separate process via IPC → copyleft typically does not propagate
• This is why license compatibility analysis focuses on how components are combined, not just what they are

Key vocabulary:
• Copyleft propagation — the spread of copyleft obligations from GPL-licensed code to the combined distributed work
• Distribution trigger — the act of providing software to others outside your organization, which activates copyleft obligations
• Combined work — a work created by combining or linking two or more separately-licensed components
• Tight coupling — integrating components so closely (e.g., static linking, inlining) that they form one executable work
• IPC (Inter-Process Communication) — communication between separate processes (pipes, sockets), which may insulate from copyleft propagation