The Complete Guide to Licensing Your Open Source Project Correctly

So you’ve built something cool. Your code works, the README is polished, and you’re ready to share it with the world. But there’s one glaring question that can make or break how your project gets used, forked, and contributed to: What license do you slap on it?

Pick the wrong one, and you might scare off contributors. Pick none at all, and you’ve effectively told the world: “Please don’t touch this, or sue you if you do.” Yes, no license means default copyright—meaning nobody can legally copy, modify, or distribute your work without your explicit permission.

Let’s cut through the legal jargon and walk through what each major license actually does, when to use it, and how to apply it without hiring a lawyer.

Why Licensing Matters More Than You Think

Imagine putting your project on GitHub without a license. Developers see that, and most will walk away. Companies especially—they have legal teams that flag unlicensed code as a liability. Your project becomes invisible to the open source community.

A license is your project’s terms of service. It tells users:

• Can they use your code in their commercial product?
• Do they have to share their changes back?
• Can they repackage it and sell it?
• Do they need to credit you?

Without those rules, everyone assumes the worst: no permission.

The Two Big Families: Permissive vs. Copyleft

Every open source license falls into one of two camps:

• Permissive: Lets people do almost anything—use, modify, sell—as long as they keep your copyright notice. Minimal strings attached.
• Copyleft: Requires that any derivative work (changes, forks, larger projects that include your code) also be open source under the same license. It’s designed to keep code free forever.

Think of permissive as “I trust you to do the right thing” and copyleft as “I’m guaranteeing nobody can lock this code up.”

The Most Common Licenses in Practice

MIT – The Default Choice

The MIT License is short, sweet, and everywhere. You see it on projects like React, jQuery, and Node.js. It says: do whatever you want—just include the original copyright notice. That’s it.

When to use it: You want maximum adoption. Companies love MIT because they can embed your library into proprietary products without legal hassle. It’s great for libraries, tools, and small utilities.

Downside: Some proponents of ethical open source argue it lets corporations profit off your work without giving back. If that bothers you, read on.

Apache 2.0 – MIT’s Bigger, Safer Cousin

Apache 2.0 is like MIT but with explicit patent protection. It grants users a patent license from the project’s contributors, meaning they can’t later sue you for using code they contributed. Essential for projects where patents might be an issue (think machine learning libraries, hardware-related code).

It also requires you to state any changes you made in a NOTICE file. Slightly more paperwork than MIT, but still very permissive.

Used by: Kubernetes, TensorFlow, Android.

GPLv3 – The Strong Copyleft Champion

The GNU General Public License v3 is the poster child for copyleft. If you distribute a modified version of GPLv3 code, you must release your entire project under GPLv3 too. That means anyone who gets your software also gets the source code and the right to modify it.

This makes it a hard sell for most businesses, but a powerful tool for building free software ecosystems. If your project is a complete application (not a library), and you want to ensure nobody can take it closed-source, GPLv3 is your friend.

Used by: Linux kernel (v2 only), WordPress, Git.

AGPLv3 – The Network Copyleft

The Affero GPLv3 fixes a loophole in the GPL: if software runs on a server and users never receive a copy, the GPL doesn’t force source release. AGPLv3 closes that—if someone uses your code in a web service, they must make the source available to users over the network.

Used by: MongoDB (until they switched licenses), many SaaS-focused tools. It’s the most restrictive widely-used license.

LGPL – The Library Exception

The Lesser GPL is a copyleft license designed for libraries. It lets companies link to your library from proprietary software without forcing them to open-source their whole app. Changes to the library itself must still be shared.

Use this when you want to keep your library free, but still allow wide adoption in both open and closed source projects.

BSD Licenses – Permissive with Variations

The BSD 3-Clause is similar to MIT but adds a “no endorsement” clause—you can’t use the names of contributors to promote products without permission. BSD 2-Clause is nearly identical to MIT.

Less common now, but still used in many academic and historical projects.

What Happens When You Don’t Pick a License?

In most countries, code is automatically copyrighted the moment you write it. No license means no permission. That means:

• Nobody can legally fork, modify, or distribute your code.
• Your project can’t be included in package managers (PyPI, npm, etc.) without explicit permission.
• People can look at your code, but they can’t use it.

There’s a common myth that “open source code on GitHub is free for anyone to use.” Wrong. Without a license, you’re just showing your work, not sharing it.

How to Actually Apply a License

Step-by-step, dead simple:

1. Choose a license using the guidelines above.
2. Create a file named LICENSE in the root of your repository. Copy the full text of your chosen license into it. (You can find templates on choosealicense.com.)
3. Update each source file with a short header: for MIT, just a copyright line at the top. For GPL, include the standard preamble. Many projects automate this with tools like licenseheaders.
4. Add a badge in your README (it helps people at a glance). Something like [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT).

That’s it. You’re legally protected, and the world can start using your code.

Real-World Mistakes to Avoid

• “Creative Commons for code.” Don’t use Creative Commons licenses for software. CC licenses are meant for art, writing, and media. They don’t handle software-specific issues like linking, distribution, or patents.
• Dual licensing without a plan. Some projects offer one license for open source use and another for commercial. That’s fine if you’re the sole copyright holder, but it gets messy with contributions from others.
• Changing a license later. You can’t unilaterally relicense code that has contributions from others (unless you own all copyrights). Once you send it out under MIT, that version stays MIT forever. New versions can have a new license, but old copies live on.

A Quick Decision Flowchart

• Is your project a small utility or library? → MIT
• Does your project involve patents or you want explicit safety? → Apache 2.0
• Is your project a full application you want to keep free? → GPLv3
• Is it a web application where users interact through a server? → AGPLv3
• Do you want to let companies use your library without open-sourcing their app? → LGPL

No license is perfect, but the worst license is no license at all. Pick one, add the file, and let the community build on what you’ve started.