Why We Open-Sourced ChatML Under GPL-3.0 (And What That Actually Means)

You have seen this movie before.

A new developer tool launches. The landing page says "open source" in big letters. You get excited. You click through to the repo. You find the license file. And there it is: BUSL-1.1, or SSPL, or some custom license that looks like MIT if you squint but includes a clause about "competing products" or "production use" that effectively means you can look at the code but you cannot actually do anything interesting with it.

Or maybe the license is genuinely permissive -- but the open source version is missing half the features. Session management? Enterprise. Team collaboration? Enterprise. The open source repo is a demo. A lead-generation funnel dressed up as a community project.

This is open core. When every VC-backed startup calls itself open source while gating core functionality behind a paywall, engineers stop trusting the label entirely. We do not blame them. We have been those engineers.

ChatML is licensed under the GNU General Public License, version 3. The entire codebase. No asterisks. No "community edition." No enterprise tier. No Contributor License Agreement that quietly gives us special rights over your contributions. This post explains what GPL-3.0 means in practice, why we chose copyleft, and how the architecture is designed so you can actually contribute.

What GPL-3.0 means in practice

The GPL-3.0 is a well-established open source license with a clear set of rights and one key requirement. Let's be specific about what it grants you and what it asks in return.

You can use ChatML commercially. Run it at your company. Use it to build and ship software. Use it in your daily development workflow. There are no usage restrictions whatsoever. The GPL does not limit how you use the software -- it governs distribution, not use.

You can modify it. Fork the repo, change whatever you want, customize it for your workflow. You have full access to every line of code and full freedom to change it.

You can distribute it. Share it with your team. Host it on your internal network. Bundle it in your development environment setup. Distribute it to anyone, anywhere.

The key requirement: copyleft. If you distribute a modified version of ChatML -- if you take the code, change it, and give that changed version to other people -- you must distribute your modified version under the same GPL-3.0 license. You must make the source code of your modifications available.

This is the part that makes GPL different from permissive licenses like MIT or Apache. It is also the part that makes GPL powerful.

What copyleft means in practice is that no one can take ChatML, add features, close the source, and sell a proprietary version. No company can absorb the community's work into a closed product. If someone builds on ChatML, their work stays open too. The contributions of every engineer who submits a PR, every person who fixes a bug, every developer who adds a feature -- all of it remains available to everyone, permanently.

License Comparison at a Glance

No CLA, No Catch

There is no Contributor License Agreement. When you submit a PR to ChatML, your code is GPL-3.0 licensed, same as everything else. We do not ask you to sign a CLA that grants us special rights to relicense your contributions. We cannot take the project proprietary, because we do not have special legal standing over the codebase that community contributors lack.

No Enterprise Tier

There is no "community edition" with artificial limitations. The version you download is the only version. If we build a feature, it ships to everyone. There is no sales team waiting for you to hit a usage limit.

Open source vs open core is not a subtle distinction -- it is the difference between software you control and software that controls you. If a tool can remove features you depend on and move them behind a paywall, it is not open source in any way that matters. It is a free trial.

Why GPL and not MIT

MIT is the most permissive popular open source license. It lets anyone do anything with your code -- use it, modify it, distribute it, relicense it, close the source. Maximum freedom, minimum friction.

GPL-3.0 is copyleft. It grants the same freedoms -- use, modify, distribute -- but adds one requirement: if you distribute a modified version, you must also distribute the source under GPL-3.0.

Some people describe this as GPL being "less free" than MIT. We see it the other way around. MIT is free for the first person who takes the code. GPL is free for everyone, forever.

We have watched the pattern play out too many times. A developer tool launches as MIT-licensed. A community forms around it. Engineers contribute features, fix bugs, build integrations. Then a well-funded company forks the project, adds a proprietary layer, closes the source, and sells it. The community's work -- hundreds of hours of unpaid labor from engineers who contributed in good faith -- is now inside a proprietary product that competes with the open source version they helped build.

The MIT license says that is fine. Recent history makes this concrete. HashiCorp relicensed Terraform from MPL to BUSL in 2023. Redis moved from BSD to dual-license with SSPL. Elastic switched Elasticsearch from Apache 2.0 to SSPL. In each case, years of community contributions ended up inside products that the community could no longer freely use. The GPL prevents this pattern structurally, not just by promise. "Technically allowed" and "good for the community" are not the same thing.

