Pick the license by answering one question before anything else: do you want to force everyone downstream to share their changes back, or not? If yes, use the GNU General Public License version 3 (GPLv3), or the Affero version (AGPLv3) if your code runs as a network service. If no, use the MIT License for simplicity, or the Apache License 2.0 when you need an explicit patent grant. Everything else is detail. Answer that first and the choice narrows fast.

Last updated: 2026-07-21

What does a license actually control?

Copyright already gives you exclusive rights the moment you write the code. A license is you granting some of those rights back to other people, on conditions. No license means no permission, so "I put it on GitHub" gives nobody the legal right to use, copy, or ship it. Public repo, all rights reserved.

So the license governs three things: use, modification, and distribution. It sets what a downstream user must do in return, usually keep your notice, sometimes share their own changes under the same terms. It does not govern your trademark, your patents beyond what the license grants, or your right to sell the same code under a different license to a paying customer.

Read the actual text once before you commit. Most licenses are a page or two, and the obligations are plain. The Open Source Initiative keeps the approved list, and an OSI-approved license means it has been reviewed against a real definition, not just something a company slapped "open" on.

How do you choose a license for your project?

Work top down, from the one decision that changes everything to the details that rarely matter.

1. Decide copyleft or permissive. Do you want modified versions to stay open? That is the fork in the road. Copyleft forces it; permissive does not.
2. Check how your code is delivered. Shipped as a binary or hosted as a service? A hosted service never "distributes" anything, so plain GPLv3 does not trigger. AGPLv3 closes that gap.
3. Check whether patents are in play. Corporate, hardware-adjacent, or codec-style work needs an explicit patent grant. Apache 2.0 has one; MIT does not.
4. Check your dependencies. Your license cannot be more permissive than what you link in. A GPL library drags GPL obligations into your project whether you meant it or not.
5. Match the ecosystem default unless you have a reason to fight it.

Most people overthink steps three through five and skip step one. Get step one right and the rest is bookkeeping.

The three license families you actually need to know

Every open source license lands in one of three buckets. Learn the buckets and the individual names stop mattering.

• Permissive – MIT, Apache 2.0, BSD. Do almost anything, including folding the code into closed proprietary software, as long as you keep the copyright notice. The MIT License is one of the most popular open source licenses precisely because that is the whole deal.
• Weak copyleft – LGPL, Mozilla Public License 2.0 (MPL). Changes to the licensed files must stay open, but you can link or combine with proprietary code around them. Copyleft scoped to a boundary.
• Strong copyleft – GPLv3, AGPLv3. The GPL requires that derivative works use the same license. Touch the code, ship the result, and your whole combined work goes out under the GPL too.

The BSD 3-Clause License states it in one line: redistribution and use in source and binary forms, with or without modification, are permitted. Everything else in the permissive family is a variation on that one sentence.

How open source licenses compare in practice

Here is the side-by-side I check against, on the terms that decide real cases.

The column people forget is the last one. GPLv3 only triggers on distribution, and running a web service is not distribution. If someone can take your GPLv3 code, run it on a server, and never share their changes, that is working as designed. AGPLv3 was written to close exactly that hole.

Which license fits a library versus an application

Library authors lean permissive; application authors lean copyleft. That split trips up first-timers, so here is the reasoning.

A library lives or dies on adoption. If a company cannot link your library without opening their whole product, they will pick a different library. So MIT, Apache 2.0, or LGPLv3 for anything meant to be embedded. LGPLv3 is the sharp choice when you want the library itself to stay open but do not care what it gets linked into. I have written more on using LGPL for device drivers where that boundary matters.

An end-user application is different. Nobody links your photo editor into their product; they run it. So copyleft costs you almost no adoption and buys you the guarantee that forks stay open. GPLv3 fits here, AGPLv3 if you ship it as a hosted app. If you are picking a license for kernel-space code, the constraints are tighter and worth reading up on before you decide.

Patents, contributors, and adoption

Three practical worries sit behind the license text, and they are what actually cost people.

Patents first. A permissive license with no patent clause, like MIT, leaves a gap: a contributor could hand you code, then sue users over a patent it infringes. Apache 2.0 makes every contributor grant a patent license and revokes it if they sue. Use Apache over MIT the moment patents are anywhere near your project.

Contributor rights come next. Every person who commits owns copyright on their part, which means you cannot relicense later without all of them agreeing. That is why big projects use a Contributor License Agreement (CLA) up front. Annoying to set up, brutal to add after ten thousand commits.

Adoption is the quiet one. A stricter license does not just filter users, it filters contributors and downstream projects too. That is a fair trade if your goal is keeping forks open. It is a bad trade if you wanted a library everyone reaches for by default.

How license compatibility works when you combine code

Treat dependency licenses like a stack trace: follow every branch to the bottom, because one bad line deep in the tree taints everything above it. Your project's effective license is the strictest one in the whole dependency graph, not the one in your own LICENSE file.

The direction that matters: permissive licenses are compatible with copyleft licenses, so you can pull MIT code into a GPL project freely. The reverse fails. You cannot pull GPL code into an MIT project and keep it MIT, because the GPL's share-alike terms follow the code and there is no way to strip them.

So run a license scan on your transitive dependencies before a release, not after a lawyer emails you. Tools that read your lockfile will flag a stray GPL package buried three levels down. That is the compatibility bug that ships in a "permissive" product and nobody notices until it is expensive. If you work in the kernel, the same discipline shows up as GPL compliance in kernel code, where the module symbols themselves enforce it.

