I've watched developers spend ten minutes agonising over which font to use in their README and then pick a license in thirty seconds without really understanding what it means. License choice is one of those invisible decisions that has real long-term consequences, so let me give you the plain-language version of the three most common options.
MIT License: Maximum Permissiveness
MIT is the most popular open source license on GitHub and for good reason: it's essentially "do whatever you want with this, just keep the copyright notice." Commercial use? Allowed. Modification? Allowed. Distribution? Allowed. Closed-source distribution? Also allowed. You can take MIT-licensed code and ship it in a proprietary product without sharing any of your source code.
Use MIT when: You want maximum adoption. You want companies to be able to use your project without legal hesitation. You don't care whether improvements made downstream are shared back.
The trade-off: Someone can take your project, improve it significantly, and ship those improvements in a closed-source product without giving anything back. If that bothers you, MIT is the wrong choice.
Apache 2.0: MIT Plus Patent Protection
Apache 2.0 has the same permissiveness as MIT with one significant addition: it includes an explicit patent licence. Contributors to Apache-licensed projects grant users a licence to any patents that cover the contribution. This matters primarily in enterprise contexts where patent exposure is a legal concern.
Use Apache 2.0 when: Your project might involve technology where patents are a concern, or when you want corporate adoption and corporations' legal teams need explicit patent protection to approve using your project internally.
The practical difference from MIT for most developers is minimal. Google, Apple, and most large tech companies have internal policies that specifically allow Apache 2.0 software, partly because of the patent clause.
GPL (and LGPL, AGPL): Copyleft
GPL is "you can use this freely, but if you distribute software that includes it, you must release that software under the same license." This is the copyleft principle. It's designed to ensure that improvements to the software remain open source.
GPL (strong copyleft): Any software that includes GPL code and is distributed must itself be GPL. This makes it unsuitable for use in most proprietary products, which is intentional.
LGPL (weak copyleft): Allows linking to the library without requiring the linking software to be GPL. Used for libraries where you want copyleft but still want commercial software to be able to use your library.
AGPL: Like GPL but closes the "SaaS loophole" — if you run AGPL software as a service over a network, you must release the source. Redis and MongoDB briefly used AGPL-based licences to prevent cloud providers from offering managed versions without contributing back.
Use GPL when: You actively want to prevent your project from being used in proprietary software. You want improvements to stay open. Linux, Git, and gcc are GPL.
The Practical Decision
For most developer tools and libraries: MIT or Apache 2.0. If you're not sure which, MIT is simpler. If enterprise adoption is important, Apache 2.0's explicit patent grant can help.
For projects where you specifically want to prevent proprietary use and ensure the open source ecosystem benefits from improvements: GPL or AGPL.
The worst choice is no license at all. Without a license, the default copyright law applies: nobody can legally use, modify, or distribute your code. An unlicensed project is not open source regardless of whether it's public on GitHub.
