Open source licenses compared: MIT, Apache, GPL, AGPL, LGPL and MPL
Every open source license lets you use the code. They differ on what you owe in return, and that difference decides whether a library is safe to ship inside your product.
Arnold Francisca / UnsplashAll licenses approved by the Open Source Initiative let you use, change and share the code. Where they differ is in the conditions attached, and those conditions mostly kick in when you distribute the software to others.
Licenses fall into two broad families. Permissive licenses ask for little more than keeping the copyright notice. Copyleft licenses require that if you distribute the software, including your changes, you do so under the same license with source code available.
The main licenses side by side
Based on the summaries at choosealicense.com, run by GitHub:
| License | Type | Main conditions | Patent grant |
|---|---|---|---|
| MIT | Permissive | Keep the license and copyright notice | Not stated |
| Apache 2.0 | Permissive | Keep the notice; state significant changes | Yes |
| MPL 2.0 | Weak copyleft (file level) | Share source of modified files under the same license | Yes |
| LGPLv3 | Weak copyleft (library level) | Share source of the library and changes to it under the same license | Yes |
| GPLv3 | Strong copyleft | Share source of the whole work under the same license when distributed | Yes |
| AGPLv3 | Strong copyleft, network use | As GPLv3, and offering the software over a network counts as distribution | Yes |
All of them disclaim liability and warranty.
What that means in practice
For internal use only, such as a tool your staff run on your own servers, most licenses ask very little of you, because you are not distributing the software. The exception is AGPL: if users interact with a modified AGPL application over a network, you have to make your modified source available to them.
For software you sell or ship to customers, the difference matters a lot. Permissive components such as MIT or Apache code can usually be included with a notice in your documentation. GPL components can require you to release your own source code if they are combined into the same program. LGPL and MPL sit between the two, with obligations limited to the library or files you changed.
Code with no license at all is the riskiest case. Without a license, you have no permission to use it, whatever is posted publicly.
A simple policy
Most companies settle on a three-color list:
- Approved for any use: MIT, BSD, Apache 2.0.
- Approved with review: MPL 2.0, LGPL, depending on how the component is linked and shipped.
- Legal sign-off required: GPL and AGPL in anything distributed or offered as a service, and anything with no license or a custom license.
This is general information, not legal advice. For anything you distribute commercially, have counsel review the specific licenses involved.
What IT teams should do
- Write a one-page license policy with legal, using the three-color list as a starting point.
- Configure your dependency scanner to flag licenses outside the approved list.
- Check any AGPL components in customer-facing services.