Open source licenses explained: MIT, Apache, and GPL compared

An open source license tells other developers what they may and may not do with your code. It decides whether someone can use your library in a commercial product, modify it, and redistribute their changes — and under what conditions. This guide explains the two big families of open source licenses (permissive and copyleft), compares the most common ones (MIT, BSD, Apache 2.0, GPL, LGPL, AGPL), and gives practical guidance for picking a license for your own project.

What an open source license is and why it matters

Code you write is protected by copyright by default. Without a license, nobody has explicit permission to copy, modify, or distribute it — "all rights reserved" applies even to code posted publicly on GitHub. An open source license is a legal grant of rights that tells others exactly what they are allowed to do. The Open Source Definition, maintained by the Open Source Initiative, lists the criteria a license must meet to be called "open source", including free redistribution, access to source code, and permission to create derivative works.

Choosing a license matters because it is difficult (and often impossible) to change after you have already published your code and others have relied on it. Once code is released under a license, you cannot retroactively revoke those rights, and you cannot later relicense code that others have contributed without getting their permission.

Permissive licenses: MIT, BSD, and Apache

Permissive licenses impose the fewest restrictions. They let anyone use, modify, copy, and distribute the code — even in proprietary, closed-source commercial products — as long as they keep the copyright notice. They are the most common licenses for libraries and open source components because they maximize adoption.

MIT license

The MIT License is a short, permissive license originating at the Massachusetts Institute of Technology in the late 1980s. It allows reuse within proprietary software provided that all copies of the software, or its substantial portions, include the copyright notice and the license text. It has no copyleft requirement and no strong patent provisions, which makes it the simplest permissive option — and the single most popular open source license on GitHub. Many projects, including popular libraries and tools, use it because it imposes the fewest obligations.

BSD licenses

BSD licenses are permissive licenses closely related to MIT. The 2-clause BSD license is functionally similar to MIT. The 3-clause version adds a non-endorsement clause: it prevents your name from being used to promote derivative products without permission, and it also forbids implying endorsement by the original authors. BSD licenses have no copyleft and no explicit patent grant, which is the main practical difference from Apache 2.0.

Apache License 2.0

The Apache License 2.0 is a permissive license written by the Apache Software Foundation and first released in January 2004. Like MIT, it allows use, modification, and distribution with few restrictions. Its distinguishing feature is an explicit patent grant: contributors grant patent rights to users for the code they contribute, and this grant terminates if a user sues someone over a patent related to the code (a patent retaliation clause). Apache 2.0 also requires preserving the copyright notice and a NOTICE file when one exists. This patent clause is why many companies prefer Apache 2.0 for infrastructure projects they want used broadly in industry.

Copyleft licenses: GPL, LGPL, and AGPL

Copyleft licenses go further than permissive ones. They require that derivative works — code derived from or incorporating the licensed code — be distributed under the same license, with source code made available. The idea, defended by the Free Software Foundation, is to keep software and its improvements free and open. The trigger is redistribution: if you distribute a derivative work, the copyleft applies. Purely internal or server-side use that is never distributed to others generally does not trigger it.

GNU General Public License (GPL)

The GPL is the canonical strong-copyleft license, written by Richard Stallman and the Free Software Foundation. Under the GPL, if you distribute a derivative work, you must offer the whole work under the GPL and make the source code available to recipients. The Linux kernel is a famous GPL project. Because the GPL propagates to the whole derivative, a project that links GPL code typically has to be released as GPL too.

GPL version 3 (2007) adds explicit patent provisions and anti-tivoization clauses that restrict hardware makers from blocking users from running modified versions of the software. GPL version 2 famously dropped the advertising clause that had made the original BSD license incompatible with GPL.

GNU Lesser General Public License (LGPL)

The LGPL is a "weak copyleft" license designed mainly for libraries. It lets programs dynamically link against the library without forcing the program itself to be released under the LGPL. Modifications to the library itself must stay under the LGPL, but your own application code that merely uses the library can remain proprietary.

GNU Affero General Public License (AGPL)

The AGPL extends the GPL's copyleft to network use. It closes what is called the "service provider loophole": under the GPL, a company running modified software only as a network service (without distributing the binary) could avoid releasing its source. The AGPL requires that users who interact with the software over a network also be offered the source code, making it common for SaaS-related projects to avoid AGPL code.

Permissive vs copyleft: key differences

Compatibility and mixing licenses

License compatibility decides whether code under two licenses can be combined. A general rule: more permissive code can flow into a more restrictive project, but not the reverse. For example, you can include MIT-licensed code inside a GPL project, but you cannot take GPL code and redistribute it under an MIT license, because that would remove the copyleft obligations that GPL recipients rely on.

Specific notes: the Apache License 2.0 is compatible with GPL version 3 — code under Apache 2.0 can be combined with GPLv3 code as long as the combined work is licensed under GPLv3. The Free Software Foundation considers Apache 2.0 incompatible with GPL versions 1 and 2.

Practical guidance for choosing a license

Pick MIT if you want maximum adoption and simplicity, and you do not care whether companies build proprietary products on your code. It is the best default for libraries, npm packages, and small projects.

Pick Apache 2.0 if everything MIT offers matters to you, plus you want an explicit patent grant that protects both you and commercial users. It is a common choice for infrastructure, cloud, and large open source projects.

Pick GPL if your goal is to ensure that derivative works stay open source, and you are comfortable that proprietary software will generally avoid linking your code.

Pick LGPL for libraries where you want the library's improvements to stay open but you still want to be usable from proprietary applications.

Pick AGPL if you want the strongest protection — closing the network loophole — and accept that most SaaS businesses will avoid your code.

If you are unsure, start with MIT: it is permissive, simple, widely understood, and easiest to change away from later if your needs evolve. Whatever you choose, add a LICENSE file at the root of the repository — without one, your code is effectively "all rights reserved".

FAQ

What is the difference between permissive and copyleft licenses?

Permissive licenses (MIT, BSD, Apache 2.0) let anyone use, modify, and distribute the code, including in proprietary products, as long as they keep the copyright notice. Copyleft licenses (GPL, AGPL) require that derivative works you distribute be released under the same license with source code made available, so the software and its improvements stay open.

Is Apache 2.0 more permissive than MIT?

Both are permissive and allow similar reuse, but Apache 2.0 adds an explicit patent grant (with a retaliation clause) and a NOTICE file requirement. MIT is shorter and imposes the fewest obligations. Neither has copyleft. In practice Apache 2.0 is chosen when patent clarity matters to commercial users.

Do I have to pay to use open source software?

No. Open source licenses grant free rights to use, modify, and distribute code. Licenses sometimes add obligations — like keeping copyright notices or releasing modified source under the same license — but none require payment. Some companies sell commercial licenses or support separately, but that is on top of the open source license.

Can I put GPL code in my proprietary project?

Generally no. If you distribute a project that incorporates GPL code, the whole derivative work must be offered under the GPL with source, so you would lose the ability to keep it proprietary. Purely internal use that is never distributed may not trigger the copyleft, but shipping it to customers or users will.

What happens if I publish code without a license?

Without a license, the default rule is "all rights reserved" — nobody has explicit permission to copy, modify, or distribute your code, even though it is public. If you want others to use it, you must add an explicit license file. If you accept contributions, you also need a way to ensure those contributors grant the same rights (for example a contributor license agreement or a clear inbound license).