Open Source Licenses — What Engineers Actually Need to Know

You’re adding a dependency. You find the perfect library — great API, active maintainers, good docs. You run npm install or pip install and move on with your life.

Six months later, someone from legal sends you a spreadsheet asking what licenses your project depends on. You open the library’s repo, see “BSD-3-Clause” in the LICENSE file, and realize you have no idea what that means. Is that the good one? Can you use it commercially? Do you need to open-source your code now?

This is the post I wish I’d read before that moment.

Why you should care

Licenses aren’t a legal curiosity. They’re a contract. When someone publishes code under a license, they’re telling you: “Here are the rules for using my work.” Ignore the rules, and you’re in breach — same as ignoring any other contract.

Three scenarios where this hits engineers directly:

1. Picking a dependency. Your company might have a list of approved licenses. GPL on that list? Probably not. You need to know why.
2. Contributing to open source. When you submit a PR, you’re agreeing to license your contribution under the project’s license. If it’s GPL, your code is now GPL.
3. Releasing your own project. “I’ll just slap MIT on it” is fine until someone forks your project, patents a feature you invented, and sues you. (Apache 2.0 would’ve prevented that.)

The knowledge gap isn’t “I don’t care about licenses.” It’s “I don’t have a mental model for how they differ.” So let’s build one.

The spectrum: permissive to copyleft

Every open source license sits somewhere on a spectrum. On one end: “do whatever you want.” On the other: “if you use my code, you must share yours too.”

Permissive ◄────────────────────────────────────► Copyleft

MIT, BSD, Apache          MPL, LGPL           GPL, AGPL
"Do anything,             "Share changes       "Everything that
 keep my name"             to MY files"          touches this
                                                 must be open"

Permissive licenses give maximum freedom to downstream users. You can use the code in proprietary software, modify it, sell it — just keep the copyright notice. The author is saying: “I built this for the world. Take it.”

Copyleft licenses give freedom with conditions. The core idea: if you benefit from open source, you should contribute back. If you modify copyleft code and distribute it, your modifications must also be open source, under the same license.

Neither is “better.” They reflect different philosophies about how open source should work. Permissive says freedom means no restrictions. Copyleft says freedom means ensuring everyone stays free — including users of derivative works.

Most of the confusion engineers have comes from not knowing where a specific license falls on this spectrum. So let’s go through the big ones.

The big five

These are the licenses you’ll encounter in 90%+ of open source projects.

MIT — “do whatever, just keep my name”

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software... to deal in the Software without restriction...

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

That’s basically the whole license. It’s ~170 words. The deal:

• Use it for anything. Commercial, proprietary, whatever.
• Modify it however you want.
• The only obligation: include the copyright notice and license text.

MIT is the most popular open source license by a wide margin. React, jQuery, Rails, .NET (partially), VS Code — all MIT. It’s popular because it’s simple, short, and places almost no burden on users.

The catch: MIT has no patent clause. If the author holds a patent on something in the code, they could theoretically still sue you for patent infringement even though they gave you a copyright license. In practice, this almost never happens. But “almost never” wasn’t good enough for some very large companies, which is why Apache 2.0 exists.

Apache 2.0 — MIT’s lawyer-approved cousin

Apache 2.0 does everything MIT does, plus two important additions:

1. Explicit patent grant. Contributors automatically grant you a license to any patents that cover their contribution. If someone contributes code and later tries to sue you for using it, the patent grant kicks in and protects you.
2. Contribution terms. It defines what a “contribution” is and how contributions are licensed. This matters for large projects with many contributors — it removes ambiguity about who owns what.

Apache 2.0 is longer (~2,500 words vs MIT’s ~170), but the extra length is legal scaffolding, not extra restrictions. The freedoms are essentially the same.

Who uses it: Kubernetes, Android (AOSP), TensorFlow, Swift, Rust. Basically — projects backed by large companies that want permissive licensing but also want patent protection.

The trade-off: You must include the full license text AND a NOTICE file if one exists. Slightly more work than MIT when redistributing, but still very lightweight.

BSD (2-clause, 3-clause) — MIT’s older sibling

BSD licenses predate MIT. They’re functionally almost identical — permissive, minimal obligations, keep the copyright notice.

2-clause BSD (aka “Simplified BSD” or “FreeBSD license”): Basically MIT with different words. Use it for anything, keep the notice.

3-clause BSD (aka “New BSD”): Same as 2-clause, plus one extra rule — you can’t use the author’s name to endorse your product without permission. “We use code from Berkeley” is fine. “Endorsed by Berkeley” is not, unless they actually said so.

There was also a 4-clause BSD (the “original BSD”) that had an advertising clause requiring you to credit the original authors in all advertising materials. This was a nightmare for projects with many BSD dependencies — imagine crediting 50 different authors in every ad. The 4-clause version is effectively dead. Don’t use it.

