Why We Chose MIT Over SSPL: The License Philosophy

We chose MIT for DenchClaw when SSPL or BSL would have 'protected' us more. Here's why that was the right call—and the philosophy behind it.

Kumar Abhirup

March 26, 2026·7 min read

When we open-sourced DenchClaw, we had a choice to make about licensing. MIT is the most permissive option. SSPL, BSL, and Commons Clause are "source available" licenses designed to prevent competitors from using your code commercially. Many successful open source companies have chosen these more restrictive options.

We chose MIT.

I want to explain why, because the reasoning goes beyond "we want to be nice to the community." It's strategic, and it reflects a theory about what makes open source products successful in the AI era.

What SSPL and Commons Clause Actually Do#

First, let me be precise about what the restrictive licenses do.

SSPL (Server Side Public License): Used by MongoDB and others. If you host the software as a service, you must open source your entire service stack. Designed to prevent AWS from offering MongoDB-as-a-service without contributing back.

BSL (Business Source License): Used by HashiCorp, MariaDB, and others. Restricts commercial use for a period (typically four years), after which it converts to open source. Designed to give the company a commercial window.

Commons Clause: An addendum to MIT or Apache that prohibits selling the software. Narrow but meaningful restriction on commercial use.

All of these share a design goal: let individuals use the software freely, but prevent companies from building commercial products on top of it without some form of reciprocity or payment.

The motivation is understandable. Open source companies have been burned by cloud hyperscalers who took open source projects, hosted them as services, and captured most of the commercial value. MongoDB's switch to SSPL was explicitly a response to Amazon's DocumentDB — AWS taking the MongoDB API without contributing back.

Why We Still Chose MIT#

Given the legitimate concerns about hyperscaler free-riding, why did we choose MIT?

The value in DenchClaw isn't the code. The code — a CRM application with a DuckDB backend and an OpenClaw agent — can be built by anyone with reasonable engineering talent. What makes DenchClaw valuable is the skill ecosystem, the community, the brand trust, the support, and the network of people who use it and contribute to it.

These things can't be forked. You can clone the code. You can't clone the community. An SSPL license on the code would protect the code and hurt the community, because it would make community contributors uncertain whether their use cases are permitted.

License uncertainty kills ecosystem. When developers evaluate whether to build a skill, contribute a feature, or integrate DenchClaw into their workflow, they assess the licensing. MIT: unambiguous, no restrictions, use it however you want. SSPL: requires legal review for commercial use. That review step doesn't happen for most contributors. They pick a different tool.

The skill ecosystem is DenchClaw's moat. Every skill published on clawhub.ai makes the product more valuable for every user. Every integration built by a community member extends the platform in ways the core team can't. Restricting this contribution with a license that requires legal analysis is cutting off the compounding value of open source for a protection that doesn't address our actual competitive risk.

Our competitive risk is not AWS. MongoDB needed SSPL protection because AWS could offer MongoDB-as-a-service and capture the commercial value of the software. DenchClaw's primary value is delivered locally — on the user's machine. AWS can't meaningfully offer "DenchClaw as a service" because the value proposition (local data, local AI, your machine) requires running locally.

The threat to our business isn't a hyperscaler hosting our software. It's someone building a better local-first AI CRM. An MIT license doesn't help defend against that. Good product does.

The React Precedent#

The example I keep coming back to is React.

React under MIT has been foundational to Meta's developer ecosystem strategy. The enormous community of React developers, the massive library ecosystem, the prevalence of React in web development — all of this makes React a platform that Meta's products benefit from. The value created by the open source community dwarfs whatever value might have been extracted if React were licensed more restrictively.

React under a more restrictive license would have had less adoption. Less adoption would have meant a smaller ecosystem. A smaller ecosystem would have meant less value. The MIT license is part of why React is dominant, not despite it.

The same logic applies to DenchClaw and OpenClaw. The more broadly these are adopted, the more valuable the ecosystem becomes for everyone, including Dench.

The Honest Business Case#

I should be transparent about the business case, because it's not just altruistic.

DenchClaw as a local-first open source product is our top-of-funnel. Developers install it, use it, maybe contribute skills or bug fixes. Some of them want a managed version — cloud hosting, team features, enterprise support. That's Dench Cloud.

The funnel from MIT open source to paid cloud product works better with genuine open source than with restrictive licenses. Users who trust that DenchClaw will always be free and open are more willing to invest in learning it, contributing to it, recommending it. Users who worry about a future license change are more cautious.

Every company that has done an open-core bait-and-switch — acquired users with permissive licensing, then restricted it when they were dependent — has damaged their reputation in the developer community. HashiCorp's switch from MPL to BSL for Terraform was deeply controversial and led to the OpenTF fork. The community's memory is long.

MIT is both philosophically correct and practically safer. It's the commitment that you won't do a bait-and-switch.

The Trust That MIT Buys#

There's an intangible value to MIT that's hard to quantify but very real: trust.

When you build on an MIT-licensed tool, you know the rules won't change under you. You can deploy it, build on it, modify it, and ship it to customers without worrying about a future license change invalidating your investment. This trust is worth a great deal to the people who build on DenchClaw.

Skills authors trust that the skills they publish will work with DenchClaw indefinitely. Integrations built on top of DenchClaw's APIs won't be invalidated by a license change. Companies that deploy DenchClaw internally can plan on it remaining available.

This trust generates loyalty that's qualitatively different from what you get with restrictive licensing. It's the difference between choosing a tool and betting on a tool.

We want people to bet on DenchClaw. MIT is part of how we earn that bet.

Frequently Asked Questions#

Aren't you worried about someone just forking DenchClaw and competing with you?#

Someone can, and we'd welcome it. Competition on quality is healthy. A fork that's better than DenchClaw for some use case benefits users. Our competitive advantage is product quality, community, and ecosystem — none of which a code fork provides.

What prevents a company from using DenchClaw's code in a commercial product without paying?#

Nothing, and that's intentional. If a company builds value on top of DenchClaw and doesn't contribute back, that's legal under MIT. We'd prefer contribution, but the MIT license accepts non-contributing use. The ecosystem benefits more from broad adoption than from enforced reciprocity.