Open-Source Licenses Explained: MIT, Apache 2.0, GPL 3.0, ISC and MPL 2.0

You're about to push the first commit of a new project — a small CLI, a React component, an internal utility — and GitHub is asking which license you want. You stare at the dropdown for longer than you'd like to admit, pick MIT because everyone else does, and move on. That's fine, but the license you pick actually changes what other people are allowed to do with your code, and picking the wrong one (or none) can quietly block adoption or, conversely, let a competitor rebrand your work without giving back.

This guide walks through the licenses you'll actually see in the wild, what they require, and when to pick which. When you're ready, the License Generator builds a ready-to-commit LICENSE file from your choices.

The two big families

Every open-source license sits on a spectrum between two ideas:

• Permissive — "Do almost anything, just keep my copyright notice." You can use the code in proprietary software, modify it, redistribute it, sell it. The only real obligation is attribution.
• Copyleft — "If you distribute a modified version, you have to share your modifications under the same license." Copyleft ensures improvements to the code stay open.

Within those families, licenses vary in how strong the copyleft is (just the file, just the library, or the entire application), and whether they include extra clauses like patent grants or naming restrictions.

Before and after: what your repo looks like licensed vs not

A repository with no LICENSE file is, by default, all rights reserved. That means:

• Nobody has explicit permission to copy, modify, or redistribute your code — even if it's public on GitHub.
• Companies with policies against using unlicensed code (very common) can't touch it.
• Well-meaning contributors are unsure whether their pull requests would even be usable.

Adding a single LICENSE file with the right text flips the default to "yes, with these terms," and your repo is suddenly adoption-ready.

The licenses you actually encounter

MIT — the permissive default

MIT License

Copyright (c) <year> <copyright holders>

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, ...

What it requires: Keep the copyright notice and license text in copies or substantial portions of the software.

What it allows: Almost everything — commercial use, modification, distribution, sublicensing, private use, even selling the code itself.

When to pick it: Libraries, frameworks, tools, sample code, anything you want adopted as widely as possible. MIT is what React, Rails, jQuery, and a majority of npm use.

ISC — functionally identical, simpler text

ISC is the spiritual successor to the original BSD licenses. The text is shorter and simpler than MIT, but the practical effect is essentially the same: keep the copyright notice, do whatever you want. Pick ISC if you prefer the wording — many projects (including Node.js itself) use it for that reason.

Apache 2.0 — permissive with an explicit patent grant

Apache 2.0 is MIT plus two important additions:

• Patent grant — anyone using the code gets a license to use the patents held by contributors that are necessarily infringed by the code.
• Patent retaliation clause — if you sue anyone for patent infringement related to the code, your patent grant terminates.

When to pick it: When you or your contributors might hold patents the code reads on, and you want to make that patent license explicit. Large companies and corporate-backed projects (Kubernetes, Android, Swift) tend to prefer Apache for this reason.

BSD 2-Clause and 3-Clause

Older permissive licenses, still common in C and systems-level code. BSD-2 is essentially MIT under different wording. BSD-3 adds a "non-endorsement" clause: your contributors' names can't be used to endorse derived works without permission. Both are reasonable picks for systems code where tradition matters.

MPL 2.0 — file-level copyleft (weak copyleft)

MPL says: if you modify the MPL-licensed files, you must publish your modifications under MPL. But you can freely combine those files with proprietary code in a larger application.

When to pick it: When you want improvements to your code to stay open, but you don't want to force the entire application built on top of your library to be open. Firefox is the canonical example.

LGPL — library-level copyleft

LGPL is one step stronger: dynamic linking against your library is fine in proprietary apps, but static linking or substantial modifications require the modifications to your library to be open. Most projects that need a library-style copyleft now use MPL 2.0 because LGPL's distinction between static and dynamic linking is awkward in modern bundlers.

GPL 2.0 and GPL 3.0 — strong copyleft

GPL says: any derivative work distributed to others must also be GPL. In practice, that means an application that links GPL code typically has to be GPL too.

• GPL 2.0 — the classic. Used by the Linux kernel, WordPress, and many core tools.
• GPL 3.0 — adds explicit patent provisions, anti-Tivoization clauses, and an AGPL companion that closes the "service provider loophole" (running the software as a network service without distributing it).

When to pick it: When your project's primary goal is user freedom and you want derivatives to remain free. Pick AGPL 3.0 specifically if you want to prevent large companies from hosting your code as a service without contributing back.

Permissive vs copyleft: the practical decision

Ask three questions:

1. Do I want competitors to be able to use this code in proprietary products?

   • Yes → MIT, ISC, Apache 2.0, or BSD.
   • No, I want derivatives to stay open → GPL, AGPL, MPL, or LGPL.

2. Am I (or might contributors be) holding patents related to the code?

   • Yes → Apache 2.0, for its explicit patent grant.

3. Is this a library used by other code, or a standalone application?

   • Library used by anything → MIT or Apache (or MPL if you want file-level copyleft).
   • Standalone application → GPL or AGPL if copyleft; MIT or Apache otherwise.

If you don't have a strong preference, MIT is a safe default for a library, Apache 2.0 is a safe default if patents are in scope, and AGPL 3.0 is a safe default if you're building a network service and care about derivative work staying open.

Common mistakes

• No license file at all. This is the worst option: nobody can safely use your code.
• A LICENSE file that doesn't match the license declared in package.json / README. CAs and package registries sometimes check both; a mismatch causes friction.
• Adding a CLA without realizing it changes the license terms. Contributor License Agreements are a separate discussion; they're orthogonal to the project license itself.
• Using GPL for a UI component library. Companies building proprietary apps will simply not adopt it; you'll get less reach than MIT would have given you.
• Picking AGPL for a SaaS without telling anyone. Surprise copyleft is the fastest way to lose contributors.

Everything stays in your browser

The License Generator runs 100% client-side. You pick the license, fill in the year and copyright holder, and it produces the exact LICENSE text — no signup, no upload, no account.

Next: actually ship the file

Choosing a license is the decision; producing the file is one click. Open the License Generator, pick the license that matches the reasoning above, and commit the resulting LICENSE file at the root of your repository so anyone landing on the project can see it immediately.