License Compatibility and Attribution

Modern applications contain hundreds or thousands of open source components, each under a license with conditions. Most conditions are easy to satisfy — keep copyright notices and include the license text — but some carry significant obligations: releasing source code for derivative works, offering source to network users, or avoiding combinations with incompatible licenses. Problems usually surface late: during an acquisition's due diligence, a customer's procurement review, or a takedown request.

Managing licenses is mostly inventory and process: know what you ship, identify each component's license with SPDX identifiers, apply a policy that says which licenses are acceptable for which uses, generate attribution notices automatically, and involve legal counsel for edge cases. This page explains the concepts engineers need; it is not legal advice.

TL;DR

Quick Example

Declaring licenses in source files with SPDX headers (the REUSE convention):

Checking a Node.js project's production dependencies against a policy, and producing a summary:

A Rust project policy with cargo-deny:

Core Concepts

License Families

See Open Source Licensing.

What Triggers Obligations

Most copyleft obligations apply when you distribute software — shipping binaries, mobile apps, desktop apps, firmware, container images to customers, or JavaScript bundles sent to browsers. Running GPL software only on your own servers generally does not trigger source distribution, but AGPL does when users interact with modified software over a network. Attribution obligations apply to anything distributed, including front-end bundles and Docker images.

Compatibility

Combining components in one distributed work requires licenses that permit the combination:

"Or later" versions and dual licensing (MIT OR Apache-2.0) affect compatibility; many Rust and other ecosystem crates are dual-licensed to maximize compatibility. Edge cases — linking semantics, plugins, generated code — need legal review.

Attribution

For distributed software, preserve copyright notices and license texts, include Apache NOTICE file contents, and provide a third-party notices file or screen (for example an "Open source licenses" page in apps). Generate notices automatically from dependency metadata so they stay complete as dependencies change.

SPDX and SBOMs

SPDX provides standard license identifiers and expressions (GPL-2.0-only, GPL-2.0-or-later, MIT OR Apache-2.0, Apache-2.0 WITH LLVM-exception). Use them in package manifests, file headers, and SBOMs (SPDX or CycloneDX formats), which also support supply chain security. See Software Supply Chain Security.

Scanning

Declared license metadata can be missing or wrong; scanners that read license files and headers catch discrepancies. See Package Managers.

Policy and Inbound Contributions

A practical license policy lists licenses that are pre-approved, need review, or are not allowed — often by use case (internal tools, SaaS, distributed products) — enforced in CI with an exception process. For your own projects, decide inbound terms: a DCO sign-off or a CLA, especially if you might relicense later. See Building Open Source Projects and Contribution Workflows and Review Etiquette.

Best Practices

Know What You Ship

Generate SBOMs for every release, including container base images and front-end bundles.

Automate Policy Checks

Check licenses in CI and fail builds on disallowed licenses, with a documented exception path.

Generate Notices Automatically

Produce third-party notices from dependency data on every release rather than maintaining them by hand.

Involve Legal Early for Copyleft and Source-Available Terms

Review AGPL, GPL, and source-available components before adoption, not at release time.

Common Mistakes

Forgetting Front-End and Container Attribution

AGPL in a SaaS Product

Trusting Package Metadata Blindly

FAQ

What is the difference between permissive and copyleft licenses?

Permissive licenses allow reuse in almost any project with attribution. Copyleft licenses require that derivative works, when distributed, are released under the same license with source code.

Does using GPL software in my SaaS require releasing my code?

Running GPL software on your own servers generally does not trigger source distribution. The AGPL extends obligations to users interacting over a network. Get legal advice for your specific case.

What is an SPDX license identifier?

A standardized short name for a license, such as MIT or GPL-3.0-only, used in files, manifests, and SBOMs so tools and people can identify licenses unambiguously.

What does Apache-2.0 require beyond MIT?

In addition to keeping copyright and license notices, Apache-2.0 includes an explicit patent license with termination terms, requires noting significant changes, and requires including the contents of any NOTICE file.

Are source-available licenses open source?

No. Licenses such as BSL or SSPL restrict certain uses — often offering the software as a service — and are not approved by the Open Source Initiative.

Related Topics

References