A Practical Test for Open-Source AI Releases

A real release rarely arrives with every legal and technical fact neatly labelled. The provider may call a model open-source, the licence may contain conditions, the weights may be public while usage information is sparse, and several organisations may have changed or deployed the model. This chapter turns the earlier rules and value-chain map into a disciplined judgment method: check the Article 53(2) conditions first, identify the actor and lifecycle layer, then ask who controls, foresees, benefits from, and can mitigate the relevant risk.

The method is not a substitute for a complete compliance assessment or legal advice. Its purpose is narrower and more useful for an initial decision: to prevent a label from doing the work of evidence, to keep model-level relief separate from system and deployment duties, and to show what question should be asked next when the facts are incomplete.

Start with the statutory test

The first step is not to debate whether a project is philosophically open. It is to collect the facts that Article 53(2) actually makes relevant. Identify the person or organisation that developed and made the GPAI model available. Then inspect the licence: does it allow access, usage, modification, and distribution? These are the four permissions named by the rule, and the selected evidence does not support replacing them with a looser measure of openness.

Next inspect the public release package. Are the model’s parameters, including the weights, publicly available? Is information about architecture public? Is information about model usage public? A free download or public repository may be useful evidence, but it does not answer all three questions. If one element is missing, the narrow documentation exception has not been established on the known facts.

Then check systemic risk. Article 53(2) expressly excludes GPAI models with systemic risks from the exception. The sources used here do not provide a complete current classification procedure, so a reader should not invent a threshold from a general description. The correct sequence is to identify whether the category is relevant and, if it is, treat the carve-out as decisive.

Finally, write down what the exception would and would not change. The rule concerns the obligations in Article 53(1), points (a) and (b): technical documentation for authorities and information and documentation for downstream AI-system providers. It does not erase the copyright policy, public training-content summary, or cooperation duty described in the same article. It also does not decide what obligations may attach to a later AI system or deployment.

This first pass produces a bounded model-level conclusion. The release may qualify for narrow relief; it may fail because a condition is missing; or the available facts may be insufficient. None of those results, by itself, determines whether a fine-tuned model, integrated system, or deployment is lawful or appropriate.

Identify the actor and the layer

The next step is to locate the decision in the model’s lifecycle. Ask whether the relevant actor is the original model provider, a fine-tuner, an integrator, or a deployer.

The original provider controls upstream design and release choices. A fine-tuner changes an existing model and may become a provider of a new model, although the selected evidence does not provide a bright-line threshold for that transition.