# Open-Source License Compatibility > How open-source licenses work and combine — permissive vs copyleft, GPL/MIT/Apache compatibility, and how to stay compliant. Guide | Author: Lidiia Levitska | Source: Intellectual Property Law (outsideipcounsel.com) Canonical: https://outsideipcounsel.com/guides/open-source-license-compatibility/

Quick answer: Open-source license compatibility is whether you can legally merge code under two different licenses into one project and satisfy both at once. Licenses fall into three buckets: permissive (MIT, BSD, Apache 2.0) with almost no conditions, weak copyleft (LGPL, MPL) that only require you to share changes to the covered files, and strong copyleft (GPL, AGPL) that require the whole combined work be released under the same license. Permissive code flows into copyleft projects freely; copyleft code cannot be pulled back into closed source. The hard conflicts are copyleft-to-copyleft — for example, Apache 2.0 is incompatible with GPLv2 but fine with GPLv3.

Almost every modern application is built on someone else's open-source code — and every one of those components ships with a license that sets rules for how you may combine, modify, and distribute it. Get the combinations right and open source is a superpower; get them wrong and you can be forced to open-source proprietary code, strip out a dependency late in a release, or face a copyright claim. ## What is open-source license compatibility? Every open-source license is a **copyright license**: the author keeps copyright and grants you permission to use the code *on conditions*. Two licenses are **compatible** when you can bundle code under each into a single work and honor every condition of both simultaneously. They are **incompatible** when their conditions contradict — most often when one license says "you may not add any further restrictions" and the other imposes exactly the kind of restriction the first forbids. This matters at the moment of **combination and distribution**, not while you are just using software internally. Merge two libraries into one binary, statically link them, or fork and modify a project, and you have created something that must comply with both upstream licenses. If they clash, there is no lawful way to ship the result. Compatibility is often **one-directional**. Permissive code can be absorbed into a copyleft project, but copyleft code generally cannot be relicensed under a permissive license. Think of it as a one-way valve: code tends to flow *toward* stronger copyleft, never back out. For the strategic view of how to build with open source without creating legal risk, start with the [software IP pillar guide](/guides/open-source-and-software-ip/). This guide is the mechanics layer beneath it. ## What are the three families of open-source licenses? Nearly every open-source license sits in one of three tiers, and knowing the tier tells you most of what you need. - **Permissive licenses** — MIT, BSD (2- and 3-clause), Apache License 2.0, ISC, zlib. These grant broad rights with minimal strings: keep the copyright notice and license text, and you can use the code in closed-source, commercial products. They impose **no obligation to share your own source**. - **Weak (file-level) copyleft** — LGPL, Mozilla Public License 2.0 (MPL), Eclipse Public License. These require you to share modifications *to the covered files or library*, but let you combine that component with proprietary code without opening your entire application. - **Strong copyleft** — GNU GPL (v2 and v3) and, most aggressively, the **AGPL**. If you distribute a work that includes strong-copyleft code, the **entire combined work** must be released under that same license, with source code available. The distinction is the *reciprocity* obligation. Permissive says "credit us." Copyleft says "keep it open — and if you build on it and share the result, share your build too." Neither is "better"; they encode different philosophies. Both are enforceable copyright licenses under U.S. law, a point the Federal Circuit confirmed in *[Jacobsen v. Katzer](https://www.courtlistener.com/opinion/209693/jacobsen-v-katzer/)* (2008), which held that violating open-source license conditions can be copyright infringement, not merely breach of contract. ## Do permissive licenses grant patent rights? This is the detail founders miss, and it can matter more than the copyleft question. A permissive license may cover copyright but say **nothing about patents** — leaving you exposed to a patent claim from the very people who gave you the code. - **MIT and BSD** are copyright-only. They contain **no express patent grant**. There is an argument that use implies a patent license, but it is not spelled out. - **Apache License 2.0** includes an **explicit patent grant** from contributors, plus a **patent-retaliation clause**: if you sue an Apache contributor for patent infringement over that code, your patent license terminates. This is why many companies prefer Apache 2.0 over MIT for anything patent-sensitive. - **GPLv3** and **MPL 2.0** also include express patent grants, closing a gap that GPLv2 left open. If your project touches patented technology or you care about defensive patent posture, favor licenses with an explicit patent grant. For how patents and software interact more broadly, see [what is patentable](/guides/what-is-patentable/) and [can you patent an app](/guides/can-you-patent-an-app/). ## What counts as a "derivative work" or "linking"? Copyleft obligations trigger when your code forms a **[derivative work](https://www.law.cornell.edu/uscode/text/17/101)** of the licensed code — and where that line falls is the hardest, least-settled question in open-source law. A few anchors: - **Copying, modifying, or forking** the source clearly creates a derivative work. - **Static linking** (compiling a library directly into your binary) is widely treated as creating a combined work that triggers the GPL. - **Dynamic linking** is genuinely debated. The Free Software Foundation's position is that dynamic linking still creates a combined GPL work; some lawyers and courts are skeptical. There is no controlling U.S. appellate ruling resolving it, so **treat dynamic linking to GPL code as risky** unless the license carves it out. - **Arm's-length communication** — one program calling another over a network socket, pipe, or CLI, exchanging data — is generally *not* a derivative work. This is the classic "mere aggregation" that the GPL expressly permits. Two license families exist precisely to soften linking: - **The LGPL** lets you dynamically link a covered library into a proprietary program without opening your code, as long as users can swap in a modified version of the library. - **The AGPL** does the opposite — it closes the "network use" loophole. Under the GPL, running modified code on a server you offer as a service is not "distribution," so no source obligation. The **AGPL treats offering the software over a network as triggering the source-disclosure duty**, which is why many SaaS companies ban AGPL dependencies outright. Because "derivative work" is fact-specific and unsettled, this is an area where the safe move is the conservative one. ## Which license combinations are (and aren't) allowed? Here are the combinations that come up most, stated as practical rules. - **Permissive + permissive** (MIT + BSD + Apache 2.0): almost always fine. Keep every component's notice and license text; the result can be closed or open. - **Permissive + GPL**: allowed, but the **combined work must ship under the GPL**. MIT/BSD code relicenses cleanly into a GPL project. You keep the original notices, but the whole program is now GPL-governed and its source must be available. - **Apache 2.0 + GPLv2**: **not compatible.** The FSF treats Apache's patent-termination and indemnity terms as "further restrictions" GPLv2 forbids. Do not merge them into one program. - **Apache 2.0 + GPLv3**: **compatible**, but one-way — GPLv3 was drafted to accept Apache's terms, so the combined work goes out under GPLv3. - **GPLv2-only + GPLv3**: **incompatible with each other.** GPLv2 code that lacks the "or any later version" clause cannot be combined with GPLv3 code, because each imposes terms the other rejects. Projects licensed "GPLv2 or later" avoid this trap. - **MPL 2.0 + GPL**: MPL 2.0 is expressly **GPL-compatible** (unlike the old MPL 1.1) unless a file is specifically marked "Incompatible With Secondary Licenses." - **Any copyleft + proprietary/closed distribution**: not allowed if the copyleft code is part of the distributed work. You cannot ship GPL code inside a closed-source product you distribute. A compatibility matrix is really just asking one question over and over: *can I obey both licenses at the same time?* When one demands the result stay open and the other demands (or allows) it stay closed, the answer is no. ## What are your actual compliance obligations? Compatibility tells you whether you *can* combine; compliance tells you what you must *do* when you distribute. Obligations cluster into three duties: - **Attribution / notice preservation** (all open-source licenses). Keep the copyright notices, the full license text, and — for Apache 2.0 — any `NOTICE` file. This is the one obligation even MIT imposes, and forgetting it is the most common violation. - **Source disclosure** (copyleft). When you distribute a GPL/LGPL/MPL work, you must make the **corresponding source code** available to recipients, including your modifications and the build scripts needed to produce the binary. AGPL extends this to network users. - **Same-license / reciprocity** (copyleft). You must license the covered work (the whole program for GPL, just the covered files for LGPL/MPL) under the same license, and you may **not add restrictions** — no extra NDAs, no "you can't redistribute" terms layered on top. Two more traps: **state changes** (GPL requires you to note that you modified files and when), and **DRM/anti-tamper terms** (GPLv3 forbids using the code in ways that stop users from running modified versions on consumer devices). ## How do you stay compliant in practice? Compliance is a process problem more than a legal one. A workable program: - **Maintain a Software Bill of Materials (SBOM).** You cannot comply with licenses you don't know you're using. Automated **license-scanning tools** (FOSSA, Snyk, ScanCode, the OpenChain-aligned tooling) inventory every dependency and flag its license. - **Adopt a license allowlist/denylist.** Many companies allow MIT/BSD/Apache 2.0 freely, gate LGPL/MPL through review, and ban AGPL and sometimes GPL in distributed products. - **Track transitive dependencies.** The risky license is usually four layers down in your dependency tree, pulled in by something you chose deliberately. - **Ship the notices.** Generate a `THIRD-PARTY-NOTICES` or attribution file in your build, and include license texts with your distribution. - **Watch the distribution trigger.** Internal-only use rarely triggers copyleft; distributing a binary or (for AGPL) offering a network service does. - **Check your own contributions.** If you contribute back, you may be bound by a **Contributor License Agreement (CLA)** or **Developer Certificate of Origin (DCO)** that assigns or licenses your work — see [contributor license agreements](/guides/contributor-license-agreements/) — and make sure your team isn't pasting copyleft snippets into proprietary code. For the business-strategy layer — how license choices affect fundraising, acquisition diligence, and your own licensing model — see [open-source licensing for startups](/guides/open-source-licensing-startups/) and [building a company on open source](/guides/building-a-company-on-open-source/). Investor diligence almost always includes an open-source audit; we cover that in [IP in fundraising due diligence](/guides/ip-in-fundraising-due-diligence/). ## The bottom line Open-source license compatibility comes down to a single question you can answer for any pairing: *can I satisfy both licenses at the same time?* Permissive licenses (MIT, BSD, Apache 2.0) say yes to almost everything and flow freely into other projects — just preserve the notices, and prefer Apache 2.0 when patents matter. Copyleft licenses (LGPL, MPL, GPL, AGPL) demand reciprocity, cannot be merged back into closed source, and clash with each other in specific, knowable ways (Apache 2.0 vs. GPLv2, GPLv2-only vs. GPLv3). Keep an SBOM, run a license scanner, honor the notice and source-disclosure duties at distribution, and treat AGPL and GPL linking as decisions, not accidents. To see how courts have handled software and copyright disputes, browse our [copyright case archive](/topics/copyright/). *This guide is general education, not legal advice, and does not create an attorney-client relationship. License compatibility and "derivative work" questions turn on your specific code, how it is combined, and unsettled case law — consult an attorney licensed in your jurisdiction before shipping a product built on mixed open-source licenses.* ## Frequently asked questions ### What does open-source license compatibility mean? Two open-source licenses are compatible when you can legally combine code under each into one project and satisfy both sets of obligations at the same time. Incompatibility happens when the licenses impose contradictory requirements — for example, one forbids adding restrictions while the other requires them. Permissive licenses like MIT and Apache 2.0 combine easily with almost anything; strong copyleft licenses like the GPL are far pickier about what they can merge with. ### Can I combine MIT and GPL code in the same project? Yes, but the result must ship under the GPL. MIT is a permissive license with almost no conditions, so its code can be relicensed into a GPL project. Once you link MIT-licensed code with GPL code to form a single program, the GPL's copyleft governs the combined work: you must release the whole thing under the GPL and provide source. You cannot pull the GPL parts back out and ship them as closed source. ### Is Apache 2.0 compatible with GPLv2? No. The Free Software Foundation considers Apache 2.0 incompatible with GPLv2 because Apache's patent-termination and indemnification terms count as extra restrictions GPLv2 does not permit. Apache 2.0 is, however, one-way compatible with GPLv3, which was written to accept those terms. If you must combine Apache 2.0 code with GPL code, use a GPLv3 (or later) project to avoid the conflict. ### What is the difference between permissive and copyleft licenses? Permissive licenses (MIT, BSD, Apache 2.0) let you use, modify, and redistribute code — including in closed-source or commercial products — as long as you keep the copyright notice and license text. Copyleft licenses (GPL, LGPL, MPL, AGPL) add a reciprocity condition: if you distribute a modified or combined work, you must release that work's source under the same license. Copyleft keeps derivatives open; permissive licenses do not.