Every founder I asked told me to use MIT. I went AGPLv3 on our invoicing platform anyway. Here is the math, because the standard advice is wrong, or at least overconfident, in a way that costs early-stage SaaS founders real money.

The orthodoxy

Ask the standard founder Twitter / VC LinkedIn crowd about licensing your SaaS code, and the answer comes back nearly unanimous: MIT, or possibly Apache 2.0. The reasoning, paraphrased:

“Permissive licenses get more adoption.”
“Developers won’t use copyleft code.”
“GPL is dead. AGPL is dead-er.”
“You want enterprise to buy your product, and they’re scared of copyleft.”

This is approximately the same crowd that, three years ago, said “VC funding is mandatory” and, six months ago, said “AI is overhyped.” I take their consensus as a useful contrarian indicator.

The actual breakdown is more interesting.

What MIT actually does to your SaaS

MIT says, in plain English: take this code, do whatever you want, just keep my copyright notice. Don’t sue me if it breaks.

That’s it.

Specifically, MIT does not require:

Releasing your modifications back
Crediting the original author in your product UI
Telling anyone that you used the code
Asking permission

For a library or a developer tool, this is fine. The whole point is adoption. The value is in the artifact being used widely.

For a SaaS product that you intend to run as your business, MIT has a specific failure mode that nobody talks about until they’re living it:

MIT lets a well-capitalized competitor fork your code and run it as their own service, with zero obligation to contribute back, and they will win because they have more money.

The canonical examples are all in living memory:

ElasticSearch relicensed away from permissive in 2021, after AWS shipped a clone called OpenSearch and ate their cloud market.
MongoDB went to SSPL in 2018, after AWS DocumentDB.
Redis went to RSAL/SSPL in 2024, after AWS ElastiCache and Memorystore. The community forked it into Valkey almost overnight.
Sentry went BSL then FSL, after competitors started reselling their code.

Every one of those companies started permissive. Every one relicensed once they realised the math. The migration goes one direction. Nobody who started with copyleft has switched to MIT after seeing the numbers.

What AGPLv3 actually does

AGPL is the GPL with one extra clause that closes the “SaaS loophole” in regular GPLv3:

If you run modified code as a network service, you must release your modifications.

Read that twice. The trigger is running modified code as a service, not distributing it. This is the missing piece in GPLv3, which only triggers on distribution. For a SaaS product, GPL alone is useless: nobody distributes SaaS, they just host it.

AGPL is what you want if:

Your business is hosting your own code as a service
Anyone is welcome to take the code, modify it for themselves, contribute back, or fork it under the same terms
You don’t want a well-capitalized competitor to grab your code, slap a logo on it, and run it on AWS without contributing back

You can still:

Use AGPL code internally with whatever modifications, without releasing anything. Internal use, even modified, doesn’t trigger any obligation.
Build commercial products on top of AGPL libraries, as long as the service that uses them releases its source.
Sell hosted SaaS of your own AGPL code, because you own the copyright. The license is for everyone else.

That last point is the one founders consistently misunderstand. You are not bound by your own license. AGPL applies to other people running your code. You can dual-license at will, sell hosted versions, sell commercial licenses for people who need a non-AGPL variant. The OSS license is the floor for everyone else; it’s not a ceiling for you.

The orthodoxy’s actual argument, steelmanned

Here is what the MIT advocates are actually saying, if you press them:

1. “You need adoption to win.” True for libraries, mostly false for end-user SaaS. Nobody installs a SaaS from source. The adoption you need is paid users, and they want a hosted product, not your repository.

2. “Enterprise won’t touch AGPL.” Partially true. Some enterprise legal departments have AGPL on their auto-reject list. Most don’t, and those that do can be addressed with a commercial license for that specific buyer. This is a solvable objection, not a structural problem.

3. “You’ll get more contributors with MIT.” Empirically backwards. Most OSS contributors don’t care about the license, they care about whether the project is alive and the maintainer is responsive. The Linux kernel is GPL. Postgres is permissive. Both have armies of contributors. License is not the bottleneck.

4. “GPL/AGPL is old and lawyers don’t trust it.” Every reputable corporate legal team understands AGPL. It’s been around since 2007. The OSI approved it. Lawyers know exactly what it does, which is a feature compared to newer license types where they have to read carefully.

