A developer pulls a library from GitHub, integrates it into your product, and nobody glances at the license. Then a legal question surfaces during a compliance audit, and suddenly you discover: your product is bound by GPL copyleft clauses or carries Apache 2.0 obligations that were never fulfilled. Open source licenses sound theoretical until they become practical. Then they cost time, money, or in the worst case, control over your own product.
The Four Licenses That Matter in Practice
Hundreds of open source licenses exist, but four dominate in commercial software. Each grants different freedoms and imposes different obligations.
MIT. Maximum Freedom with Minimal Restrictions
MIT is the freedom ticket of the open source world. It allows almost everything: copy, modify, distribute, use commercially. The only condition: original copyright notice and license terms must be included. That’s it.
React, Express.js, Node.js, and Lodash use MIT. Not coincidence. these projects wanted maximum adoption with minimum friction.
From a business perspective: MIT is green light. You can work almost freely, provided you include license notices in your documentation. No hidden obligations, no requirement to disclose your code.
Apache 2.0: Freedom with Explicit Patent Protection
Apache 2.0 resembles MIT but adds a crucial element: the licensor grants users patent rights too. For enterprise, this is valuable. If the original author holds a patent on the technology, they free users from patent infringement claims.
Kubernetes, Terraform, Apache Spark, Airflow. at large infrastructure projects, Apache 2.0 is standard.
One distinction: Apache 2.0 explicitly prohibits suing the licensor. More legal thoroughness than practical concern, but it signals: Apache 2.0 is designed for projects that corporations depend on.
From a business perspective: Apache 2.0 is also green light, often better than MIT because patent protection provides legal peace.
GPL: The Viral License with Real Consequences
GPL. GNU General Public License. is fundamentally different. GPL states: if you use this code, your code must also be GPL. This is called “copyleft”. freedom is contagious, and the purpose is explicit: proprietary software should avoid GPL code without also freeing it.
Linux, WordPress, GIMP: the major GPL projects are stable and proven. But the license is one-way.
GPL has versions (GPLv2, GPLv3), and v3 is more restrictive. for instance on DRM circumvention. Small but important differences.
From a business perspective: GPL is red flag for commercial products. If your product contains GPL code and you don’t open-source it, you need a commercial license from the author (if one exists) or must refactor GPL code out completely.
The gray zone lies in how you use it: GPL typically only binds code you use as a whole or linked together. If you run GPL software only as a service (e.g., WordPress hosting) without linking it to proprietary code, you fall outside the copyleft obligation. But this has legal boundaries that are hard to draw individually.
AGPL: GPL for the Cloud Era
AGPL is like GPL with one decisive addition: even if you don’t distribute the code but only offer it over a network (e.g., SaaS), you must make the source code available.
This closes the GPL loophole for cloud times. GPL only required disclosure when you distributed software. MongoDB Community, Grafana (AGPL through v7), Mattermost. these cloud-friendly projects use AGPL specifically: to prevent competitors from selling their product without giving back.
From a business perspective: AGPL is red light for SaaS. If you operate a service with AGPL code and offer it to customers (even free), you must disclose all code. Practically a prohibition for commercial SaaS.
LGPL: A Middle Ground
LGPL (Lesser General Public License) attempts a compromise: LGPL code must stay open, but code that links to it doesn’t. Useful for libraries.
Qt is an example. under LGPL you can use a GUI framework and keep your code proprietary, provided you link Qt dynamically.
From a business perspective: LGPL is yellow to green, depending on how well you control dynamic linking.
Practical License Traps in the Wild
Four concrete scenarios where licenses create problems:
Scenario 1: GPL Code in Your Backend
You develop a SaaS product and use a battle-tested GPL library for image processing. The code compiles and runs on your servers; customers don’t see it. Still, you must provide the entire source code to customers on request. including your proprietary business logic.
Solution paths: refactor GPL dependency (time, cost), purchase commercial license from author (if available), or open-source your product (business model change).
Scenario 2: AGPL in the Cloud
Similar: you integrate an AGPL library into your SaaS platform. During a billing audit, you discover: you must disclose AGPL source because you offer it over a network. Worse: AGPL is ambiguous about “network offer”. some interpret it so narrowly that even internal APIs count. Legal certainty = zero.
Solution paths: replace AGPL code with Apache 2.0 or MIT, document the requirement in developer guidelines, or implement an SBOM process (see below).
Scenario 3: Dependency Lottery
You import Package A under MIT. Package A depends on Package B under Apache 2.0. Package B depends on Package C under GPL. Your product is now transitively GPL-bound, even though you never directly used Package C.
This happens more often than developers realize. npm, PyPI, Maven Central. all are full of transitive dependencies, and nobody checks licenses.
Solution paths: SBOM tools (Software Bill of Materials) like Trivy, CycloneDX, or SPDX automatically scan transitive dependencies.
Scenario 4: Dual-Licensing Disappears
You use a library under a permissive license. The author is acquired by a corporation, and the next major version has a more restrictive license. Your old versions remain legal (already licensed), but you’re essentially frozen. upgrades become risky, and over time the old code becomes a security liability.
Not a bug, but a feature of open source economics: many projects switch to dual-licensing or subscription models (Terraform, HashiCorp BSL).
SBOM: License Transparency from Day One
The most critical control instrument is a Software Bill of Materials (SBOM). It’s a machine-readable catalog of all direct and transitive dependencies with their licenses.
An SBOM looks like:
{
"bomFormat": "CycloneDX",
"specVersion": "1.3",
"components": [
{
"type": "library",
"name": "react",
"version": "18.2.0",
"license": "MIT"
},
{
"type": "library",
"name": "kubernetes",
"version": "1.28.0",
"license": "Apache-2.0"
}
]
}Tools like Trivy (free, open source) generate SBOMs automatically for containers, dependencies, and binaries. CycloneDX is the standard format.
Process:
- Generate an SBOM during build.
- Scan against policies. e.g., “no GPL in production code” or “only MIT and Apache 2.0”.
- Document exceptions explicitly.
- Share SBOM with customers on request (increasingly a compliance requirement).
Practical Decision Maker Guidelines
Three action items for productive operations:
1. Define a License Policy Specify which licenses are allowed in which contexts. Example:
- Production services: only MIT, Apache 2.0, ISC
- Developer tools (internal): MIT, Apache 2.0, BSD, GPLv2/v3
- Strict exceptions for AGPL and proprietary
2. Integrate SBOM into CI/CD Run Trivy at build time, generate SBOM, check policy. If an unapproved license appears, the build should fail (configurable).
3. Review Dependencies Regularly Licenses change. Developers update dependencies. An annual audit (or per major release) catches drift early.
Conclusion
Open source licenses aren’t academic. GPL forces you either to disclose or refactor. AGPL makes SaaS impossible without disclosure. Apache 2.0 and MIT give freedom but require documentation. Transitive dependencies hide risks deep in your dependency tree.
The answer: build an SBOM process. Generate automatically at build time, check against policy, document exceptions. This is less a legal problem than a transparency one. and that’s solvable.
If you’re uncertain which licenses your software carries or how to build a compliance program: contact us for a consultation. We help you clarify dependencies and introduce a process that keeps licenses under control from day one.
Learn more about software supply chain security in our guide to managing technical debt and our article on supply chain attacks with Trivy.
Frequently Asked Questions
Which open source license is safest for commercial products?
Apache 2.0 is often the best choice. it grants freedoms like MIT but adds patent protection. MIT is also safe, with fewer explicit legal guarantees. Avoid GPL and AGPL in production code.
Can a project have multiple licenses?
Yes, “dual licensing” is common. A project can be available under different terms: one free open source license for community use, and a separate commercial license for proprietary products. The licenses typically aren’t interchangeable. You must pick one based on your use case.
How often should I audit licenses?
Annual audits or checks per major release are a baseline. Better: automate license scanning in your CI/CD pipeline with SBOM tools and policy enforcement. This catches new license risks at build time with no extra overhead and zero delay.
What if I miss a GPL dependency?
Worst case: copyright holder forces you to disclose or sues for damages. In practice rare. most GPL projects are pragmatic. But the risk is real and uninsured.
Do I need a lawyer for open source compliance?
Not for basics. Many projects have simple, clear licenses. For complex cases (GPL in proprietary products, SBOM with hundred dependencies, dual licensing), an IP specialist helps.
