Alright, let’s talk about the GPL. You can’t swing a dead cat in the open-source world without hitting it, and for good reason. It’s the legal engine that made Linux possible and keeps it from being co-opted and locked away. It’s not just a license; it’s a philosophical statement with very sharp, legally-binding teeth. Forget “open source” for a second; the GPL is about Free Software, and the difference is ideological. Open source is a development methodology; Free Software is a social movement. The GPL is its manifesto.

The genius of the GPL (GNU General Public License) is that it uses copyright law against itself. Hence, “copyleft.” Standard copyright says “all rights reserved”—you can’t use this unless I say so. The GPL uses that power to say, “Okay, you can use this, but you must also grant these same rights to anyone you distribute it to.” It’s a legal contagion for freedom. You get the four essential freedoms: to run the program for any purpose, to study and change it, to redistribute copies, and to distribute your changes. The kicker is that if you distribute a program based on GPL code, you must distribute your modified source code under the same GPL terms. This is called the “viral” or “reciprocal” clause, and it’s what makes corporate lawyers break out in a cold sweat. It prevents someone from taking a billion dollars of community effort, adding one proprietary feature, and selling the whole thing as a closed product. They’d have to open-source their entire derivative work, which defeats the purpose of hoarding it.

The Practical Requirements: What You Actually Have To Do

So, you’ve used some GPLv2 code in your project. What now? If you distribute your software (i.e., give it to anyone who isn’t you or your immediate coworker), you have obligations. Let’s be direct.

  1. Provide the Source Code. You must either ship the source with the binary or provide a written offer to give the source to anyone who asks for up to three years. In 2024, just host it. A public GitHub repo is the easiest way to fulfill this. The source must be the “preferred form for modification,” meaning not just some obfuscated, minified mess.
  2. Provide the License. You must include a copy of the GPL license itself. Don’t modify it.
  3. State Your Changes. You must clearly document any changes you made to the original source. A git history is perfect for this; a CHANGELOG file will do in a pinch.

Here’s the kind of thing you must avoid. Imagine you have a proprietary application, my-secret-app, and you statically link it to a GPL library, libGPL-example.a.

// my-secret-app.c (Your proprietary code)
#include "libGPL-example.h" // Uh oh...

int main() {
    super_secret_business_logic();
    some_function_from_libGPL(); // This is a problem!
    return 0;
}

You then compile it with:

gcc -o my-secret-app my-secret-app.c libGPL-example.a

Boom. You’ve just created a “derivative work” based on the interpretation of most courts and the Free Software Foundation. By distributing my-secret-app, the GPL requires you to release the entire source code of my-secret-app.c under the GPL. This is the classic pitfall.

The Quirks and Edge Cases: Where It Gets Fuzzy

This is where the brilliant, and sometimes infuriating, nuance comes in.

  • Static vs. Dynamic Linking: The FSF’s view is that both static and dynamic linking create a derivative work, thus invoking the GPL’s terms. However, the legal world is less settled on dynamic linking. Some argue that a program that only dynamically links to a library on the user’s existing system is merely “using” it, not creating a derivative work. This is a gray area legally, but to be safe, assume dynamic linking to a GPL library still requires your code to be GPL-compatible.
  • The System Library Exception: This is a critical carve-out. The GPL explicitly allows linking to “System Libraries,” which are things that are part of the major operating system distribution (like the C library, glibc). You can write a fully proprietary app that links with glibc because it falls under this exception. This is why proprietary Linux apps exist.
  • AGPL: The Web Loophole Plugger: The vanilla GPL only triggers on distribution. So what did clever SaaS companies do? They took GPL software, modified it, and ran it on their servers without distributing the modified version to their users. Perfectly legal under GPLv2, but against its spirit. The AGPL (Affero GPL) was created to close this loophole. It says that if you run the software on a network server, you must make the source available to all users of that service. It’s the GPL, but for the age of the cloud.

Best Practices: Don’t Be a Schmuck

  1. Audit Your Dependencies: Before you write a line of code, know what licenses you’re pulling in. Use tools like licensecheck on Debian/Ubuntu or various scanning CI/CD tools.
    # Example: quickly scan a directory for common licenses
licensecheck -r --copyright ./src/
  2. Understand the Incompatibility: You can’t just mix and match code with different “copyleft” licenses. GPLv2-only code is incompatible with GPLv3 code. You can’t combine a GPL project with an Apache 2.0 project that has specific patent clauses the GPL doesn’t like. It’s a mess. If in doubt, stick with one license for your entire project or use permissively licensed code (MIT, BSD) that can be absorbed into a GPL project.
  3. When in Doubt, Ask: The Free Software Foundation has a page for license questions. If you’re building a business on this, get a real lawyer who specializes in open source. It’s cheaper than a lawsuit.

The GPL isn’t a gentle suggestion; it’s a carefully constructed legal device designed to enforce software freedom. It’s the reason Linux thrives while corporate entities can’t simply absorb it and kill it. It demands a quid pro quo: you get to stand on the shoulders of giants, but you can’t then build a wall around your spot on the giant. Love it or hate it, you have to respect its effectiveness.