MIT vs Apache vs GPL — what do the licences mean for startups?
By SuLe · Updated 23 June 2026
MIT and Apache-2.0 are permissive licences — you can use, modify and sell the code freely — while GPL is copyleft, meaning that distributing software containing it can force you to release your own source. For a commercial startup the practical order of comfort runs permissive first, weak copyleft next, and strong or network copyleft treated with real caution.
Key facts
- MIT and BSD let you use, modify and sell freely, provided you keep the copyright and licence notice.
- Apache-2.0 is permissive too, adds an express patent licence, and requires you to state your changes.
- GPLv2/v3: distributing software containing GPL code means offering the whole derivative under the GPL, with source.
- LGPL permits dynamic linking without infecting your own code; AGPL extends copyleft to network use, making it the classic SaaS red flag.
- Teams commonly gate dependencies against a licence allowlist in CI — MIT/BSD/Apache in, AGPL flagged for review.
What is the real difference between permissive and copyleft?
It comes down to what you must give back. Permissive licences let you take the code and build a proprietary product on top with almost no strings; copyleft licences attach conditions designed to keep derivative works open.
Permissive (MIT, BSD, Apache) says: use it, change it, sell it — just keep the notice. Copyleft (GPL, AGPL) says: if you distribute a derivative, you must pass on the same freedoms, which for a startup can mean releasing your own source code.
Everything else about choosing licences flows from this split. The Open Source Initiative's licence list is the authoritative reference for the exact terms.
Which permissive licence should I prefer — MIT or Apache?
Both are safe commercial defaults, and the difference is patents and change-tracking. MIT is short and simple: keep the copyright and licence notice, and you can use, modify and sell freely.
Apache-2.0 does the same but adds an express patent licence from contributors — useful protection that MIT is silent on — and requires you to state the changes you make. For a commercial product, that patent grant often makes Apache-2.0 the stronger permissive choice.
BSD sits alongside MIT in spirit. Any of the three is a comfortable base for a proprietary product, which is why they dominate startup dependency allowlists.
What obligations does GPL actually impose?
GPL is copyleft, and the trigger is distribution. Under GPLv2 and GPLv3, if you distribute software that contains GPL code, the whole derivative work must be offered under the GPL, with source code made available to recipients.
For a startup shipping software to customers, that can be incompatible with a proprietary licensing model. Pure server-side use, however, is not distribution — so a SaaS product that never ships the binary may avoid the GPL trigger entirely.
LGPL is the gentler cousin: it permits dynamic linking without infecting your own code, so you can call an LGPL library from proprietary software if you respect its linking and notice conditions. See the wider picture in can I legally use open-source code in my commercial product.
Why is AGPL the one to watch for SaaS?
Because it removes the escape hatch that SaaS relies on. AGPL extends copyleft to network interaction: if users interact with AGPL-covered software over a network, the source-code obligation is triggered even though you never distribute the software.
For a SaaS startup, that can mean being required to publish your own source code — usually a non-starter. That is why AGPL is the classic red flag when a software-composition-analysis scan reads your dependency tree.
Manage it structurally: keep a dependency inventory with licences from day one, and gate new dependencies against an allowlist — MIT, BSD and Apache in, AGPL flagged for review — with automated scanners in CI. It also makes Series A due diligence far smoother.
| Licence | Type | Distribute in a product | Use in SaaS (server-side) | Extras |
|---|---|---|---|---|
| MIT / BSD | Permissive | Fine — keep the notice | Fine | Simple, minimal conditions |
| Apache-2.0 | Permissive | Fine — keep notice, state changes | Fine | Express patent licence |
| LGPL | Weak copyleft | Dynamic linking allowed | Fine | Don't statically merge into your code |
| GPLv2 / GPLv3 | Strong copyleft | Whole derivative must be GPL + source | Not distribution — may be OK | Incompatible with proprietary shipping |
| AGPL | Network copyleft | Source obligation applies | Network use triggers source release | The SaaS red flag |
Worked example
Raj is building a developer-tools startup that ships a command-line binary to users, so almost everything it does counts as distribution. His team wants three dependencies: a CLI parser (MIT), a crypto library (Apache-2.0) and a diffing engine (GPLv3).
MIT and Apache-2.0 are fine for a distributed commercial product — they keep the parser and crypto library usable while Raj retains his proprietary licence, and Apache's patent grant is a bonus. The GPLv3 diffing engine is the problem: distributing it would force the whole CLI under the GPL with source. Raj swaps it for an MIT-licensed equivalent, spends about £2,500 of engineering time on the change, and adds a CI allowlist so a copyleft dependency cannot slip in unnoticed before his raise.
Where founders go wrong
Treating all open source as interchangeable
— MIT and AGPL sit at opposite ends of the obligation spectrum.Forgetting Apache's patent grant
— choosing MIT by habit can leave patent protection on the table that Apache-2.0 would give you.Assuming GPL is fine because you're SaaS
— it may be, but AGPL specifically catches network use and can force a source release.Skipping notices on permissive code
— MIT, BSD and Apache all require you to keep the original copyright and licence notice.
Related questions
What is the core difference between MIT and GPL?
MIT is permissive: you can use, modify and sell the code freely as long as you keep the notice. GPL is copyleft: if you distribute software containing GPL code, the whole derivative must be offered under the GPL with source. That is a fundamental difference in obligation. [More: Can I legally use open-source code in my commercial product?]
What does Apache-2.0 add over MIT?
Apache-2.0 is permissive like MIT but adds an express patent licence from contributors, giving you patent protection MIT is silent on, and it requires you to state the changes you make. For commercial products it is often the preferred permissive default.
Is LGPL safer than GPL for a startup?
Generally, yes. LGPL permits dynamic linking without infecting your own code, so you can use an LGPL library from proprietary software without having to release your source, provided you respect the linking and notice conditions.
Why do teams flag AGPL specifically?
AGPL extends copyleft to network use, so users interacting with the software over a network can trigger the source-code obligation even without distribution. For SaaS startups that can mean publishing your source, so AGPL is the classic red flag in a dependency scan.
How should a startup manage licences day to day?
Keep a dependency inventory with licences from day one, and gate new dependencies against an allowlist — MIT, BSD and Apache in, AGPL flagged for review — using automated scanners in CI. It makes Series A software-composition due diligence far smoother.
The wrong open-source licence in your codebase can turn into an emergency the week an investor's scan finds it, and the fix is far cheaper before the round than during it. A SuLe solicitor can review your licence mix and set an allowlist policy that holds up in due diligence. Book a free consultation about your product's legals and get a regulated startup lawyer to check your dependencies.
Keep reading: Can I legally use open-source code in my commercial product? · Who owns AI-generated code or content? · Is web scraping legal in the UK? · Who owns copyright in software in the UK? · Can I patent software in the UK? · What IP protection does an early-stage startup actually need?
Primary sources: Open Source Initiative — licences
