How to Choose a License for Your Open Source Project

You created a repository, clicked "Add a license" on GitHub, and found yourself staring at a list of eleven options with no clear answer. You picked MIT because everyone picks MIT. Maybe that was right. Maybe not.

The post on MIT, Apache, and GPL covers what each of those licenses actually permits and prohibits. This one is the step before that: the decision tree to get there. Because the question "MIT or Apache?" already assumes you want open source — and that isn't always true.

The first question isn't "which license"

It's: do you want anyone besides yourself to be able to use this code?

If the answer is "no, for now" — or if you're simply not sure — leaving a repository without a license is a deliberate choice, not an oversight. A public GitHub repository without a LICENSE file is not public domain. It's the opposite: default copyright applies, which means no one has legal permission to copy, modify, or distribute the code beyond what GitHub's terms of service allow (which is pretty limited — basically viewing and forking to contribute back).

No license = closed by default. That might be exactly what you want.

Public GitHub repo without LICENSE:
✗ Commercial use by third parties
✗ Redistribution
✗ Modification and redistribution
✓ Viewing
✓ Fork to open a Pull Request (GitHub terms)

The myth that "public code on GitHub is open source" is dangerous. It isn't. Open source requires a license that explicitly grants the four basic freedoms: use, study, modify, distribute.

You want the code public but closed?

That's a real pattern. Some projects live on GitHub for reference or portfolio purposes, without any intention of allowing free use. In these cases, a "read-only" license is clearer than no license at all.

Creative Commons BY-NC-ND is used this way — allows viewing and sharing with attribution, but prohibits modification and commercial use. Not the default choice for code (it was designed for content), but it shows up in design projects, technical documentation, and templates.

For proprietary code you want to publish for transparency or security auditing purposes, some companies use custom viewing licenses (like the Business Source License, or BUSL) that allow non-commercial use for a period and convert to a permissive license after N years. HashiCorp did this with Terraform in 2023, which generated significant discussion in the community.

If you're at a company developing internal software that lives in a private GitHub repo, the licensing question still matters for what you use, not what you publish. That's a different problem.

Decision tree: from zero to the right license

The central question is about what you want to happen to the code once it leaves your hands:

Branch 1: I want maximum adoption, no restrictions

You want people to use the code — in commercial products, closed-source products, other open source projects, in any context. You don't want to create friction for anyone.

→ MIT if the project is small and you have no patent concerns.
→ Apache 2.0 if there are corporate contributors, the project could become a patent litigation target, or you work at a company where legal will review dependencies.

The difference between MIT and Apache 2.0 is almost always irrelevant for individual projects. For projects with multiple contributors and scaling potential (infrastructure, build tools, protocols), Apache 2.0 is more defensive.

Branch 2: I want the code to stay open

You want whoever uses your code and distributes derivatives to also have to keep the code open. You don't want a company to close it, monetize it, and give nothing back.

