Open weights, closed weights and the rights your firm needs

Source boundaries are recorded below. This guide is not legal advice and does not approve a deployment.

The useful starting question is not “Which model is most open?” It is “Which access and rights arrangement supports the work our firm intends to do?”

An Australian professional-services firm might need an assistant to classify internal documents, prepare material for human review or support a client-facing workflow. Those activities can require different permissions and controls. Access to downloadable files is not permission to do everything with them. Buying hosted access does not establish that a service is suitable for confidential work.

Before choosing a route to investigate, separate three things: what you can obtain, what you may do with it and what you must operate. Then test whether the proposed system can do the actual task.

Start with the intended work, not the label

Write a short statement of purpose before comparing models:

We want to use an AI assistant to classify internal documents into our existing records structure. Staff will review its suggestions. The initial evaluation will use synthetic documents. Client access and distribution of model files are outside this evaluation.

This is a fictional, untested scope example, not an approved deployment. Its value is that it makes the immediate decision smaller.

“Use AI in the business” is too broad to establish the rights needed. Internal inference, adapting a model, offering a client-facing service and giving someone model files are different activities. A possible future product should be recorded as a future requirement, not quietly folded into permission for an internal evaluation.

Also name the person responsible for the evaluation, the information it may use and the conditions that would stop it. Otherwise, a technically convenient trial can drift into a business dependency before anyone has resolved its terms or operating responsibilities.

Separate the labels

Dimension	What it tells you	What it does not establish
Closed weights	Trained parameters are not generally available for customers to download	Privacy, quality or suitability
Downloadable or open weights	Parameters can be obtained under stated terms	Permission for every use or open-source status
Source code	Some implementation, training or integration code is available	Rights to weights, data or other components
Data information	Information about the data used to develop the system is available	Availability of every raw training example
Hosted access	A provider operates a service you can access	Rights to download, modify or redistribute its model
Licence and companion terms	Permissions and obligations apply to specified artefacts or activities	That every component or service has identical terms

Closed weights and hosted access are not the same category

Closed weights describe the availability of trained parameters. Hosted access describes how you use a service.

A provider may offer a hosted API for a model whose weights are also downloadable. Conversely, a firm using a closed-weight service may have no practical need to download the model. The choice depends on the work, not on treating one label as automatically better.

With hosted access, examine the actual service: provider, endpoint, model identifier, relevant version or date, data handling and exit arrangements. Ask whether the model can change behind a stable service name and how that would affect testing.

Downloadable weights provide a choice, not a complete system

Obtaining weights may support operation on infrastructure selected by the firm, evaluation or permitted adaptation. It does not supply a maintained business service by itself.

Someone still needs to verify the files, select a runtime, secure the environment, manage updates and support the resulting workflow. The proposed hardware must also be adequate. File availability settles none of those questions.

“Open weights” should therefore prompt a more precise enquiry: which files, from which publisher, under which terms, for which activity?

Code and data information matter separately

Published code may cover architecture, inference utilities, training scripts or integrations. These components can have different repositories and terms. Possessing code is not the same as possessing trained parameters; possessing parameters does not necessarily provide everything needed to study or modify the system meaningfully.

The Open Source Initiative’s Open Source AI Definition 1.0 describes freedoms to use, study, modify and share an AI system. Its preferred form for modification addresses data information, code and parameters. Under that OSI framework, downloadable weights alone are insufficient.[B-1]

This is OSI’s definition, not a universal legal rule or evidence that every supplier uses the label consistently. Its treatment of data information should not be rewritten as a demand to redistribute every raw training example.

Treat adoption as five separate gates

A favourable answer at one gate must not stand in for evidence at another.

1. Licence: may we perform the intended actions?

Identify the exact artefact and the permissions relevant to the proposed activity. These may include business use, modification and redistribution, with obligations concerning attribution or notices.

A repository-card licence label is a useful starting point, not the answer. Hugging Face’s documentation describes licence metadata and directs users to seek out and respect the project’s licence.[B-2] Inspect the applicable text and the scope it covers.

The companion exact-weight licence worksheet helps you record permissions and unresolved rights questions; it does not provide legal clearance. The strategic decision here is whether the permissions needed for the current scope can be established.

2. Companion and service terms: what else governs the arrangement?

Check applicable acceptable-use conditions and, for hosted access, the relevant service agreement. Do not assume a downloadable model’s licence describes the hosted product’s data handling, retention or availability.

Likewise, “commercial use” is not a complete answer to every intended business activity. Running a tool internally does not establish permission to supply a modified checkpoint to a client.

If the terms are missing, conflicting or unclear for a material action, keep that action outside the approved scope pending review.

