Open-Source License Compliance

Why license compliance matters

Open-source does not mean “free to use however you want.” Every open-source library comes with a license that defines what you can and cannot do with the code. Ignoring those terms creates legal risk.

The risk is not theoretical. The Software Freedom Conservancy has pursued GPL enforcement cases against companies shipping products with GPL code without complying with the license terms. In 2024, Vizio settled a case over GPL violations in its smart TV firmware. The BusyBox project filed multiple lawsuits against consumer electronics manufacturers in the early 2010s.

Beyond litigation, license compliance shows up in due diligence. If your company is being acquired, the buyer’s legal team will audit your open-source usage. If they find undisclosed copyleft dependencies in your commercial product, it can affect the valuation or kill the deal.

For SaaS companies, the AGPL license deserves special attention. Unlike most licenses that trigger on distribution, AGPL triggers when software is made available over a network. Running an AGPL library in your backend that users access through a web browser can require you to release your entire server-side source code.

Most license compliance issues are avoidable. They happen because no one checked. Automating license scanning through SCA tools eliminates this blind spot.

License types explained

Open-source licenses fall into three categories based on what they require from you.

Permissive licenses

Permissive licenses let you do nearly anything with the code – use it commercially, modify it, redistribute it. Your main obligation is to include the original copyright notice and license text.

Examples: MIT, Apache 2.0, BSD (2-clause and 3-clause), ISC.

These are the lowest-risk licenses for commercial software. Most companies approve them by default.

Copyleft licenses

Copyleft licenses require that if you distribute software containing copyleft code, you must also distribute the source code of the combined work under the same license. This is the “viral” effect – the license spreads to code that includes it.

Examples: GPL v2, GPL v3, AGPL v3.

Copyleft licenses create real problems for commercial software. If your proprietary application links against a GPL library and you distribute the application, GPL requires you to release your application’s source code under GPL.

Weak copyleft licenses

Weak copyleft is a middle ground. The copyleft requirement applies to modifications of the library itself, but not to software that merely uses the library through its public API.

Examples: LGPL v2.1, LGPL v3, MPL 2.0 (Mozilla Public License), EPL 2.0 (Eclipse Public License).

If you use an LGPL library as a shared library (dynamic linking), your proprietary code does not need to be open-sourced. If you modify the LGPL library itself, those modifications must be shared.

The most common licenses and what they require

Here is what each license actually requires from you in practice.

MIT License

The most popular open-source license. Roughly 30% of packages on npm and GitHub use it.

Requirements: Include the copyright notice and license text in your distribution. Allows: Commercial use, modification, distribution, private use. Risk level: Minimal.

Apache License 2.0

Used by many Apache Software Foundation projects, Kubernetes, Android, and TensorFlow.

Requirements: Include the license text, state changes you made, and include a NOTICE file if one exists. Allows: Commercial use, modification, distribution, patent use. Includes: An explicit patent grant. Users receive a license to any patents the contributor holds that cover their contribution. This is a real advantage over MIT. Risk level: Minimal.

BSD Licenses (2-clause, 3-clause)

Common in older projects, FreeBSD, and networking libraries.

Requirements: Include the copyright notice. The 3-clause version adds a restriction against using the contributor’s name for endorsement. Risk level: Minimal.

GPL v2 / GPL v3

Used by the Linux kernel (v2), GCC, WordPress, and many GNU tools.

Requirements: If you distribute software that includes GPL code, you must make the complete source code of the combined work available under GPL. Users must be able to build and run their own version. The key distinction: This applies to distribution. If you use GPL software purely internally and never distribute the binary or source, the requirement does not trigger. Risk level: High for commercial distribution. Manageable for internal-only use.

LGPL v2.1 / LGPL v3

Used by glibc, GTK, and many C/C++ libraries.

Requirements: If you modify the LGPL library itself, you must share those modifications under LGPL. If you use the library as-is via dynamic linking, your proprietary code is not affected. Practical impact: Link against the LGPL library as a shared library (.so, .dll). Do not statically link it into your binary or you may trigger the full copyleft requirement. Risk level: Low if used correctly via dynamic linking. Moderate if statically linked.

AGPL v3

Used by MongoDB (before their SSPL switch), Grafana (prior to Apache relicense), and some SaaS-focused projects.

Requirements: If users interact with the software over a network, you must provide the complete source code, including your modifications. This is the network-triggered copyleft. Why it matters for SaaS: Most open-source licenses only trigger on distribution of binaries. AGPL triggers when you run the software as a service. If your SaaS backend includes an AGPL library, you may need to release your server-side code. Risk level: High for SaaS companies. Many organizations ban AGPL dependencies entirely.

License comparison summary

Copyleft risk: when using GPL code forces your hand

