Software licensing works by granting you a set of usage rights to code you don't own, under conditions the copyright holder defines — and understanding it matters because most of the code you ship is licensed to you by someone else, with obligations attached. Whether you can use, modify, redistribute, or sell software, and what you must do in return (attribute, share source, pay a fee), all comes down to the license attached to it. This guide explains the mechanics without the legalese.
The foundation: copyright and the license
By default, code is protected by copyright the moment it's written. Without permission, you can't legally copy, modify, or distribute someone else's code. A software license is that permission — a contract where the copyright holder grants you specific rights in exchange for accepting specific terms.
That framing explains everything else. "Open source" doesn't mean "no rules"; it means the source is available and the license grants broad rights, still with conditions. "Proprietary" doesn't mean "you can't touch it"; it means the license grants narrow rights, usually for a fee. Every license sits somewhere on that spectrum of what it permits and what it requires in return.
Open-source licenses: permissive vs copyleft
Open-source licenses split into two broad families, and the difference is the single most important thing to understand.
Permissive licenses — MIT, Apache 2.0, BSD — grant almost everything and require little. You can use, modify, and redistribute the code, including in closed-source commercial products, as long as you preserve the copyright notice and license text. Apache 2.0 adds an explicit patent grant, which is why many companies prefer it over MIT for larger projects. These are low-friction and dominate modern package ecosystems.
Copyleft licenses — the GPL family, LGPL, AGPL, MPL — grant the same freedoms but attach a reciprocity requirement: if you distribute software that incorporates the code, you must make your source available under the same license. This is the "share-alike" obligation.
- GPL (v2, v3) is strong copyleft: link GPL code into your application and distribute it, and the whole work generally must be GPL.
- LGPL is weaker: you can link the library into proprietary software as long as the library itself stays LGPL and can be swapped.
- AGPL closes the "SaaS loophole" — it triggers the source-sharing obligation even when users interact with the software over a network rather than receiving a copy.
- MPL is file-level copyleft: only modified MPL files must be shared, not your whole codebase.
The practical risk: pulling a GPL or AGPL dependency into a proprietary product can create an obligation to open-source your own code. That's the compliance landmine teams step on.
Commercial and proprietary licensing
Commercial licenses grant narrow, paid rights. Common models include:
- Per-seat / per-user — priced by the number of users.
- Per-core / per-machine — priced by hardware, common in enterprise software.
- Subscription (SaaS) — recurring access, the dominant modern model.
- Perpetual — a one-time purchase, often with paid maintenance.
The key terms to read are scope (how many users, machines, environments), whether it covers production or only development, and restrictions on redistribution. Many "free tier" tools are proprietary licenses that permit limited use but forbid commercial or redistributed use — read those carefully.
Dual licensing is also common: a project offers a copyleft license for free plus a commercial license for companies that don't want the copyleft obligations. MySQL and Qt are classic examples.
How this shows up in your dependency tree
Here's the part most developers underestimate. A modern application has hundreds or thousands of transitive dependencies, and each carries its own license. You inherit obligations from all of them, not just the ones you added directly. A permissively-licensed library you chose deliberately might pull in a copyleft dependency four levels deep that you never evaluated.
Licenses are machine-identified using SPDX identifiers — a standardized short code like MIT, Apache-2.0, GPL-3.0-only, or AGPL-3.0-or-later. Tooling reads package metadata and lockfiles to build a license inventory of your whole tree.
# Node.js: quick license summary of your dependency tree
npx license-checker --summary
# Python
pip-licenses
These give you a starting inventory, but they only see what package metadata declares — which is sometimes wrong or missing.
Staying compliant in practice
A workable license compliance process has four parts:
- Inventory every license in your dependency tree, including transitive ones. This is where a software bill of materials (SBOM) earns its keep.
- Define a policy — which licenses are allowed, which need review, and which are banned (many companies block AGPL and sometimes GPL for proprietary products).
- Gate in CI so a new dependency with a banned license fails the build before it ships, not during an acquisition due-diligence review.
- Track attribution obligations — even permissive licenses require you to reproduce notices, so generate a NOTICES/attribution file at build time.
License scanning is a natural companion to vulnerability scanning, since both read the same dependency graph. An SCA tool that inventories dependencies for CVEs will typically also report their licenses, and a tool such as Safeguard can flag a transitively-introduced GPL package against a policy that forbids it — before it reaches production. Our security academy covers building a license policy that engineering will actually follow.
FAQ
What is the difference between permissive and copyleft licenses?
Permissive licenses (MIT, Apache 2.0, BSD) let you use and redistribute code, including in closed-source products, with minimal obligations beyond attribution. Copyleft licenses (GPL, AGPL) add a reciprocity requirement: distributing software that includes the code can obligate you to release your own source under the same license.
Can I use GPL software in a commercial product?
You can use GPL software commercially, but if you distribute a product that incorporates GPL code, the strong-copyleft terms generally require you to make your combined source available under the GPL. Many companies avoid GPL/AGPL in proprietary products for this reason, or use LGPL libraries that allow linking.
What is an SPDX identifier?
SPDX identifiers are standardized short codes for licenses, like MIT, Apache-2.0, or GPL-3.0-only. Tooling uses them to machine-read the license of each dependency and build a license inventory across your whole project.
How do I check the licenses in my dependencies?
Use ecosystem tooling — npx license-checker for Node.js, pip-licenses for Python, or a dedicated SCA tool that reports licenses alongside vulnerabilities. For full coverage, inventory transitive dependencies too, not just the packages you declared directly.