Open weights are not open source

I keep running into model releases that call themselves open source, and I have started actually reading the licence attached to the weights before I let the word through into anything I write about them. The habit started the day I found a field-of-use clause in one of these licences — a restriction on what kind of application the weights could be used inside — sitting a few paragraphs below a page that used the phrase open source three times. That is not a minor labelling quibble. It is the specific thing the term was defined to rule out.

The Open Source Definition is the document that actually fixes what the term means, and it is more precise than the way the industry throws it around. Its sixth criterion states, verbatim, that “the license must not restrict anyone from making use of the program in a specific field of endeavor.” The first criterion requires free redistribution, and the second requires the source code itself be available, not just a compiled artefact. None of those three is a stylistic preference. Each one is closing a specific door a vendor might otherwise want left open — restricting a competitor’s use case, controlling who can redistribute, or keeping the actual buildable form of the thing to themselves while shipping only the finished product.

Model weights sit in an odd spot against that second criterion even before you get to licensing terms. Source code is the human-editable form a compiled binary comes from — change the source, rebuild, get a new binary. You can inspect a compiled binary’s behaviour and, with the source in hand, understand and change why it behaves that way. Having the weights alone lets you run the model and, within limits, fine-tune it, but it does not let you understand or change the process that produced its behaviour in the first place, because that process never shipped with the release. Weights are the end state of a training run, and having them does not hand you the thing that produced them: the training data, the training code, the hyperparameters, the decisions about what to filter out and what to keep in. A released weight file is closer to a compiled binary than to source, whatever adjective the release page reaches for. Calling it open by the same standard that governs a codebase is comparing two different kinds of object and pretending the comparison is exact.

Then there is the licence itself, which is where criterion six actually starts to matter for real usage decisions rather than abstract ones. A model I can download but not deploy inside a particular kind of product is not open by the definition’s own terms, whatever the download page says, because the definition rules out exactly that shape of restriction. I have started reading the licence text of a released model the same way I would read the terms on any other piece of infrastructure I am about to depend on for my estate: what am I actually allowed to build with this, and does that restriction sit somewhere I have not noticed yet. More than once the answer has changed which release I picked, because the more permissively licensed option was the one I could actually trust not to constrain me six months into a project.

None of this makes an open-weight release useless or dishonest to want — plenty of them are genuinely valuable, and I use several of them myself. What I have stopped doing is letting the phrase open source stand in for due diligence on what the licence actually permits. The two questions are separate: is this useful, and is this open by the definition that term was built to enforce. Conflating them is how a field-of-use restriction ends up buried three paragraphs into a licence nobody reads before building on the thing it governs, and I would rather catch that before committing my estate’s infrastructure to it than after. I now check the licence before a model goes anywhere near my pipeline, not after I have already built around it, because unwinding a dependency on the wrong terms costs far more than reading them up front would ever have.