The Product Boundary: Software, SaaS, AI, and Open Source
Directive (EU) 2024/2853 creates a classification problem that older product-liability language could often avoid: what, exactly, is the product when software runs in a cloud, an AI system changes a device’s behaviour, or open-source code is integrated into a commercial system? This chapter builds a functional answer. It shows how the Directive treats software and AI systems, why digital manufacturing files are different from ordinary digital content, when a digital service becomes a component, and why “open source” is not by itself either an exemption or a liability rule.
Product is a function, not a delivery format
Article 4 defines a product as all movables, even when they are integrated into or interconnected with another movable or an immovable. It expressly includes electricity, raw materials, digital manufacturing files, and software. That formulation matters because it does not make physical packaging the gateway to liability. A piece of software can be a product even when it is not shipped on a disc, stored permanently on the customer’s device, or sold as a separately named item.
The Directive’s recital makes the digital point more directly. Software includes familiar categories such as operating systems, firmware, computer programs, applications, and AI systems. It may be placed on the market as a standalone product or integrated into another product as a component. Its route to the user may be a device, a communication network, cloud technology, or a software-as-a-service model. Delivery through a browser or an API therefore does not settle the classification question in favour of “service.” The legal analysis must look at what the software does and how it relates to a product’s safety.
That does not mean every commercial service delivered online is automatically a product. The same Directive distinguishes software from information and from the content of digital files, such as media files or e-books. The mere source code of software is not treated as a product simply because it contains instructions. This boundary separates an operational capability that can execute and affect safety from information that is merely carried, displayed, or read. The distinction may be difficult at the edges, but its purpose is clear: digitisation alone is not enough.
An AI system illustrates why this functional approach matters. Suppose an application analyses sensor data and issues a command that changes how a physical device operates. The fact that the model is hosted remotely does not make its safety relevance disappear. The application may be a standalone software product, a component of the device, or part of a related service, depending on the system’s structure and the role the software performs. The recital says that a developer or producer of software, including an AI system provider within the meaning of the Union’s AI legislation, should be treated as a manufacturer. That is a strong signal about the intended allocation of responsibility, although it does not remove the need to establish the facts of the particular architecture and market relationship.
The same functional logic explains digital manufacturing files. Article 4 defines one as a digital version of, or template for, a movable that contains the functional information needed to produce a tangible item by enabling the automated control of machinery or tools. A computer-assisted-design file that directs a 3D printer, mill, or other machine is not merely a document in this context. If a defect in the file produces a tangible item that causes harm, the file can be relevant as a product when it was developed or supplied in the course of commercial activity.
An ordinary e-book does not play that role. Neither does the text of a source file merely because a programmer could use it to build software. The difference is not that one file is important and the other is unimportant. It is that the digital manufacturing file contains the functional instructions that operate production machinery. It is closer to a control input in a manufacturing process than to content consumed by a reader. That is the kind of distinction a court can use without pretending that every digital artefact belongs in the same legal category.
The definition also reaches integration. A product may be connected to another movable or installed in an immovable, and software may be one of its components. A smart appliance, for example, can be a physical product whose safety depends partly on embedded firmware, a downloaded application, or another digital capability. Calling the software a “feature” does not answer whether it is a component or what operator supplied it. The important questions are whether it is part of the product’s functional system and whether its defect can contribute to damage.
This is why the delivery channel is a poor shortcut. “On-premises,” “cloud,” “subscription,” and “SaaS” describe how an offering reaches a user or how access is paid for. They do not by themselves describe whether software is a product, whether it is integrated into another product, or whether a separate digital service determines a product function. The Directive moves the reader from the commercial label to the functional relationship.
The dependency test: components and related services
Article 4 defines a component broadly. It can be a tangible or intangible item, a raw material, or a related service that is integrated into or interconnected with a product. A related service is narrower: it is a digital service integrated into or interconnected with a product in such a way that its absence would prevent the product from performing one or more of its functions.
The phrase “would prevent” does important work. It points to functional dependence, not mere usefulness. A digital service may make a product more convenient, attractive, or profitable without becoming a related service. By contrast, a service that supplies the information or control needed for a product to carry out one of its functions can sit inside the product-liability analysis even though the service itself is delivered from elsewhere.
The Directive’s examples make the relationship concrete. Continuous traffic data can be essential to a navigation system. A health-monitoring service can rely on a physical product’s sensors to track activity or health measures. A temperature-control service can monitor and regulate a smart refrigerator. A voice-assistant service can allow products to be controlled through spoken commands. In each case, the service is not being treated as a generic internet offering. It is being considered as a digital dependency that helps determine what the connected product can do and how safely it does it.
Internet access is the boundary case. The Directive says that internet access services should not be treated as related services because they cannot be considered part of a product within the manufacturer’s control. It would be unreasonable to make a product manufacturer liable for every shortcoming in a general connectivity service. But that exclusion does not give the product a safety exemption. If a product depends on connectivity and fails to maintain safety when the connection is lost, the product itself may be defective. The service can be outside the related-service category while the product’s design remains subject to an expectation of safe behaviour during a foreseeable loss of connection.
This produces two separate questions that are easy to merge. First: is the external service a component or related service under the functional-dependency definition? Second: regardless of how the external service is classified, did the product fail to provide expected safety in the conditions it was designed to face? A manufacturer might not control a general network, but it may still have designed a device that reacts dangerously when the network disappears. Conversely, the mere fact that a product works better when connected does not prove that the connectivity provider is part of the product.
Control adds a further filter. A related service or component is within the manufacturer’s control when the manufacturer integrates it, supplies it, authorises or consents to its integration or supply, or presents it as part of the product. That does not follow merely from technical compatibility. Nor does it follow simply because the manufacturer recommends a brand or fails to ban every possible third-party service. The point is to connect responsibility to a meaningful decision or representation, not to every possible interaction in an open digital ecosystem.
For example, a manufacturer that markets a smart appliance as including a particular video or monitoring application may have a stronger control connection than a manufacturer whose device merely works with thousands of independent applications. The first presentation may lead users to see the application as part of the product. The second may show only general compatibility. The legal conclusion would still depend on evidence about the product, the representation, the integration, and the safety consequence, but the distinction gives the analysis a principled starting point.
The diagram is a decision aid, not a mechanical flowchart for every dispute. A single system can occupy more than one box: software can be a product in its own right and a component of a physical device; a related service can also be a component; and an open-source component can move from a non-commercial context into a commercial product without changing the underlying code’s licence.
Open source: the commercial-activity boundary
Article 2(2) excludes free and open-source software that is developed or supplied outside the course of a commercial activity. The reason is not that open-source code is presumed safe. The recital explains that freely shared code supports research and innovation and that software developed or supplied outside commerce is, in that setting, not placed on the market. Contributing code, improving it, or putting it in an open repository does not by itself count as making it available on the market.
The operative question is therefore not simply, “Is the licence open?” It is, “Was this software developed or supplied in a commercial activity?” The recital says that supply by a non-profit organisation is in principle outside a business-related context unless the supply occurs in a commercial activity. It also gives two indicators that move in the other direction: software supplied for a price, or supplied in exchange for personal data used for purposes other than exclusively improving its security, compatibility, or interoperability, is treated as commercial supply for this purpose.
That rule prevents the open-source exclusion from becoming a universal shield for a business model built around open code. A company may publish code openly while selling hosted access, support, integration, or a service that uses personal data for broader purposes. The source supplied for free and the commercial service around it may need to be analysed separately. The Directive does not provide a complete taxonomy for every sponsorship, dual-licence arrangement, paid hosting model, or data practice, so the facts of supply and use remain important.
The downstream rule is just as important. If free and open-source software was supplied outside commercial activity and a manufacturer later integrates it into a product in the course of a commercial activity, the integrating manufacturer can be liable for damage caused by the software’s defectiveness. The non-commercial software developer is not treated as having placed that component on the market. Liability follows the commercial act that turned the code into part of a product offered through the market, rather than reaching backward automatically to every volunteer contributor.
This allocation reflects the Directive’s broader method. It asks who made the relevant thing available, who integrated it, what function it performs, and who had a meaningful relationship to the product’s safety. A licence label can provide context, but it cannot substitute for that analysis. The same is true of “SaaS.” A cloud-delivered application may fall within the product concept, while a separate service may remain outside it; the answer depends on the software’s function, the product’s dependence, and the commercial and control relationships around them.
A usable classification rule
When a digital offering is difficult to place, begin with three questions. What is the thing doing: executing software, controlling machinery, carrying content, or providing a separate service? What product function depends on it, if any? And how was it developed, supplied, integrated, or presented in the market? These questions do not replace the Directive’s legal definitions, but they keep the inquiry tied to the facts that give those definitions meaning.
The result is a boundary with two sides. The Directive is broad enough to reach standalone software, AI systems, cloud-delivered software, digital manufacturing files, and digital services that are functionally integrated into products. It is not so broad that every file, every internet connection, every compatible application, or every non-commercial open-source contribution becomes a product. Once the relevant item or dependency has been identified, the next problem is no longer classification. It is safety: how the product changes, learns, connects, and remains—or ceases to remain—within an operator’s control after launch.