When you click "Add a license" on a new GitHub repository, GitHub hands you a dropdown of roughly a dozen options pulled from choosealicense.com. GitHub licenses are just standard open-source license templates that GitHub bundles into repo creation so you don't have to hunt one down yourself — the choice between them still depends entirely on how permissive or protective you want your project to be. Picking blind, or picking whatever the last repo you forked used, is how projects end up with license terms nobody on the team actually agreed to.
This matters more than it looks. The license file in your repo root is a binding grant of rights, and it governs what downstream users, forks, and even your own company can legally do with the code years after you've forgotten which box you checked.
What license options does GitHub actually offer?
GitHub's repo-creation flow surfaces the handful of licenses that choosealicense.com recommends as clear and widely used: MIT, Apache License 2.0, GNU GPLv3, GNU LGPLv3, the BSD 2-Clause and 3-Clause licenses, the Mozilla Public License 2.0, the Unlicense, and a few others like Boost and the Eclipse Public License. GitHub deliberately keeps this list short rather than exhaustive, because the SPDX license list itself has hundreds of entries and most of them are either legacy, extremely narrow in scope, or duplicative of a more common option. If your project needs something outside that list, you can still add any SPDX-recognized license text manually — GitHub just won't auto-generate it for you.
How do you choose between a permissive and a copyleft license?
Choose a permissive license (MIT, Apache 2.0, BSD) if you want the widest possible adoption with the fewest restrictions on downstream use, and choose a copyleft license (GPL, LGPL, MPL) if you want modifications and derivative works to stay open under the same terms. The practical dividing line is commercial reuse: a company can take MIT-licensed code, modify it, and ship it in a closed-source product without ever publishing their changes. Under GPLv3, if they distribute a modified version, they generally have to release that modified source under GPL too. Neither is objectively better — it's a policy decision about whether you're optimizing for adoption or for keeping the commons open.
MIT vs Apache 2.0: what's the actual difference?
MIT is shorter and simpler, granting broad rights with almost no conditions beyond keeping the copyright notice attached. Apache 2.0 grants the same broad usage rights but adds an explicit patent license from contributors to users, plus a requirement to state significant changes made to the code. That patent grant matters a lot more than people give it credit for: it means a contributor can't later sue downstream users for patent infringement over code they contributed themselves. If your project touches anything patent-sensitive, or you want that extra protection for users, Apache 2.0 is the safer default over MIT. If you want the shortest, most-recognized permissive license with zero patent complexity, MIT wins.
What happens if you don't add a license at all?
Without a license file, your code is not automatically open source — under default copyright law, all rights are reserved, and technically nobody else has permission to use, copy, modify, or distribute your code even though it's publicly visible on GitHub. This surprises a lot of people, since anyone can view and clone a public repo, but visibility and licensing are entirely separate concepts. GitHub's own terms of service grant other users the ability to view and fork your repo, but that's not the same as a legal license to reuse the code in their own projects. If your repo has no LICENSE file, you should assume nobody outside your organization is legally allowed to depend on it.
How does license choice interact with your dependency tree?
Every license you choose becomes a downstream constraint on anyone who depends on your package, and every license your dependencies carry becomes a constraint on you. This is where things get complicated fast in real projects with hundreds of transitive dependencies pulled in through npm, PyPI, or Maven — a single GPL-licensed transitive dependency buried five levels deep can theoretically create copyleft obligations for an otherwise MIT-licensed application, depending on how it's linked and used. Most teams don't manually audit this; they rely on software composition analysis tooling to flag license conflicts automatically as part of CI, the same way it flags known-vulnerable packages. Safeguard's SCA product surfaces license metadata alongside vulnerability data specifically so a GPL or AGPL dependency doesn't slip into a commercial codebase unnoticed.
Can you change a license after you've already published?
You can change the license going forward, but you generally cannot revoke the license under which code was already distributed. If you relicense a repo from MIT to a more restrictive license, anyone who already has a copy of the MIT-licensed version retains their MIT rights to that version — the new license only applies to future releases. Relicensing also gets legally messy if you have external contributors, because you typically need agreement from every copyright holder (i.e., every contributor) to change the terms, which is why many larger open-source projects require a contributor license agreement (CLA) up front.
FAQ
Does GitHub's license picker cover every license I might need?
No. It surfaces the most common, choosealicense.com-recommended options. Less common or industry-specific licenses (like the GNU AGPL for network-service copyleft, or the SIL Open Font License) need to be added manually, but they're still fully valid to use in a GitHub repo.
Is a license required for a private repo?
Not in the same way. Private repos are already access-restricted, so a license mostly matters when you plan to make the repo public or distribute the code outside your organization. Still worth adding one before you flip visibility to public.
Can I use a different license for documentation than for code?
Yes, and it's common — many projects license code under MIT or Apache 2.0 and license docs separately under a Creative Commons license like CC-BY-4.0, since documentation and code have different reuse norms.
How do I check what licenses my dependencies use?
Run a software composition analysis scan against your manifest files (package.json, requirements.txt, pom.xml, etc.). Tools built for this, including Safeguard's SCA scanning, enumerate every direct and transitive dependency's declared license so you can catch a GPL or AGPL package before it ships in a commercial build.