Open Weights vs Open Source, Platforms, and Standards

Open Weights, Open Source, Open Platforms, and Open Standards

Open weights, open source, open platforms, and open standards are not interchangeable. Each describes a different combination of artifacts, rights, governance, and continuing dependency.

The practical test is simple. Ask what you received, what you may do with it, what remains controlled, and what happens when the owner changes the rules.

flowchart LR
    A["Claim: this is open"] --> B["Which artifacts are available?"]
    B --> C["Which legal rights apply?"]
    C --> D["Which services remain controlled?"]
    D --> E["Which specification or governance body exists?"]
    E --> F["Write the precise claim"]

Open weights

Open weights means that learned model parameters are available under stated terms. The release may also include inference code, examples, a model card, or safety tools.

Weights alone do not reveal the complete training corpus, data-cleaning process, training code, optimizer state, evaluation process, or every design decision. They also do not create unrestricted rights. The applicable license controls use, modification, redistribution, attribution, and other obligations.

Meta’s Llama 3 release is a useful example. Meta distributed 8B and 70B model weights and supporting material under the Meta Llama 3 Community License. The license granted broad rights but imposed conditions, an acceptable-use policy, a restriction involving improvement of another large language model, and additional terms for very large services.

Calling that release open-weight under Meta’s license tells the reader more than the word open.

Open source

Open source is a standards claim about the freedom to use, study, modify, and share qualifying material.

AI complicates the older software framing because a model system can depend on code, data information, parameters, and tooling. The Open Source AI Definition 1.0 describes the preferred form for modifying a machine-learning system and includes data information, code, and parameters.

The definition is the Open Source Initiative’s standard. It is not legal advice or a court ruling. It is still useful because it prevents a marketing label from becoming the only classification test.

The OSI analysis of Llama 3.x concludes that Meta’s license does not meet its standards. A writer can report both facts without collapsing them: Meta called Llama open source, and OSI disagreed.

Open platforms

An open platform lets outside developers, device makers, publishers, or service providers participate through documented interfaces and rules.

The platform owner may still control admission, accounts, identity, stores, certification, monetization, APIs, data access, discovery, support, and roadmap. Participation can be meaningful without being unrestricted.

Meta’s Horizon OS partner announcement opened the operating system to named hardware partners and described a wider application ecosystem. It did not release every platform component as open-source software.

Open platform is therefore a relationship and distribution description. It is not automatically a source-code or license description.

Open standards

An open standard is a technical specification intended to support compatible implementation. The important questions concern access to the specification, governance, change control, intellectual-property terms, conformance, and adoption.

A proprietary product can implement an open standard. An open-source project can use a proprietary service. A platform can publish an API without becoming an open standard. The categories can overlap, but one does not prove another.

The edge-case test

When a claim still feels ambiguous, ask what a second party can actually do without special permission. Can it inspect the relevant source, reproduce the artifact, modify it, redistribute the result, build a compatible implementation, reach users outside the owner's store, or continue operating after the owner changes direction?

The answers may differ across layers. A model may expose weights while withholding training data. A headset may use open-source components while depending on a controlled store. A public specification may support interoperability while its reference service remains proprietary. Precise language records those differences instead of forcing one label onto the whole system.

A rights and dependencies map

How to write the claim

Name the artifact first. Then name the rights, restrictions, dependencies, and date.

“Llama 3 weights were available under Meta’s community license” is reviewable. “Meta open-sourced AI” hides the model version, artifacts, legal terms, and standards disagreement.

“Meta opened Horizon OS to selected hardware partners” is reviewable. “Meta open-sourced its operating system” asserts a source-code and licensing event that the announcement did not establish.

The same discipline improves procurement. A team can compare the value of access without pretending that access removes cost, safety, security, privacy, or exit obligations.

E013 introduced this language problem. E026 and E027 continue the model-access story. E029 examines training and evaluation claims. E038 shows why a public model claim still needs reproducible evidence.

This explainer is educational, not legal advice. Current licenses, policies, specifications, and platform terms must be reviewed for the exact version and intended use before publication or adoption.

AI assisted with research organization, structure, drafting, and validation. Dalton Anderson remains the attributed author and final editorial authority. The transcript and linked public sources control factual claims. Publication remains unauthorized.