In practice: BSD and MIT are interchangeable for most purposes. If you see BSD-2-Clause or BSD-3-Clause on a dependency, treat it the same as MIT. You’re fine.

GPL (v2, v3) — copyleft, the one everyone worries about

The GNU General Public License is where things get interesting.

GPL’s core idea: if you distribute software that includes GPL code, the entire combined work must also be distributed under GPL, with source code available. This is “copyleft” — the license propagates to derivative works.

The analogy I like: GPL is like a cooking show that says “you can use my recipe, modify it, sell the dish — but you must give every customer the full recipe, including your modifications.” MIT is more like “here’s my recipe, do whatever.”

GPL v2 (1991) — The original copyleft license. Linux kernel, Git, WordPress. The key rule: if you distribute a binary that links against GPL code, you must offer the source code under GPL.

GPL v3 (2007) — Same copyleft principle, but adds:

• Anti-tivoization: You can’t use hardware restrictions to prevent users from running modified versions. (Named after TiVo, which used GPL Linux but locked the hardware so you couldn’t run your own builds.)
• Patent retaliation: If you sue someone for patent infringement related to the software, your license is terminated.
• Better internationalization: More legally robust outside the US.

The nuance everyone misses: GPL triggers on distribution. If you use GPL code internally — in your company’s servers, in your internal tools — you don’t have to release your source code. You only have to share source when you distribute the combined work to others.

This is why Google can run massive amounts of GPL code on their servers without open-sourcing everything. The servers run the code; they don’t distribute it to users. (The AGPL closes this loophole — more on that below.)

What “linking” means: This is the forever-debate. Does dynamically linking a proprietary program against a GPL library make the proprietary program a “derivative work”? The Free Software Foundation says yes. Many lawyers disagree. The ambiguity is real, and it’s one reason companies avoid GPL when they can.

LGPL — GPL for libraries

The Lesser GPL exists because pure GPL was too restrictive for libraries. If a common utility library was GPL, then every program that used it would need to be GPL too — which would make the library useless for most commercial software.

LGPL says: you can link against this library from proprietary code without triggering copyleft. But if you modify the library itself, those modifications must be LGPL.

Think of it as: “Use my library freely. But if you change my library’s code, share those changes.”

Who uses it: glibc (the C standard library on Linux), Qt, FFmpeg (parts of it), many foundational libraries. It’s the license that lets proprietary applications run on Linux without being GPL themselves.

The ones that trip people up

Beyond the big five, there are a few licenses that cause outsized confusion.

AGPL — the network copyleft

The Affero GPL plugs the “server loophole” in regular GPL. Remember how GPL only triggers on distribution? AGPL triggers when you provide the software as a network service. If you run AGPL code on a server and users interact with it over the network, those users have the right to receive the source code.

This is specifically designed for SaaS. A company can’t take an AGPL project, modify it, run it as a web service, and keep the modifications proprietary. They must offer the modified source to anyone who uses the service.

Why this matters: MongoDB was originally AGPL (before switching to SSPL). If you ran a modified MongoDB as a service, you owed your users the source code. Many companies responded by… not using MongoDB. Or using it unmodified. Or switching to alternatives.

Corporate reaction: AGPL is on the “banned” list at most large companies. Google famously prohibits it. The compliance burden — having to potentially release source code for any service that uses an AGPL component — is too risky for most legal teams to accept.

MPL 2.0 — file-level copyleft

The Mozilla Public License is copyleft, but with a much smaller blast radius than GPL. The copyleft applies per file.

If you modify an MPL file, your modifications to that file must be released under MPL. But you can combine MPL files with proprietary files in the same project, and the proprietary files stay proprietary.

This is a genuinely useful middle ground. Firefox and Thunderbird use MPL. It says: “If you improve my code, share the improvements. But you don’t have to open-source your entire application just because you used one of my files.”

Creative Commons — not for code

CC licenses (CC-BY, CC-BY-SA, CC-BY-NC, CC0) are designed for creative works — articles, images, music, documentation. They are NOT designed for software and should not be used for code.

Why? CC licenses don’t address software-specific concepts like linking, compilation, or patent rights. Using CC-BY-SA on code creates ambiguity about what constitutes a “derivative work” in a software context.

Exception: CC0 (public domain dedication) is sometimes used for code, and it works fine — it’s essentially “I waive all rights, do whatever.” But for actual licensing terms, use a real software license.

Where you’ll see CC: Documentation, README files, blog posts, datasets. Stack Overflow answers are CC-BY-SA. Wikipedia is CC-BY-SA. That’s appropriate — those are creative works, not software.

The decision tree

You’re releasing a project. Which license?

