Open-Source License Types Explained: Permissive vs Copyleft

Intellectual Property · Updated August 2026

Every software product is built partly from open-source code, and every piece of it carries a licence that sets the rules for how you can use it. Most of the time those rules are harmless. But a few licence types can force a company to publish its own source code or expose it to legal risk — and the difference between "MIT" and "AGPL" is the difference between a footnote and a problem. Here's a plain-English map of the open-source licence types and what each one actually asks of you.

Why the licence type matters

An open-source licence is a grant with strings attached. The strings range from "just keep our copyright notice" to "if you build on this, you have to open-source your whole product." Because these obligations travel with the code — into your product, and into any company that acquires you — knowing which tier each dependency falls into is the whole game. The licences sort into a small number of risk tiers.

Permissive: MIT, BSD, Apache

Permissive licences are the friendliest. MIT, BSD and Apache-2.0 let you use, modify and ship the code in a commercial, closed-source product, asking little more than that you preserve the attribution and licence notice. Apache-2.0 adds an explicit patent grant, which is a plus. For most companies, permissive dependencies are low-risk — the main obligation is simply keeping the notices intact in your distribution.

Weak copyleft: LGPL, MPL, EPL

Weak-copyleft licences ask for reciprocity, but only for the component itself. If you modify an LGPL or MPL library, you generally have to share those changes — but you can still keep your own separate code proprietary, especially if you link the library rather than fold it in. These are manageable, provided you don't modify the component and you respect how it's linked.

Strong copyleft: the GPL family

Strong copyleft is where risk climbs. The GPL requires that if you distribute a product that includes or links GPL code, you offer the whole work's source under the GPL as well. For a company that ships proprietary software, a GPL dependency buried in the product can create an obligation to open-source far more than intended. It's not automatically fatal, but it needs to be caught and handled deliberately.

Network copyleft: the AGPL trap

The AGPL deserves its own warning. It extends copyleft to software offered over a network — so a single AGPL dependency inside a hosted or SaaS product can trigger an obligation to release the source of the entire service, even though nothing is ever "shipped" to a customer. This is the sharpest open-source risk for any web product, and teams routinely discover an AGPL component only when an audit surfaces it.

The hidden tier: no licence at all

A dependency or repository with no licence file is not "free to use" — under default copyright it is all-rights-reserved, meaning there is no grant to use or redistribute it. A no-licence component is a real gap: you're relying on code you have no documented right to use.

How to check your own project

You can't manage what you can't see. The practical step is to inventory every dependency — direct and transitive — and classify each one's licence by tier, so the copyleft and AGPL items get flagged before they ship. Reading a project's dependency graph (its software bill of materials) and mapping each licence to its tier turns "we use open source" into an actual risk picture.

Check the licences in your code. OpenDD's Open Source Due Diligence inventories the open-source a project publishes and depends on, classifies every licence by risk tier, and flags copyleft and AGPL exposure — with a link to each licence's definition. Run an open-source licence check →

The bottom line

Open-source licences sort into permissive (low risk), weak copyleft (manageable), strong copyleft (handle with care), network copyleft/AGPL (sharp risk for SaaS), and no-licence (treat as off-limits). Knowing which tier each dependency falls into — and catching the AGPL and GPL items early — is what keeps an open-source stack from becoming an open-source liability. This is general information, not legal advice; licence interpretation is fact-specific, so confirm obligations against each licence.