Open-weight LLMs let an enterprise run a model's parameters on its own infrastructure, but the weights come with a licence, an acceptable-use policy and a supply chain, and each one can create obligations or risk. Before production, someone must answer three questions. Are we allowed to use the model this way? Can we trust the files we downloaded? Can we defend the choice to auditors, customers and regulators? This guide covers licence types, derivative obligations, provenance and security checks, and an approval process you can adapt.
For choosing between candidate models, see how to choose an LLM for enterprise. Serving (GPUs, inference servers, quantization) is covered in the self-hosting LLMs guide, and model size in small language models for enterprise. This article assumes you already have a candidate model and need to get it approved.
Open-weight vs open-source AI
"Open-weight" means you can download the trained parameters. On its own, that says nothing about what you may do with them. An open-weight model can still have a licence that bans some uses, caps commercial scale, or requires attribution on anything you build from it.
"Open source" has a stricter meaning. The Open Source Initiative (OSI) publishes an Open Source AI Definition. In general terms, it requires that you are free to use the system for any purpose, study how it works, modify it and share it. It also requires the "preferred form" for making modifications:
- Parameters: the weights and configuration.
- Code: the source used to process data, train the model and run it.
- Data information: enough detail about training data that a skilled person could build a substantially equivalent system. Publishing the full dataset is not always required.
Many popular open-weight models fall short of this. Some lack training code or data information, and some have use restrictions that conflict with "any purpose". This matters in practice. Your procurement team's list of approved open-source licences may not cover a model just because its announcement called it "open". And the less a publisher discloses about training data, the harder governance questions become. In internal documents, call a model "open-weight" unless it actually meets an open-source definition.
Open source LLM licence types
Model licences fall into three broad groups. Terms can change between generations, and even between sizes in the same family, so check the licence for the exact repository and revision you will deploy.
Permissive licences (Apache 2.0, MIT)
Enterprises already know these software licences. They generally allow commercial use, modification and redistribution as long as you keep the notices. Apache 2.0 also includes a patent grant and asks you to mark files you changed. Examples at the time of writing, according to their model cards: OpenAI's gpt-oss models and Qwen3 models are under Apache 2.0, many of Mistral's open models use Apache 2.0, and DeepSeek-R1's code and weights are under MIT. A permissive licence covers only the weights. It says nothing about training-data rights or base-model licences.
Custom community licences
Some publishers write their own terms. The Llama community licences are the best-known example. Common clauses include:
- Scale thresholds: very large organisations (for Llama, those above a monthly-active-user threshold) must ask the publisher for a separate licence.
- An incorporated acceptable-use policy that you must follow.
- Attribution and naming: for example, displaying "Built with Llama", and starting the name of any derivative model you distribute with "Llama".
- Limits on using outputs to improve other models.
Many enterprises approve these licences. Each one needs its own legal review, and its conditions must be enforced in engineering. A single family can mix licence types: Qwen2.5, for example, released some sizes under Apache 2.0 and others under Qwen-specific licences.
Research-only and non-commercial licences
Some weights are released for research or non-commercial use only. Block these for production and internal business use unless legal confirms otherwise. The usual failure is not a deliberate breach. A research-licensed model wins a proof-of-concept benchmark, and nobody re-checks the licence when the pilot becomes production.
| Licence group | Commercial use | Typical obligations | Approval effort |
|---|---|---|---|
| Permissive (Apache 2.0, MIT) | Generally allowed | Keep notices; Apache adds change marking and patent terms | Low; still verify repository and base models |
| Custom community | Allowed with conditions | Acceptable use, thresholds, attribution, naming, output-use limits | Medium; legal review per licence version |
| Research-only / non-commercial | Not without a separate agreement | Research or evaluation only | Block for production by default |
Acceptable-use policies
An acceptable-use policy (AUP) lists prohibited uses. These usually include illegal activity, malware, harassment, deceptive impersonation and some high-stakes automated decisions. An AUP may be part of the licence or a separate document that the publisher can update.
Whether you comply depends on the use case, not just the model. A model approved for summarising internal tickets is not automatically approved for credit decisions or for a public chatbot. So:
- Record approved use cases next to each model in your inventory.
- Re-check the AUP whenever someone proposes a new use case.
- Keep a dated copy of the licence and AUP you reviewed. A link to a page that can change is not an audit record.
- Where you can, block prohibited uses technically through your guardrails.
Derivative and fine-tuned model obligations
Fine-tuning, merging, quantizing and distilling all create derivatives. Before a fine-tuning project starts, answer these questions:
- Does the licence carry over? Custom licences often require derivatives to keep the same terms and notices.
- Internal use or distribution? Many obligations apply once you distribute a model or make it available to others. If an Indian services firm or GCC delivers a fine-tuned model to a client or another group entity, that may count as distribution.
- Training on outputs: using one model's outputs to train another is the core of model distillation. Some licences restrict it. Others allow it explicitly, and DeepSeek-R1's model card is one example.
- Inherited licences: a derivative also inherits its base model's licence. DeepSeek-R1's card notes that its distilled variants built on Llama and Qwen bases carry those base licences.
Keep a lineage record for every derivative. It should list the base model and revision, the licence, the fine-tuning datasets and their licences, and the checksum of the resulting artefact.
Attribution and notices
Permissive licences require you to keep licence and copyright notices when you redistribute. Some custom licences also require visible attribution in the product or its documentation. Ship a third-party-licences file with the model package and container image. Track model licences in your software bill of materials, just like library licences.
Provenance and supply-chain risk
Treat a model file as executable risk, not just data. Controls to apply when you adopt a model:
- Source: download only from the publisher's verified organisation on the hub. Lookalike repositories and "optimised" re-uploads are common attack vectors.
- Format: pickle-based checkpoints can run arbitrary code when loaded. Prefer
safetensors, which stores tensors without executable content. - Remote code: avoid repositories that need custom loader code, or review and pin that code like any other dependency.
- Pin and checksum: record the exact revision and file hashes. Mirror approved artefacts into an internal registry and serve only from there.
- Scan: hub scanning is best-effort, so run your own malware and format checks during intake.
Hub (verified org)
| pinned revision
v
Intake: format check -> hash -> scan
| pass
v
Internal model registry (versioned)
|
v
Eval + red-team gate -> approvedDevSecOps for enterprise AI shows how to automate these checks in CI alongside container and dependency scanning.
Training-data transparency and copyright
Publishers disclose very different amounts about training data, from detailed documentation to a single paragraph. Copyright and data-protection questions about training on scraped content are still unsettled in several jurisdictions. Engineering teams can't resolve those questions, but they can make the risk visible:
- Record what each publisher discloses, and flag models with minimal disclosure for extra review.
- Note the indemnity position. Open-weight models are usually provided as-is, while some commercial APIs offer indemnities with conditions. Compare both routes using your AI vendor due diligence checklist.
- Add review steps for generated content that is published externally.
- Fine-tune only on data you have rights to, and document where it came from.
Jurisdiction, export and sanctions
Where the publisher is based, which law governs the licence, and where you deploy can all matter. Raise these points with legal and compliance:
- The licence's governing law and venue, and whether your group's policy accepts them.
- Regional limits that some licences or AUPs have placed on particular uses.
- Export controls and sanctions on AI technology, compute and counterparties. These change over time and differ by country, which matters when a GCC serves group entities abroad.
- Client or regulator policies on where software and models originate, especially in banking.
- Rules for EU deployments: see the EU AI Act for Indian IT teams.
These rules change often, so consult legal for current guidance on your facts.
Want a structured path through LLMs, RAG, agents and model governance with hands-on labs? Cloudsoft's AI, GenAI and Agentic AI course covers these foundations in our Ameerpet classroom or live online.
Security evaluation before adoption
A clean licence and verified files are not enough. Test how the model behaves:
- Safety behaviour: test refusals and resistance to jailbreaks. Safety tuning in open weights can be weak or easy to remove, so re-test every derivative.
- Prompt injection and tool misuse: run the scenarios from your AI red teaming playbook if the model reads untrusted content or calls tools.
- Hidden behaviours: a backdoored model can act normally until a trigger appears, and no test proves a backdoor is absent. Trusted sourcing and pinned artefacts are your main defence.
- Leakage: check whether the model reproduces memorised sensitive text, especially after fine-tuning on internal data.
Link the results to the specific revision you tested. A new revision needs a new evaluation.
An internal model-approval process
Good enterprise open model governance means a repeatable gate, not a fresh debate for every request. The process below plugs into the inventory and risk tiers described in enterprise AI governance.
| Stage | Owner | Checks | Evidence |
|---|---|---|---|
| 1. Request | Requesting team | Use case, data classification, users, deployment target | Request with risk tier |
| 2. Licence review | Legal / open-source office | Licence group, thresholds, AUP, derivative and output rules, attribution, governing law | Dated licence copy; decision with conditions |
| 3. Provenance intake | Platform / security | Verified source, pinned revision, safetensors, no unreviewed remote code, hashes, scans | Artefact in internal registry |
| 4. Transparency review | Governance / risk | Training-data disclosure, model card, limitations, indemnity | Risk notes and extra controls |
| 5. Evaluation and red team | AI engineering + security | Task quality, safety, injection, leakage, bias where relevant | Eval report tied to revision |
| 6. Jurisdiction check | Compliance | Export, sanctions, client and regional restrictions | Sign-off or restrictions |
| 7. Approval | Risk-tiered review board | Evidence complete; conditions assigned | Inventory entry: revision, licence, use cases, expiry |
| 8. Re-review | Product owner | Licence or AUP change, new revision, incident, new use case | Re-review on trigger or expiry |
Two choices keep the process workable. First, tier the effort: an internal use case on a permissively licensed model should get a lighter path than a customer-facing one. Second, approve a specific model revision for a specific use case, not the model in general.
Illustrative example: a bank GCC approves an open-weight model
Consider a bank's capability centre in Hyderabad that wants a self-hosted internal assistant. It would summarise operations runbooks and draft incident notes for the bank's IT teams in several countries. Data residency rules favour self-hosting.
- Request: two models score well on the team's eval set, one under Apache 2.0 and one under a custom community licence. The data is confidential but the use is internal, so the request is classed as medium risk.
- Licence: legal clears both. For the custom licence, legal notes that naming and attribution rules would apply if a fine-tuned version were later shared with other group entities. The team chooses the Apache 2.0 model to keep future reuse simple.
- Provenance: platform engineering pulls the pinned revision from the verified organisation and confirms the files are safetensors only. It declines an optional remote-code loader, records the hashes and mirrors the model internally.
- Transparency: the model card gives only general information about training data. Because a human reviews every draft, risk accepts this and records it.
- Evaluation: injection tests show that instructions planted in runbooks can change the output format. The team adds input sanitisation and output checks.
- Approval: the board approves this revision, for this use case, in these regions, with a review date. When another team later asks to use the model for customer chat, the request goes back through stages 1, 2 and 5.
The result is more than a running model. The bank has an evidence trail it can show auditors and regulators. Moving work like this from demo to an audited production system is what Forward Deployed Engineers do inside customer organisations.
Not legal advice
This article is general engineering and governance guidance, not legal advice. Licences, AUPs and regulations change, and how they apply depends on your circumstances. Verify the current licence for the exact model and revision you use, and let your legal and compliance teams make the final call.
Frequently asked questions
What is the difference between open-weight and open-source AI?
Open-weight means the trained parameters can be downloaded under whatever licence the publisher chooses. Open-source AI, as defined by the Open Source Initiative, also requires freedom to use, study, modify and share the system for any purpose, plus access to the code and enough training-data information to build a substantially equivalent system.
Can I use open-weight models commercially?
Often, depending on the licence. Apache 2.0 and MIT generally allow commercial use with notice requirements. Custom community licences allow it with conditions such as acceptable-use policies, scale thresholds and attribution. Research-only or non-commercial licences do not allow it without a separate agreement.
Does fine-tuning an open-weight model change its licence?
Usually not. A fine-tuned model is a derivative and normally stays bound by the base model's licence, including any naming, attribution and acceptable-use terms, especially once you distribute it. Keep a lineage record for every derivative.
Why prefer safetensors over other model file formats?
Pickle-based checkpoint files can execute arbitrary code when loaded. Safetensors stores tensors without executable content. Combine it with verified sources, pinned revisions, checksums and an internal model registry.
Is a model from a well-known hub automatically safe?
No. Hub scanning is best-effort and anyone can create a lookalike repository. Download from the publisher's verified organisation, pin the revision, verify hashes, run your own scans and serve from an internal mirror.
Do open-weight models come with copyright indemnity?
Generally not. Open-weight models are usually provided as-is, whereas some commercial API providers offer indemnities with conditions. Ask legal how much residual risk is acceptable for your use case.
Who should own open model governance?
Ownership is shared. Legal owns licence decisions, platform and security own provenance, AI engineering owns evaluation, compliance owns jurisdiction checks, and a risk-tiered board approves each combination of model revision and use case.
How often should an approved model be re-reviewed?
Re-review whenever something changes: a new revision, a licence or acceptable-use policy change, a new use case, an incident or a new deployment region. Also give every approval an expiry date.
Ready to build these skills, from LLM fundamentals to RAG, agents, evaluation and governance? Join Cloudsoft's GenAI and Agentic AI training in Hyderabad, in the Ameerpet classroom or live online. Call +91 96660 19191 for a free demo.
