Choosing between open source software licenses can feel like legal homework. The short answer: permissive licenses let you reuse code almost freely, while copyleft licenses require derivative work to stay open.
This guide sits within the wider topic of open source software, and it compares the main license families in plain language.
| Item | Key fact |
|---|---|
| Two primary categories | Permissive and copyleft |
| MIT License | Requires only that the copyright notice and permission notice be included |
| Apache License 2.0 | Permissive, with patent grants |
| GNU GPL | Archetypal strong copyleft license |
| Mozilla Public License (MPL) | File-level copyleft |
| GPLv3 publication date | 29 June 2007 |
The figures come from FOSSA’s license guide and the GNU project’s GPLv3 text. License terms and versions can change, so check the source before you rely on them.
What an open source license actually does
Software is protected by copyright by default, which means nobody else may copy, change or share it without permission. A license is that permission, written down. It tells you what you may do with the code and what you owe in return.
The obligations differ a lot from one license to the next. Some ask for little more than a credit line. Others tell you what you must do with your own changes.
When you compare open source software licenses, these questions usually matter most:
- Can you use the code in a commercial product?
- Must you publish your own changes?
- Must the larger program you build be released under the same license?
- Does the license say anything about patents?
- What notices must you keep when you redistribute?
Answers to these sort licenses into families. FOSSA describes it this way: “The two primary categories are permissive and copyleft licenses, with several specialized licenses that don’t fit neatly into either category.”
Permissive licenses: minimal strings attached
FOSSA says “Permissive licenses place minimal restrictions on how the software can be used, modified, and redistributed.” You can usually fold the code into a closed product, as long as you meet the attribution terms.
The common ones are:
- MIT License: one of the simplest and most popular, requiring only that the original copyright notice and permission notice be included in all copies or substantial portions of the software.
- Apache License 2.0: a more comprehensive permissive license that includes patent grants and requires documentation of changes.
- BSD family: a group of similar licenses with varying requirements, generally requiring attribution and disclaimers.
The trade-off is that someone can take your code, improve it and keep the improvements private. Many projects accept this in return for the widest possible adoption.
The patent language is the main practical difference between MIT and Apache. If your users or contributors are companies that worry about patent claims, a license with an explicit patent grant gives more reassurance than a very short one.
Copyleft licenses: keeping derivatives open
FOSSA puts it like this: “Copyleft licenses ensure that derivative works remain open source by requiring that any modifications or extensions also be distributed under the same license terms.” In practice, if you distribute a program built on copyleft code, you must offer the source to the people who receive it.
The family has a spectrum, from strong to weak:
- GNU General Public License (GPL): the archetypal strong copyleft license, requiring that any work that incorporates GPL code must itself be distributed under the GPL.
- GNU Lesser General Public License (LGPL): a weak copyleft license designed for libraries, allowing linking from proprietary software without triggering copyleft requirements.
- Mozilla Public License (MPL): a file-level copyleft license that allows mixing with proprietary code at the file level, a middle ground between permissive and strong copyleft.
The GPL’s own preamble explains the goal: it “is intended to guarantee your freedom to share and change all versions of a program–to make sure it remains free software for all its users.” That is the idea behind copyleft in one sentence.
If the choice between the two big camps is your question, a comparison of gpl vs mit license goes deeper on that pairing.
How the license landscape developed
The license families grew out of different needs, and a short timeline helps explain why so many exist. FOSSA’s history of licensing marks these points:
- 1989: the first GNU General Public License is published, introducing the concept of copyleft licensing.
- 2004: Apache License 2.0 is released with patent grants.
- 2007: GPLv3 addresses patent rights, hardware restrictions (tivoization) and license compatibility issues.
- 2012: GitHub’s rise leads to widespread adoption of permissive licenses like MIT for new projects.
The GPLv3 text itself is dated “Version 3, 29 June 2007”. Its preamble says some devices deny users the ability to install or run modified software, and the authors “designed this version of the GPL to prohibit the practice for those products.”
Permissive versus copyleft at a glance
The list below condenses the practical differences between the two families, based on the descriptions above.
- Restrictions on reuse: permissive licenses impose minimal ones, while copyleft keeps derivative works under the same or compatible terms.
- Use inside closed software: permissive code is generally allowed with attribution; copyleft depends on strength, so it is restricted for the GPL and easier for the LGPL and MPL.
- Source code for recipients: permissive licenses do not require it, while copyleft requires it for the covered code.
- Typical aim: permissive licenses favor wide adoption, while copyleft aims to keep the code free for all users.
Treat this as a starting point, not legal advice, and read the actual license text before you commit to a choice. Exact duties depend on the license text and on how you combine and distribute code.
How to pick a license for your situation
Start with what you want to happen to your code once others use it. A few common cases:
- You want the widest reuse: a permissive license such as MIT or Apache is the usual fit.
- You want patent clarity: look at a license with an explicit patent grant, such as Apache.
- You want improvements shared back: choose copyleft, and decide between strong (GPL) and lighter (LGPL, MPL).
- You are a user, not an author: read the license of each component you depend on before you ship.
Mixing licenses in one project is where trouble starts. Two licenses may have terms that cannot both be satisfied at once, so check compatibility before combining code.
Tools you adopt bring their own licenses too. If you are evaluating process automation software, the terms matter alongside features, and a guide to open source workflow engines is a sensible next step.
Frequently asked questions
Is open source the same as free of charge?
No. Open source describes the rights the license gives you, such as reading and changing the code. Price is a separate matter.
Can I use MIT-licensed code in a commercial product?
Generally yes. The MIT License requires only that the original copyright notice and permission notice be included in all copies or substantial portions of the software.
Does the GPL force me to release my code?
If you distribute a work that incorporates GPL code, FOSSA says that work must itself be distributed under the GPL. Weaker licenses such as the LGPL allow linking from proprietary software.
Which license covers patents?
Apache License 2.0 includes patent grants, and GPLv3 addresses patent rights, according to FOSSA’s guide.
