Is Apache 2.0 compatible with the GPL?

Apache 2.0 is one-way compatible with GPLv3 and AGPLv3, so Apache code can be combined into a GPLv3 project. It is NOT compatible with GPLv2-only because of Apache's patent and termination clauses.

Can I put GPL code in my MIT project?

No. GPL is strong copyleft, so combining GPL code forces the entire distributed work to become GPL. You cannot keep a permissive MIT licence on the combined result.

What does compatible-with-conditions mean for LGPL?

LGPL allows use in non-(L)GPL projects only if you dynamically link the library and let users replace it with a modified version. Static linking generally pulls you into LGPL obligations for the linked code.

Why is direction important?

Compatibility is asymmetric. Permissive code flows into copyleft projects freely, but copyleft code rarely flows into permissive projects. Always check component-into-project, not the reverse.

Is this legal advice?

No. This tool reflects widely cited FSF and OSI guidance for the common case of combining and distributing code. For ambiguous cases, dual licensing, or commercial risk, consult a lawyer.

Open Source License Compatibility Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Open source licence compatibility, the practical question

When you pull a library into your project the question is rarely “what licence is it?” but “can these two licences live in the same distributed binary?” Compatibility is one-directional: it asks whether a component under licence A can be combined into a project distributed under licence B. Permissive licences (MIT, BSD, Apache 2.0) flow into almost anything; strong copyleft licences (GPL, AGPL) impose their terms on the whole combined work and so flow into very few targets.

How it works

Each licence pair is looked up in a curated rule table reflecting FSF and OSI guidance. The verdict is one of three:

Compatible — the component can be combined and redistributed under the project licence with normal notice obligations.
Compatible with conditions — allowed only if you follow a specific rule, e.g. LGPL requires dynamic linking and the ability to replace the library; MPL 2.0 keeps copyleft at the file level via its secondary-license clause.
Not compatible — the licences clash. The classic traps are Apache 2.0 → GPLv2-only (patent clause) and any copyleft code going into a permissive project.

Notes and examples

GPLv2-only is incompatible with the entire v3 family — if a project is “GPLv2 or later” you can treat it as GPLv3 and the picture changes. AGPLv3 adds a network-use (“SaaS”) obligation on top of GPLv3, so even where it is technically compatible it imposes stronger duties on the combined work. MPL 2.0 is unusual: its copyleft is file-scoped, so MPL files stay MPL while the surrounding larger work can carry a different licence. This reference is informational and not legal advice.