Which licence should I pick?

Two questions usually settle it. Do you want people who modify your code to share those modifications? If no, choose the permissive family (MIT, BSD, Apache 2.0); if yes, copyleft (GPL, AGPL). Second: does patent protection matter in your field? If so, prefer Apache 2.0 over MIT. The common landing spots are MIT for a small library and Apache 2.0 for a project courting corporate contributors.

Can I change the licence later?

Going forward, yes. Retroactively, no. Future releases can carry any licence you choose, but every version you already published stays under the licence it shipped with. You also need to own the copyright in all the code: if you have accepted outside contributions you need permission from each contributor, or you need to rewrite their work.

The freedoms granted are effectively the same: commercial use, modification, distribution, private use. Apache 2.0 adds an explicit patent grant with a retaliation clause, a requirement to document changes, and a limit on trademark use. MIT fits on one page; Apache 2.0 runs to several. For a small library MIT is sufficient. Where patents are a live concern or corporate adoption is the goal, Apache 2.0 is safer.

Do I need a licence for a private repository?

Legally no: without one you retain all rights already. It is still worth adding in two cases. If the repository may go public later, getting the file right from the start keeps the history clean. And inside a team, writing down who may use the code prevents an awkward conversation. Internal projects often ship a short proprietary notice instead of an open source LICENSE.

What if I use a GPL dependency?

Running it yourself creates no obligation; GPL does not restrict use. Obligations begin at distribution. If you distribute an application linked against a GPL library, the combined work is expected to be released under a GPL-compatible licence. Where linking creates a derivative work is contested legal ground, so take advice before putting a GPL dependency in a commercial product. An LGPL or MPL alternative usually removes the question.

Open Source Licence Chooser

Compare MIT, Apache 2.0, GPL, AGPL, BSD and MPL side by side, then generate the LICENSE file with your name and year filled in.

Your data never leaves the browserUpdated: July 2026

Licence comparison

Licence comparison
Licence	Commercial use	Modification	Distribution	Private use	Patent use	Conditions	Limitations
MIT License	Commercial use	Modification	Distribution	Private use		2	2
Apache License 2.0	Commercial use	Modification	Distribution	Private use	Patent use	3	3
GNU General Public License v3.0	Commercial use	Modification	Distribution	Private use	Patent use	5	2
GNU Affero General Public License v3.0	Commercial use	Modification	Distribution	Private use	Patent use	6	2
BSD 3-Clause License	Commercial use	Modification	Distribution	Private use		2	3
Mozilla Public License 2.0	Commercial use	Modification	Distribution	Private use	Patent use	4	3
The Unlicense	Commercial use	Modification	Distribution	Private use		0	2

Choose a licence

Year

SPDX identifier: MIT

Conditions

Keep the copyright notice
Include the licence text

Limitations

No liability
No warranty

Read the full text

LICENSE

MIT License

Copyright (c) 2026 [fullname]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Key Takeaways

A repository with no LICENSE file is not open source. With no licence granted, default copyright applies and that means all rights reserved.
What Apache 2.0 adds over MIT is an explicit patent grant with a retaliation clause, which is usually the specific thing a corporate legal review is looking for.
AGPL differs from GPL by a single clause: offering a modified version over a network counts as distribution, closing the SaaS loophole.
A licence applies to a version. You can relicense future releases, but you cannot un-license what you already published.

No LICENSE file means all rights reserved

Making a repository public on GitHub does not make the code usable. Under the Berne Convention a work is protected by copyright the moment it is created, and where no permission has been granted the default is all rights reserved. You may read an unlicensed repository and, under GitHub's own terms, fork it on the platform. What you do not have is any legal basis for using that code in your own project.

Choosing a licence is therefore an act of granting permission, not of restricting anyone. Until the file exists you have given nobody anything, which is exactly why a careful company will refuse an unlicensed dependency, and why they are right to.

Three families: permissive, strong copyleft, weak copyleft

The difference between licences is what the recipient of your code is obliged to do. Permissive licences ask for almost nothing: keep the copyright notice, and the rest is yours. Strong copyleft requires derivative works to carry the same licence. Weak copyleft sits between the two by limiting the scope of that requirement.

Licence	Family	Source disclosure	Patent grant	Typical use
MIT	Permissive	None	Not explicit	Libraries; the most common choice by far
BSD 3-Clause	Permissive	None	Not explicit	Same as MIT, plus a no-endorsement clause
Apache 2.0	Permissive	None	Yes	Corporate projects, patent-sensitive fields
MPL 2.0	Weak copyleft	Only modified MPL files	Yes	Components embedded in closed products
GPL 3.0	Strong copyleft	The whole derivative work	Yes	Applications and end-user tools
AGPL 3.0	Strong copyleft	Including network use	Yes	Server-side software
Unlicense	Public domain dedication	None	Not explicit	Snippets where you want no attribution at all

