Open weights or closed TTS: who wins when

"Open source" in model releases has drifted close to meaningless. A model gets announced, the weights appear on Hugging Face, the launch post says open, and the licence file says something narrower.

For text-to-speech this matters more than usual, because TTS ends up inside products that earn revenue per call. A licence with a revenue ceiling in it becomes a problem at precisely the moment the product starts working.

We have been on the wrong side of this in our own catalogue, so this is not a lecture.

What does Apache 2.0 actually grant?#

More than most teams assume, and it costs almost nothing.

• Commercial use. No ceiling, no revenue share, no separate agreement at scale.
• Modification. Fine-tune it, quantise it, distil it, delete half of it.
• Redistribution. Ship the weights inside your own product, including a closed-source one.
• Private use. Run it internally and tell nobody.
• A patent grant. Contributors licence their relevant patents to you. This is the clause that makes corporate legal teams relax.

What you owe back is small: keep the licence and copyright notices, include the NOTICE file if there is one, and state significant changes you made. The full text is four pages and worth twenty minutes.

You do not owe anyone your source code. Apache 2.0 is permissive, not copyleft. In our experience this single misunderstanding blocks more adoption than any technical concern.

Which licences look open and are not?#

Three patterns recur, and all three get announced with the word "open".

None of these are illegitimate. An author is entitled to licence their work however they like. The problem is that the distinction only surfaces during a procurement review, months into a build.

Read the licence on the weights, not the badge on the repo#

This is the trap that catches the most people, and it caught us.

A model repository often carries two licences: one for the code and one for the weights. The code is frequently Apache 2.0 or MIT. The weights frequently are not. A glance at the repository badge tells you about the inference code you were never going to modify, and nothing about the artefact you actually depend on.

Our own catalogue is the example:

Anyone who read a repository badge and stopped there would have drawn the wrong conclusion about what they were allowed to build on KaniTTS. Gepard 1.0 ships Apache 2.0 weights, which was a deliberate change and the reason we now lead with the licence rather than with benchmark numbers. The model guide has the full breakdown, including the separate NVIDIA licence on the audio codec.

When does open actually win?#

Four situations where owning the weights is decisively better.

Volume. Past roughly 300M characters a month, a GPU you rent yourself is cheaper than any per-character rate, including ours. The crossover arithmetic is here. A closed vendor cannot follow you across that line; an open model can.

Regulated or air-gapped data. Some audio cannot leave the building. This is not a negotiation with a vendor, it is a property of the deployment, and it eliminates every hosted-only option immediately.

Latency floor. If the model runs next to your application, you delete a network round trip. When the synthesis itself takes 50 milliseconds, the network stops being a rounding error and starts being most of the budget.

Longevity. Weights you have downloaded cannot be deprecated, reprices or sunset. Every hosted model eventually gets a successor and a migration deadline.

When does closed still win?#

Frequently, and pretending otherwise would be dishonest given what we sell.

Language coverage. No open model matches the breadth of the largest closed vendors. Gepard covers English, Spanish (Mexico), Portuguese (Brazil) and Dutch. If you need twenty languages next quarter, that is the end of the discussion.

Nobody to run it. Owning weights you cannot serve well is worse than renting an API that works. Self-hosting is a GPU plus an on-call rotation, upgrades, autoscaling, cold-start handling and monitoring. If that list has no owner on your team, the API is not a compromise, it is the correct answer.

Contractual guarantees. An SLA with money behind it, indemnity, a support contract, a security questionnaire someone will actually fill in. Open weights give you none of these. Some buyers require them.

Low volume. Below the crossover, hosting costs more than the API and adds operational surface. Optimising this early is a classic waste.

Specific capabilities. Emotion controls, extensive voice libraries, dubbing tooling, studio features. Closed vendors have invested heavily in surface area that open models mostly lack.

The position worth aiming for#

The most useful property of open weights is not that you will definitely self-host. It is that no branch of the decision tree forces a migration.

Start on the hosted API because it is fastest to ship. Cross the volume threshold and move to your own GPUs, running the identical model. Win a regulated customer and deploy on-premise, running the identical model. Same weights, same voices, same wire protocol at every step.

That is what we optimised for, and it is why our API speaks the Cartesia protocol rather than inventing one. Portability that only works in one direction is not portability.

The counter-argument is fair: a company that makes leaving easy has to keep earning the business. We would rather compete on price and latency than on how expensive we made it to migrate.