A 2024 definition sets three tests for calling AI open source

Three requirements, spelled out

The Open Source Initiative's Open Source AI Definition, finalised as version 1.0 around the organisation's All Things Open conference in late October 2024 according to its own published process timeline, sets out what an AI system must provide to be called open source. The definition requires three elements under OSI-approved terms: "data information" detailed enough that "a skilled person can build a substantially equivalent system"; "the complete source code used to train and run the system"; and "the model parameters, such as weights", including intermediate checkpoints. All three, the text states, must support the same four freedoms as the original Open Source Definition - to use, study, modify and share.

Why weights alone are not enough

The definition's central move is separating "open weights" from "open source". A model whose parameters are downloadable but whose training data is undisclosed and whose training code is unavailable meets only one of the three requirements. On the timeline's own account, this definition followed a multi-year, co-designed drafting process, with a release-candidate stage debated publicly through 2024 before the stable 1.0 text was announced. That process is itself evidence that the line between "open weights" and "open source" was contested among the people who wrote the definition, not a settled fact the OSI is merely reporting.

A definition, not a certification body

The document sets criteria; it does not itself audit or certify that a named model complies, and this analysis has not tested any specific release against it. Many widely used models publish weights under licences with use restrictions or scale thresholds - for example the Llama 2 Community License Agreement, which caps free use at a stated monthly-user threshold - which the OSI's own criteria would treat as falling short of the data-information and code requirements. Readers should check a model's actual data-disclosure and training-code availability against the text above rather than assume a vendor's use of the word "open" tracks this definition.

• Does the model's provider publish data information detailed enough to attempt a substantially equivalent build, or only a general description?
• Is the training code published, or only the inference and fine-tuning code?
• Does the licence attached to the weights impose a use restriction or a user-count threshold that the four freedoms would not permit?

Calling a model "open" is a marketing choice; checking it against a written definition with three concrete requirements is a verification step. The OSAID gives reviewers a checklist rather than a single label, which is the more useful thing for a deployer deciding what a claim of openness actually commits a vendor to.