GPL prevents this. If someone forks ChatML and distributes it, their version must also be GPL-3.0. The community's contributions cannot be captured inside a proprietary product. This is not a hypothetical protection -- it is the mechanism that has kept Linux open for over thirty years.

Linux is GPL. The kernel that runs the majority of the world's servers, phones, and embedded devices is copyleft. Thousands of companies use Linux commercially. The GPL has not prevented commercial adoption. It has prevented commercial capture. GCC is GPL. The GNU Compiler Collection has been the backbone of software development for decades. WordPress is GPL. It powers over 40% of the web with an enormous commercial ecosystem around it. The most successful open source projects in history chose copyleft because they understood that the value of open source is not just access to source code today -- it is the guarantee that the source remains accessible tomorrow, next year, and next decade.

For a developer tool that runs locally on your machine, the copyleft requirement has minimal practical impact. You are using ChatML, not distributing modified versions of it. The GPL governs distribution, not use. You can use ChatML commercially, internally, on every machine in your organization, and the copyleft clause never comes into play.

The copyleft matters at the ecosystem level. If someone builds a better version of ChatML, that better version stays open. The growing ecosystem of gpl 3 developer tools -- from compilers to editors to build systems -- proves that copyleft and commercial viability are not in conflict. Contributing to ChatML is a safe investment of your time, because your work cannot be locked behind someone else's paywall.

Architecture designed for contributions

An open source license is necessary but not sufficient. If the codebase is a tangled monolith where every change requires understanding the entire system, the license is just a piece of paper. Nobody contributes to software they cannot understand.

ChatML's polyglot architecture -- four languages, each chosen for a specific reason -- creates natural contribution boundaries. You do not need to understand the Go backend to improve the React UI. You do not need to know Rust to add a new AI provider. Each layer has clear interfaces and responsibilities, which means you can find work that matches your skills and get productive quickly.

Here are the major contribution surfaces:

AI provider interface. The provider abstraction in Go defines a clean interface for communicating with language models. Adding support for a new LLM means implementing this interface, adding configuration, and submitting a PR. You need to understand the provider package. You do not need to understand the worktree lifecycle manager, the session orchestrator, or the UI layer. The interface boundary is the whole point.

Skills system. Skills are modular capabilities -- commit changes, review a PR, run tests, analyze code. Each skill is self-contained with a definition, a prompt template, and a registration step. Adding a new skill is one of the best entry points for first-time contributors. You do not need to modify the core agent loop.

MCP server integration. ChatML supports the Model Context Protocol. External tools can extend its capabilities without modifying the core codebase. Build an MCP server for Linear, Jira, or your internal tools, and ChatML picks it up. No fork required.

UI components. The React frontend uses standard TypeScript patterns inside a Tauri 2 shell. If you are a frontend engineer, you already know how to contribute here. The UI is also where accessibility improvements have the most impact.

Local-first means you are in control

"Open source" and "local-first" are expressions of the same principle: you should control your tools, not the other way around.

ChatML runs entirely on your machine. Your code never leaves your computer unless you push it to a remote. API keys are stored in encrypted local storage. Sessions, worktrees, conversation history -- all local files. There is no ChatML server between you and your AI provider. No telemetry. No account required.

If a tool is open source but requires a connection to the vendor's infrastructure to function, your freedom is theoretical. ChatML has no such dependency. You clone the repo, you build it, you run it. If we disappeared tomorrow, every ChatML installation would continue functioning exactly as it does today.

We wrote about the problem with AI coding tools sending your code through cloud services. ChatML's local-first design means your proprietary code, your API keys, your workflow patterns -- none of it flows through infrastructure we control. The open source ai coding tool community has been pushing for this kind of architecture for years, and we think they are right.

What we need help with

Open source projects fail when contribution opportunities are vague. Here are specific areas where we need help right now:

• Windows and Linux support. ChatML is currently macOS only. The Go backend and React frontend are cross-platform. The Tauri shell needs platform-specific work for window management, system tray, file watching, and native menus. If you have Tauri experience on Windows or Linux, this is high-impact work.
• Additional AI providers. The provider interface in Go is ready for OpenAI, Google Gemini, and local model runners like Ollama and llama.cpp. Each implementation is self-contained -- you need to understand Go and the target API, nothing else.
• New skills. The skills system is modular and waiting for ideas: database migrations, Docker management, deployment workflows, structured code review. If you have a workflow you repeat daily, it is probably a good skill candidate. The workflows post covers how skills compose.
• Accessibility. ARIA labels, full keyboard navigation, high contrast themes, screen reader announcements. This is not a nice-to-have. It turns "anyone can use this" from a slogan into a fact.
• Documentation. Setup guides, architecture walkthroughs, provider implementation guides, skill development tutorials. Good documentation is what turns a codebase into a community.

The economics

"How will you make money?" It is a fair question. Every engineer who has watched an open source project get acquired, relicensed, or slowly strangled by a pivot to enterprise has earned the right to ask it.

The GPL-3.0 license actually makes the business model clearer, not murkier. Because no one can take ChatML's code, close the source, and sell a proprietary fork, we are not in a race against our own codebase. We do not need to hold features back to protect a moat. The copyleft clause is the moat -- it ensures that a well-funded competitor cannot simply take the community's work and undercut us with a proprietary version.

This is fundamentally different from the MIT dilemma. MIT-licensed projects live under a constant strategic threat: any company with more resources can fork the project, build proprietary extensions, and commoditize the open source original. With GPL, that path is closed. If someone forks ChatML and builds on it, their improvements are GPL too. They flow back to the commons.

If ChatML becomes valuable enough that teams want collaboration features -- shared sessions, team-wide skill libraries, centralized configuration -- there may be opportunities for hosted services or support contracts. Those would be additions, not restrictions. The core tool -- the thing you download and run on your machine -- will always be free and GPL-3.0 licensed.

The GPL keeps everyone honest -- us included. We cannot relicense the project without the consent of every contributor, because there is no CLA granting us special rights. If we ever tried to pull the rug, we could not do it unilaterally. The community has structural protection, not just our word. That means we have to keep earning your trust by shipping good software, not by locking you in.

How to get involved

If you have read this far, you are the kind of engineer we built ChatML for. Here is how to start:

Try it first. Download ChatML and use it on a real project. Ten minutes of real use generates better feedback than an hour of reading documentation.

Star the repo. Stars are how open source projects get discovered. Find us at github.com/chatml/chatml.

Check the issue tracker. We label issues with good first issue for tasks that are well-scoped and do not require deep familiarity with the codebase. These are real tasks, not busywork.

Read the contributing guide. It covers development setup, coding conventions, PR process, and the test suite. Clone to merged PR without needing to ask basic setup questions.

Join the conversation. GitHub Discussions is where we hash out design decisions and coordinate larger efforts. If you have opinions about how an open source ai coding tool should work, we want to hear them. If you have specific concerns about ChatML's approach, raise them. We would rather address skepticism directly than pretend it does not exist.

Build something. Pick a provider, a skill, an accessibility improvement, a documentation gap. We review PRs promptly because nothing kills contributor motivation faster than silence.

The bet we are making

The tradeoff of GPL licensing is well understood: we give up the ability to have our code absorbed into proprietary products, and in exchange, we guarantee that the community's work stays open. Some potential contributors who want to use ChatML's code in proprietary projects will choose something else. We accept that tradeoff willingly.

The bet is that copyleft produces better outcomes for developer tools than permissive licensing. That engineers who know their contributions are protected will invest more deeply. That the strongest open source communities are built on trust that runs in both directions: the maintainers trust the community to contribute, and the community trusts that their contributions cannot be captured.

Linux made this bet in 1991. WordPress made this bet in 2003. Both built ecosystems worth billions of dollars, with the source code open and protected the entire time. The GPL did not prevent commercial success. It ensured that commercial success was shared.

ChatML is GPL-3.0 licensed. The whole thing. No asterisks. No enterprise tier. No open core bait-and-switch.

The code is open. The code stays open. That is the promise, and the license enforces it.

Download it, read the source, and decide for yourself.