Operating systems are within the software category
Article 4 of Directive (EU) 2024/2853 includes software among products. An operating system supplies basic capabilities through which applications and hardware work together, such as memory management, permissions, scheduling and device access. The Directive's recitals expressly discuss operating systems when explaining software coverage. Their role as background infrastructure does not remove them from the product-classification inquiry.
The broader explanation of what counts as a product helps distinguish the operating system from the computer or other device running it. A device can be a physical product containing an operating system as an intangible component. An operating system can also be supplied separately for installation. Those different supply arrangements may affect the factual inquiry without changing the basic point that an operating system is software.
Name the actual operating-system product
A family name alone may identify millions of installations with materially different characteristics. Record the edition, build, architecture and relevant configuration. A version screen may show only a marketing release, while a servicing record identifies a different patch level. Preserve both where possible. The aim is to identify the software present during the alleged incident, rather than merely the vendor whose brand appears at startup.
Separate the base operating system from drivers, bundled utilities and application packages. Some components are supplied by the same developer; others come from hardware manufacturers or independent vendors. A failure described as an operating-system crash may originate in a driver or hardware condition. Classification should make these possibilities visible rather than using a familiar platform name to resolve a disputed technical cause.
Supply method does not determine product status
Software can be supplied through installation media, a download, a device image or network access. The Directive's recitals explain that the mode of supply or use is not the reason software qualifies as a product. A purchaser does not need to receive a disc. Conversely, a file copied onto a device is not necessarily the commercially supplied operating system alleged to have been defective.
Keep the licence and delivery records, installation source and any manufacturer customisation. A system image prepared by a device manufacturer may contain changes absent from the generic release. Those differences can matter when identifying the relevant supplied product and its integration. Product classification should follow the actual software and supply facts, without treating contract terminology such as licensed rather than sold as the complete legal answer.
An operating system can also be a component
Article 4's component definition includes intangible items integrated into or interconnected with a product. An operating system installed in a connected device can fit that description while retaining its identity as software. The manufacturer of the finished product and the developer of the operating system may consequently require separate role mapping. Their potential legal responsibility depends on the conditions in Article 8 and other relevant provisions.
The article on mobile applications as products explains another software layer that may interact with the same operating system. A mobile application may rely on permission controls, system libraries and hardware interfaces. Recording those dependencies helps avoid attributing every unsafe outcome to either the app or the operating system merely because both were present when the incident occurred.
Free and open-source arrangements need separate attention
Article 2 excludes free and open-source software developed or supplied outside the course of commercial activity. The exclusion cannot be decided solely from a zero purchase price. A commercially supplied operating system can incorporate open-source components, and the manufacturer's supply of the assembled commercial product raises distinct questions from the activities of an independent upstream maintainer.
Preserve distribution details, commercial support arrangements and the identity of whoever assembled or modified the relevant image. Do not assume that a recognisable open-source licence excludes the entire device or every participant from the Directive. Equally, do not assume that public availability proves commercial supply by every contributor. Identify the relevant actor and activity before applying the statutory scope boundary.
Distinguish classification from unsafe behaviour
An operating system is not defective merely because it contains a bug or requires an update. Article 7 uses a safety standard taking account of all circumstances, and Article 10 addresses the proof of defectiveness, damage and causation. A compatibility problem or loss of convenience may raise different questions from a system condition alleged to have caused injury or covered damage.
The software product liability guide provides the broader framework for those liability questions. This classification article establishes why the operating system belongs in the product map. Preserve evidence of the relevant build and its relationships with hardware and applications. That information can support later assessment without implying that a platform supplier is responsible for every application error or malfunction on its system.
Keep product dates distinct from incident dates
For the new Directive, corrected Article 2(1) uses products placed on the market or put into service after 8 December 2026. Record the operating system's supply history, device supply and any later installation or configuration change separately. National implementation must still be checked. A later incident involving an old installation does not, by its timing alone, establish that the new framework applies.
Records that help the review
Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.
- Operating-system build, edition and architecture
- Device and driver compatibility information
- Installation image, supply and integration records
Independent educational information at EU Directive level. National implementing law and procedure require separate review.
Primary sources and legal scope
This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.
- Directive (EU) 2024/2853, consolidated text: Articles 2, 4, 6, 7, 8, 10, 11 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.