What Counts as Open Enough?
The EU AI Act does not decide whether a GPAI model is “open” by looking at a project label or a download button. This chapter focuses on the factual test behind the Article 53(2) exception: what rights does the licence grant, and what information about the model is publicly available? By separating those two questions, readers can evaluate a release on evidence rather than assume that open weights, public code, or free access automatically creates relief.
The test has two parts. First, the model must be released under a free and open-source licence that allows access, usage, modification, and distribution. Second, the model’s parameters—including its weights—and information on its architecture and usage must be made publicly available. The wording matters because the conditions work together. A release can be unusually accessible and still fail to establish every fact the rule requires.
A licence is a set of permissions
In ordinary conversation, “free” can mean that a model costs nothing to download. In a legal licence, “free” describes what the recipient is allowed to do. Those are different ideas. Article 53(2) uses the phrase “free and open-source licence” and then identifies four permissions: access, usage, modification, and distribution.
Each permission answers a different practical question. Can people obtain the model? Can they run it for their own purposes? Can they alter it? Can they pass the model or a modified version to someone else? The rule’s structure treats all four as relevant. It is not enough to show one or two of them and infer the rest.
That cumulative character is the first safeguard against a misleading label. A provider may describe a project as open because the weights can be downloaded, while the accompanying terms restrict modification. Another release may permit experimentation but limit redistribution. A model may be available without a fee while its licence reserves a category of use. The sources do not provide a complete catalogue of licence edge cases, but the legal starting point is clear: a reader must inspect the actual permissions instead of treating “open-source” as a conclusion.
The same distinction applies to public code. Source code can help people understand or reproduce part of a system, but the Article 53(2) question concerns the licence under which the GPAI model is released. The public availability of code does not, by itself, prove that recipients may use, modify, and distribute the model or its parameters. A software repository and a model release can have different terms, different owners, and different boundaries.
Nor does a free download settle the question. A provider can make a model available at no charge while retaining restrictions that matter to modification or redistribution. Price is therefore a poor substitute for permission. The reader needs the licence terms that govern the model itself.
This is also why the legal test should not be turned into a popularity contest between licensing philosophies. The relevant question is not whether one licence is generally “more open” than another. It is whether the particular release gives the four permissions identified by the rule. If the facts do not establish one of them, the safest conclusion is not that the project has failed every possible legal obligation; it is that the Article 53(2) documentation exception has not been shown on the available facts.
A useful inspection starts with the terms that govern the model itself, not with a repository description or a community reputation. Imagine one provider permits anyone to download and run the weights but reserves the right to modify them to the provider alone. That release may be accessible without giving recipients the modification permission named in the rule. Imagine another provider allows modification but attaches terms that restrict how a changed version can be passed on. The selected sources do not resolve every such licence design, but the examples show why a reader must check each permission separately rather than infer the whole set from one favourable feature.
Those permissions also affect what later actors can do. Access and usage determine whether a recipient can operate the model. Modification determines whether a fine-tuner can create a changed version under the release terms. Distribution determines whether that changed version can move onward through the ecosystem. The licence is therefore not only a legal label attached to the original provider; it helps shape the chain of actors that may appear after release. That does not decide the downstream legal analysis, but it explains why the licence must be read before the exception is claimed.
Public availability means more than a downloadable file
The licence test is only half of the inquiry. Article 53(2) also requires that the model’s parameters, including the weights, and information on the model architecture and model usage be made publicly available. This is a separate condition about the technical and informational package surrounding the release.
The word “parameters” matters because a model’s public description is not the same as a public model. A page that explains a model’s purpose may help people understand it, but it does not necessarily make the parameters available. The text specifically includes weights, which are central to running and inspecting many released models. A provider that publishes general information while keeping the weights private has not presented the same kind of release as a provider that makes the weights available.
Architecture information serves another function. It tells a reader something about how the model is organised, rather than merely what the publisher hopes it will do. The short Article 53 text does not specify every level of detail or a single required format. It does, however, make architecture information part of the public-information condition. A release package cannot be assessed only by asking whether a file can be downloaded.
Usage information adds a third perspective. People need to know how the model is meant to be used and what constraints or limitations accompany that use. This information can shape the decisions of a downstream provider integrating the model into an AI system. It also helps distinguish a technical release from a responsible handoff: access without usable information may leave later actors unable to judge whether the model fits their intended context.
The conditions are best understood as complementary. A licence gives rights to recipients; public parameters and related information give them something meaningful to access, use, modify, or distribute. If the licence grants broad rights but the model’s weights or architecture information are withheld, legal permission does not become technical availability. If the weights are public but the licence does not allow modification or redistribution, technical access does not become the required legal openness.
This is the point at which “open weights” can mislead. Public weights may satisfy one important part of the release package, but the rule also refers to the licence, architecture information, and usage information. The phrase “open weights” is therefore evidence about one feature, not a complete answer to the exception question.
The two-part test
A reader can represent the rule as a sequence without pretending that it is a complete compliance opinion:
The word possible in the final node is important. Meeting the two conditions does not mean the provider is exempt from the AI Act, and it does not answer the separate question of systemic risk. It means that the provider may have reached the eligibility threshold for the specific Article 53(2) relief, subject to the facts and the rule’s express limits.
The diagram also shows why the test should not be applied as a checklist with a single vague input called “open.” The licence and the public release package are separate evidence sets. A provider should be able to show the terms that govern access and the technical information that the public can actually obtain. If one set is missing, the conclusion must stop at the point the evidence stops.
What the text leaves open
A precise rule can still leave implementation questions. Article 53(2) identifies architecture and usage information, but the selected sources do not establish how detailed each must be in every situation. They do not supply a universal format that makes any release automatically sufficient. Nor do they resolve all licence designs, such as terms that grant broad permissions but attach conditions to a particular kind of redistribution or modification.
These are not reasons to replace the legal test with a general statement that “anything goes.” They are reasons to distinguish clear conditions from unresolved application. The licence must allow the four named activities. The parameters, weights, architecture information, and usage information must be public. Beyond that, a real assessment may require more facts or future guidance.
The distinction is especially important for a release that mixes openness with limited disclosure. Imagine a provider publishes weights under a licence that appears permissive but gives little information about architecture or intended use. The evidence points in two directions: recipients may have substantial technical access, but the complete Article 53(2) condition is not established by weights alone. A careful reader should record what is known, identify the missing element, and avoid turning uncertainty into either automatic qualification or automatic condemnation.
The reverse scenario is equally instructive. Suppose a provider publishes extensive architecture and usage information but allows only restricted access or prohibits redistribution. The release may be transparent in one dimension and still fail the cumulative licence test. Public explanation cannot replace the permissions the rule names.
Why no single openness signal dominates
The comparison between these cases reveals a general principle. No single signal—price, source code, weights, documentation, or community reputation—dominates the others because the conditions perform different jobs.
- Licence permissions determine what recipients are legally allowed to do.
- Parameters and weights determine whether the released model is technically available in a meaningful sense.
- Architecture information helps others understand what they are receiving.
- Usage information helps shape later decisions about how the model should be applied.
This is not an invitation to create a much longer private taxonomy of release types. It is a reason to preserve the rule’s structure. The exception is aimed at a form of open release that combines rights to use and change the model with enough public information to make the release inspectable and usable. The precise boundaries still require interpretation, but the reader knows which facts the interpretation must address.
It also clarifies the relationship between the provider and later actors. A qualifying release may give recipients more freedom to inspect or adapt the model, but that freedom does not tell an integrator whether a particular application is appropriate. Public usage information can help, yet the integrator still has to consider the system they are building. The model’s openness can improve the evidence available downstream without eliminating downstream judgment.
The test is necessary, not sufficient
At this point, the reader can make a bounded statement: if the licence permissions and public-information conditions are both established, the provider may be able to rely on the Article 53(2) exception for the specified documentation duties, unless the systemic-risk carve-out applies. If either condition is missing, the exception is not established on the known facts. If the facts are unclear, the appropriate result is an unresolved question, not a confident label.
That bounded statement is deliberately smaller than “the model is exempt.” The previous chapter identified the duties from which relief might be carved. This chapter identifies the facts that can make the carve-out available. The remaining issue is what happens after the test appears to succeed: which duties continue, how systemic risk changes the result, and how the answer should be applied to realistic release scenarios.
A release can therefore be open in a meaningful everyday sense and still fail the legal conditions, or satisfy the conditions and still remain part of a wider accountability chain. The next test is not whether the model has a better label. It is whether the claimed relief is limited to the duties and facts that the rule actually covers.