Using open source code comes with rules. A plain guide to permissive and copyleft licenses, the differences that matter, and how to check what your project depends on.
Almost every project uses open source code. Every piece of that code comes with a license, and the license decides what you may do with it. Most of the time the rules are friendly, but a few licenses have conditions that can surprise a company that did not read them.
Two big families
Permissive licenses let you do almost anything, including using the code in closed source products, as long as you keep the copyright notice. Copyleft licenses add a condition: if you distribute software that includes the code, you must share your own source under the same terms.
The common licenses at a glance
| License | Family | In plain words |
|---|---|---|
| MIT | Permissive | Do almost anything. Keep the copyright and license notice |
| BSD (2 or 3 clause) | Permissive | Similar to MIT. The 3 clause version also forbids using the authors’ names to promote your product |
| Apache 2.0 | Permissive | Like MIT, plus an explicit patent grant and a requirement to note changes |
| LGPL | Weak copyleft | You can use the library from closed source code, but changes to the library itself must be shared |
| GPL | Strong copyleft | If you distribute software that includes it, the whole combined work must be GPL too |
| AGPL | Strong copyleft | Like GPL, but also applies when users interact with it over a network, such as a hosted service |
Why AGPL worries companies
With GPL, the sharing duty is triggered when you distribute software. A web service that users only access over the internet is not usually distributed, so GPL often does not apply. AGPL closes that gap. If you offer a modified AGPL program as a service, you must make your source available to its users. That is why many companies avoid AGPL dependencies unless they have reviewed them carefully.
Source available is not open source
Some projects publish their code under licenses that restrict certain uses, such as running it as a competing commercial service. You can read the code, but these licenses are not generally considered open source. Read them carefully, especially if you plan to build a product on top.
Practical habits
- Choose a license for your own project. Code with no license is not open source. By default, others have no permission to use it.
- Check before you add a dependency. The license is listed in the package page and usually in a
LICENSEfile. - Scan your project. License checking tools can list every dependency and its license, and flag ones that need a review.
- Keep notices. Even permissive licenses require you to keep the copyright notice, so include a third party notices file.
- Write your policy down. Many teams keep a short list of approved, review-needed and forbidden licenses.