An open source licenses comparison really comes down to one axis: how many obligations attach when you use and distribute the code, ranging from almost none (permissive) to significant sharing requirements (copyleft). Every open-source license grants you the right to use, modify, and distribute the software; what separates them is the conditions. Get the comparison of open source licenses wrong and you can face a legal obligation to publish your own source code, or a compatibility conflict that makes two components impossible to ship together. This is a practical walk through the common open source licenses, grouped by how demanding they are.
Two families: permissive and copyleft
Before comparing individual licenses, understand the two camps, because that division explains almost everything.
Permissive licenses ask very little. Use the code however you like, including in closed-source commercial products, as long as you preserve the copyright notice and license text. They do not require you to share your own changes.
Copyleft licenses require that derivative works be distributed under the same license, which in practice means sharing your source code under those terms. The intent is to keep the code and its descendants open. Copyleft comes in strengths: strong (affects the whole combined work), weak (affects only the licensed component), and network (triggers even when you provide the software as a service without distributing it).
Which family a component belongs to matters far more than the specific license name.
The permissive licenses
These are the different open source licenses you will meet most often in modern dependency trees, and the easiest to comply with.
MIT License. The most popular license on the internet, and about as simple as it gets. Do almost anything, keep the copyright and permission notice. No patent clause, no copyleft. Its brevity is its appeal.
Apache License 2.0. Permissive like MIT, with two important additions. It includes an explicit patent grant, contributors grant you a license to any patents their contribution implicates, which gives commercial users meaningful protection. It also requires you to state significant changes and preserve NOTICE files. For companies, the patent grant makes Apache 2.0 the safer permissive choice.
BSD licenses (2-Clause and 3-Clause). Very close to MIT in spirit. The 3-Clause variant adds a non-endorsement clause preventing use of the project's name to promote your derived product. Functionally, treat them like MIT.
Among permissive open source licenses, the practical ranking for commercial use is Apache 2.0 (permissive plus patent protection), then MIT and BSD (permissive, no patent language). All three let you build proprietary products on top without sharing your source.
The copyleft licenses
Here the obligations get real, and here is where license reviews earn their keep.
GPL (v2 and v3). Strong copyleft. If you distribute software that incorporates GPL code, the combined work must be released under the GPL, source included. This is the license that can compel you to open-source your own code. GPLv3 modernized v2 with explicit patent terms and anti-tivoization provisions, and GPLv2 and GPLv3 are not automatically compatible with each other, which trips up combinations.
LGPL (Lesser GPL). Weak copyleft, designed for libraries. You can link an LGPL library from proprietary software without the copyleft reaching your code, provided you allow users to replace the library (typically by dynamic linking). Modify the LGPL library itself, though, and those changes fall under the LGPL.
MPL 2.0 (Mozilla Public License). File-level copyleft, a middle ground. Changes to MPL-licensed files must be shared under the MPL, but you can combine those files with proprietary code in a larger work without the copyleft spreading to your files. A reasonable compromise when you want some sharing without full GPL reach.
AGPL (Affero GPL). Network copyleft, the strongest in practical terms for web software. It closes the "SaaS loophole": if you run modified AGPL code as a network service, you must offer the source to users of that service, even though you never distributed a binary. Many companies ban AGPL dependencies outright because of this reach, so flag it wherever it appears.
Why compatibility, not just choice, matters
The trap in any comparison of open source licenses is assuming you only need to pick your own project's license. You also inherit obligations from every dependency, and some licenses cannot coexist. You cannot combine GPL code into a project you intend to keep proprietary. Some permissive-to-copyleft directions are one-way: you can pull MIT code into a GPL project, but not the reverse. And the transitive dependencies, the ones several layers down that you never explicitly chose, carry their own licenses that bind you just the same.
This is exactly why a manual audit falls short. You would have to read the license of every direct and indirect component, and that set changes with every dependency update. Automated tooling that inventories your dependency tree and reports each component's license, flagging copyleft or policy-violating ones, is the only approach that scales. An SCA tool does this alongside vulnerability scanning, since the same dependency inventory answers both "is this vulnerable?" and "what license does it carry?" For a fuller treatment of building a license policy, the Academy covers it.
Choosing a license for your own project
If you are releasing code and want maximum adoption with minimum friction, a permissive license fits, MIT for simplicity, Apache 2.0 if you want patent protection. If you want to ensure derivatives stay open, choose copyleft matched to your goal: GPL for applications, LGPL for libraries you want usable in proprietary software, AGPL if network use should trigger sharing. The right choice follows from what you want to happen when someone else builds on your work.
FAQ
What is the difference between permissive and copyleft licenses?
Permissive licenses (MIT, Apache 2.0, BSD) let you use and modify the code, including in closed-source products, as long as you preserve notices. Copyleft licenses (GPL, LGPL, MPL, AGPL) require derivative works to be shared under the same license, which usually means publishing your source.
Which open source license is best for commercial use?
Among permissive options, Apache 2.0 is often preferred for commercial use because it adds an explicit patent grant on top of permissive terms. MIT and BSD are equally permissive but lack patent language. All three allow building proprietary products without sharing source.
Why is AGPL treated more cautiously than GPL?
AGPL extends copyleft to network use. If you run modified AGPL code as a hosted service, you must offer users the source, even without distributing a binary. Because most GPL obligations trigger only on distribution, AGPL reaches situations GPL does not, so many organizations restrict it.
How do I know what licenses my dependencies use?
Inventory your full dependency tree, including transitive dependencies, since those carry obligations too. Manual review does not scale and goes stale with every update, so use software composition analysis to report each component's license automatically and flag ones that violate your policy.