Should ecosystem norms decide for you?

Usually, yes. Rust and Node projects default to MIT or dual MIT/Apache, Linux is GPLv2, and much of the JVM world runs on Apache 2.0. When you match the default, your code drops into other people's projects with zero friction and no lawyer review. That frictionlessness is worth real money in adoption.

Override the default only when you have a concrete reason the ecosystem does not share. Maybe you are building a hosted product and need AGPLv3 to stop competitors from freeloading. Maybe you are in a patent-heavy field and want Apache's grant even where MIT is customary. Those are good reasons.

What is not a good reason is picking an exotic license because it sounds clever. A weird license makes every potential user stop and think, and most will just move on. The debate over Apache versus GPL for drivers is really this question in disguise: fight the ecosystem norm only when the payoff is clear.

Licensing docs, art, and other non-code work

Software licenses fit software badly for prose, images, and fonts, so use Creative Commons for anything that is not code. The Creative Commons license suite covers documentation, logos, datasets, and media with terms written for creative work instead of source files.

The pieces are modular. BY requires attribution and nothing else. BY-SA adds share-alike, the copyleft idea for creative work, so remixes carry the same license. BY-NC blocks commercial use, which sounds friendly and quietly makes your work unusable by a lot of legitimate projects, including some nonprofits.

CC BY-SA 4.0 is the pick when you want share-alike behavior on non-code assets, which is why it backs Wikipedia. Keep it separate from your code license: put the software under MIT or GPL, and the docs and art under a CC license, and say so plainly in the repo, so nobody has to guess which terms cover which files.

What attribution, commercial, and remix terms really mean

Strip the legal wrapper and these clauses do three concrete things.

Attribution means you must keep the author's name and notice attached, even in a derivative. It is the one obligation nearly every open source and CC license shares, and it is why deleting the copyright header is a violation, not a cleanup.

Commercial restriction, the NC in CC BY-NC, means the work cannot be used for commercial advantage. The trap is how broad "commercial" reads. A company blog, an ad-supported site, a paid training course, all commercial. If you want your work actually used, think hard before adding NC.

Remix or derivative permission decides whether people can build on your work at all, and under what terms they release the result. ShareAlike says derivatives must match your license. NoDerivatives says they cannot distribute changes at all, which is close to useless for anything meant to be collaborated on. Match the clause to how you actually want the work to spread.

Is public domain dedication a real option?

Yes, but it is legally shakier than a license, so use it with eyes open. CC0 and the Unlicense try to waive every right and demand nothing back, not even attribution. When it works, that is the maximally free choice.

The catch is that some countries do not let you abandon copyright the way US law roughly allows. In those jurisdictions a bare "public domain" note may not hold, which is why CC0 includes a fallback all-permissions license for when the waiver itself fails. The Unlicense is thinner and gives lawyers less to lean on.

Pick a public domain dedication for tiny snippets, examples, schemas, or config that you genuinely want copied without ceremony. For a real project you want people to depend on, MIT costs you almost nothing extra and is far better understood by the people whose legal team has to approve it. Certainty beats purity here.

Mistakes that bite you later

The expensive failures are all diligence you skipped, and every one traces back to not reading what you actually shipped.

• No CLA, then a relicense need. You want to move to a new license years in, and now you need sign-off from every past contributor. Some are unreachable. The project is stuck at whatever it started as.
• License drift after a dependency update. A minor version bump swaps a permissive dep for a copyleft one, or adds a copyleft transitive dependency, and your "permissive" release is quietly now something else. Scan on every release.
• No license at all. Code on a public host with no license grants nobody any rights. Contributors cannot legally build on it, and you cannot fix that retroactively without their permission.
• Copied code with the header stripped. That is the single most common violation, and it is discoverable by anyone with a copyright scanner.

None of these show up on day one. They show up the day you try to change something, which is the worst possible time to learn your license history was wrong. Get it reproducible: know every license in your tree, and know why each one is there.

FAQ

Can I change my project's license later?
Only with permission from everyone who holds copyright in the code, which means every contributor unless they signed a CLA assigning that right. For a solo project you can relicense freely going forward, though old released versions stay under their old terms forever. Plan the CLA before the contributors pile up, not after.

What happens if I dual-license my project?
You offer the same code under two licenses and let each user pick one. A common pattern is GPLv3 for the community plus a paid commercial license for companies that cannot accept copyleft. It works, but you must own or have assignment on all the code, so it is another reason to run a CLA from the start.

Does putting code on GitHub make it open source?
No. Visibility is not permission. Without a license file, default copyright applies and nobody may legally use, modify, or redistribute your code. Add a LICENSE file in the repo root with the full text, and put a short notice header in each source file.

Is GPLv2 or GPLv3 the better copyleft choice?
GPLv3 for new projects, because it added an explicit patent grant and closed loopholes the older version left open. GPLv2 still matters where you must stay compatible with a GPLv2-only codebase, the Linux kernel being the big one. Check what you are combining with before you assume you have a free choice.

How do I check the licenses of my dependencies?
Run a license scanner against your lockfile and read the report, the same way you would read a stack trace to the bottom. It lists every direct and transitive dependency and its license, so a lone copyleft package buried deep in the tree shows up before release instead of after someone's lawyer finds it.

Related: LGPL vs GPL: Key Linking Differences Explained