Software licensing is the set of legal terms that govern how you may use, modify, and distribute a piece of software, and for modern applications the licensing that matters most is not your own product's, it is the terms attached to the hundreds of open source dependencies you pull in without reading. Most engineering teams treat licenses as a lawyer's problem until an acquisition due-diligence review or a customer's procurement questionnaire turns it into an urgent one. This guide explains what software licensing covers and why it belongs in the same conversation as supply chain security.
What Is Software Licensing
At its simplest, what is software licensing comes down to this: software is protected by copyright, so by default nobody may copy or redistribute it. A license is the grant that gives you permission, subject to conditions. It answers three questions. Can I use it? Can I change it? Can I give it or a derivative to someone else, and if so under what terms?
Commercial software licensing (the EULA you click through) tends to restrict: one seat, no reverse engineering, no redistribution. Open source licensing does the opposite, granting broad permissions in exchange for conditions like attribution or sharing changes. The reason licensing has become a supply chain topic is that a typical application ships with code under dozens of different open source licenses, and their conditions stack.
The License Categories That Matter
You do not need to memorize the hundred-plus licenses in the wild. You need to know the buckets.
Permissive licenses (MIT, BSD, Apache 2.0) let you do almost anything as long as you preserve the copyright notice. Apache 2.0 adds an explicit patent grant, which is why enterprises often prefer it. These are the easy ones; the condition is basically "keep the attribution."
Weak copyleft (LGPL, MPL 2.0) requires you to share changes to the licensed component itself, but does not "infect" the rest of your application. You can link to an LGPL library from proprietary code, provided users can swap in a modified version of that library.
Strong copyleft (GPL, AGPL) is where teams get burned. GPL requires that if you distribute a derivative work, you release the whole thing under GPL, including your own source. AGPL extends that trigger to software offered over a network, so running AGPL code in a SaaS backend can obligate you to publish source. Pulling one AGPL dependency into a proprietary product is a genuine problem, not a paperwork nuisance.
How a Bad License Ends Up in Your Product
Nobody deliberately adds an AGPL library to a closed-source product. It happens transitively. You install a helpful permissive package, and four levels down its dependency chain sits a copyleft component you never chose and never saw. Your direct package.json or pom.xml looks clean. The obligation is real anyway.
This is exactly why software licensing and supply chain security overlap. The same dependency tree that hides a vulnerable transitive package hides a hostile license. You cannot answer "what licenses are in my product" by reading your own manifest; you have to resolve the full graph. A generated software bill of materials (SBOM) that records the license of every component is the artifact that makes the question answerable, and an SCA tool will flag a copyleft license buried in a transitive dependency the same way it flags a buried CVE.
Simple Software Licensing Requirements to Actually Meet
Teams overcomplicate this. The simple software licensing requirements that cover most organizations fit on one page:
Maintain an inventory of every third-party component and its license. An SBOM does this automatically; a spreadsheet does not scale past a few dozen dependencies.
Define an allowed and denied list. Most companies allow MIT, BSD, and Apache 2.0 freely; require review for LGPL and MPL; and block GPL and AGPL in distributed or SaaS products unless legal signs off explicitly. Write it down so engineers do not have to ask every time.
Gate it in CI. A build that pulls in a denied license should fail the pipeline, not surprise you at release. This is the single highest-leverage control, because it catches the problem when it costs an hour to swap a package instead of a lawsuit to unwind a shipped product.
Preserve attributions. Permissive licenses require you to include their copyright and license text, usually in a NOTICES file or an "open source licenses" screen. Generate this from your SBOM rather than maintaining it by hand.
Re-check on every dependency update. A minor version bump can change a component's license or add a new transitive dependency with different terms. Continuous scanning catches the drift.
The Cost of Getting It Wrong
The consequences are not theoretical. License non-compliance shows up as blocked acquisitions when due diligence finds copyleft code in a product being sold, as customer contract violations when a procurement clause forbids GPL, and occasionally as litigation from copyright holders enforcing their terms. The remediation, ripping out an embedded dependency late in a product's life, is far more expensive than the CI gate that would have stopped it at commit time.
There is also a maintenance dimension worth naming. Some widely used projects have relicensed under more restrictive terms in recent years, moving from permissive to source-available licenses. A dependency that was compliant when you added it can become a liability on its next release, which is another argument for scanning continuously rather than once. The Safeguard Academy covers how to set up license policy gates without slowing developers down.
FAQ
What is the difference between a license and copyright?
Copyright is the default legal protection that says nobody may copy software without permission. A license is the grant of that permission under stated conditions. Copyright is the lock; the license is the key and the rules for using it.
Is it safe to use GPL software in a commercial product?
It depends on distribution. Using GPL software internally is generally fine. Distributing a product that includes GPL code, or offering AGPL code over a network, can obligate you to release your own source under the same license. For proprietary products, most teams block GPL and AGPL by default and require legal review for exceptions.
How do I find out which licenses are in my dependencies?
Generate a software bill of materials that records the license of every component, including transitive ones. Reading your own manifest is not enough, because the risky licenses usually hide several levels deep in the dependency graph where you never see them.
What are the minimum license compliance requirements for a small team?
Keep an SBOM-based inventory, define an allowed and denied license list, fail the CI build on denied licenses, preserve required attributions in a notices file, and re-scan on every dependency update. That five-item baseline covers the majority of real-world risk.