Understanding Licenses
Why Licenses Exist
Software is automatically protected by copyright the moment it is written. In most jurisdictions, the author holds exclusive rights to copy, modify, distribute, and display the work. Without a license, nobody else can legally do any of these things — even if the source code is published on GitHub for the world to read.
A license is a legal grant of permission. It says: "I, the copyright holder, allow you to do X, Y, and Z with this software, under these conditions." Different licenses grant different permissions and impose different conditions. Understanding the spectrum of licenses is essential for anyone who uses, contributes to, or publishes open source software.
If you skip this topic and accidentally use a GPL library in your proprietary product, you may be legally required to open source your entire application. This has happened to companies. It is not theoretical.
The License Spectrum
Licenses range from maximally permissive ("do whatever you want") to strongly copyleft ("your modifications must also be open source"). Understanding where a license falls on this spectrum tells you what you can and cannot do with the software.
MORE PERMISSIVE MORE RESTRICTIVE
| |
MIT BSD Apache 2.0 LGPL MPL 2.0 GPL v3 AGPL v3
| | | | | | |
Do Do Do whatever Copyleft Copyleft Copyleft Copyleft
what- what- + patent on the on the on the on the
ever ever grant library file program program +
only only network
use
Permissive Licenses
Permissive licenses impose minimal restrictions. They allow you to use, modify, and distribute the software for any purpose, including incorporating it into proprietary software. The main requirement is preserving the copyright notice.
MIT License
The MIT license is the most popular open source license, used by React, Vue, Rails, jQuery, Express, and thousands of other projects. It is 171 words long and says essentially:
- You can use this software for any purpose
- You can modify it
- You can distribute it
- You can incorporate it into proprietary software
- You must include the copyright notice and the license text
That is it. No patent clauses, no restrictions on commercial use, no copyleft obligations. The MIT license maximizes adoption because it minimizes friction. A company's legal team can approve MIT dependencies in minutes.
The downside: the MIT license offers no patent protection. If a contributor holds a patent that covers the code they contributed, the MIT license does not prevent them from suing users for patent infringement. In practice, this has not been a significant issue for most projects, but it is a gap.
Apache License 2.0
The Apache License 2.0 is used by Kubernetes, TensorFlow, Android (AOSP), Kafka, and most Apache Software Foundation projects. It is similar to MIT but adds two important provisions:
Patent grant. Contributors automatically grant users a royalty-free patent license covering any patents that are necessarily infringed by the contributed code. This means a contributor cannot contribute code and then sue users for patent infringement. This protection is why many corporate legal teams prefer Apache 2.0 over MIT.
Patent retaliation. If you sue the licensor or any contributor for patent infringement related to the software, your license (including the patent grant) is automatically terminated. This discourages patent litigation against open source projects.
The Apache License 2.0 is longer than MIT (about 1,500 words) but still permissive. You can use Apache 2.0 code in proprietary software as long as you include the copyright notice, the license text, and a NOTICE file if one exists.
BSD Licenses
The BSD license family includes the 2-clause BSD (FreeBSD license) and the 3-clause BSD (original BSD license). They are functionally similar to MIT:
- 2-clause BSD: Same as MIT. Use, modify, distribute, keep the copyright notice.
- 3-clause BSD: Adds a "no endorsement" clause — you cannot use the project's name or contributors' names to promote derived products without permission.
PostgreSQL uses its own license (the PostgreSQL License), which is essentially identical to the 2-clause BSD license. FreeBSD, NetBSD, and OpenBSD use BSD licenses.
The practical difference between MIT, Apache 2.0, and BSD is small for most users. The choice often comes down to ecosystem convention (Rust projects tend toward MIT or Apache 2.0; BSD projects use BSD licenses) and whether patent protection matters.
Copyleft Licenses
Copyleft licenses require that derivative works also be distributed under the same license. The idea is that if you benefit from open source software, your improvements must also benefit the community. This is the philosophical core of the free software movement.
GPL v3 (GNU General Public License)
The GPL v3 is the strongest widely-used copyleft license. It requires that:
- If you distribute a modified version of GPL software, you must distribute the source code of your modifications under the GPL
- If you link GPL code into your program and distribute it, the entire program must be GPL
- You must provide installation instructions for modified versions (the "anti-Tivoization" clause, which prevents hardware manufacturers from locking down software on their devices)
The GPL is used by the Linux kernel (GPL v2), GCC, GIMP, WordPress, and many GNU tools. It is effective at keeping software free — no company can take GPL code, modify it, and release a proprietary version without also releasing the source code.
The GPL's scope is what makes it powerful and controversial. "Linking" is interpreted broadly. If your proprietary application links to a GPL library, your entire application may need to be GPL. This is why many companies prohibit GPL dependencies in their codebases.
AGPL v3 (Affero General Public License)
The AGPL v3 extends the GPL to cover network use. Under the GPL, if you modify software but only use it internally (on your own servers), you do not need to distribute the source code because you are not "distributing" the software. The AGPL closes this loophole: if users interact with the software over a network, you must provide the source code.
This matters for SaaS. Under the GPL, a cloud company can modify an open source database, deploy it as a service, and never release their modifications. Under the AGPL, they must release their modifications.
The AGPL is used by MongoDB (before they switched to SSPL), Grafana, Nextcloud, and Mastodon. Many companies use the AGPL as a business tool: the AGPL version is free, but companies that do not want to comply with the AGPL can purchase a commercial license.
Weak Copyleft Licenses
Weak copyleft licenses apply copyleft to the licensed component but not to software that uses the component.
LGPL (Lesser General Public License)
The LGPL allows you to link to LGPL libraries from proprietary code without making your code LGPL. However, if you modify the LGPL library itself, those modifications must be released under the LGPL.
This makes LGPL suitable for libraries that want to be used everywhere (including proprietary software) while ensuring that improvements to the library stay open. GNU libc (glibc), Qt (with a dual license), and FFmpeg use the LGPL.
The boundary between "linking" and "modifying" can be fuzzy. Statically linking an LGPL library into your binary is treated differently than dynamically linking. Most LGPL libraries recommend dynamic linking to keep the boundary clear.
MPL 2.0 (Mozilla Public License)
The MPL 2.0 applies copyleft at the file level. If you modify an MPL file, your modifications to that file must be released under the MPL. But you can combine MPL files with proprietary files in the same project without the copyleft applying to your proprietary files.
This is a pragmatic middle ground. Firefox, Thunderbird, and LibreOffice use the MPL. It is less restrictive than the GPL but still ensures that improvements to existing files are shared.
The MPL 2.0 is compatible with the GPL, meaning MPL code can be incorporated into GPL projects. This compatibility was a deliberate design choice by Mozilla.
No License: The Default
If a repository has no license file, default copyright applies. The author retains all rights. Users cannot legally:
- Copy the code
- Modify the code
- Distribute the code
- Use the code in their own projects
GitHub's terms of service grant limited rights for code hosted on GitHub (other users can view and fork the repository), but this does not grant permission to use the code in other projects.
If you publish code without a license, you are not making it open source. You are making it visible. These are very different things.
License Compatibility
Not all licenses are compatible with each other. License compatibility determines whether you can combine code from different licenses in the same project.
COMPATIBILITY (simplified)
MIT code can be used in:
MIT, BSD, Apache 2.0, LGPL, GPL, AGPL projects
Apache 2.0 code can be used in:
Apache 2.0, LGPL v3, GPL v3, AGPL v3 projects
(NOT GPL v2 due to patent clause conflict)
GPL v3 code can be used in:
GPL v3, AGPL v3 projects
(NOT MIT, Apache 2.0, or proprietary projects)
AGPL v3 code can be used in:
AGPL v3 projects
(NOT GPL v3, MIT, Apache 2.0, or proprietary projects)
The key insight: permissive licenses are compatible with everything. Copyleft licenses are compatible only with the same or stronger copyleft. This is why many libraries choose MIT or Apache 2.0 — maximum compatibility.
Common Pitfalls
Assuming "No License" Means "Free to Use"
It means the opposite. No license means all rights reserved. If you use code from a repository without a license, you may be infringing copyright. Always check the license before using any open source code.
Confusing GPL With MIT
Adding a GPL dependency to your proprietary project has legal consequences that adding an MIT dependency does not. Know which license each dependency uses. Automated tools can help (see the licensing compliance topic).
Ignoring the AGPL for SaaS
If you run a SaaS product and include an AGPL library, you may be required to release your entire application's source code. The AGPL was specifically designed to cover this case. Do not ignore it.
Mixing Incompatible Licenses
Combining Apache 2.0 code with GPL v2 code in the same binary is not permitted due to conflicting terms. License compatibility matters for every dependency in your project.
Writing Your Own License
Custom licenses are almost always a bad idea. They have not been reviewed by lawyers, are not recognized by the OSI, are not understood by developers, and create uncertainty for users. Use an established license.
Key Takeaways
- Without a license, code is "all rights reserved" by default. A license is the legal mechanism that makes open source possible.
- Permissive licenses (MIT, Apache 2.0, BSD) allow almost anything, including use in proprietary software. They differ mainly in patent protection.
- Copyleft licenses (GPL, AGPL) require that derivative works also be open source. The AGPL extends this to network use.
- Weak copyleft licenses (LGPL, MPL) apply copyleft to the library or file, not to code that uses the library.
- License compatibility determines what you can combine. Permissive licenses are compatible with everything; copyleft licenses are not.
- Always check the license before using open source code. A single GPL dependency can change the licensing requirements for your entire project.