Copyleft risk is the scenario where using a single GPL dependency forces you to release your entire application as open source. Understanding where this line is helps you avoid crossing it.

When copyleft triggers

The GPL copyleft obligation triggers when you distribute a binary or source code that includes GPL code. “Distribution” means giving the software to someone outside your organization: shipping a product, publishing a download, or handing an executable to a client.

Running GPL software on your own servers for internal use does not trigger the copyleft requirement (except AGPL, which triggers on network access).

The transitive dependency problem

Here is where it gets tricky. Your application might not directly depend on a GPL library. But if a dependency three levels deep in your tree uses a GPL library, and it is statically linked, the copyleft obligation can propagate up to your application.

This is why automated scanning matters. Manually checking the license of every transitive dependency in a project with 500+ packages is not realistic. SCA tools resolve the full dependency tree and flag license conflicts automatically.

Real-world scenarios

Scenario 1: Node.js backend using a GPL utility. You deploy this as a SaaS application. Users interact with it over HTTP. Since you are not distributing the binary, GPL does not trigger. But if you switch to AGPL, it does.

Scenario 2: Mobile app using a GPL library. You distribute the app through the App Store. You are distributing a binary that contains GPL code. GPL requires you to make the source code available to users under the same license.

Scenario 3: Docker image containing GPL tools. You publish the Docker image to a registry for customers to pull. This is distribution. GPL obligations apply to everything in the image.

Mitigation

Flag GPL and AGPL dependencies during CI/CD builds. Configure your SCA tool to block merges that introduce copyleft licenses into commercial projects. Maintain a list of approved licenses and review exceptions before they ship.

Automating license scanning with SCA tools

Manual license audits do not scale. They are slow and easy to get wrong. A single developer adding a dependency can introduce a license conflict that nobody catches until legal review months later.

How SCA tools handle licensing

SCA tools read your manifest and lockfiles, resolve the full dependency tree, and check the license of every direct and transitive dependency against your organization’s policy. Findings are reported alongside vulnerability results.

Most tools detect licenses through a combination of:

• Package registry metadata (npm, PyPI, Maven Central publish license fields)
• License file detection (scanning for LICENSE, COPYING, or NOTICE files in the package)
• SPDX identifiers (standardized short-form license names)

Tool comparison for license scanning

FOSSA and Black Duck are the strongest options if license compliance is a primary concern. Their databases cover edge cases like custom licenses, dual-licensing, and license changes between versions that lighter tools miss.

For teams that primarily need vulnerability scanning with basic license checks, Snyk or Mend SCA cover both in a single tool.

CI/CD integration

Add license checks to the same CI pipeline where you run vulnerability scans. Most tools support a configuration file that specifies allowed and denied licenses:

# Example: Snyk policy
license:
  deny:
    - GPL-2.0
    - GPL-3.0
    - AGPL-3.0
  allow:
    - MIT
    - Apache-2.0
    - BSD-2-Clause
    - BSD-3-Clause
    - ISC

When a developer adds a dependency with a denied license, the build fails with a clear explanation of which dependency introduced the violation and what license it uses. The developer can then find an alternative library or request a policy exception.

Building a license policy for your organization

A license policy defines which licenses are approved, which are banned, and how exceptions are handled. Without one, every license decision is ad hoc and inconsistent.

Start with three tiers

Approved (green). Permissive licenses that require no legal review: MIT, Apache 2.0, BSD (2-clause, 3-clause), ISC, Unlicense, CC0.

Review required (yellow). Licenses that need case-by-case evaluation: LGPL, MPL 2.0, EPL, CC-BY, artistic licenses. The risk depends on how the library is used (dynamic vs static linking, distribution model).

Denied (red). Licenses incompatible with your distribution model: GPL, AGPL, SSPL, proprietary licenses with conflicting terms. Developers cannot add these without explicit approval from legal.

Handle exceptions

Some GPL libraries have “classpath” or “linking” exceptions that relax the copyleft requirement. For example, the GCC Runtime Library Exception allows proprietary code compiled with GCC. OpenJDK uses the “Classpath Exception” that permits proprietary code to use standard Java APIs without triggering GPL.

Document each exception with the specific library, the exception clause, and the approved usage pattern.

Maintain an inventory

Track which licenses are in use across all projects. A Software Bill of Materials generated by your SCA tool provides this automatically. Review the inventory quarterly to catch new patterns. If a popular internal framework starts pulling in LGPL dependencies, you want to know early.

Communicate the policy

Put the policy where developers will actually see it: in the CI/CD failure message when a denied license is detected. “Build failed: dependency [email protected] uses GPL-3.0, which is not permitted for commercial distribution. See [link to internal policy] for alternatives or to request an exception.”

The policy is only useful if it is enforced automatically. Manual compliance audits find problems too late. Automated checks in CI/CD catch them before merge.

FAQ

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.