What is Open-Source Licenses?
Legal terms that let anyone use, modify and redistribute software. The main families are permissive (MIT, BSD, Apache-2.0) and copyleft (GPL, LGPL, AGPL, MPL), which differ in whether you must share your changes and under what terms.
Definition
An open-source license is the legal grant that turns published code into software others may use, change and share. Without a license, code is all rights reserved by default, even on a public GitHub repository. The Open Source Initiative (OSI) maintains a list of licenses that meet its Open Source Definition; MIT, Apache-2.0, GPL-2.0, GPL-3.0, LGPL, AGPL-3.0, MPL-2.0, BSD-2-Clause and BSD-3-Clause are all on it. Permissive licenses ask very little: keep the copyright and license notice, and accept that there is no warranty. You can use the code in closed-source, commercial products. MIT and the BSD licenses are short and simple. BSD-3-Clause adds a clause forbidding use of the authors' names to endorse derived products. Apache-2.0 is longer and adds an explicit patent grant from contributors, a requirement to state significant changes, and a clause that it grants no trademark rights. Copyleft licenses require that when you distribute the software, or a modified version, you do so under the same license with source available. The GPL (versions 2 and 3) applies to the whole combined program, which is why it is called strong copyleft. The LGPL is weaker: it is designed for libraries, so proprietary programs can use an LGPL library while changes to the library itself stay LGPL. The AGPL-3.0 closes the "SaaS loophole": if you modify AGPL software and let users interact with it over a network, those users must be able to get the source of your modified version. MPL-2.0 is file-level copyleft: modified MPL files stay MPL, but you can combine them with proprietary files in a larger work. Obligations at a glance (based on choosealicense.com's comparison): MIT: notice required; no source disclosure; no same-license rule; no explicit patent grant. BSD-2/BSD-3: notice required; no source disclosure; no same-license rule; BSD-3 forbids endorsement using authors' names. Apache-2.0: notice required; state changes; explicit patent grant; no trademark rights; no source disclosure. MPL-2.0: notice required; disclose source of modified MPL files; same license per file; patent grant. LGPL-3.0: notice required; disclose source of the library and changes; same license for the library; state changes; patent grant. GPL-3.0: notice required; disclose full source when distributing; same license for the whole work; state changes; patent grant. AGPL-3.0: everything in GPL-3.0, plus network use counts as distribution. Compatibility matters when you combine code. Apache-2.0 code can be included in GPLv3 projects, but the FSF does not consider Apache-2.0 compatible with GPLv2. MPL-2.0 code can be combined with GPL code under conditions set out in the MPL FAQ, unless it is marked "Incompatible With Secondary Licenses". Source-available licenses are not open source. The Server Side Public License (SSPL), the Business Source License (BSL or BUSL) and similar licenses publish the code but restrict how it may be used, typically banning competing hosted services. They are not on the OSI-approved list, and the OSI has stated that the SSPL is not an open-source license because it restricts fields of use.
When to Use Open-Source Licenses
Use SPDX identifiers (MIT, Apache-2.0, GPL-3.0-only, GPL-3.0-or-later, LGPL-3.0-only, AGPL-3.0-only, MPL-2.0, BSD-3-Clause) in package metadata and file headers. They are unambiguous and understood by license scanners. Choosing a license for your own project: - Want maximum adoption, including in commercial closed-source products: MIT or BSD-3-Clause. - Want permissive terms plus explicit patent protection, common for company-backed projects: Apache-2.0. - Want improvements to come back to the community but allow use in proprietary larger works: MPL-2.0 (file level) or LGPL (library level). - Want every distributed derivative to stay open: GPL-3.0. - Building server software and want hosted forks to share their changes: AGPL-3.0. Using open-source dependencies in a product: - Permissive dependencies: keep their license and copyright notices in your distribution (a NOTICE or third-party licenses file). Apache-2.0 also requires passing on its NOTICE file contents. - GPL dependencies: if you distribute a binary that includes GPL code, the combined work must be offered under the GPL with source. Running GPL software only on your own servers is not distribution under GPL; under the AGPL, offering it to network users is covered. - LGPL dependencies: generally fine in proprietary apps when used as a separate, replaceable library, but changes to the library must be released. - Run a license scanner in CI and keep an allow list. Treat AGPL, SSPL and BSL as needing legal review. This page is general information, not legal advice; for commercial distribution decisions, have counsel review your specific case.
Open-Source Licenses in Practice
- MIT: widely used across JavaScript packages; React and Node.js are MIT-licensed.
- Apache-2.0: Kubernetes and Apache Software Foundation projects, chosen partly for its explicit patent grant.
- GPL-2.0: the Linux kernel (GPL-2.0 only, with a syscall note), the classic example of strong copyleft.
- LGPL: the GNU C Library (glibc), licensed under the LGPL (version 2 or any later version, per its project page), which proprietary programs routinely link against.
- MPL-2.0: most Mozilla software projects, and OpenTofu, the community fork of Terraform created after HashiCorp moved Terraform to the source-available BSL.
- AGPL-3.0: self-hosted SaaS-style apps such as Plane, the open-source project management tool, so hosted modified versions must share source.
Common Mistakes
- Publishing code without a LICENSE file and assuming it is open source. With no license, others have no right to use or modify it.
- Calling SSPL or BSL projects open source. They are source-available and not OSI-approved.
- Assuming AGPL only matters if you distribute binaries. Letting users interact with modified AGPL software over a network triggers the source-offer requirement.
- Mixing Apache-2.0 code into a GPLv2-only project. The FSF considers them incompatible; GPLv3 is compatible.
- Stripping copyright and license notices from permissive code. MIT, BSD and Apache-2.0 all require keeping them.