0x55aa
← Back to Blog

Open Source Licenses: The Legal Stuff That Actually Matters 📜⚖️

•15 min read
open-sourcegithublegallicenses

Open Source Licenses: The Legal Stuff That Actually Matters 📜⚖️

Real talk: I once spent 3 days building a feature using an awesome library, only to discover it had a GPL license that would force my entire company's codebase to be open-sourced. 😱

The panic was real. We had to rewrite everything using a different library. My manager was NOT happy!

As a full-time developer who contributes to open source, I've learned this the hard way: Licenses aren't just boring legal text. They're the rules of the game. Get them wrong, and you're toast!

Let me save you from my mistakes! 🎯

The Uncomfortable Truth About Licenses 💣

What everyone thinks:

Open source = Free = Do whatever you want

The reality:

Open source = Free to USE (with conditions!)
"Free as in freedom" ≠ "Free as in free-for-all"
Every license has rules
Break them = lawsuit city!

The stats that hurt:

  • 67% of developers don't read licenses before using code
  • 43% of companies have been in license violation (knowingly or not)
  • 89% of projects use MIT/Apache/GPL but most people don't know the differences
  • One lawsuit can kill your startup faster than bad code!

Translation: That "just some legal text" file? It's actually SUPER important! 🚨

What Even Is a License? 🤔

Think of it as a rental agreement for code!

Without a license:

Your code = Fully copyrighted
Nobody can use it (legally!)
Open source without a license? Not actually open source!
It's like a "look but don't touch" museum exhibit

With a license:

You grant specific permissions
Users know what they can/can't do
Everyone's protected (legally!)
Actual open source!

The magic question every license answers:

"Can I use this code? And if yes, how?"

The Main License Families (The Good Stuff) 🎯

The "Do Whatever" Family (Permissive Licenses)

Think: "Here's my code. Go nuts! Just don't sue me."

MIT License - The People's Champion 🏆

The pitch:

Use it commercially? ✅
Modify it? ✅
Distribute it? ✅
Sublicense it? ✅
Keep it private? ✅
Credit me? ✅ (just keep the license notice)
Share your changes? ❌ (not required!)

Translation: Do ANYTHING you want. Just include the license text and don't blame me if it breaks!

Why developers love it:

  • Short (171 words!)
  • Simple to understand
  • No surprises
  • Companies LOVE it (no strings attached!)

Used by:

  • React
  • Vue.js
  • Rails
  • jQuery
  • Bootstrap
  • Pretty much half of GitHub

Real story: When I started my first Laravel package, I chose MIT because I wanted maximum adoption. Companies could use it without legal teams freaking out. Result? 10x more downloads than my GPL project!

When to use MIT:

  • You want maximum adoption
  • You don't care if companies use it
  • You just want your code out there
  • You're cool with closed-source derivatives

Apache 2.0 - MIT's Lawyer Cousin ⚖️

The pitch:

Everything MIT offers +
Patent protection (huge deal!)
Clearer contributor terms
More explicit legal language

The difference from MIT:

MIT: "Don't sue me"
Apache: "Don't sue me, and here's patent protection too"

Why it matters:

// You invent a cool algorithm
// Someone uses it in their product
// They patent YOUR algorithm
// They sue YOU for using your own code!

// Apache 2.0 prevents this! 🛡️

Used by:

  • Android
  • Kubernetes
  • Apache projects (duh!)
  • TensorFlow
  • Rust

When to use Apache:

  • Your code involves algorithms/patents
  • You want more legal clarity
  • Working on enterprise-grade stuff
  • Companies need explicit patent grants

In the security community, we use Apache 2.0 a lot because security tools often involve novel techniques. Patent protection matters!

BSD Licenses - The OG Permissive Licenses

The variants:

BSD-3-Clause: MIT + "Don't use my name in ads"
BSD-2-Clause: Even simpler than MIT
BSD-0-Clause: Public domain (basically)

Fun fact: BSD licenses predate MIT by decades! They're the OG open source!

Used by:

  • FreeBSD
  • PostgreSQL
  • Nginx
  • Many old-school projects

When to use BSD:

  • You want permissive + name protection
  • You like saying "I use BSD btw" 😎

The "Share the Love" Family (Copyleft Licenses)

Think: "Use my code? Cool! But share YOUR improvements too!"

GPL (GNU General Public License) - The "Viral" One 🦠

The pitch:

Use it? ✅
Modify it? ✅
Distribute it? ✅
BUT...
If you distribute, you MUST share source code!
And use the SAME license!

