Open Source and Contributor License Agreements in a Nutshell

So, you’re thinking about open-source licensing, huh?

Maybe you’re considering tossing your latest masterpiece onto GitHub, or maybe you’re just trying to figure out how to legally “borrow” someone else’s code without ending up in a courtroom.

Either way, welcome to the wild world of Open Source and Contributor License Agreements….

\History of Open Source Licenses

Once upon a time, in the early days of computing, software was basically shared freely among nerds in lab coats.

Then, capitalism happened.
(MONEY!!!!)

Companies like Microsoft decided, “Hey, maybe we should charge for this stuff,” and thus, proprietary software took over the world.

But not everyone was on board with this.

Richard Stallman, the godfather of open source (and a man with very strong opinions), launched the GNU Project in 1983, followed by the Free Software Foundation (FSF).

This led to the birth of the GNU General Public License (GPL), which basically said: “If you use this software, you gotta share any changes you make. No hoarding!”

As time went on, some people thought the GPL was a bit too strict, so they created more relaxed licenses.

Thus, we got the MIT License, Apache License, BSD License, and a whole bunch of others that basically said, “Do whatever you want, just don’t sue us.”

And just like that, open-source software became a thing, with licenses ranging from “share everything or else” to “eh, whatever, have fun.”

When it comes to open-source licensing, there are two main schools of thought:

Copyleft Licenses (a.k.a. “You must share!”)
- Examples: GPL, AGPL, LGPL
- If you use this code in your project, you must also open-source your project.
- Great for idealists who want to keep software free forever.
- Terrible if you’re a company trying to make money without sharing your secret sauce.
Permissive Licenses (a.k.a. “Do whatever, I don’t care.”)
- Examples: MIT, BSD, Apache
- You can use the code in your project, and you don’t have to open-source your own changes.
- Great if you want to build a closed-source, money-making machine.
- This is why companies love MIT and Apache licenses.

So, if you’re building an open-source library and want to ensure it stays open forever, you go GPL.

If you don’t care what happens to your code and just want people to use it, MIT or Apache is the way to go.

Contributor License Agreements (CLAs): The Fine Print Before You Contribute

Alright, now let’s talk about Contributor License Agreements (CLAs).

Ever tried to contribute to a big project, and suddenly they ask you to sign some weird legal document?

That’s a CLA, and it’s basically a contract saying:

You wrote the code (or have the right to contribute it).
You’re giving the project permission to use it.
The project maintainers won’t get sued because of your code.

Companies and big projects like Google, Microsoft, and Apache require CLAs because they don’t want some random person showing up years later saying, “Hey, I wrote that function! Pay me!” It’s a legal safety net.

But not everyone loves CLAs.

Some see them as overly corporate and a way for companies to “own” contributions. Others just find them annoying, like those Terms of Service agreements nobody reads before clicking “I Agree.”

Open Source vs. Closed Source: Can You Keep Your Code Secret?

This is where licenses and CLAs get interesting. If you’re using GPL-licensed code, guess what? You HAVE to make your modifications public if you distribute your software.

That’s why companies tend to stay far, far away from GPL unless they’re fully committed to open source.

But if you’re using MIT or Apache licensed code, you can take that code, build a billion-dollar business on top of it, and never share a single line of your changes. (Looking at you, big tech companies!)

So, before you slap an open-source license on your project, think about what you want:

Want to force people to share? Use GPL.
Want people to just credit you but do whatever? Use MIT.
Want something in-between? Apache lets people use your code, but they have to give credit and can’t sue you.

Static vs Dynamic Linking: Why It Matters for Open Source Licenses

What is Linking, and Why Does It Matter?

Before we get into the legal mess, let’s break it down. When your software needs to use code from another library, you have two ways to include it:

1. Static Linking (a.k.a. The “One Big Happy Family” Approach)

The external library is baked into your compiled executable.
Your final program contains all the code from the external library.
Example: You compile your C++ program with a static .lib file, and everything becomes one giant binary.

2. Dynamic Linking (a.k.a. The “Let’s Keep It Separate” Approach)

The external library stays separate from your program.
Your program calls the library at runtime instead of embedding it.
Example: You distribute a .dll (Windows), .so (Linux), or .dylib (macOS) file that your program loads when it runs.

So far, so good, right? Now here’s where things get spicy: Certain open-source licenses treat static and dynamic linking differently.

How Linking Affects Open Source Licenses

As mentioned above, open-source licenses come in two main flavors:

Copyleft Licenses (like GPL) – Share everything!
Permissive Licenses (like MIT, BSD, Apache) – Do whatever you want, just don’t sue us.

The GPL (General Public License) is very aggressive about keeping code open. If you statically link your program to a GPL-licensed library, congratulations! Your entire program is now legally considered a “derivative work” of that GPL code.

Translation: You must open-source your entire program under the GPL. No exceptions. If you were planning on keeping your code closed-source, you’re out of luck.

GPL and Dynamic Linking: Maybe You Can Get Away With It

Now here’s where things get weird. If you dynamically link to a GPL library, things get murky. Some argue that since the library isn’t physically inside your program, it’s not a derivative work.

But the FSF (Free Software Foundation) (aka the GPL police) says otherwise. According to them, even dynamic linking could make your software a derivative work, meaning you still need to open-source it.

The short answer? It’s legally unclear, but if you’re linking to GPL code (statically or dynamically), you’re probably in for a world of legal pain if you try to keep your software closed-source.

LGPL: The Loophole License

Luckily, there’s a lighter version of the GPL: The Lesser GPL (LGPL).

If you statically link to an LGPL library, you must provide object files so others can relink your program.
If you dynamically link to an LGPL library, you’re in the clear! You can keep your software closed-source while still using the library.

Many companies prefer LGPL over GPL because it allows them to use open-source libraries without being forced to open-source their own software.

MIT, BSD, Apache: Do Whatever You Want

On the other hand, MIT, BSD, and Apache licensed libraries don’t care how you link to them. Static or dynamic, it doesn’t matter—you can still keep your software closed-source. That’s why companies love permissive licenses.

So What Does This Mean for You?

If You’re Building Open-Source Software:

If you want to force people to open-source their programs when they use your code, use GPL.
If you want to let companies use your code but still require modifications to be open, use LGPL.
If you don’t care and just want people to use your code freely, use MIT, BSD, or Apache.

If You’re Using Open-Source Code:

If the library is GPL and you statically link to it, you must open-source your software.
If the library is GPL and you dynamically link, it’s legally unclear, but you’re still at risk.
If the library is LGPL, dynamically linking is safe, but static linking requires some extra steps.
If the library is MIT, BSD, or Apache, you’re totally fine—do whatever you want.