5. “Just go FSL or BSL instead.” These are real alternatives. Sentry’s FSL-1.1-MIT is the recent favourite: source-available for 2 years, then auto-converts to MIT. The pitch is “protect short-term, gift long-term.” It’s a legitimate middle path, especially if you think your moat is your current sprint’s code, not the codebase as a permanent asset. But these licenses are newer, less battle-tested, and rejected by some buyers who do accept AGPL.

The strongest counter-position to AGPL isn’t MIT, it’s FSL or its cousins. FSL gives you stronger short-term competitive protection than AGPL while signaling “we’ll be MIT eventually” to permissive-loving developers. We considered it. We didn’t pick it.

Why we picked AGPL anyway

For our invoicing platform:

The competitive threat is asymmetric. Anyone serious in the invoicing space already has their own product. They will not fork us to compete head-on. The threat AGPL mitigates is more specific: someone hosting our code in a niche we don’t serve (a country, an industry vertical), without contributing back. AGPL turns that into a contribution funnel.

The hosted SaaS will be our business model. We’re selling the hosted version. The OSS version is the on-ramp and the trust signal. You can self-host if you want; here’s our actual code, nothing hidden. AGPL doesn’t slow that down for one minute. The 5% of users who self-host are not the same people as the 95% who pay for hosting.

AGPL is old, boring, and well-understood. A potential buyer’s legal team will know what AGPL means in 60 seconds. With FSL or SSPL or BSL, they have to actually read it. Boring is good for licensing.

We don’t need short-term protection more than long-term protection. FSL bets that what you ship in the next 2 years matters more than what you ship after. For a foundational product, what we ship in year 4 matters as much as what we ship now. Permanent copyleft fits the time horizon.

Reversibility is asymmetric. Going from AGPL to MIT is easy: you control the copyright, you can relicense at any time. Going from MIT to AGPL is essentially impossible. You’d need every contributor’s explicit consent, and you’d be the first project in years to tighten its license. Start with the more restrictive license. You can always loosen later. You can almost never tighten.

The honest counterargument

There is one real failure mode I’ll acknowledge. If our invoicing platform has zero competitive moat in the actual hosting (not the code; the hosting: integrations, deliverability, support, brand), and if a competitor with $10M can spin up a clone with $200k of dev effort and outmarket us, then licensing doesn’t save us. AGPL slows that competitor down by exactly one weekend of legal review. After that they fork, they ship modifications they don’t publish, we sue them maybe, and we’ve wasted six months on litigation we don’t have the resources to win.

This is the real argument against copyleft for very early-stage founders: enforcement requires you to be alive and resourced enough to enforce. AGPL is paper protection until you have the means to use it.

I accept this with one caveat: even paper protection is better than no protection, because it discourages the lazy version of the threat. The well-capitalized competitor who would fork you in a weekend under MIT will look at AGPL and pick a different target. The competitor sophisticated enough to fork you and ignore the license is a competitor you have bigger problems with anyway.

There’s also a nuance worth flagging from the MongoDB story: AGPL stops a sloppy fork-and-host, but it does not stop a hosting-without-modification clone. MongoDB ran unmodified by AWS for years under AGPL because AWS wasn’t modifying the code. They added their own management plane outside the AGPL boundary. For a database, this turned out to matter; for our invoicing platform, hosting without modification is basically impossible (you need integrations, branding, payment routing, all of which require modifications), so AGPL is plenty for us.

Net: AGPL is not a magic shield. It’s a small piece of friction that filters out the lowest-effort threats. For a solo studio with a SaaS business model, that filter is worth more than the marginal adoption you lose by picking it.

When this advice doesn’t apply

If you’re building:

A developer library or framework - use MIT or Apache, full stop. Adoption is the entire game.
A side project you’d be happy to see anyone do anything with - MIT.
A product where source availability isn’t part of the trust story - proprietary, no OSS needed.
A product you expect to acquihire-flip in 18 months - MIT, because acquirers prefer it.

If you’re building a SaaS product you intend to run, that has competitive risk from cloud providers or well-capitalized adversaries, and you want OSS distribution as a trust signal: AGPLv3 in 2026 is still the right default, against the orthodoxy.

The orthodoxy is, as usual, right about the headline (“permissive = adoption”) and wrong about the failure modes. The problem isn’t adoption. The problem is monetization without being eaten by your own license.

We’ll see if we still believe this in three years. License decisions, like most decisions, are reversible in only one direction. We picked the one that goes the way we can recover from.

If you’re sitting on the same call, the decision tree is the same one I’d write for any legacy file format question: default to the more restrictive option, because loosening is cheap and tightening is impossible.