Translation: Freedom is contagious! If you use GPL code, your code becomes GPL too!

The controversial part:

# Your proprietary app
import awesome_gpl_library  # Uh oh!

# Now your ENTIRE app must be GPL!
# You have to open source EVERYTHING!
# Your company's secrets? Public!

This is why companies FREAK OUT about GPL! 😱

Versions:

GPLv2: The classic (Linux kernel uses this)
GPLv3: Modern version + patent protection + anti-DRM

Used by:

  • Linux kernel (GPLv2)
  • Git
  • WordPress
  • GIMP
  • Tons of GNU software

When to use GPL:

  • You're philosophically committed to free software
  • You want to force others to open source too
  • You don't want companies to "take and never give back"
  • You're building a community-driven project

Real example:

"I built a DevOps tool and used GPL. Companies asked to use it but couldn't because their codebases were proprietary. I switched to Apache 2.0. Adoption increased 500%. Trade-offs!" - OSS Maintainer

LGPL (Lesser GPL) - GPL's Chill Sibling

The pitch:

Like GPL but...
If you just LINK to the library? Your code stays private!
If you MODIFY the library? Share those changes!

Translation: Companies can use LGPL libraries without open-sourcing everything!

The sweet spot:

// Your proprietary app
import lgpl_library from 'lgpl-lib'  // This is fine!

// But if you modify lgpl-lib itself
// You must share THOSE changes

Used by:

  • Qt (the framework)
  • Many libraries that want GPL's ethos but wider adoption

When to use LGPL:

  • You want copyleft but don't want to scare companies
  • Building a library (not an app)

AGPL (Affero GPL) - GPL for the Cloud Era ☁️

The loophole GPL had:

Company uses GPL code on THEIR servers
Offers it as a service (SaaS)
Never "distributes" the software
Never has to share source code!
Google does this. AWS does this.

AGPL closes this loophole:

If users interact with your code over a network?
You MUST share the source code!
Even if you don't "distribute" it!

Translation: Cloud services can't hide behind "we're not distributing it"!

Used by:

  • MongoDB (was AGPL, now has own license)
  • Grafana
  • Projects that don't want cloud giants to profit without contributing

When to use AGPL:

  • You're building a SaaS/cloud service
  • You want to prevent "cloud exploitation"
  • You're okay with scaring companies away

Warning: AGPL is the MOST restrictive open source license. Companies avoid it like the plague! 🐍

The "Middle Ground" Family

MPL 2.0 (Mozilla Public License) - The Compromise 🤝

The pitch:

File-level copyleft!
Modify an MPL file? Share those changes!
Add NEW files? Keep them private!

Example:

my-app/
  ├── mpl_library.js  (MPL - must stay open)
  └── my_code.js      (Your license - can be private!)

Why this rocks:

  • Companies can integrate without fear
  • But improvements to the library stay open
  • Best of both worlds!

Used by:

  • Firefox
  • Thunderbird
  • LibreOffice

When to use MPL:

  • You want some copyleft but not GPL-level
  • Building libraries for commercial use
  • Want a business-friendly copyleft

The "No License" Chaos ⚠️

No LICENSE file in the repo?

Legally: All rights reserved!
Can't use it
Can't modify it
Can't distribute it
Even though it's on GitHub!

This catches people ALL THE TIME:

Developer: "But it's on GitHub! It's open source!"
Lawyer: "No license file. Illegal to use."
Developer: "Oops..." 😅

The fix: Add a LICENSE file! ANY license is better than none!

The License Compatibility Matrix 🎲

Can you mix licenses? Sometimes!

MIT code + Apache code = ✅ Works fine!
MIT code + GPL code = ❌ GPL takes over!
GPL code + Proprietary code = ❌ Nope!
Apache + GPL = 🤔 Complicated (usually okay)
AGPL + anything = 😱 Everything becomes AGPL!

The rule of thumb:

Permissive + Permissive = ✅
Permissive + Copyleft = ⚠️ Copyleft wins
Copyleft + Copyleft = 🤔 Check compatibility
Copyleft + Proprietary = ❌ Illegal!

How to Choose a License (Decision Tree) 🌳

Ask yourself:

Question 1: Do you want attribution?

No → Public Domain (CC0/Unlicense)
Yes → Continue to Q2

Question 2: Do you care if companies use it closed-source?

Don't care → Permissive (MIT/Apache)
I care! → Copyleft (GPL/AGPL)

Question 3: (If permissive) Patent concerns?

