Almost every modern application includes open source components, often hundreds of them pulled in as dependencies. Each comes with a licence, and those licences set the rules for how you may use, modify and distribute the code. Most of the time the rules are easy to follow. Occasionally they have significant consequences for a commercial product. This guide to open source licenses explains the main families and the ones you will meet most often.
This article is general information, not legal advice. For decisions affecting your product or contracts, consult a lawyer familiar with software licensing.
Two families: permissive and copyleft
Open source licences fall broadly into two groups.
- Permissive licences let you do almost anything with the code, including using it in proprietary, closed-source products, as long as you keep the copyright and licence notices. MIT, BSD and Apache 2.0 are the best known.
- Copyleft licences also let you use and modify the code, but if you distribute the software, or in some cases a modified version, you must make the corresponding source code available under the same licence. The GNU General Public License (GPL) is the classic example. The idea is that freedoms granted to you must be passed on.
Copyleft strength varies. "Strong" copyleft (GPL) covers the whole combined work; "weak" copyleft (LGPL, MPL) applies mainly to the licensed component itself.
The main open source licenses compared
| Licence | Type | Key conditions | Patent grant |
|---|---|---|---|
| MIT | Permissive | Keep copyright and licence notice | Not explicit |
| BSD (2- and 3-clause) | Permissive | Keep notices; 3-clause also forbids using contributors' names to endorse products | Not explicit |
| Apache 2.0 | Permissive | Keep notices, include NOTICE file if present, state significant changes | Yes, explicit |
| MPL 2.0 | Weak copyleft (file level) | Modified MPL files must stay under MPL and be shared when distributed | Yes |
| LGPL | Weak copyleft (library) | Changes to the library must be shared; applications using it can stay proprietary if conditions on linking and replacement are met | v3 includes patent terms |
| GPL v2 / v3 | Strong copyleft | Distributing the software or derivative works requires providing source under the GPL | v3 includes patent terms |
| AGPL v3 | Strong copyleft, network | As GPL v3, plus users interacting with modified software over a network must be offered the source | Yes |
MIT: short and simple
The MIT licence is only a few paragraphs long. You may use, copy, modify, merge, publish, distribute, sublicense and sell the software, provided the copyright and permission notice are included in copies. It comes with no warranty. Many popular JavaScript libraries use it. For businesses, MIT-licensed components are generally the easiest to adopt.
Apache 2.0: permissive with patent protection
Apache 2.0 is similarly permissive but longer and more formal. Its notable feature is an explicit patent licence: contributors grant users a licence to any of their patents that the contribution covers. It also includes a patent termination clause: if you sue alleging the software infringes your patents, the patent licence granted to you ends. Many companies prefer Apache 2.0 for this added clarity.
GPL: share alike
The GPL ensures that software, and works derived from it, remain open when distributed. Key points:
- Internal use is generally not distribution. Running GPL software inside your company, even modified, does not by itself require you to publish changes.
- Distribution triggers obligations. If you ship software containing GPL code to customers, for example as a downloadable app, an installed product or firmware in a device, you must make the corresponding source available under the GPL.
- What counts as a "derivative work" is the most debated question, especially around linking. This is where legal advice matters.
The Linux kernel is licensed under GPL v2. WordPress is also GPL-licensed, which is why themes and plugins distributed for it are generally expected to respect GPL terms.
AGPL: closing the SaaS gap
Under the GPL, offering software as a web service is not usually distribution, so modifications can stay private. The Affero GPL (AGPL) closes that gap: if you modify AGPL software and let users interact with it over a network, you must offer them the source of your modified version. If you run a SaaS business, check carefully for AGPL components. Some companies choose AGPL for their open source editions precisely for this reason.
LGPL and MPL: the middle ground
The Lesser GPL is commonly used for libraries. It lets proprietary applications use the library while requiring that changes to the library itself remain open, and that users can replace the library with a modified version. The Mozilla Public License works file by file: modified MPL files must stay open, but they can be combined with proprietary files in a larger work.
What this means for common scenarios
- Internal business tools: nearly all open source licences are straightforward, because you are not distributing the software.
- SaaS products: permissive and GPL components are usually manageable; AGPL needs careful review.
- Distributed products (desktop apps, mobile apps, devices, on-premises installs): GPL components may require releasing source code; permissive licences require notices.
- Client projects: agree in the contract which licences are acceptable and how third-party components are listed.
Practical compliance steps
- Inventory dependencies. Software composition analysis tools can list the components and licences in a codebase, often producing a software bill of materials (SBOM).
- Set a licence policy: which licences are pre-approved, which need review and which are not permitted for your product type.
- Keep notices. Include required copyright and licence texts in your distribution, for example in an "open source notices" screen or file.
- Review before adding new dependencies, not after release.
- Watch for licence changes in new versions of components you rely on.
For readable summaries of individual licences, choosealicense.com is a helpful starting point, and the Open Source Initiative publishes the full approved list. If you are selecting open source components for a product, our open source solutions team can help assess fit, and software consulting can support technology assessment, though licensing questions with legal consequences belong with your lawyer.
Key takeaways
- Permissive licences (MIT, BSD, Apache 2.0) mainly require keeping notices.
- Copyleft licences (GPL, AGPL) require sharing source when you distribute, or for AGPL, when users interact over a network.
- Weak copyleft (LGPL, MPL) limits obligations to the component itself.
- Maintain an inventory of dependencies and a clear licence policy.