The most popular open source licenses are MIT, Apache 2.0, GPL-2.0 and GPL-3.0, the BSD family, MPL-2.0, LGPL, and AGPL-3.0, and they split cleanly into two philosophies: permissive licenses that ask almost nothing, and copyleft licenses that require sharing changes when you distribute. If you internalize that split, every license question becomes tractable. This is a working comparison of open source licenses for engineers who need to make decisions, not a legal treatise.
GitHub's own license data has shown the same picture for a decade: MIT leads by a wide margin, Apache 2.0 second among permissive options, the GPL family leading copyleft. Those seven or eight texts cover the overwhelming majority of packages your dependency tree will ever contain.
The Two Families
Permissive (MIT, Apache 2.0, BSD, ISC): use, modify, redistribute, commercialize, keep your changes private. The only conditions are attribution-shaped: keep the copyright notice and license text, and for Apache 2.0, propagate the NOTICE file and state changes.
Copyleft (GPL, AGPL, LGPL, MPL, EPL): the same freedoms, plus a reciprocity condition. Distribute the software or a derivative and you must offer the source under the same license. The licenses differ mainly in how far that condition reaches, from a single file (MPL) to your entire combined work (GPL) to software merely accessed over a network (AGPL).
MIT: The Default
Around 170 words. Permission for everything, one condition: preserve the notice. No patent language, no NOTICE mechanism, compatible with virtually everything including GPLv2. When a maintainer says "I just want people to use this," MIT is the standard answer, which is why an enormous share of npm and PyPI ships under it.
The gap to be aware of is patents. MIT grants "permission to deal in the Software" but never says the word patent. For most web libraries this is academic; for codecs, ML runtimes, or anything near standards-essential patents, it is not.
Apache 2.0: Permissive with Armor
Apache 2.0 keeps the permissive philosophy and adds legal machinery: an express patent grant from every contributor, termination of that grant for patent aggressors, explicit contribution terms, and the NOTICE file. This is why foundations and enterprises drifting large infrastructure projects into the open (Kubernetes, Airflow, Kafka, Swift) overwhelmingly chose it.
Costs: slightly heavier compliance (NOTICE propagation, change statements) and GPLv2 incompatibility. We dig into the practical differences in Apache 2.0 and MIT commercial use.
BSD 2-Clause and 3-Clause: The Elders
Functionally close to MIT. BSD 2-Clause is essentially MIT with different phrasing; BSD 3-Clause adds a clause forbidding use of contributors' names to endorse derived products. You will meet BSD constantly in foundational C libraries, Python's standard-library-adjacent ecosystem, and Go tooling (Go itself is BSD 3-Clause). ISC, the license of much OpenBSD-adjacent software and many npm packages, is another MIT-equivalent worth recognizing on sight.
GPL-2.0 and GPL-3.0: Strong Copyleft
The GPL conditions distribution of a combined work on releasing the whole work's source under the GPL. That makes GPL libraries effectively unusable inside proprietary distributed products, while leaving three big use cases untouched:
- Internal use. Running GPL software in-house, unmodified or modified, triggers nothing. Distribution is the trigger.
- Separate processes. Invoking a GPL tool as a subprocess (calling
gitfrom your app) is generally fine; linking its code into your binary is not. - Being the product. Linux (GPL-2.0) and the GNU userland power practically everything, consumed as an operating system rather than linked code.
GPL-3.0 added patent provisions, anti-tivoization terms, and Apache 2.0 compatibility. Plenty of major projects deliberately stayed on GPL-2.0, Linux most famously.
LGPL, MPL-2.0, and AGPL-3.0: The Scoped and the Strict
LGPL scopes copyleft to the library itself: proprietary applications may link it if users can swap in a modified version (dynamic linking is the easy path). Historically common for C libraries like glibc and FFmpeg components.
MPL-2.0 is file-level copyleft: modify an MPL file, share that file's source; the rest of your work is untouched. It is the pragmatic middle ground, used by Firefox and much of HashiCorp's ecosystem before their 2023 move of flagship projects to the source-available BSL.
AGPL-3.0 extends GPL obligations to network use: run a modified AGPL program as a service and you must offer users its source. Written to close the SaaS loophole, it is the license most commonly banned outright in corporate policies, less because compliance is impossible and more because the legal analysis is expensive. MongoDB's pre-SSPL server and Grafana are the projects that put AGPL on most companies' radar.
Choosing and Enforcing a Policy
For maintainers choosing a license: MIT for maximum adoption, Apache 2.0 when patent protection matters, GPL or AGPL when you want improvements to stay open or want to steer commercial users toward a paid license.
For companies consuming open source, the license question is a dependency-graph question. Direct dependencies are the visible tip; the common open source licenses actually governing your product arrive transitively, five levels down, in packages nobody chose deliberately. A three-tier policy (allow permissive, review weak copyleft, escalate strong and network copyleft) only works if it is enforced automatically. SBOM-driven software composition analysis evaluates every component's declared license on each build and blocks the surprises at pull-request time, the same control point you already use for vulnerabilities. If you are budgeting for that kind of tooling, our pricing page shows where license policy checks land in a typical rollout.
FAQ
What are the most popular open source licenses?
MIT is the most widely used, followed by Apache 2.0 among permissive licenses and GPL-2.0/GPL-3.0 among copyleft licenses. BSD 2-Clause and 3-Clause, ISC, MPL-2.0, LGPL, and AGPL-3.0 round out the set that covers most real dependency trees.
What is the difference between permissive and copyleft licenses?
Permissive licenses (MIT, Apache 2.0, BSD) require little more than attribution and allow closed-source commercial use. Copyleft licenses (GPL, AGPL, LGPL, MPL) additionally require you to share source under the same license when you distribute the software or derivatives, with each license scoping that obligation differently.
Can I mix code under different open source licenses?
Often, but compatibility is directional. MIT and BSD code can flow into Apache 2.0 or GPL projects; Apache 2.0 can flow into GPL-3.0 but not GPL-2.0; GPL code cannot flow into permissive or proprietary projects. When licenses conflict, the combined work usually cannot be distributed at all.
Which open source license should I avoid in commercial products?
None need blanket avoidance, but AGPL-3.0 and strong GPL warrant legal review before inclusion in anything you distribute or offer as a service. The riskiest case is not a famous license, it is a dependency with no license at all, which defaults to all rights reserved.