The open-source license trap — picking AGPL vs MIT vs Apache

Educational only — not legal advice. Open-source licensing has significant commercial implications; consult a specialist open-source attorney before locking in your license choice.

The license you pick for an open-source project is one of the highest-leverage decisions you make as a founder. The wrong choice means competitors can host your code and sell it; the right choice protects the commercial path you'll need for revenue. Here's the trade-off space.

The two camps

Permissive licenses (MIT, Apache 2.0, BSD) — anyone can do almost anything with the code, including hosting it as a commercial service. No requirement to share modifications. No requirement to disclose derivative works. Examples in the wild: Linux kernel (GPL), React (MIT), Kubernetes (Apache).

Copyleft licenses (GPL, AGPL, SSPL) — derivatives must be released under the same license. AGPL specifically requires service-host code to be open-sourced if you offer the software as a network service. SSPL goes further: hosting providers must open-source their entire stack. Examples: MongoDB (SSPL), Elastic (under SSPL since 2021), Grafana (AGPL).

The classic trap

You pick MIT because it's friendly. You build a thriving open-source project. AWS or another cloud provider hosts your project as a managed service, charges customers for it, and you don't see a dollar.

This has happened repeatedly: MongoDB (re-licensed to SSPL in 2018 after AWS DocumentDB), Elastic (to SSPL in 2021 after AWS Elasticsearch), Redis (changed terms after AWS ElastiCache), HashiCorp (Terraform changed to BSL in 2023).

Each re-license caused community backlash and forks (OpenSearch, OpenTofu). The damage is real; the lesson is to think about the license upfront, not retroactively.

The decision frame

Ask: what's your commercial path?

• Cloud-hosted managed service is the primary revenue line. AGPL or SSPL protects against cloud providers competing with you. Cost: some companies refuse to use AGPL-licensed code at all. Acceptable trade-off if your buyer is the founder/CTO, not procurement.

• Enterprise features (SSO, RBAC, audit log) are the primary revenue line. Apache 2.0 with explicit "enterprise edition under commercial license" works well. The community gets the core; you sell the enterprise tier. This is GitLab, Mattermost, Sentry's shape.

• Embedded / library / SDK. MIT or Apache. You want maximum adoption; the commercial value is in services, support, or upstream contributions, not in restricting hosting.

• You're not sure yet. Default to Apache 2.0 for the project. It's permissive (broad adoption), explicit on patent grants (protects you and downstream), and lets you offer a commercial license alongside if the path emerges.

The patent angle most founders miss

Apache 2.0 includes an explicit patent grant. MIT and BSD don't. If you have or might apply for patents related to your project, Apache is safer — it makes the patent grant unambiguous.

Some large open-source consumers (Google specifically, for a long time) prefer Apache for exactly this reason. MIT can create patent ambiguity in commercial-use contexts.

What to do at project launch

1. Pick the license deliberately. Don't default to MIT because it's the "friendly" choice.
2. Document the commercial path in the README. "This project is open under Apache 2.0. Commercial features (SSO, audit log) are available under a commercial license at [URL]." Public commitment prevents the bait-and-switch perception later.
3. Talk to a specialised open-source attorney before v1.0. Not after. The first conversation is usually under $1k; the re-licensing later is six figures and community trust.
4. CLA or DCO for contributions. Decide upfront whether contributors sign a Contributor License Agreement (CLA, gives you broader rights to relicense) or just a Developer Certificate of Origin (DCO, attribution-only). CLA is more flexible commercially but creates friction for casual contributors.

What to avoid

• Custom licenses. Don't write your own. Use a recognised license. Custom licenses kill enterprise adoption (procurement teams reject anything they can't quickly validate).
• Multiple licenses on the same project without a clear structure. "MIT-licensed, but with a custom non-compete addendum" is functionally a custom license.
• Re-licensing without a clear contributor policy. If you accepted MIT contributions and then re-license to SSPL, you may not actually own the right to do so without each contributor's consent. The CLA matters precisely for this scenario.