→ GPL v3 for software that is distributed (installed on users' computers).
→ AGPL v3 for software that runs as a cloud service. The classic GPL's gap is that you can take GPL code, run it on a SaaS server, and never "distribute" anything in the technical sense — AGPL closes that gap by requiring users of the service to have access to the source code.
→ LGPL if you're making a library that needs to run inside proprietary products, but you want the library's code itself to remain open.

The choice between GPL and AGPL depends on where the software is executed. If you're building a database, a web server, a monitoring system — anything that companies tend to run as a service without distributing binaries — AGPL is the license that protects your work. MongoDB, Grafana, and Nextcloud use AGPL for exactly this reason.

Branch 3: I want to monetize, but also have an open source community

This is the dual licensing case, and it's more common than it seems.

The strategy: license the project under GPL (or AGPL) for free open source use, and sell a commercial license to companies that need to use it in closed products. MySQL was the most famous case — Oracle still uses this model. Qt does the same.

The condition for dual licensing to work: you need to control 100% of the code's rights. If you accept external contributions without a CLA (Contributor License Agreement), contributors keep copyright of what they submitted, and you can't relicense their code for the commercial version.

Dual licensing requires:
✓ Centralized copyright (just you, or mandatory CLA)
✓ Ability to sell the commercial license
✓ Corporate users who prefer paying over opening code
✗ Doesn't work well with community contributions without CLA

If you're planning dual licensing from the start, the initial license decision needs to include the CLA policy. It's not something you add after 50 contributors.

Branch 4: I want to use other people's code in my closed project

This is the reverse perspective — not about what you publish, but about what you use.

The rule here is simple: check the licenses of all dependencies before building on them.

• MIT and BSD: no problem for closed projects.
• Apache 2.0: no problem, with a compatibility caveat with GPL v2.
• GPL v2 / v3: don't use in a closed distributed product. Internal use without distribution is generally safe.
• AGPL: don't use in SaaS without opening code. The criterion is whether external users access the service via the network.
• LGPL: can use in a closed product if the linking is dynamic and you don't modify the library. Read section 4 of the license.

# Audit npm dependency licenses
npx license-checker --summary --excludePrivatePackages

# Python
pip-licenses --order=license --format=table

Running this in CI before each release is reasonable practice for any commercial project. Dependencies change licenses — it happened with Elasticsearch, HashiCorp Vault, Redis, and other major projects in recent years.

The special case of "source available" licenses

Over the last five years a middle-ground category has grown that is neither open source nor classic proprietary software: source available.

Business Source License (BUSL), Server Side Public License (SSPL, MongoDB), Elastic License — all allow viewing and studying the code, but restrict competitive or production use. The OSI (Open Source Initiative) does not consider any of them truly open source, because they restrict specific uses.

If you work at a company and your dependency repository contains any of these, it's worth confirming that your use case is permitted under the terms. "Code on GitHub" does not imply permission to use in production.

Changing licenses later

Possible, but with one condition: you need permission from all copyright holders.

If the project has only you as author, it's simple — you can relicense. If it has external contributors who submitted code without a CLA, each of them holds copyright of what they wrote. You'd need the consent of all of them to change the license.

Linux tried to move from GPL v2 to GPL v3 and couldn't for exactly this reason — Linus Torvalds holds copyright on some of the code, but there are decades of contributions from thousands of people without a centralized CLA. The change would be operationally infeasible.

This reinforces the importance of deciding before accepting the first external contributions. Once the community grows, the license gets locked in.

Frequently asked questions

Can anyone use a project with no license?

No. Without a license, default copyright applies: no one can use, copy, modify, or distribute without explicit permission from the author. A public GitHub repository without a LICENSE file is code with "all rights reserved" copyright. People can view the code, but they have no legal permission to use it. If you want others to use it, you need a license.

Is MIT enough for most projects?

Yes, in most cases. MIT works well for libraries, command-line tools, frameworks, and components you want to be widely adopted. The situation where MIT isn't enough: (1) you want explicit patent protection — use Apache 2.0; (2) you want to ensure derivatives stay open — use GPL; (3) you want to prevent SaaS services from using it without contributing back — use AGPL. If none of those cases apply, MIT is the right choice.

Can different parts of the project have different licenses?

Yes, it's a pattern called "multi-tier licensing" or simply files with different license headers. Documentation often uses Creative Commons while the code uses MIT or Apache. SDKs can have the core under MIT and commercial plugins under a proprietary license. The requirement is making it clear which part has which license — usually with file headers or a LICENSES/ directory with the relevant texts.

How do I license a portfolio project I don't plan to actively distribute?

Three common options: (1) MIT, because you don't care what people do — it's portfolio, you want people to see and use it; (2) no license, if you only want it viewable and don't want it copied; (3) CC BY-NC if the project is more content than code and you want attribution. For most technical portfolio cases, MIT is the path of least friction.

The right license matches your intent, not the most popular choice

MIT won mindshare because it's simple and works for the most common case. But "everyone uses MIT" isn't sufficient reason if you have specific intentions for the project.

The flow is straightforward: decide if you want open source. If yes, decide if you want copyleft or permissive. If permissive, MIT vs Apache 2.0 depends on the patent context. If copyleft, GPL vs AGPL depends on how the software is executed. If you want to monetize, consider dual licensing with a CLA.

To understand what each of these licenses implies in detail — the actual text, compatibility implications, edge cases — the post MIT, Apache, and GPL: what each license actually allows covers it line by line.