Copyleft Licenses: "Share and Share Alike

GPL, AGPL, LGPL

These are "viral" or "reciprocal" licenses. The philosophy behind them is different from permissive licenses. They are not designed to maximize developer freedom — they are designed to protect the freedom of the code itself. The idea: if you benefit from free software, you must give back to the commons.

The core rule: "You can use this. But if you modify it and distribute your software, your software MUST also be released under this same license." This "viral" property is why they are treated with extreme caution in commercial software development.

1. GPL (General Public License) v2/v3 — "Strong Copyleft":
If you incorporate GPL-licensed code into your proprietary application and distribute that application (ship it as a product, sell it, give it to customers), your entire application must be released under the GPL. You must provide the source code to anyone who receives the binary.

The trigger is distribution: giving someone a copy of the compiled software. This is why many companies allow GPL tools for internal use (no distribution) but ban them from any shipped product.

• Risk Level: High for distributed software.
• Enterprise Usage: Generally banned for proprietary software that ships to customers. Permitted for internal tooling in many companies.
• Examples: Linux kernel (GPL v2), Git (GPL v2), GCC (GPL v3).

2. AGPL (Affero GPL) — "The Cloud Loophole Closer":
Standard GPL has a well-known escape hatch for SaaS companies. The viral clause is triggered by distribution — giving someone a copy of the software. If you run GPL code on your servers and users interact with it over a network, you never "distribute" the binary. You keep it on your machines. So technically, you don't have to share your source code.

AGPL closes this loophole explicitly. It adds: "If users interact with the software over a network, that counts as distribution." Running AGPL code in your backend and exposing it to users — even via an API — triggers the share-alike requirement.

• Risk Level: Critical. Using AGPL code in your backend service could legally require you to open-source your entire backend.
• Enterprise Usage: Almost universally banned in commercial products. Many companies (Google, for example) have explicit policies prohibiting AGPL code in any product.
• Examples: MongoDB (original license before SSPL switch), Grafana (some components), Nextcloud.

3. LGPL (Lesser GPL) — "The Middle Ground":
LGPL was created specifically to allow proprietary software to use a library without the viral clause activating, as long as the library remains a separate, dynamically-linked component. The idea: you can call into the LGPL library from your proprietary code, but you cannot fold the library's source into your own codebase.

• The key distinction: Dynamic linking (your app calls a .so or .dll at runtime) is generally safe under LGPL. Static linking (the library's code is compiled directly into your binary) may trigger the copyleft clause.
• Risk Level: Low-to-Medium, depending on how you link.
• Examples: GNU C Library (glibc), Qt (LGPL option), FFmpeg (LGPL option).