Which open-source license should you pick?
Picking an open source license for a project is not obvious. MIT? Apache? GPL? Each has different rules about what others can do with your code, whether they have to give you credit, whether their derivative works also have to be open source.
This tool helps you pick. Two modes: wizard (a few yes/no/any questions narrow the list) or browse (the full list of 16 licenses with side-by-side comparison).
After choosing, fill in your name + year, then copy or download a ready LICENSE file to drop into your project root.
How to use it
- Pick a mode at the top: Wizard (question-driven) or Browse (with search).
- In the wizard, answer 4 questions: do derivatives have to be OSS, commercial use, attribution required, patent grant needed. The list narrows live.
- Click a license to see details: permissions (what others can do), conditions (what they must do), limitations (what you disclaim).
- Fill in your name and the year to insert them into the license text.
- Copy the result or download a LICENSE file. Drop it into the root of your repository.
When this is useful
Everyday situations where you need to pick a license:
- Publishing your first npm library - without a license no one can legally use it. Most popular pick: MIT (short, simple, used by React/Vue/Angular).
- Corporate library, worried about patents - Apache 2.0 has an explicit patent grant protecting both contributors and users. Required by CNCF and many enterprise programs.
- You want every change to stay open - GPL-3.0 forces derivatives to use the same license. AGPL-3.0 adds source disclosure even when your tool is just hosted as SaaS.
- You are writing documentation or making art - use MIT/Apache for code, but for docs and images typically pick CC BY 4.0 (attribution) or CC BY-SA 4.0 (attribution + copyleft).
- You want to monetize but show the source - BSL 1.1 (HashiCorp Terraform) or Elastic 2.0 (Elasticsearch) - source-available with restrictions on commercial hosting. Note: these are NOT OSI-approved.
- No restrictions at all - Unlicense or CC0 for full public domain. WTFPL is a joke but legally functional.
- Adding a LICENSE file to an existing repo - pick it, fill in your details, copy into a `LICENSE` (or `LICENSE.md`) file at the root.
Related tools: the .gitignore generator for new project bootstrapping. The package.json validator checks the `"license"` field in your manifest.
Questions and answers
Without a license, all rights stay with the author (you). Technically others cannot use, modify, or redistribute your code - even if you put it on GitHub. Picking a license is a clear agreement: "I am OK with you doing X if you do Y". Without one, people simply skip your project.