Open Source License Obligations in Commercial Software: The Complete Primer

Open source software is not free in the legal sense — it is free as in freedom, with conditions. Every open source component you incorporate into your product comes with a license that imposes obligations on how you can use, modify, and distribute that code. Understanding these obligations is not optional for commercial software companies.

The Two License Families

Permissive licenses (MIT, Apache 2.0, BSD, ISC) allow you to use, modify, and distribute open source code in proprietary software with minimal requirements. Typically you must include the original copyright notice and, for Apache 2.0, a copy of the license. These licenses are developer-friendly and carry very low commercial risk.

Copyleft licenses (GPL, LGPL, AGPL, MPL) impose reciprocal sharing requirements. If you distribute software that incorporates copyleft code, you may be required to release your modifications — and potentially your entire product — under the same copyleft terms. The strength of this obligation varies significantly between license versions and depends heavily on how the copyleft code is incorporated.

Distribution: The Trigger That Changes Everything

The GPL and most copyleft licenses are triggered by distribution — delivering software to someone outside your organization. If you use GPL code purely internally, without distributing it to external users, the copyleft conditions typically do not apply. The moment you ship a product containing GPL code to a customer, embed it in a device, or offer it as a hosted service in certain configurations, the obligations activate.

This distinction matters enormously for SaaS companies. The AGPL was specifically designed to close the "SaaS loophole" — it is triggered by network interaction, not just physical distribution. An application running AGPL code on your servers that users interact with over the internet may require you to provide the full source code to those users.

Attribution: The Obligation Everyone Forgets

Even permissive licenses carry one near-universal obligation: attribution. MIT, Apache 2.0, and BSD licenses all require that the original copyright notice and license text be preserved and included with any distribution of the software. Many companies violate this without knowing it — they include open source components in their products but do not ship the required attribution notices.

This is not a theoretical risk. Organizations that have been audited for license compliance frequently discover that attribution violations are the most pervasive category of non-compliance, even in organizations that believed they had no GPL exposure.

Transitive Dependencies: Where the Risk Hides

The most dangerous license risk is not in the libraries you consciously chose. It is in the libraries those libraries depend on. A copyleft license buried three levels deep in your dependency graph carries the same legal force as a direct dependency — but it is invisible without automated scanning. Manual review does not scale to the hundreds or thousands of transitive packages present in modern applications.

Building a License Compliance Program

Effective license compliance requires: an automated scanner that analyzes the full dependency tree including transitive dependencies; a defined license policy specifying which licenses are approved, restricted, and banned; a CI/CD gate that flags or blocks builds introducing policy-violating licenses; and an attribution generator that produces the copyright notices required for product distributions.

// Recommended Tool

Automate License Compliance with Fossity

Fossity — Fossity scans your full dependency tree — direct and transitive — identifying every license, flagging policy violations, and generating attribution reports for your product distributions. Stop discovering license obligations after you have already shipped.

Visit Fossity.com →
// Author: Esteban C.