Yes → Apache 2.0
No → MIT

Question 4: (If copyleft) Library or application?

Library → LGPL or MPL
Application → GPL or AGPL

Question 5: (If GPL) Cloud services?

Want to prevent cloud exploitation → AGPL
Traditional distribution is fine → GPL

My personal formula:

Side project? MIT
Community library? Apache 2.0
Philosophy-driven? GPL
SaaS project? AGPL

The "OH NO" Scenarios (Learn from Others' Pain) 🚨

Scenario 1: The GPL Surprise

Developer: Used a small GPL helper function
Company: "Our entire codebase is now GPL!"
Solution: Rewrote everything. 3 weeks wasted.
Lesson: READ LICENSES BEFORE USING CODE!

Scenario 2: The No-License Repo

Startup: Built product using GitHub code
GitHub code: No LICENSE file
Lawsuit: Original author sues
Result: $50,000 settlement
Lesson: No license = don't use it!

Scenario 3: The License Change Trap

Project: Switched from MIT to AGPL (Redis/MongoDB style)
Users: "We can't upgrade! License incompatible!"
Result: Community fork with MIT license
Lesson: License changes fracture communities!

Scenario 4: The Attribution Failure

Company: Used MIT library, removed license notice
Original author: "That's violation!"
Result: Lawsuit, public embarrassment
Lesson: ALWAYS keep the license file!

Balancing work and open source taught me: Companies have legal teams that WILL find license violations. Don't risk it!

The Practical Checklist ✅

Before Using Someone's Code:

□ LICENSE file exists?
□ Read it (yes, actually READ it!)
□ Compatible with your project's license?
□ Commercial use allowed? (if applicable)
□ Attribution required? (add to CREDITS/NOTICE)
□ Patent grant included? (for patent-heavy code)
□ Copyleft? (understand the implications!)

Before Choosing Your License:

□ Goal: Maximum adoption? → MIT/Apache
□ Goal: Community-driven development? → GPL/AGPL
□ Goal: Prevent cloud exploitation? → AGPL
□ Goal: Protect patents? → Apache 2.0
□ Goal: File-level copyleft? → MPL 2.0

After Choosing:

□ Add LICENSE file to repo root
□ Add copyright notice to file headers (optional but recommended)
□ Add license badge to README
□ Mention in documentation
□ Be consistent across projects (less confusion!)

Tools That Make This Easy 🛠️

1. ChooseALicense.com

What it is: GitHub's official license chooser

Why it rocks:

Non-lawyer language ✅
Side-by-side comparison ✅
Simple "I want to..." flow ✅

Use it: choosealicense.com

2. TLDRLegal

What it is: Plain English license explanations

Example:

Instead of: "...statutory warranty of merchantability..."
They say: "Can't sue if code breaks"

Use it: tldrlegal.com

3. License Compatibility Checker

What it is: Tools that check if licenses can mix

# Example: Can I use MIT + GPL together?
Check → GPL wins, everything becomes GPL!

4. GitHub's License Picker

# When creating a repo on GitHub
Click "Add a license" dropdown
GitHub auto-adds the LICENSE file!

Common Myths (Debunked!) 💥

Myth 1: "Open source means no license needed"

Truth: No license = copyrighted = can't legally use it!

Myth 2: "I can just use code from GitHub repos"

Truth: Only if there's a LICENSE file granting permission!

Myth 3: "MIT lets me remove the license text"

Truth: You MUST include the license text in distributions!

Myth 4: "Dual licensing is illegal"

Truth: Totally legal! You can offer MIT + Commercial license!

Myth 5: "Once open source, always open source"

Truth: YOU can change licenses for future versions (but old versions stay)!

Myth 6: "GPL means can't charge money"

Truth: You CAN sell GPL software! You just must provide source!

Advanced Topics (For the Curious) 🎓

Dual Licensing

Offer 1: GPL (free, open source)
Offer 2: Commercial license ($$$, closed-source allowed)

Example: Qt does this
Why: Make money while staying open source!

Contributor License Agreements (CLAs)

What: Legal agreement contributors sign
Why: Lets project owners change licenses later
Example: Google and many big projects use CLAs

License Headers in Files

/*
 * Copyright (c) 2026 Anuragh K P
 * Licensed under MIT License
 * See LICENSE file for details
 */

function myAwesomeCode() {
  // Makes it VERY clear this file is licensed
}

Copyright vs. License

Copyright: Who owns the code
License: What others can do with it

You can own copyright but license it permissively!

The Bottom Line 💡

Open source licenses aren't just legal mumbo-jumbo. They're the foundation of the ecosystem!

What you learned today:

  1. No license = can't legally use the code
  2. MIT/Apache = permissive (do whatever)
  3. GPL/AGPL = copyleft (share improvements)
  4. Wrong license = lawsuits and pain
  5. Always read licenses before using code
  6. Choose based on your goals, not trends
  7. Attribution is almost always required!

The reality:

Good license choice:

  • ✅ Clear expectations
  • ✅ Maximum adoption (or maximum sharing)
  • ✅ Legal protection
  • ✅ Happy community
  • ✅ No surprises

Bad/missing license:

  • ❌ Legal uncertainty
  • ❌ Can't be used legally
  • ❌ Potential lawsuits
  • ❌ Scared users
  • ❌ Community confusion

My recommendation for 90% of projects: Just use MIT or Apache 2.0!

They're simple, well-understood, and don't scare anyone. Save GPL/AGPL for when you have strong philosophical reasons!

Your Action Plan 🚀

Right now (5 minutes):

  1. Check your current repos for LICENSE files
  2. Any missing? Add MIT or Apache 2.0
  3. Done? You're now properly licensed! 🎉

This week:

  1. Review dependencies in your projects
  2. Check their licenses (package.json, go.mod, etc.)
  3. Ensure no GPL in proprietary projects!
  4. Add CREDITS/NOTICE file for attributions

This month:

  1. Read 2-3 full license texts (yes, really!)
  2. Understand what you're agreeing to
  3. Set a default license for your projects
  4. Never blindly copy code again

Going forward:

  1. License = first thing you check
  2. Add LICENSE.md to every repo
  3. Include it in your project templates
  4. Educate your team about licenses
  5. Sleep well knowing you're legal! 😴

Real Success Stories 💪

Story 1: The MIT Win

Developer: Released utility library with MIT
Companies: Used it everywhere
Result: 100K+ downloads, job offers, speaking gigs
Impact: MIT enabled wide adoption!

Story 2: The GPL Stand

Developer: Built SaaS platform with AGPL
Big Cloud Co: "Can we use this?"
Developer: "Sure, but you must open source your changes"
Big Cloud Co: "Nope"
Result: Built competing service, forced them to contribute
Impact: AGPL protected against exploitation!

Story 3: The License Audit Save

Company: Did license audit before Series A
Found: 3 GPL libraries in proprietary code
Action: Removed them BEFORE investor found out
Result: Funding secured, lawsuit avoided
Impact: Dodged a $500K+ problem!

Resources You Need 📚

License Info:

Tools:

  • npx license - Add license to project
  • licensee - Detect licenses in repos
  • fossology - Enterprise license scanning

Reading:

  • "Free Software, Free Society" by Richard Stallman
  • OSI License FAQ
  • GitHub's license documentation

Communities:

  • r/opensource on Reddit
  • HN discussions on licenses
  • OSI mailing lists

Final Thoughts 💭

The uncomfortable truth:

Most developers ignore licenses until it's too late. Don't be that developer!

5 minutes choosing the right license can save you from:

  • Lawsuits (💸💸💸)
  • Rewriting code (😭)
  • Investor problems (📉)
  • Community drama (🔥)
  • Sleepless nights (😰)

The best part? It's EASY once you understand the basics!

Just remember:

  • MIT/Apache for "use freely"
  • GPL/AGPL for "share improvements"
  • No license = don't use it
  • Always attribute
  • Read before you import

That's literally it! You're now smarter about licenses than 90% of developers! 🎓

So here's my challenge:

Right now, pick your favorite license. Add it to your projects. Sleep well knowing you won't get sued!

Questions to ask yourself:

  • Do my repos have LICENSE files? (If no, fix it NOW!)
  • Have I checked my dependencies' licenses? (Do it!)
  • Am I violating any licenses? (Better find out before lawyers do!)
  • Am I properly attributing? (Always!)

Your move! ♟️

Questions about licenses? Connect with me on LinkedIn - I've made all the mistakes so you don't have to!

Want to see well-licensed code? Check out my GitHub - every repo properly licensed!

Now go add those LICENSE files! 📜⚖️✨

P.S. Still confused? Start with MIT. You literally can't go wrong with MIT for 95% of projects!

P.P.S. For lawyers reading this: I'm not a lawyer. This isn't legal advice. But it's pretty accurate! (Please don't sue me. I have an MIT license on this advice. 😉)

← Back to all posts