Are you releasing code?
├── No (documentation, data, creative work)
│   └── Use Creative Commons (CC-BY-4.0 or CC0)
│
└── Yes
    ├── Do you want maximum adoption / minimal friction?
    │   ├── Do you care about patent protection?
    │   │   ├── No → MIT
    │   │   └── Yes → Apache 2.0
    │   └── (BSD is also fine here — it's the same tier)
    │
    ├── Do you want modifications to your code shared back?
    │   ├── Only modifications to your specific files?
    │   │   └── MPL 2.0
    │   ├── Only to the library, not to applications using it?
    │   │   └── LGPL
    │   └── All derivative works must be open?
    │       ├── Including network services?
    │       │   └── AGPL v3
    │       └── Only distributed binaries?
    │           └── GPL v3
    │
    └── Do you want to give up all rights?
        └── CC0 or Unlicense (public domain)

The default recommendation for most engineers: Apache 2.0. It’s permissive enough that people will actually use your code, and the patent grant protects you from edge cases MIT doesn’t cover. There’s a reason it’s the license most foundations (Apache, CNCF, Linux Foundation projects other than the kernel) default to.

If you want copyleft: GPL v3 for applications, LGPL for libraries, AGPL if you’re worried about the SaaS loophole.

Corporate reality

Here’s what license compliance actually looks like inside a company.

The banned list

Most companies maintain a list of license categories:

The “red” licenses aren’t red because they’re bad. They’re red because the compliance requirements are complex, the legal risk is ambiguous (what counts as a “derivative work”?), and the cost of getting it wrong is high. A company would rather use a permissive alternative than spend legal hours analyzing GPL linkage boundaries.

What “license compliance” actually means

In practice, license compliance is about three things:

1. Attribution. Almost every license requires you to include the copyright notice and license text somewhere. For MIT/BSD/Apache, this usually means a NOTICE file or a third-party licenses section in your docs.

2. Source distribution. For copyleft licenses, you need to offer source code to anyone who receives the binary. This is why companies avoid GPL — not because they don’t want to share code, but because the compliance process (tracking which code needs to be shared, with whom, in what form) is operationally expensive.

3. Dependency tracking. You need to know what you’re using. This is where SBOMs come in.

SBOM — Software Bill of Materials

An SBOM is a list of every component in your software, including its license. Think of it as the ingredients label on food packaging, but for code.

{
  "name": "react",
  "version": "18.2.0",
  "license": "MIT",
  "supplier": "Meta Platforms, Inc."
}

SBOMs are increasingly mandatory. The US executive order on cybersecurity (2021) requires SBOMs for software sold to the federal government. The EU Cyber Resilience Act is heading in the same direction. Tools like syft, cyclonedx, and GitHub’s dependency graph can generate them automatically.

As an engineer, the practical takeaway: if your company asks for an SBOM, this is what they mean. It’s not scary — it’s a dependency list with license metadata. Your package manager already knows most of this.

Quick reference table

*LGPL patent grant exists in v3 through its relationship with GPL v3, but v2.1 is less explicit about patents.

Key: “Commercial use” means you can use the software in proprietary, for-profit products. All open source licenses allow this — the question is always about the conditions, not whether commercial use is permitted.

The things nobody tells you

A few gotchas that aren’t in any license FAQ:

“No license” is not “public domain.” If a GitHub repo has no LICENSE file, the code is under default copyright. You have NO rights to use, modify, or distribute it. It’s not “free to use because it’s on GitHub.” It’s “the author hasn’t told you what you can do with it.” This is worse than GPL — at least GPL tells you the rules.

Dual licensing is a business model. Some projects (Qt, MySQL, MongoDB before SSPL) offer the code under both GPL and a commercial license. The message: “Use it for free under copyleft rules, or pay us for a permissive license.” This is legal and common.

License compatibility matters. You can’t combine Apache 2.0 code with GPL v2 code — they’re incompatible (Apache 2.0 has additional restrictions that GPL v2 doesn’t permit). But Apache 2.0 IS compatible with GPL v3. This stuff gets arcane fast, and it’s genuinely the domain of lawyers. The practical rule: if you’re combining code under different copyleft licenses, ask someone who knows.

CLA vs. DCO. When contributing to open source, you might encounter a Contributor License Agreement (CLA) or a Developer Certificate of Origin (DCO). A CLA typically grants the project extra rights to your contribution — sometimes including the right to re-license it. A DCO is lighter — it just says “I have the right to submit this and I agree to the project’s license.” Know what you’re signing.

TL;DR

• Permissive (MIT, Apache, BSD): use freely, keep the notice, done.
• Copyleft (GPL, AGPL, LGPL): use freely, but share your changes under the same terms.
• For your own projects: Apache 2.0 unless you have a specific reason not to.
• For dependencies: check your company’s approved list. Green = go. Yellow = ask. Red = find an alternative.
• No license file = no permission. Not the same as public domain.
• Licenses aren’t scary. They’re contracts, and most of them are short enough to actually read. MIT is 170 words. You’ve read longer Slack messages.