MIT vs Apache 2.0 vs GPL vs AGPL: what each licence means when you build on it

Why does the licence matter before you write code?

The licence of a dependency or a fork decides what you owe others when you ship. Picking a base project with the wrong licence can force you to publish your own source, or block a sale during due diligence.

This guide is a practical orientation for developers, not legal advice. For high-stakes cases such as an acquisition, a dual-licensing plan or a large commercial product, consult a lawyer who knows software licensing.

The four licences below cover a large share of the open-source projects you will meet when building with AI tools, self-hosted apps and developer libraries.

Licences also shape who will adopt your own project. Enterprises often have policies that fast-track permissive dependencies and route copyleft ones through legal review, so your choice affects sales cycles as well as community.

How do MIT, Apache 2.0, GPL and AGPL compare?

What do the permissive licences, MIT and Apache 2.0, allow?

MIT is short and permissive. You can use, copy, modify, merge, sublicense and sell the software, as long as you keep the copyright and licence notice.

It gives no warranty and says nothing explicit about patents. For most builders that is fine, and MIT code is the easiest to embed in closed products.

Apache 2.0 is also permissive, but longer and more precise. Contributors grant users a patent licence, and that grant ends for anyone who sues over patents in the work.

You must keep the licence, carry forward any NOTICE file and state that you changed modified files. Many companies prefer Apache 2.0 for exactly that patent clarity.

In day-to-day building, the two behave almost the same. The practical differences show up in corporate settings, where patent language and change-marking duties get checked during reviews, and in combinations with GPLv2-only code, where Apache 2.0 is considered incompatible.

What do GPL and AGPL require?

The GNU GPL is copyleft. If you distribute software that includes or is derived from GPL code, you must offer the complete corresponding source under the GPL too.

The trigger is distribution: shipping a binary, an app, a device or a download. Running modified GPL code only on your own servers is generally not distribution, which is why GPL alone rarely touches pure SaaS.

GPLv2 and GPLv3 differ in details such as patents and anti-tivoization rules, and some projects are GPLv2-only, so compatibility between them is not automatic.

The AGPL v3 is the GPL v3 plus a network clause. If you modify AGPL software and let users interact with it over a network, you must offer those users the source of your modified version.

That closes the “SaaS loophole”. It is why many self-hosted apps and open-core companies choose AGPL: competitors can host it, but must share their improvements.

Using an unmodified AGPL service behind your app, such as a separate database or search server, is treated differently by many practitioners than linking its code into yours. Where that line sits is exactly where a lawyer earns their fee.

Copyleft is not a ban on business. It is a condition: if you pass the software on, you pass on the same freedoms. Many profitable companies build on GPL and AGPL software by respecting that condition and selling services around it.

What happens when you mix licences or fork an AI project?

Real products combine dozens of licences. Permissive code can usually flow into anything, including GPL projects, as long as you keep notices. Copyleft code flows only into works that can accept the same terms.

The practical rule: permissive into copyleft works, copyleft into permissive-only closed products does not. If an AGPL library sits in the middle of your proprietary backend, the whole backend may inherit obligations when you serve it to users.

Architecture helps. Running a copyleft component as a separate, unmodified service over a clean API is a common way teams keep boundaries clear, but whether that is enough depends on how tightly the parts are coupled.

What about LGPL, MPL and source-available licences?

You will meet other licences too. The LGPL is a weaker copyleft aimed at libraries: you can link it from closed code, but changes to the library itself must be shared. The MPL 2.0 is file-level copyleft: modified MPL files stay open, your own files do not.

Source-available licences such as the Business Source License, the Server Side Public License or various “fair code” licences let you read the code but restrict competing hosted offerings or commercial use. They are not open source under the OSI definition, so read them as custom commercial terms.

AI model weights add another layer. Many open-weight models ship under bespoke licences with acceptable-use rules or user thresholds, so treat the model licence as separate from the inference code’s licence.

Forking a permissive project gives you the most freedom: you can close your changes, rebrand and sell, keeping notices. Forking a GPL desktop tool means your distributed builds stay GPL. Forking an AGPL server means a hosted version must offer its source to users.

None of these block a business. AGPL-based companies often monetize hosting, support or a separately licensed enterprise edition. What breaks businesses is discovering the obligation after launch.

Which licence should you choose for your own project?

Whatever you pick, apply it consistently: a LICENSE file in the root, a clear statement in the README and, if you accept outside contributions, a written policy on how contributions are licensed.

• You want maximum adoption, including inside closed products: MIT.
• You want permissive terms plus explicit patent protection, often for company-backed work: Apache 2.0.
• You ship desktop or embedded software and want improvements to stay open: GPL v3.
• You run a self-hostable server product and want cloud competitors to share changes: AGPL v3.
• You plan to sell commercial licences alongside open source: a copyleft licence plus a contributor agreement, designed with legal help.

How to check a dependency’s licence before building on it

• Read the LICENSE file in the repository root, not just the badge in the README.
• Look for extra files such as NOTICE, COPYING or per-folder licences, and for enterprise folders under different terms.
• Check model weights and datasets separately; they often carry their own licence distinct from the code.
• Run a licence scanner over your full dependency tree, since transitive dependencies count too.
• Record the result, because acquirers and enterprise customers will ask.

Common mistakes with open-source licences

• Assuming “open source” means “no obligations”. Every licence here has conditions.
• Forking an AGPL project into a SaaS and keeping changes private.
• Removing copyright headers or the NOTICE file when vendoring code.
• Treating source-available licences, such as business source or “fair code” licences, as if they were open source.
• Ignoring that a project can change licence for future versions, while older releases keep their original terms.

Frequently asked questions

Can I use GPL code in a SaaS without releasing my source?

Generally, plain GPL obligations are triggered by distribution, and running software on your own servers is usually not distribution. AGPL is different because it covers network use. Edge cases exist, so for a real commercial product have a lawyer review the setup.

Is Apache 2.0 compatible with GPL?

The Free Software Foundation considers Apache 2.0 compatible with GPL v3, meaning Apache code can be combined into a GPL v3 project. It is not considered compatible with GPL v2 only. The combined work is then distributed under GPL v3.

Can I sell software built on MIT-licensed code?

Yes. MIT allows commercial use and sale, including in closed-source products. You must keep the original copyright and permission notice somewhere in the distribution, such as a licences screen or a bundled text file.

Why do some startups pick AGPL?

AGPL lets anyone self-host and modify the software, but a company offering it as a hosted service must share its modifications. That discourages large clouds from reselling the project without contributing, while the original company can sell commercial licences or hosting.