Apache 2.0 vs custom terms: reading Chinese open-weight licences

The fastest way to get a licence question wrong is to assume a family has one licence. Chinese labs release under several: permissive open-source, custom terms with usage restrictions, and fully proprietary hosted APIs — sometimes across models in the same family.

This is an engineering summary, not legal advice. Route anything commercial through your counsel.

The three buckets

Permissive (Apache 2.0, MIT). You can use, modify, redistribute and commercialise, including in closed products. Obligations are attribution and, for Apache 2.0, a patent grant plus notice requirements. Qwen's open releases are largely Apache 2.0; DeepSeek's flagship open weights have been MIT; Hunyuan's open line is permissive.

Custom open weights. The weights are downloadable and often commercially usable, but the licence adds conditions: acceptable-use clauses, attribution formats, thresholds that trigger extra terms, or restrictions on training derivative models. GLM and Kimi open releases sit here, and the terms have changed between releases.

Proprietary API. No weights. You get a service contract and terms of service. ByteDance's Doubao, MiniMax and Kling are hosted-only, which is fine for most products but rules out on-prem deployment.

The checklist that actually matters

For each model you plan to ship:

1. Pin the exact model card. Terms attach to a specific release, not a brand. Save a copy of the licence text with the model ID in your repo.
2. Read the acceptable-use section. Restrictions on military use, surveillance, or specific jurisdictions appear in custom licences and are the clauses that surprise product teams.
3. Check the derivative-model clause. Fine-tuning for internal use is usually allowed; redistributing a fine-tuned model sometimes is not.
4. Check attribution requirements. Apache 2.0 needs a NOTICE file. Custom licences sometimes require the model name in your UI.
5. Check the output clause. Some custom licences assert rights over generated output. If your product resells generated assets, this matters.
6. Record the version and date. Licences get revised. A snapshot in your compliance repo is worth more than a link.

Jurisdiction and infrastructure

Two questions come up in every enterprise review:

• Where does inference run? A hosted Chinese API and a self-hosted open-weight model have different data flows. If the requirement is "no data leaves our VPC", only the open-weight path qualifies.
• Who is the counterparty? For hosted APIs you are contracting with the provider, under their terms and their governing law. For open weights, you are using software, and your obligations are the licence plus your own local law.

Emerging export-control and AI-governance rules are moving targets in several jurisdictions. Treat a compliance sign-off as dated, and re-check it when you change models — not once at project start.

A workable internal policy

Most teams end up with something like:

• Default: permissive open weights for anything customer-facing that needs to run in our infrastructure.
• Exception: hosted proprietary APIs for capabilities with no open equivalent (video generation being the common case), with a data-processing review.
• Gate: custom-licence open weights require legal review per release, with a recorded licence snapshot.

The families and their licence positions are summarised on each vendor page. Where a model's terms are unclear, ask the provider for the licence text in writing before you ship — vendors answer this question constantly and a slow answer is itself informative.