3. Deployment location and data path: where does information actually go?

Choosing an environment is not evidence that all processing stays there. Review the configured application, integrations, logging and other relevant data flows.

For hosted access, establish the service arrangements and configuration that apply to the proposed account and workload. For a self-operated system, examine the surrounding software rather than assuming that downloaded weights imply local-only processing.

Neither route is a privacy or Australian regulatory compliance finding. Confidential information should not be introduced merely because someone has described the model as “private” or “local”.

4. Technical feasibility: can we support it?

A legally permitted deployment can still be impractical. Check whether the proposed runtime, hardware and supporting systems can sustain the workload, and whether the firm has an accountable maintenance owner.

Do not commit to self-operation solely to avoid a subscription. Include setup, monitoring, updates and recovery in the evaluation. Equally, do not assume hosted access removes integration and support work.

Hardware sizing is a separate technical check: record the proposed runtime, memory capacity, workload and maintenance owner before selecting infrastructure.

5. Task suitability: does it perform acceptably in this workflow?

Access and permission say nothing about accuracy on your documents. Define representative test material, acceptable outcomes, human review and failure handling before relying on the system.

A model that runs successfully has passed a technical step, not demonstrated business fitness. Keep task testing distinct from the rights review. Record the task, representative examples, unacceptable errors and who checks results; this rights guide does not establish performance.

Choose the responsibility you can sustain

Hosted and self-operated arrangements shift responsibility; neither eliminates it.

Route to investigate	Main decision for the owner
Hosted service	Can we accept the specific provider dependency, terms, data path and version behaviour?
Self-operated weights	Can we establish the required rights and sustain the infrastructure, security and maintenance work?
Managed deployment of selected weights	Who is responsible for each part, and what evidence supports those boundaries?

A hosted service can reduce the underlying model infrastructure the firm must operate. The firm still owns its choices about information submitted, user access, integration and review of outputs.

Self-operation can provide more choice over the inference environment. That choice needs an owner, resources and controls. A neglected deployment is not made suitable by the openness of its weights.

The detailed responsibility matrix is in the companion guide Hosted access versus operating weights: who does what?. For this decision, identify any responsibility for which neither the firm nor a contracted provider has an established owner. That is a gap to resolve, not an incidental implementation detail.

Separate today’s evaluation from tomorrow’s product

Fictional decision example—not a client case, tested deployment or recommendation.

An advisory firm wants an internal document-classification assistant. It is also considering a future client workspace.

For the initial evaluation, the owner limits testing to synthetic documents and staff review. The team investigates two routes:

• A hosted service, checking the applicable terms and service behaviour.
• A downloadable checkpoint, checking exact-artefact rights and whether the team can support a test environment.

Neither route is selected merely because of its access label. If the hosted service meets the bounded evaluation requirements, downloading weights may offer no immediate benefit. If control over the inference environment is essential, the downloadable route warrants investigation—but still needs evidence at all five gates.

The future client workspace remains a separate decision. It might change the users, information, delivery method and permissions required. Providing access to an application is also different from distributing model files. The owner records those possibilities without claiming they have been cleared.

This prevents two avoidable mistakes: overbuilding infrastructure for a small evaluation, and treating a successful evaluation as permission for a materially different product.

Make a bounded decision

Use the following rule:

• Go to a defined evaluation when the exact access arrangement and required permissions are evidenced, the information boundary is acceptable, operating responsibilities have owners and a task test is specified.
• Hold the affected activity when a material permission, data path or operating responsibility is unresolved. Do not treat missing evidence as a favourable answer.
• Name the next check precisely: for example, identify the checkpoint’s applicable licence, obtain the proposed service terms or verify the configured logging path.

“Go” means proceed within that recorded scope. It is not blanket production, legal or compliance clearance.

For the next educational step, use the exact-weight licence worksheet to record permissions and unresolved rights questions, Hosted access versus operating weights for operating responsibilities, and Using model outputs for training and distillation for output-reuse rights questions. For systems that can take actions, use the published agent tool-authority guide to define what the agent may read or change. It owns that separate question.

Sources and boundaries

• [B-1] Open Source AI Definition 1.0, especially the freedoms and preferred form for modification. This is the OSI framework, not a universal legal classification or a licence for a particular checkpoint.
• [B-2] Hugging Face licence documentation, on repository-card metadata and checking the project’s actual licence.

These primary passages were checked on 5 October 2026. The proposed checks are a decision method; no named checkpoint, customer account or deployment is cleared by this article. The timeline’s seven weight-licence milestones show source-specific changes and their qualifications.