No, not in general. Article 2(12) excludes AI systems released under free and open source licences from the scope of the Regulation, except for high risk systems, Article 5 prohibited practices and Article 50 transparency systems. A free and open source system that is high risk, that falls within a prohibition, or that is subject to Article 50 must meet the duties that apply to its category, even though it is open source. For general purpose AI models, Article 53(2) relieves a provider from two documentation duties only, where the licence and public availability conditions are met, and does not relieve the provider from the copyright policy or the training summary duties, or from the systemic risk duties. Open source changes which duties apply in defined cases; it does not remove the Act from the system.
What does Article 2(12) exclude, and what does it not exclude?
Article 2(12) provides that the Regulation does not apply to AI systems released under free and open source licences, unless they are placed on the market or put into service as high risk systems, as systems that fall within Article 5, or as systems subject to Article 50. The exclusion therefore applies to AI systems, not to general purpose models as such, and it applies subject to the three exceptions. A system that is released under a free and open source licence, and that is not high risk, not prohibited and not subject to Article 50, is outside the Regulation on that ground. A system that is released under such a licence, but that is intended for a high risk purpose, that falls within a prohibition, or that is subject to transparency duties, is inside the Regulation for the duties that apply to its category. The licence alone does not decide the exclusion. The licence must be a free and open source licence, the release must be under that licence, and the system must not fall within an exception. A licence that restricts use, that reserves rights, or that is not recognised as free and open source will need to be examined, and the exclusion should not be assumed from the label open source alone. The record should state the licence, the release terms, and the exception analysis, with the Article 2(12) text checked.
How does monetisation affect the exclusion?
Recital 103 states, in outline, that free and open source AI components should be understood as software and data, including models, released under licences that allow access, usage, modification and redistribution, and that the exclusion should be understood in the context of the open source ecosystem, with commercial activities, including charging for a service or for support, not by themselves removing the exclusion where the licence conditions are met. A recital is an aid to interpretation, not an operative provision, and the operative provision is Article 2(12). A provider that charges for hosting, for support, for a managed service or for a downstream product should therefore not assume that charging alone removes the exclusion, and should not assume that charging alone preserves it. The question is whether the system is released under a free and open source licence, and whether it falls within an exception. A hosted service that is not released under such a licence, a managed product that adds a high risk function, or a downstream system that is placed on the market as high risk, can be inside the Regulation even where the underlying component is open source. The record should separate the component, the release, the service and the downstream system, and should analyse each one. A single open source label for a whole product, service and model stack will hide the distinctions that decide the exclusion.
For the broader regulatory framework, see questions and misconceptions overview.
What duties apply to open source general purpose models?
For general purpose AI models, Article 53(2) provides that a provider of a model released under a free and open source licence that allows access, usage, modification and distribution, and whose parameters, including weights, architecture and model usage information, are made publicly available, is not required to comply with Article 53(1)(a) and (b), on technical documentation and on information to downstream providers, subject to the systemic risk exception. That relief is narrow. It does not relieve the provider from Article 53(1)(c), the copyright policy, or from Article 53(1)(d), the training content summary, and it does not apply to a model with systemic risk, which must meet the Article 55 duties. A model that is described as open, but whose weights, architecture or usage information are not publicly available, or whose licence restricts access, usage, modification or distribution, will not meet the Article 53(2) conditions, and the relief should not be claimed. A model that meets the conditions for Article 53(2) relief can still be subject to duties as a component in a high risk system, where a downstream provider integrates it into such a system, and the downstream provider must meet the high risk duties for the system. The open source model provider should therefore provide clear licence, availability and documentation information, so that downstream providers can assess their own duties.
What duties apply to downstream use of open source systems?
A person who takes an open source AI system or model and places it on the market, puts it into service, or integrates it into a product or a workflow can become a provider, a deployer, an importer or a product manufacturer for the resulting system, with the duties that follow from that role. Article 25 value chain provisions, including the rule that a person who substantially modifies a high risk system, or who puts their name or trademark on a high risk system, becomes a provider, must be checked. A deployer that uses an open source system for a high risk purpose must meet the deployer duties in Article 26, including the fundamental rights impact assessment where required, the monitoring, the human oversight and the information duties. A provider that builds a product on an open source component must meet the high risk duties for the product where Article 6 classifies it as high risk, and must not treat the open source origin of a component as a substitute for the conformity file. The record should show the component, the licence, the integration, the role, and the duties for the resulting system, separately from the component record. A downstream user that assumes that the open source licence of a component covers the whole system will miss the duties that apply to the system it places on the market or uses.
How should an open source position be recorded?
An open source position should be recorded with the licence text or identifier, the release date and version, the public availability of the parameters and information, the system description, the intended purpose, the exception analysis for high risk, prohibition and transparency, and the general purpose model analysis where relevant. The record should state the component, the release and the downstream system separately, and should state the conclusion for each one. It should be updated when the licence changes, when the system is modified, when the intended purpose changes, or when the law or guidance changes. It should be kept with the system inventory and the conformity file, so that a reviewer can follow the open source analysis into the duties that were applied or not applied. A record that states only that a system is open source, without the licence, the availability or the exception analysis, does not show that Article 2(12) or Article 53(2) was considered. A record that shows the analysis, with the licence and the exceptions, shows that the exclusion was tested, even where the conclusion is that the exclusion applies.
Continue with open source AI systems: exceptions and limits.
What does this correction not decide?
This correction does not decide whether any named licence is a free and open source licence, does not decide whether any named system or model meets the Article 2(12) or Article 53(2) conditions, and does not give a licence or copyright opinion for any component. Licence classification, public availability and exception analysis need the licence text, the release record and the system facts, checked against the consolidated Article 2, 53 and 54 provisions and, where needed, legal advice. This guide corrects the general misconception that open source is exempt, not the open source position for a particular system or model.
Frequently asked questions
Is a high risk system exempt if it is open source?
No. Article 2(12) expressly excludes high risk systems from the open source exclusion. A system released under a free and open source licence that is placed on the market or put into service as a high risk system must meet the high risk duties that apply to its category.
Does charging for an open source model remove the exclusion?
Not necessarily by itself. Recital 103 indicates that commercial activities, including charging for a service or support, do not by themselves remove the exclusion where the licence conditions are met. The operative test is Article 2(12), including whether the system is released under a free and open source licence and whether it falls within an exception. Charging, hosting and downstream use must be analysed separately.
What relief does Article 53(2) give for open source models?
Relief from Article 53(1)(a) and (b) only, on technical documentation and downstream information, where the licence allows access, usage, modification and distribution and the parameters, weights, architecture and usage information are public. It does not relieve the copyright policy or training summary duties, and it does not apply to systemic risk models.
Can a downstream user rely on the open source licence?
No, not for the whole system. A downstream user who places a system on the market, puts it into service or integrates a component into a high risk product can become a provider, deployer or manufacturer, with duties for the resulting system. The component licence and the system duties must be recorded separately.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