Open source license risk cheat sheet: what each license asks of you

Open source license risk comes down to what you do with the code. MIT and Apache 2.0 mostly ask for attribution. MPL 2.0 asks you to share changes to its files. GPL asks for source when you distribute. AGPL adds a duty when users reach your modified code over a network.

This sheet covers five licenses, quotes the source texts where it matters, and ends with a process you can run on your own dependency list. It is a reading aid, not legal advice. Have counsel review anything that ships to customers.

What does each license actually ask for?

MIT. One condition. The copyright and permission notice must be kept with the software, in the license's words "in all copies or substantial portions of the Software." It also disclaims warranty. Risk is low, and the usual failure is forgetting the notice file in a shipped product.

Apache 2.0. Attribution plus a few extras. If you distribute a derivative work you keep the copyright, patent and attribution notices, mark files you changed, and carry forward the relevant parts of any NOTICE file. Contributors grant a patent license, but it ends for you if you sue anyone claiming the work infringes a patent. That termination clause is the part worth explaining to your legal team.

MPL 2.0. Copyleft that stops at the file. Mozilla's FAQ says the copyleft applies to files containing MPL code. If you modify those files, your modifications stay under the MPL and recipients must be able to get the source. New files with no MPL code can stay under your own license, even when combined into a larger work. Changing MPL code purely inside your organization creates no obligation.

GPL (v3 shown). Strong copyleft triggered by conveying. The license text defines conveying as propagation that lets others make or receive copies, and says mere interaction with a user through a network, with no transfer of a copy, is not conveying. The GNU FAQ also states that linking a program statically or dynamically with a GPL module makes a combined work covered by the GPL terms. So the question is usually "do we ship this to someone, and is it combined with ours?"

AGPL v3. Section 13 says that if you modify the program, your modified version must offer all users interacting with it remotely through a network a chance to receive the Corresponding Source. This is the license that matters for hosted software, because running it as a service can trigger the duty even with no download.

Where do teams get caught?

Four patterns come up again and again, and none needs bad intent.

1. The transitive dependency. You chose an MIT library. It pulls in something under a license you would not have picked. Your top-level list looks clean, the full tree does not.
2. Shipping versus hosting. A team reads "GPL only matters if you distribute" and then packages the same code into an on-premises installer or a mobile build. Same code, different trigger.
3. The AGPL sidecar. An AGPL component is modified and exposed to users of a SaaS product. The duty is in section 13 and many people have never read it.
4. Missing notices. Not a copyleft problem at all, just a missed condition under MIT or Apache 2.0 in a distributed artifact.

What should you do?

1. Generate a full dependency inventory, including transitive packages, for each thing you ship. An SBOM in SPDX or CycloneDX is a good format for this.
2. Normalize license names to SPDX identifiers such as MIT, Apache-2.0 or GPL-2.0-only. The SPDX License List gives each a short identifier and a permanent text URL, which removes spelling ambiguity.
3. Write down your delivery modes: hosted service, on-premises, mobile, library, internal tool. Each license rule applies differently per mode.
4. Make a short policy: allowed, needs review, blocked, per delivery mode. For example AGPL might be blocked for hosted products and allowed for internal tools.
5. Run the check in CI so a new dependency is evaluated when it is added, not at release time.
6. Keep notices. Generate a third-party notices file from the inventory for every shipped build.
7. Send anything in the "needs review" bucket to counsel with the delivery mode attached. They can answer much faster with that context.

Safeguard's CLI scan writes a license.json next to the vulnerability results, which gives you a starting point for step 1 and 2 on a local project. The docs do not describe license-specific flags, so check the output against your own policy list.

What this sheet leaves out

Dual licensing, license exceptions, the LGPL, source-available licenses and non-English law. Each changes the answer. Treat an unfamiliar license as "needs review" until someone has read it.

Quick check

Sources

• MIT License, Open Source Initiative
• Apache License 2.0
• MPL 2.0 FAQ, Mozilla
• GNU GPL v3 text
• GNU GPL FAQ
• GNU AGPL v3 text
• SPDX License List
• Safeguard CLI usage

Last reviewed: 18 October 2026.