Licenses: a practical guide for people who ship
Not legal advice. A working engineer's map of what the common licenses actually require you to do.
Most engineers can name three licenses and could not tell you what any of them require. That is a problem when your product ships hundreds of dependencies and somebody in legal eventually asks.
This is not legal advice. It is the working map.
the permissive family#
MIT, BSD (2- and 3-clause), ISC, Apache 2.0.
What you must do: include the license text and the copyright notice with your distribution. That is essentially it.
What you may do: everything. Use it commercially, modify it, ship it in a closed product, sublicense it.
Apache 2.0 additionally: grants patent rights explicitly, and terminates those rights if you sue a contributor for patent infringement over the software. It also requires you to state significant changes you made.
That patent grant is why Apache 2.0 is preferred over MIT by legal departments at larger companies. MIT is silent on patents, which is not the same as safe.
In practice: include a NOTICES file or an attribution page listing your dependencies and their license texts. Generate it from your dependency tree. This is the entire compliance obligation for the permissive family and most products do not do it.
the weak copyleft family#
LGPL, MPL 2.0, EPL.
The rule: modifications to the licensed files must be released under the same license. Your own code that merely uses the library does not have to be.
MPL 2.0 is file-based, which is the cleanest formulation: if you modify a file that came under MPL, that file stays MPL. Everything else is yours.
LGPL is linking-based and the details matter. Dynamic linking is generally considered fine — the user must be able to replace the library. Static linking requires either providing object files so the user can relink, or releasing under compatible terms.
For most modern language ecosystems, "dynamic linking" does not map cleanly onto how code is actually distributed, and this is a genuine gray area. If you statically link LGPL code into a distributed binary, that is worth a real legal conversation.
In practice: MPL and EPL are unproblematic for most commercial use. LGPL is usually fine and deserves attention if you are shipping a compiled binary rather than running a service.
the strong copyleft family#
GPL v2, GPL v3.
The rule: if you distribute a work based on GPL code, the whole work must be under the GPL, and you must provide source.
The key question is what "distribute" means. Running GPL software on your server and letting users access it over a network is not distribution. This is why a very large amount of GPL software runs inside commercial SaaS products without obligation — Linux being the obvious example.
GPL v3 additionally: anti-tivoization (you must let users install modified versions on hardware you ship), and explicit patent provisions.
In practice: GPL dependencies in a hosted service are usually fine. GPL dependencies in software you ship to customers make your software GPL, which is usually not what you intended.
Know which of your dependencies are GPL. Most people do not.
the network copyleft family#
AGPL v3.
The rule: GPL, plus — if users interact with the software over a network, they must be able to get the source, including your modifications.
This closes the "SaaS loophole" deliberately. It is why many companies have a blanket policy prohibiting AGPL dependencies: the obligation is triggered by normal SaaS operation, and determining exactly how much of your system counts as "the software" is a question nobody wants to litigate.
In practice: if your company has a license policy, AGPL is almost certainly on the prohibited list. Check before you add the dependency, not after.
the source-available family#
BUSL, SSPL, Elastic License, various "fair source" licenses.
These are not open source licenses. They restrict commercial use, usually prohibiting offering the software as a service that competes with the licensor.
They exist because hyperscalers built managed services on open source projects without contributing back, and the projects had no recourse. That grievance is real.
In practice: read the actual text, every time. They differ substantially. Many convert to an open source license after a delay — BUSL typically becomes Apache 2.0 after four years — which means the version you are using today may become permissive before you care.
The specific question to answer: does your use case compete with the licensor's commercial offering? Usually the answer is obviously no and you are fine.
the practical program#
1. Generate an SBOM in CI. Every build, listing every dependency and its license. Tooling for this is mature in every major ecosystem.
2. Fail the build on prohibited licenses. Have a policy — usually: permissive fine, weak copyleft fine, GPL depends on whether you distribute, AGPL and source-available require review.
3. Generate the attribution file automatically. This is the actual compliance obligation for the licenses you are most likely to use, and generating it is a build step, not a project.
4. Check when you add, not when you ship. The cost of removing a dependency after it is embedded is enormous. The cost of checking at npm add time is zero.
the thing that trips people up#
License compatibility is not transitive intuition. You can use GPL code in a GPL project. You cannot use GPL code in an Apache-licensed library that others will embed in proprietary software — you have made your library effectively GPL, and your users will find out later.
If you publish a library, its license must be compatible with every dependency it pulls in. Check that specifically, because it is the mistake that is expensive to discover after adoption.
— Dom, June 17, 2026