Your software licensing options come down to a few families of permissive, copyleft, proprietary, and dual licenses, and choosing or accepting one is a compliance decision as much as a legal one. Most teams never sign a license form; they inherit hundreds of them the moment they run npm install, and understanding those software licensing options is what keeps a shipped product from becoming a liability.
A license is a grant of rights with conditions attached. When you pull in a dependency, you agree to its conditions whether you read them or not. The difference between a smooth acquisition due-diligence process and a painful one often comes down to whether anyone tracked those conditions along the way.
The permissive family
Permissive licenses let you do almost anything, including using the code in closed-source commercial products, as long as you preserve the original copyright notice and license text. The common ones are MIT, BSD (2-clause and 3-clause), and Apache 2.0.
MIT and BSD are short and impose little beyond attribution. Apache 2.0 adds two meaningful clauses: an explicit patent grant, which protects you from patent claims by contributors, and a termination provision if you initiate patent litigation. For most companies, permissive licenses are the low-friction default, and the main obligation is simply keeping the notices intact in your distribution.
The copyleft family
Copyleft licenses require that derivative works be released under the same terms. The intent is to keep the code and its descendants open. The strength varies:
- Strong copyleft (GPL-2.0, GPL-3.0): if you distribute software that incorporates GPL code, you must make your combined source available under the GPL. This is the clause that surprises commercial teams.
- Weak copyleft (LGPL, MPL-2.0): the copyleft obligation is scoped more narrowly, often to the licensed files themselves, so you can link against the library from proprietary code with fewer obligations.
- Network copyleft (AGPL-3.0): extends the trigger to software offered over a network, closing the "SaaS loophole." If you run AGPL code as a hosted service, users can demand the source.
Copyleft is not dangerous; it is conditional. Plenty of companies use GPL tools internally without issue because internal use is not distribution. The risk appears when copyleft code ends up inside a product you ship or a service you host without anyone realizing it.
Proprietary and commercial licenses
Proprietary licenses grant narrow, specific rights, usually for a fee, and reserve everything else. Terms vary wildly: per-seat, per-core, usage-based, or subscription. Read the restrictions on redistribution, reverse engineering, and deployment count. Commercial licenses are also where audit clauses live, giving the vendor the right to inspect your usage, so tracking actual seat counts is a compliance obligation in itself.
Dual and source-available licenses
A growing number of projects offer dual licensing: an open-source license (often AGPL) for community use plus a paid commercial license that removes the copyleft obligation. This is how many database and framework vendors monetize.
Separately, a wave of "source-available" licenses such as the BSL (Business Source License), SSPL, and Elastic License have emerged. These are not OSI-approved open source. They typically let you read and modify the code but restrict offering it as a competing hosted service. Treat them as commercial licenses with visible source, not as open source, because the usage restrictions are real.
How license risk actually bites
The failure mode is rarely a single obvious GPL library in your main repository. It is a transitive dependency, four levels deep, that carries a copyleft or source-available license nobody reviewed. During an acquisition or a customer security review, someone runs a license scan and finds it, and now you are explaining an obligation you did not know you had.
License data lives in package metadata and is expressed with SPDX identifiers, a standardized short-code system (MIT, Apache-2.0, GPL-3.0-only, and so on). Your SBOM should capture the license of every component. A tool that builds and continuously scans that inventory, such as Safeguard's SCA, can flag a newly introduced copyleft dependency in a pull request before it merges rather than during a deal.
Building a lightweight policy
You do not need a legal team on retainer to manage this well. A workable policy has three parts:
- An allowlist and a denylist. Permissive licenses (MIT, BSD, Apache-2.0, ISC) usually go on the allowlist. Strong and network copyleft go on a review-required list. Enforce it in CI so a disallowed license fails the build.
- A generated, versioned SBOM. Produce it on every build so the license inventory is always current and auditable. This doubles as evidence for compliance frameworks like SOC 2.
- An exception process. Sometimes you genuinely need a copyleft tool. Document the decision, scope it (internal use only, not distributed), and record who approved it.
If you want to go deeper on how license and vulnerability data fit into the same pipeline, our academy covers dependency governance end to end.
FAQ
Which software license is safest for commercial use?
Permissive licenses like MIT, BSD, and Apache 2.0 are the lowest-friction choice for commercial products because they allow closed-source use with only attribution requirements. Apache 2.0 adds a patent grant, which is a plus for larger organizations.
Can I use GPL code in a proprietary product?
You can use GPL tools internally without triggering obligations, because internal use is not distribution. But if you distribute a product that incorporates GPL-licensed code, strong copyleft requires you to release your combined source under the GPL. Weak copyleft licenses like LGPL are friendlier for linking from proprietary code.
Are source-available licenses the same as open source?
No. Licenses like BSL, SSPL, and the Elastic License let you view and modify code but restrict certain uses, usually offering it as a competing hosted service. They are not OSI-approved open source, so treat them as commercial licenses with visible source.
How do I track licenses across all my dependencies?
Generate an SBOM on every build and scan it for license identifiers using SPDX codes. Automated composition-analysis tooling can enforce an allowlist in CI and flag disallowed licenses in a pull request before they reach production.