Open-source compliance starts with knowing what software you have, which license applies to each part, and how that software reaches other people. A component's popularity, price, or public repository is not enough to establish permission for a particular use.
This is a practical workflow for assembling evidence and fulfilling identified requirements, not a legal opinion about a particular product. License interpretation can depend on the exact code, integration, delivery method, and jurisdiction. Bring unresolved questions to qualified counsel before relying on an assumption.
Identify the actual component and license
Record the component name, version or commit, source location, checksum, and the license files supplied with that version. Include dependencies bundled inside installers, browser assets, plugins, containers, and copied source snippets. A repository's top-level license may coexist with differently licensed subdirectories or vendored components.
Use the SPDX License List to record precise identifiers and recognized exceptions. Distinguish a specific version from an “or later” permission and an alternative-license choice from a requirement to satisfy multiple licenses. An identifier helps describe evidence; it does not replace reading the actual grant.
Record modifications and how the component connects to your program: copied code, library linkage, plugin boundary, separate executable, or remote service. Include license and attribution records for images, fonts, data, and documentation separately. A software license does not automatically license everything in the package.
Describe who receives copies and who interacts remotely
Write down the concrete delivery path. Running a tool within one organization differs from sending an installer to a customer, publishing a container image, or shipping software inside a device. Browser JavaScript is delivered to visitors even when the main application runs on your server. Do not label an entire service “internal use” without examining those copies.
The GPL version 3 text distinguishes conveying a copy from mere network interaction. Its permissions for private activity and its requirements for conveyed works need to be read in that context. Providing copies to contractors, affiliates, or customers deserves specific review rather than an assumption that every business relationship is internal.
Network use can matter under another license. AGPL version 3, section 13 requires a modified version supporting remote network interaction to offer its corresponding source to those users under the stated conditions. That provision should not be generalized into a claim that all open-source server software requires publishing all of a company's code.
Compare obligations at the level the license defines
On a small screen, scroll the table sideways to read all columns.
| License example | What to examine | Common mistake |
|---|---|---|
| MIT | Retain the copyright and permission notice in copies or substantial portions. | Treating a permissive license as having no notice requirement. |
| Apache 2.0 | License copy, change notices, relevant attribution/NOTICE material, and patent provisions. | Dropping a supplied NOTICE file or assuming trademark rights are granted. |
| MPL 2.0 | Source availability for covered files when distributing, and the treatment of a larger work. | Assuming its file-level approach is identical to every other copyleft license. |
| GPL 3.0 | Requirements for conveying covered works, corresponding source, and the scope of a combined work. | Assuming a public upstream link always supplies the exact corresponding source. |
| AGPL 3.0 | GPL-style distribution requirements plus its modified-network-version provision. | Reviewing downloadable packages while ignoring remote interaction. |
Read the direct texts: MIT license and Apache License 2.0. Apache's patent grant has defined scope and termination conditions; a permissive label does not erase them. Its redistribution rules also distinguish notices in changed files from attribution carried in a NOTICE file.
Mozilla's MPL 2.0 FAQ explains the file-level approach and distributing a larger work. Combining components still requires checking the actual terms and compatibility. Keeping code in separate repositories or packaging it in containers does not, by itself, settle the legal boundary of a work.
LGPL versions, exceptions, dual licensing, and custom commercial terms need their own analysis; this table is not a complete license catalog. If no license grant can be established, public visibility alone is not permission to copy, modify, and distribute the code.
Make compliance evidence part of the release
Turn the component inventory into a release-specific record. For each item, identify the notices to include, source-delivery requirement if applicable, modification notices, review owner, and unresolved issues. An SBOM is useful input, but a list of names and versions does not itself fulfill license conditions.
When corresponding source is required, match it to the delivered binary and the applicable license's definition. Preserve necessary changes and build or installation material. Choose a source-provision method allowed for the actual delivery scenario; do not reuse a generic written offer without checking its conditions, recipients, duration, and fulfillment process.
Package notices where recipients can reasonably obtain them, and test source links or bundles from a recipient's perspective. Check that the release artifact actually contains the intended files. Retain hashes, exact source versions, the decision record, and evidence of what was delivered. Assign ownership for keeping required source access available after the release team moves on.
Automated scanners can find license text and dependency clues, but generated files, vendored code, exceptions, and false matches require review. AI can help organize an inventory or explain a clause alongside its text; it cannot establish missing provenance or approve compatibility from package names alone. Treat its output as a draft to verify.
Fictional review: a downloadable desktop utility
A team packages its own utility with an MIT-licensed parser and a modified Apache-2.0 helper. It records exact versions, retains the parser's notice, includes Apache's license and applicable attribution, and marks the helper's changes as required. Before release, it inspects the installer rather than assuming the build copied those files.
The team then proposes adding a GPL-licensed library to the same program. That is a new integration question requiring review of the combined work and applicable terms. Copying the library's license into the installer does not resolve it. The release remains pending until the team has a supported compliance path, a different component, or other sufficient permission.
Download the open-source release review worksheet (plain text). It records provenance, use and delivery, obligations, evidence, and questions for qualified review. It is an organizer, not a license-compatibility verdict.