Every permission, condition and limitation shown in the tool is derived from this distinction.

MPL 2.0 is the one most often misread. Because its copyleft is scoped per file, you can ship an MPL component inside a proprietary product; your only obligation is to publish the MPL files you modified, under MPL. GPL does not allow that, because its scope extends across the linked work as a whole.

The Apache 2.0 patent grant

Day to day, MIT and Apache 2.0 feel identical: both let you use, modify, distribute and sell. The difference appears at a legal review. Apache 2.0 grants an explicit patent licence from every contributor, paired with a retaliation clause: sue the project over a patent and your own licence terminates. MIT says nothing about patents at all, which leaves lawyers arguing over whether an implied licence exists and how far it reaches.

The practical consequence is that large legal departments approve Apache 2.0 more readily than MIT. In exchange it asks you to document your changes and introduces the NOTICE file, so it carries a little more maintenance overhead. This tool emits the notice block from the licence's own Appendix A rather than the full text, because Apache 2.0 requires the complete document to be distributed unmodified: truncating it would produce an invalid licence file.

AGPL and the network use clause

GPL obligations are triggered by distribution. Modify the code and hand a copy to someone, and you owe them the source. Run the same modified code exclusively on your own servers and serve users over HTTP, and no distribution has occurred, so no obligation arises. That gap is what people mean by the SaaS loophole.

AGPL 3.0 closes it with one added condition: making a modified version available over a network counts as distribution, and those users must be offered the corresponding source. This is why many companies selling hosted products forbid AGPL dependencies as policy. As an author, AGPL makes sense when you want to stop someone turning your work into a closed hosted service; for a library it will measurably cost you adoption.

Relicensing and dual licensing

A licence attaches to a version. If v1.0 shipped under MIT you are free to release v2.0 under GPL, but v1.0 remains MIT for everyone forever. You cannot withdraw a published release: copies already exist, and the permissions you granted on those copies are not revocable.

json

1{2  "name": "your-package",3  "license": "MIT",4  "//": "Dual licensing is expressed with an SPDX expression:",5  "example_1": "MIT OR Apache-2.0",6  "example_2": "AGPL-3.0-or-later OR LicenseRef-Commercial"7}

One further constraint: relicensing requires you to hold copyright in all of the code. If you have merged outside pull requests, those lines belong to their authors and each has to agree, which is a large part of why projects ask contributors to sign a CLA. Dual licensing, offering the same code under AGPL and under a commercial licence, works on the same principle: it needs ownership consolidated in one place.

Note

Everything on this page is general information, not legal advice. Interpretation varies by jurisdiction, and in a commercial setting (employment agreements, patent portfolios, customer warranties) the picture gets complicated quickly. If money or contractual obligations are involved, talk to a lawyer.

Frequently Asked Questions

Which licence should I pick?: Two questions usually settle it. Do you want people who modify your code to share those modifications? If no, choose the permissive family (MIT, BSD, Apache 2.0); if yes, copyleft (GPL, AGPL). Second: does patent protection matter in your field? If so, prefer Apache 2.0 over MIT. The common landing spots are MIT for a small library and Apache 2.0 for a project courting corporate contributors.
Can I change the licence later?: Going forward, yes. Retroactively, no. Future releases can carry any licence you choose, but every version you already published stays under the licence it shipped with. You also need to own the copyright in all the code: if you have accepted outside contributions you need permission from each contributor, or you need to rewrite their work.
MIT or Apache 2.0?: The freedoms granted are effectively the same: commercial use, modification, distribution, private use. Apache 2.0 adds an explicit patent grant with a retaliation clause, a requirement to document changes, and a limit on trademark use. MIT fits on one page; Apache 2.0 runs to several. For a small library MIT is sufficient. Where patents are a live concern or corporate adoption is the goal, Apache 2.0 is safer.
Do I need a licence for a private repository?: Legally no: without one you retain all rights already. It is still worth adding in two cases. If the repository may go public later, getting the file right from the start keeps the history clean. And inside a team, writing down who may use the code prevents an awkward conversation. Internal projects often ship a short proprietary notice instead of an open source LICENSE.
What if I use a GPL dependency?: Running it yourself creates no obligation; GPL does not restrict use. Obligations begin at distribution. If you distribute an application linked against a GPL library, the combined work is expected to be released under a GPL-compatible licence. Where linking creates a derivative work is contested legal ground, so take advice before putting a GPL dependency in a commercial product. An LGPL or MPL alternative usually removes the question.