Open Source vs Proprietary Models for Production
The difference is control, not capability. Open-weight models can be downloaded, served on your own hardware, and fine-tuned into something you keep. Proprietary models are accessed through an API you don’t operate. Everything else (licence terms, data handling, upgrade timing) follows from that one distinction.
What actually differs between them?
Five properties change, and only one of them is about accuracy.
| Property | Open-weight models | Proprietary API models |
|---|---|---|
| Weight access | Download and inspect | Not available |
| Where inference runs | Your hardware, your VPC, or a device | The provider’s infrastructure |
| Licence | Varies by model, so read it | Terms of service |
| Version stability | You pin the checkpoint | The provider controls deprecation |
| Fine-tuning artefact | Weights you keep | A model on the provider’s platform |
“Open source” is doing loose work in that phrase, and the licences are where it shows.
What do the licences actually say?
They vary enough that treating “open weights” as one category is a mistake. Three of the most-used student model families in the distil labs catalog carry three materially different licences.
| Family | Licence | Notable condition |
|---|---|---|
| Qwen3 | Apache 2.0 | Standard permissive terms |
| Gemma | Gemma Terms of Use | Use restrictions must be passed to recipients |
| Llama 3.2 | Llama 3.2 Community License | Attribution and a monthly-active-user threshold |
The Qwen3-1.7B model card lists apache-2.0. The Gemma Terms of Use permit distribution of model derivatives but require that you include the use restrictions as enforceable provisions in agreements with recipients and carry a notice stating that Gemma is provided under those terms; the same document states that “Google claims no rights in Outputs you generate using Gemma”. Meta’s own Llama-3.2-1B-Instruct model card describes the Llama 3.2 Community License as a custom commercial agreement rather than a standard open-source licence: redistribution requires displaying “Built with Llama”, prefixing derivative model names with “Llama”, and requesting an additional licence from Meta above 700 million monthly active users.
None of these are obstacles for most production use, but they’re the kind of thing your legal team will ask about, and the answer is different per family.
Where does your data go?
With open weights served on your own infrastructure, nowhere. That’s the whole argument for on-prem and edge deployment, and it’s why the industrial RAG case study is set inside a segmented network with no internet path.
With a proprietary API, the answer is whatever the provider’s current documentation says, and you should read it rather than assume. OpenAI’s data controls documentation states that “data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)”, and describes abuse-monitoring log retention of up to 30 days by default, with Zero Data Retention and Modified Abuse Monitoring available as further controls. Other providers publish their own equivalents; check theirs, not a summary of theirs.
Operationally the distinction is architecture rather than trust. A model running inside your network can’t leak data to a third party because there’s no third party in the path. Everything else is a contractual guarantee, which is a different kind of assurance.
Is proprietary still better on quality?
On broad, open-ended work, generally yes. Frontier models hold a real advantage on tasks that need wide world knowledge, long-horizon reasoning, or free-form generation quality.
On bounded tasks, the ordering flips once you fine-tune. In a distil labs benchmark across 8 datasets against 10 frontier LLMs, fine-tuned models of 0.6B to 8B parameters ranked first on 4 of the 8 and placed 3.2 on average, behind Claude Opus 4.6 at 2.5 and ahead of Gemini 2.5 Flash at 3.5. The full results include the per-dataset breakdown and the cost figures, summarised in the 10x inference tax.
The same study is clear about where fine-tuned small models lost: docstring generation, where part of the output is a free-form plain-language description, and Banking77. Both need broader capability than narrow specialisation supplies. Do you actually need a bigger model covers how to tell which side of that line you’re on.
How should you decide?
Decide on constraints first, because constraints are binary and quality is a gradient.
- Does the data have to stay inside your network? If yes, open weights, and the decision is made.
- Does the model have to run on a device, or offline? If yes, open weights.
- Do you need to pin a version for years? If yes, open weights, since you control the checkpoint.
- Is the task open-ended and the volume low? A proprietary API is the cheaper answer in engineering time, and when self-hosting beats an API marks the crossover.
- Is the task bounded and the volume high? Fine-tune an open-weight model, and check the licence for the family you pick.
Most production systems end up mixed: specialised open-weight models on the high-volume structured work, a frontier API on the open-ended remainder. Model routing vs a single specialised model covers how those two tiers connect, and what size model do you need covers picking the open-weight half.