When people talk about free software, the first big split between licenses has nothing to do with price or code quality. It comes down to one precise question: if someone receives the software, then modifies and redistributes it, must they grant others the same freedoms they received? Licenses that answer "no, it is not required" are called permissive; those that answer "yes" are called copyleft. Understanding this difference prevents most of the mistakes I see in projects, both among people who write code and among those who integrate it into a product.
What they have in common
Both families are fully fledged open source licenses. All of them allow you to:
- use the program for any purpose, including commercial ones;
- study its source code;
- modify it;
- redistribute it, in its original or modified form.
The difference only shows up at the moment of distribution: as long as the software is used internally, without handing it to third parties, the two families behave very similarly (with the exception of the AGPL, which extends obligations to network use).
Permissive licenses
Permissive licenses ask for little: usually keeping the copyright notice and license text, and accepting the warranty disclaimer. The most common ones are:
| License | Main obligations | Distinctive note |
|---|---|---|
| MIT | keep copyright and license text | very short, very popular |
| BSD 2-Clause | same as MIT | different wording, same substance |
| BSD 3-Clause | same as 2-Clause | forbids using the authors' names to promote derivatives |
| Apache 2.0 | copyright, license, NOTICE file, state changes | explicit patent grant |
With a permissive license a company can take a library, modify it and embed it in a closed proprietary product without publishing its changes. Many authors see this as an advantage: the library spreads further and becomes a de facto standard.
A concrete example
A software company builds a warehouse management app and includes an MIT-licensed CSV parsing library. It can sell the app without releasing its own code. It must, however, include the library's copyright notice and MIT license text, for example in an "About" screen or an accompanying file. Forgetting this step is the most frequent violation, and also the easiest to avoid.
Copyleft licenses
Copyleft uses copyright law to ensure that software stays free in its derived versions too. Anyone who distributes a derivative work must do so under the same license and make the corresponding source code available.
There are different degrees of copyleft:
- Strong copyleft (GPL): the obligation extends to the whole derived program, including parts tightly combined with it.
- Weak copyleft (LGPL, MPL): the obligation covers the library or the individual copyleft files, not necessarily the program that uses them.
- Network copyleft (AGPL): the obligation also applies when the modified software is offered to users over a network, without being distributed.
The same example, with the GPL
If the CSV library were under the GPL and were embedded in the warehouse app shipped to customers, the whole app would become a derivative work subject to the GPL. The company would have to give customers the complete source code and allow them to modify and redistribute it. This is not a ban on selling: the GPL allows you to charge for software. But a business model based on keeping the code secret is no longer viable.
Why choose one or the other
The motivations are more philosophical and strategic than technical.
In favour of permissive:
- maximum adoption, including by companies that want no obligations;
- simple compliance;
- well suited to standards, foundational libraries, examples and small tools.
In favour of copyleft:
- ensures that improvements flow back to the community when the software is distributed;
- prevents a competitor from locking the project inside a proprietary product;
- protects end users, who always receive the source code.
A practical rule I often use: if the project's value lies in spreading as a building block for others, a permissive license works well. If the value lies in the finished product and you fear someone will make a closed version of it, copyleft is the more consistent choice.
Common mistakes to avoid
- Thinking "open source" means "no rules". Even MIT has obligations, however minimal.
- Confusing use and distribution. Many GPL obligations only apply when distributing; using a GPL program internally does not require publishing anything.
- Mixing code without checking compatibility. MIT code can flow into a GPL project, but the reverse is not possible while keeping the MIT license on the whole.
- Copying snippets from projects without checking the license. Even a few lines can be protected.
- Believing that code without a license is free. Without a license, ordinary copyright rules apply: nobody can lawfully reuse it.
How to check in practice
For every dependency in a project it is worth recording name, version, license and required obligations. Dependency analysis tools help, but the final check should be done by reading the project's license file, because package manager metadata is sometimes incomplete or wrong.
In short
- Permissive and copyleft are both open source licenses: the difference lies in the obligations when you distribute derived versions.
- Permissive licenses (MIT, BSD, Apache) mainly ask you to keep the copyright and license text.
- Copyleft licenses (GPL, LGPL, MPL, AGPL) require keeping the same license and providing the source, with varying scope.
- The choice depends on strategy: maximum spread, or a guarantee that derivatives stay free.
- Code without a license is not free: without explicit permission it cannot be reused.
