Mistral moved Large 3 and Small 4 to Apache 2.0 in 2026, and DeepSeek V4 ships under MIT. On the announcement pages everything sounds open. In practice, the licence attached to a model decides what an Australian business may legally build with it, and the gap between open in the headline and what the terms actually permit has caught more than one company mid-project. The licence is the contract. Very few teams read it before they build, and the ones that skip it are betting the project on a document they have never seen.
A licence is a commercial decision, not a legal footnote
When you build a product or an internal workflow on a model, that model becomes a core dependency of your business. Its licence sets the conditions on revenue, scale, permitted industries, and what you may do with outputs and fine-tuned versions. If those conditions do not suit you, the problem usually surfaces after the build has shipped, when a client runs due diligence, an investor runs legal review, or a regulator asks how the system works. By then the cheap fix has expired and every option left is slow and expensive.
The licence families you will meet
Most open models fall into one of four buckets, and the bucket matters more than the benchmark score.
Apache 2.0 and MIT. Permissive and broadly safe for commercial use. Apache 2.0 adds an explicit patent grant, which matters if you operate in a patent-heavy sector.
Community licences. Llama-style terms that allow commercial use below thresholds such as monthly active users, with acceptable-use policies attached. Fine until your growth crosses the line.
Research and non-commercial licences. Useful for evaluation and experiments, off-limits for anything that earns revenue. Some excellent models sit in this bucket.
Open weights with custom terms. Each one needs its own reading. There is no shortcut, because the terms vary release by release.
The traps that catch Australian businesses
The expensive mistakes are rarely about the headline licence. They live in the clauses around it.
Threshold clauses. A licence that is free at your current size can impose new obligations once user numbers or revenue grow. You inherit a renegotiation at the worst possible moment.
Version drift. The licence for version 3 does not automatically apply to version 4. Teams upgrade models the way they upgrade libraries, and the terms can shift underneath them.
Acceptable-use policies. Some terms exclude specific applications or industries. Financial services, health, and legal use cases appear in more exclusion lists than most teams expect.
Derivative obligations. Fine-tuning a model can create obligations about what you must disclose or how you may distribute the result, which matters when the fine-tune embeds your proprietary data.
For regulated firms the stakes are higher again. An APRA-regulated business that cannot show which terms govern a production model has a documentation gap as well as a legal one, and the Privacy Act adds its own questions wherever personal information flows through the system.
What it costs to get this right
A proper licence review for an SMB model stack typically costs $3,000 to $6,000 in professional time. That covers reading the actual licence text for each model in use, mapping restrictions against your products and growth plans, and recording the decisions in a form you can hand to an auditor or an acquirer. Compare that with the other path. An Australian business that ships a product on a model it was not permitted to use commercially faces a rebuild that can easily exceed $80,000 in engineering time, plus the awkward conversation with customers while it happens. A Sydney startup raising capital will also find that licence questions appear in every serious due diligence checklist, and a missing answer stalls the round faster than a missing feature.
Keep a licence register
Licences drift between versions, so a one-time check is not enough. A simple register, maintained as part of normal engineering practice, covers most of the ongoing risk.
List every model in use, the exact version, and the exact licence that applies to it
Note any restriction on commercial use, industries, scale, or derivatives
Re-check the terms at every model upgrade, not just at first adoption
Name one owner so the register does not quietly go stale
Where Claude fits
One reason we keep a Claude-first default for client work is contractual clarity. A commercial API agreement states plainly what you may build, who owns the outputs, and how data is handled, and those answers hold still while you build on them. Open models earn their place where the licence is genuinely permissive and the workload suits them, and we are happy to recommend them when both are true. The point is to make that call deliberately, with the terms in front of you, rather than discover them after the product has shipped.
If you are building on open models, or deciding whether to, we run licence and model-stack reviews for Australian businesses and keep the paperwork audit-ready. Book a brainstorm session and we will walk your stack together.
