Why Your Choice of License Actually Matters

Most developers treat licensing as a checkbox — paste in an MIT license, push to GitHub, move on. But the license you choose determines who can use your code, under what conditions, and whether they have to give back. Getting it wrong can mean your library never gets adopted, or conversely, that a corporation can ship your work in proprietary products with zero attribution.

This guide covers the four licenses you'll encounter most often in the open-source world, with concrete advice on when to use each.

The Permissive Camp

MIT License

The MIT License is the shortest and most permissive widely-used license. The only requirement it places on users is that they preserve the copyright notice and license text in their distributions. That's it. They can use your code in proprietary software, modify it without publishing changes, and sublicense it.

Use MIT when: you want maximum adoption. Libraries, utilities, and tools that you want embedded in commercial products or other open-source projects without friction benefit enormously from MIT.

Apache 2.0

Apache 2.0 is also permissive, but it adds two important clauses MIT lacks:

  • Patent grant — contributors explicitly grant users a license to any patents they hold that cover the code. This matters more than it sounds for corporate environments.
  • NOTICE file — distributions must preserve a NOTICE file with attribution.

Use Apache 2.0 when: your project is likely to be used in enterprise or corporate contexts where patent exposure is a real concern, or when you want the permissiveness of MIT with slightly stronger contributor accountability.

The Copyleft Camp

GNU GPL v3 (and v2)

The GPL is the classic copyleft license. It requires that any software distributed that incorporates GPL-licensed code must also be distributed under the GPL, with source code available. This is the "share alike" principle — it ensures improvements stay open.

GPL v3 adds protections against tivoization (using GPL software in hardware that prevents users from running modified versions) and strengthens patent and anti-DRM clauses.

Use GPL when: you want to ensure your code and all derivatives remain free and open. It's ideal for end-user applications (operating systems, desktop apps, command-line tools) where you want to build an open ecosystem. Linux, Git, and GCC all use the GPL family.

GNU LGPL v3

The Lesser GPL is a middle ground: it applies copyleft to modifications of the library itself, but allows linking from proprietary software. This makes it popular for libraries where GPL would otherwise lock out commercial users.

Use LGPL when: you're building a library and want to keep modifications open, but don't want to prevent commercial applications from using it.

Quick Comparison Table

License Commercial Use Must Open Source Changes Patent Grant
MIT ✅ Yes ❌ No ❌ No
Apache 2.0 ✅ Yes ❌ No ✅ Yes
LGPL v3 ✅ Yes (linking) ✅ Library changes only ✅ Yes
GPL v3 ⚠️ GPLv3 only ✅ Yes ✅ Yes

The Practical Decision Framework

  1. Is it a library? → MIT or Apache 2.0 for max adoption; LGPL if you want modifications to stay open.
  2. Is it an application? → GPL v3 to keep the whole ecosystem open.
  3. Are you targeting enterprise? → Apache 2.0 for the patent grant.
  4. Do you just want credit and no fuss? → MIT.

When in doubt, choosealicense.com (maintained by GitHub) walks you through the decision interactively.