Blog / Industry

Published weights are not open source, and the difference is a test

"Open" in AI usually means you can download the weights under a license. Open source means you can rebuild, modify, and redistribute. The useful question is what each one lets an outsider check.

When a model or robot stack is announced as "open," ask one question before you celebrate: could an outsider rebuild it and check the claims made about it?

If yes, it's open in the sense that matters. If you can download it but not rebuild it, inspect it but not change and redistribute it, it's a published artifact under a license. That can be valuable. It's still a different thing.

The claim #

The line between open source and published-license releases isn't ideological. It's about verification. Open source lets outsiders reproduce and audit. A published-license release lets them use. Treating the second as the first inflates trust that nobody has earned.

Why the word matters #

"Open source" has a specific meaning in software, set out in the Open Source Initiative's definition: freedom to use, study, modify, and redistribute, without discrimination against people or fields of use. Licenses that restrict who can use the thing, for what, or above what scale don't meet it, whatever they call themselves.

In AI, the confusion is easy because a model has several parts, and releases often open some and close others:

  • Weights. The trained parameters. Often released, often under a custom license.
  • Code. Training and inference code. Sometimes released.
  • Data. What the model was trained on. Rarely released in full, and sometimes impossible to release for legal reasons.
  • Recipe. Hyperparameters, data mixtures, filtering, and the evaluation harness. Often described loosely, rarely shipped.

A release with weights and inference code but no data or recipe lets you run the model. It doesn't let you rebuild it or answer questions like "was this benchmark in the training set?" Those are exactly the questions oversight needs answered.

The RP1 case #

This came up when Luna posted about RoboParty's RP1 being released as open source. I replied with a narrow question: which parts? Hardware designs, firmware, training code, policy weights, and the data used to train those policies are different layers, and "open" can apply to any subset of them.

RoboParty's own repositories answer most of that question, and the answer is better than most "open" launches. The RP1 overview repository, released under GPL-3.0, links out to the parts.1 As of launch day, Oct 16, the mechanical and electrical sources are under the CERN Open Hardware Licence (weakly reciprocal, v2), the joint-module materials are under CC BY 4.0, and the firmware and deployment SDK are under GPL-3.0.2 Those are real open licenses for hardware, documentation, and code.

Two layers are less clear. The training repository and the robot-description files (URDF and MJCF models) carried no license file when I checked, and published code without a license isn't legally reusable, however public it is. I also didn't find trained policy weights or the data behind them listed as release contents. Those gaps may close. Until they do, "full-stack open source" is accurate for the hardware and the low-level software, and not yet for the learning layer.

For robotics, the distinction bites harder than for chatbots. A robot policy that can be downloaded but not retrained can't be independently tested for the failure cases its makers didn't think to test. A hardware design you can inspect but not legally modify and redistribute can't be improved by the community that's supposed to make open hardware worthwhile.

I'm not arguing RoboParty did anything wrong. I'm arguing the label should tell you which of these you can do.

Published licenses aren't bad #

To be fair to the other side: releasing weights under a restrictive license is still far more open than a closed API. Researchers can probe the model's behavior directly, run interpretability work, test it offline, and fine-tune it for legitimate uses. That's real value, and labs that do it deserve credit.

The problem is only the label. Call it what it is — published weights, licensed for these uses — and nobody's misled. Call it open source and people assume they can rebuild, audit, and fork, then discover they can't when it matters.

A checkable standard #

Here's a short rubric I'd like to see attached to every "open" release, one line per layer:

  1. Weights: released? under what license?
  2. Code: training and inference both, or inference only?
  3. Data: released, documented, or neither?
  4. Recipe and eval harness: shipped, described, or omitted?
  5. Redistribution: can modified versions be shared, and with whom?

Five lines. It tells an outsider exactly what they can check and what they'll have to take on faith. It costs the releaser nothing they didn't already know.

What to watch #

Releases that publish all five layers will get independent replications and audits within months. Releases that publish weights only will get fine-tunes and benchmarks, but almost never a rebuild. If weights-only releases start producing independent audits of training data and recipe, my distinction matters less than I think.

Until then, read "open" as a claim about one layer, and ask which.

Notes

  1. RoboParty, RP1 overview repository on GitHub, and the launch announcement, “No More Black Boxes: RoboParty Launches Full-Stack Open-Source RP1”, PR Newswire, Oct 16, 2026. ↩
  2. License metadata as shown on GitHub on Oct 16, 2026: rp1_hardware (CERN-OHL-W-2.0), ROMOMO (CC-BY-4.0), RP1_firmware and roboparty_deploy (GPL-3.0); roboparty_train and RP1_description had no license file. ↩