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

The GPL's 'copyleft' nature dictates that if you distribute software containing GPLv3-licensed components, your entire application must also be licensed under the GPLv3. This is designed to ensure that derivative works remain open source. The tool itself doesn't change this requirement; it's the combination of code that matters.

The BSD 3-Clause license is a permissive license. It allows you to use, modify, and distribute the code in your proprietary software without requiring any source code disclosure or adherence to a specific license for your application. This makes it very flexible for commercial projects.

The Mozilla Public License 2.0 is a 'weak copyleft' license. It allows you to use the component in both open-source and closed-source projects without requiring you to release your entire application's source code. However, if you modify the MPL 2.0 licensed component itself, those changes *must* be released under the MPL 2.0.

The LGPL (Lesser General Public License) is designed to allow linking to libraries without forcing you to release your entire application's source code. However, it has a key restriction: if *you* modify the LGPLv3 library itself – specifically, its internal data structures – then you must make those changes available under the LGPLv3 license.

'Viral' or 'copyleft' licenses, like GPLv3 and MPL 2.0, have a key characteristic: if you distribute software that incorporates (or depends on) code under this license, your entire application must also be licensed under the same terms. This 'viral' effect ensures that derivative works remain open source.