In Part 1 of This Series…
…we provided a general background on free and open-source licensing. In this part, we now shed some light on the latest relevant legal definitions and effects of the regulations. We also clarify what the possible implications of FOSL for AI technologies are. Let’s start!
Introduction
Let’s say you are developing AI technologies. Perhaps you wish to simply use such technologies in your company. Or maybe you want to modify already existing AI components, adapting them to your needs and use cases. Why should you care about free and open-source licensing?
In this blog series, we address some key questions in an area that so far has not received much attention in the overall debate around AI regulation and adoption in Europe and elsewhere. We conclude that you should care about free and open-source licensing if, for example, you wish to share your technology but preserve your IP rights, while, at the same time, enforce some ethical restrictions. Or, if you want to integrate a component subject to an open license into your system.
Why should you care about open licensing as an end-user?
You should care about open licensing also if you are an end-user of AI tools released under an open license. Public (open) licenses do not require individual contact with the rights holder. They offer an interesting avenue for both developers and users and bear important legal, contractual, and strategic implications for the parties.
What is free and open-source licensing anyway, and what does it have to do with AI technologies? What are the implications of such licensing for my IP as a developer or my options as an end-user? What licensing platforms are available out there, and which one might be suitable for me? What are the advantages of subjecting my AI tool to an open license, e.g., in terms of compliance with the AI Act?
Our blog series will attempt to bring some clarity to this topic and help you understand whether free and open-source licensing is relevant for you, and why.
How to Approach and Evaluate Free and Open-Source Licensed Products?
In order to evaluate the legal implications of using free and open-source licensing (FOSL) in a specific situation, you should pay attention to several matters at the outset:
-> What is the subject matter, and what IP regime might apply to it?
For instance, if the subject matter is software that is sufficiently original or creative in the meaning of the applicable copyright law, the software is automatically protected under copyright law. Consequently, the copyright owner initially has exclusive rights towards any third party that wishes to reproduce, modify, and/or redistribute the software, subject to some limited statutory exceptions.
-> Do I need a license for my legal use of the subject matter (here, the software), and if so, what are my options?
In our example, the work is subject to copyright. Unless the action is covered by some specific exception (Art. 5 of Directive 2001/29/EC provides a list of exceptions permitted under harmonized EU copyright law. Later, Directive (EU) 2019/790 somewhat expanded the list.), an individual permission from the owner is required. Therefore, you must find the owner and obtain a license in order to legally perform acts covered by the exclusive rights. However, if the software has been released under an open license, there is no need to contract with the owner individually. It is only necessary to follow the terms and conditions of the license, under which desired use is permitted.
-> If an open license applies – what does it (legally) mean?
We have noted that there are many different open licenses coming from different sources. The licenses are designed to cover various domains, components, and enforce certain interests of the rights holders under some specific conditions. This heterogeneous structure and the lack of a single authority to determine key concepts (such as the definition of a free/open license and the permitted actions & limitations thereunder) require a broad understanding of the options and their legal implications for the parties.
In many cases, several or all five (e.g., under the GPL licenses) of the following features come with a FOSL:
(1) The freedom to conduct the acts permitted under the license despite exclusive IP (the “freedom” principle);
(2) an obligation, in case of redistribution, to make the subject matter, or a modified version thereof, available to the public per identical or essentially similar terms and conditions to those under which the licensee had initially accessed the subject matter (the “share-alike” principle);
(3) the terms of the license are available and apply equally to everyone (the “public” nature of the license);
(4) a violation of the license terms by anyone down the distribution chain reinstates IP exclusivity and is likely to cause an infringement by the violating party (the “copyleft” principle); and
(5) any such infringement also “infects” all further uses by subsequent licensees (the so-called “viral effect”).
Some open licenses do not include the copyleft element, for instance, the MIT or the Apache 2.0 licenses. Where the copyleft principle is at play, infringement of license could turn into a serious issue. You do not wish to find yourself in a situation of an IP infringement, even if the infringement happened accidentally or without knowledge that the technology you access and use is “infected” by a previous violation. Therefore, the licensee must ensure it is using a legitimate version, it must understand the terms of the license, and it further must be aware of the risks and consequences of a violation.
What Are the Possible Implications of FOSL for AI Technologies?
There is one fundamental point that underlies the whole discussion: Concepts and definitions from the universe of IP law are not inherently aligned with concepts and definitions from the sphere of AI. IP law, through individual legislations, typically defines, with more or less specificity and precision, its subject matter; copyright law defines copyrightable work, patent law defines patentable invention, and so on. FOSL historically developed around these IP definitions and the functioning of the exclusive rights attached to them.
By contrast, AI law is still in its infancy. It is fair to say that many of its fundamental concepts do not have a uniform understanding. We have been using here the term “AI technologies” as a loose reference to things like AI models and AI systems, as well as other components of machine learning, such as training data, metadata, the code that runs the model, documentation, and so on. It is not always easy or even possible to find binding legal definitions to these AI components, which is a source of headache to lawyers and everyone else who tries to understand if and how existing regulation applies to them.
Definitions and Regulations in the EU AI Act
In Europe, the EU AI Act (AIA) provides definitions to a number of basic notions, including “AI system” (Art. 3(1) AIA), certain categories of data (Art. 3 (29)-(34) AIA), and “general-purpose AI model” (Art. 3(63) AIA). If we carefully examine these definitions, it appears that some type of IP could be implicated as included in the system, model, data, etc., maybe even several types of IP are relevant, maybe none at all…
To illustrate this disparity, let us take a closer look at the basic notion of “AI model”. Interestingly, the EU AI Act does not define this term, but rather, it provides a legal definition only of the more specific category of general-purpose AI model (GPAI):
“‘general-purpose AI model’ means an AI model, including where such an AI model is trained with a large amount of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks … and that can be integrated into a variety of downstream systems or applications…”
This definition of a sub-category of AI models does not sufficiently explain the general notion of “AI model”. In other words, there is no independent definition of a model in this legislation. The lack of a general definition might lead to the conclusion that AI models that neither fall under the GPAI definition above nor are integrated in an AI system are outside the scope of the AI Act. Then again, in order to build a bridge between AI models and IP, we need a better understanding of what an AI model is.
So, what is an AI model?
There are many attempts to define AI models, which are usually context-dependent. To bring just one example, ISO/IEC 22989:2022 (Information technology — Artificial intelligence — Artificial intelligence concepts and terminology) offers this definition:
“3.3.7 machine learning model
mathematical construct that generates an inference (3.1.17) or prediction (3.1.27) based on input data or information
EXAMPLE:
If a univariate linear function (y = θ0 + θ1x) has been trained using linear regression, the resulting model can be y = 3 + 7x.
Note 1 to entry: A machine learning model results from training based on a machine learning algorithm (3.3.6).”
For IP lawyers, such a definition is not extremely helpful if they want to determine which IP is represented in the model (and not only because lawyers are notoriously bad at mathematics…). At the same time, identifying the IP is still crucial for understanding the operation of FOSL. We might reach the conclusion that a given model is not protected by any standard IP right, for instance, if it essentially consists of non-copyrightable and non-patentable elements such as weights and metadata. Scholars have identified the problem of FOSL enforceability if there is no IP right involved (for instance, when you try to protect weights or output). In short, the existence of IP, or the lack thereof, significantly projects on the force, reach, and implications of free and open-source licensing.
How about a quick example?
Let us assume that a certain model is made available to the public under an open license that permits reproduction, modification, and redistribution for free. However, redistribution of the model and any modified versions thereof must also be under the same terms (share-alike) and free of charge.
Company A reproduces the model and modifies it. Then, it offers the modified version, integrated in a new, proprietary AI system, to company B under a new license that stipulates licensing fees and enforces exclusive copyright over the entire system. Then, Company B sublicenses the system to Company C, which adapts it to its own specific needs and charges its end-customers a fee for using the final cloud-based product.
Company A might have violated the license by confining a modified model version within a proprietary AI system. However, the legal consequences for Company B and Company C vis-à-vis the original developer are different if there is any underlying IP (for instance, the original model is protected under copyright) or not.
In conclusion, for answering the IP question, every AI component and every AI system must be evaluated individually. Only after this has been done, we can turn to the question of how FOSL mechanisms such as share-alike, copyleft, or viral infringement might affect various actors in the distribution chain.
Does AI Regulation (Here: the EU AI Act) Specifically Address FOSL?
We have already seen that the EU AI Act provides some definitions for AI technology components and systems. The drafters of this legislation were aware of the possibility of subjecting AI technologies to FOSL, and indeed, the Act refers to FOSL on several occasions.
Most importantly, Article 2(12) AIA excludes FOSL systems from the scope of the AI Act subject to two exceptions:
“This 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 AI systems or as an AI system that falls under Article 5 or 50.”
This means that – other than high-risk AI systems (as defined and regulated under Chapter III of the AI Act) – a developer can offer the system under FOSL, and thereby keep it outside the scope of regulation, if
- the system is not outright prohibited under Article 5; and
- the system does not fall under any category of Article 50 (e.g., the system is intended to interact directly with natural persons; it can generate synthetic audio, image, video, or text content; it is deployed for emotion recognition or biometric categorization, among others).
Also, if you release your general-purpose AI model (GPAI) under a FOSL
“that allows for the access, usage, modification, and distribution of the model, and whose parameters, including the weights, the information on the model architecture, and the information on model usage, are made publicly available”,
then, you do not need to comply with certain documentation and transparency obligations, provided that your model is not considered having a systemic risk (Art. 53(2), Art. 63(3)-(5) AIA). Another exemption, codified in Art. 54(6), applies to the duty of GPAI providers established outside of the EU to appoint a local representative under Article 54 AIA.
FOSL lifts support obligations for third-party AI suppliers
An additional benefit for supplier of FOSL AI models, tools, services, components, etc. (other than GPAI) in the context of integration within high-risk AI systems can be found in Article 25(4) AIA: If using FOSL, such third party suppliers are exempted from the duty to specify by a written agreement “the necessary information, capabilities, technical access and other assistance based on the generally acknowledged state of the art, in order to enable the provider of the high-risk AI system to fully comply with the obligations set out in this Regulation.”
The Recitals of the AI Act provide some background to the special treatment of FOSL
Recital 102 states the importance of FOSL and its contribution to research, innovation, and economic growth. It also explains the FOSL concept under this specific legislation:
“General-purpose AI models released under free and open-source licences should be considered to ensure high levels of transparency and openness if their parameters, including the weights, the information on the model architecture, and the information on model usage are made publicly available. The licence should be considered to be free and open-source also when it allows users to run, copy, distribute, study, change and improve software and data, including models under the condition that the original provider of the model is credited, the identical or comparable terms of distribution are respected.”
Under Recital 102, an open model therefore must be transparent concerning certain key parameters (no trade secrets protection, no digital protection measures) and permit access, use, and distribution (no IP exclusivity).
Interestingly, Recital 103 states that monetization of AI components, such as software and data, tools, services, or processes for an AI system, with some minor exceptions, excludes those components from the above-mentioned exemptions.
Recital 104 explains the rationale behind the exemption in Section 53 AIA regarding some transparency obligations. It is assumed that GPAI models released under FOSL already reveal to the public parameters, “including the weights, the information on the model architecture, and the information on model usage” and therefore are eligible to “exceptions as regards the transparency-related requirements imposed on general-purpose AI models”.
EU Clarifies FOSL Criteria for GPAI Model Exemptions Under AI Act
The EU Commission has recently launched a targeted consultation supporting its effort to hammer out Guidelines clarifying the scope of regulation in this area. The final version of the Guidelines, published on 18.07.2025, includes several significant changes to the initial draft. Generally, “guidelines” released by the EU Commission are not legally binding as the main legislation itself (AIA) is. They provide nonetheless important clarifications that are likely to be followed in practice by the European AI Office and the EU Commission as having exclusive competence to enforce the rules concerning GPAI models (Guidelines, para 6). Accordingly, the Guidelines in our context should further clarify the obligations which GPAI models providers under open licenses must comply with under the EU AI Act. Among other things, the Guidelines intend to clarify key concepts underlying the provisions in the AI Act on GPAI models.
Clarifying the scope and legal effect of FOSL exemptions
Section 4 of the Guidelines is dedicated to GPAI, released under a free and open-source license, especially in the context of the exemptions mentioned earlier concerning documentation and the appointment of an authorized representative. It elaborates on the scope of the FOSL exemptions (Sec. 4.1) and the conditions of the exemptions to apply (Sec. 4.2).
Regarding scope, the guidelines emphasize that providers of general-purpose AI models that meet the conditions referred to in Section 4.2 are not exempted from the obligation laid down in Article 53(1), point (c), AI Act, to put in place a policy to comply with Union copyright law. However, there is no general obligation to reveal training data. In addition, for GPIA without a systemic risk, Article 53(1), point (a) releases its provider from the obligation to draw up and update certain documentation for provision upon request to the AI Office and national competent authorities. Article 53(1), point (b) further releases such providers from the duty to keep and make available some documentation and information required for the integration of the model into AI systems.
New clarifications on key terms and conditions
The part on the condition for these exemptions to apply adds important and partly new clarifications regarding key terms and concepts. We briefly mention some of them below:
License
According to the guidelines, a free and open source license “should be understood as a form of licensing that makes use of copyright to allow wide dissemination of the model and incentivise further developments.” (para. 77). The reference only to copyright without mentioning other forms of IP is intriguing and inconsistent with a broader understanding of FOSL in terms of IP subject matter as well as with para 80 of the same Guidelines that refers to “intellectual property rights”.
Openly shared
The license must accommodate all four rights granted to the licensee: Access, use, modification, and redistribution (para 78).
Access
Free access must be provided “without any payment requirements or other restrictions” – subject to some minor exceptions regarding safety and security (para. 79).
Usage
Para. 80 provides as follows: Usage “mean[s] that the licence guarantees that the original provider will not use their intellectual property rights to restrict the use of the model, or charge for its use. The licence should allow the model to be used without any restrictions besides restrictions ensuring attribution and distribution of the model or derivatives under the same or comparable terms.” (italicization mine)
Distribution
It is interesting to note that the concept of distribution does not mandate that all the rights stated in the original FOSL will “run with the license” and apply to all downstream users. The limiting conditions in the license regarding attribution to the author and placement of copyright notice are often used also for downstream users, but according to the understanding of the Commission, “the recipient of the licenced model should be able to modify it and redistribute the resulting derivative work under different licence terms, including closed-source proprietary terms, without prejudice to any restrictions acceptable under paragraph 80.” (para. 82). The wording “should” indicates that further limitations, for example a full “share-alike” requirement to redistribute under an open license, might not be acceptable. This could be a huge disincentive to use open licenses in the first place. Further limitations that are explicitly excluded from the Guidelines’ notion of FOSL concern noncommercial use, redistribution prohibitions, usage restrictions triggered by user scale thresholds, and requirements to obtain separate commercial licenses for specific use cases (para 83).
The guidelines also include a lengthy explanation of the “lack of monetisation” requirements under Section 4.2.2. It is worth quoting the Guidelines’ specific reference to payment with personal data, especially for those who have been following the debate over personal data as a (legitimate) contractual counter performance:
“While fully recognising that the protection of personal data is a fundamental right and that therefore personal data cannot be considered a commodity or monetised, access, use, modification, or redistribution of the model requiring the collection or otherwise processing of personal data should be treated in same manner as monetisation strategies, unless that processing is exclusively and strictly limited to the security of the model and without any commercial or financial gain. In any event, the processing of personal data should comply with the rules under Union data protection law.” (para 87)
Finally, the Guidelines elaborate on the requirement to make publicly available the model’s parameters, including “the weights, the information on the model architecture, and the information on model usage” (paras. 90-92).
Ethical clauses in open-source AI: a threat to FOSL status?
An interesting question, which cannot be discussed here in length, is whether additional usage restrictions in the license, for instance, per the “do-no-harm” principle, jeopardize the status of the GPIA as “free and open source” model. This question is raised since the interpretation of the Commission concerning “permissible” limitations in the FOSL seems to be quite restrictive. There is no explicit reference to ethical restrictions, but the Guidelines would permit “specific, safety-oriented terms that reasonably restrict usage in applications or domains where such use would pose a significant risk to public safety, security, or fundamental rights.” (para 84).
Some of the main insights can be summarized in the following flowchart:
EU’s voluntary Code of Practice for GPIA models: promises and challenges for open-source compliance
And, before closing this part, a couple of comments regarding the voluntary Code of Practice (CoP) für GPIA models published recently by the EU Commission: The current version embodies three Chapters, focusing on Transparency, Copyright, and Safety & Security, respectively. Some statements in the CoP suggest that it should be easier for companies offering their GPIA models under free and open-source licensing to adhere to it with less additional effort, but this is not always the case.
The Chapter on Transparency echoes Article 53(2) AI Act concerning certain requirements on technical documentation and information obligations vis-à-vis those integrating the GPAI model into their AI Systems. It provides that (certain) transparency Measures required under the CoP “do not apply to providers of general-purpose AI models released under a free and open-source license that satisfy the conditions specified in that provision, unless the model is a general-purpose AI model with systemic risk.”
Under the Chapter on Copyright, signatories of the CoP commit, under Measure 1.4.(1)(b), “in case of general-purpose AI models released under free and open-source licenses to alert users to the prohibition of copyright infringing uses of the model in the documentation accompanying the model without prejudice to the free and open-source nature of the license.” The idea here is not to secure the copyright of the Model’s developer (if any) but rather to mitigate the risk that a downstream AI system containing the model generates output that potentially infringes the copyright of someone else. The key phrase is “to alert”, which begs the question whether the prohibition on infringing output should be part of the FOSL legal terms of use. The more plausible interpretation is, however, that alerting means providing additional information that is external to the legal licensing conditions controlling the model usage between the provider and the user.
In Part 3 of this series…
…we will explore what options of FOSL are available for AI technologies and what FOSL means for you as a developer and as a downstream user. Also, we will summarize the essence of it all. Stay tuned for the last part of this series!
Author info
