Context

Since the European Commission proposed a revision of the Product Liability Directive (PLD) on 28 September 2022, both the Council of the EU and the European Parliament started their respective work on the file. Now that the Council has reached a general approach on 14 June 2023, all eyes are on the Members of the European Parliament (MEPs), who are still trying to agree on their version of the text.

Although some of the amendments being discussed within the European Parliament are encouraging, some others clearly lack ambition, and could even prove detrimental to the startup ecosystem. For that reason, Allied for Startups is calling on MEPs to make the right call and allow European startups to thrive and scale.

Excluding OSS and standalone software from the scope

Ensuring the appropriate scope of the Product Liability Directive is crucial for companies of all sizes to prosper. The extent to which open source software (OSS) will be excluded by the updated Directive is of utmost importance for startups in this regard. As the Commission proposes to cover open source software used in the course of commercial activity, the European Parliament’s upcoming position remains uncertain but more reassuring: to allow for innovation, many MEPs want to avoid regulating open source software. We agree with these MEPs. OSS is a key lifeline for startups in helping advance their product roadmap, especially at early stages, it should be held out of negotiations on a revised PLD. As shown by recent statistics, the number of startups relying on OSS is huge: 78% of businesses in the world are using open source software, and 68% of them utilise it to gain a competitive advantage. Considering how critical and empowering OSS is for startups (read our blogpost on the matter here), overbearing rules of the use of these systems would be an enormous impediment for startups, be it for their activities but also for them to be created in the EU. Let’s consider a startup that relies on an OSS solution for managing its customer data securely and efficiently. If OSS is covered, a manufacturer could potentially face liability for any issues arising from the use of that OSS. This could create a chilling effect, discouraging manufacturers from providing downstream actors, such as startups, with OSS solutions, hindering the growth of startups that depend on OSS for essential functions, ultimately impacting their ability to innovate and grow.

The Commission’s proposal is also problematic when it comes to including ‘standalone software’ in the definition of a product. A standalone software is a computer programme that functions independently, without requiring additional software or connections to external services. Here, MEPs haven’t agreed on whether to include the general category of ‘standalone software’ in the scope. Standalone software is also critically important to startups as they grow, as such, we firmly advise against including standalone software in the scope, particularly considering the unique nature of software compared to tangible products. Besides the fact that hardware products cannot be fixed by updates like software products can, these physical goods have an intrinsic different risk profile than software products and are way more likely to cause physical harm than standalone software. The PLD’s strict liability also appears as particularly ill-suited for standalone software: it is used for inherently perilous cases with a high risk of significant harm, prioritising safety and compensation over fault. Adding to this that European and national laws on defective software already exist (e.g. Sale of Goods Directive, Digital Content Directive, GDPR), we call for the final text to explicitly exclude standalone software from the scope. Instead, we advocate to further specify what a ‘component’ is by mentioning the term ‘embedded software’, as to ensure the liability of economic operators.

Ensuring realistic definitions 

Even though the Commission’s proposal contains a broad definition of ‘related services’, some in the European Parliament want to further extend this definition in order to include ‘digital content’, thus also covering content like ebooks. We advocate for the outright deletion of the definition of related services as well as avoiding the very dangerous amendments that seek to extend it: imposing liability to related services with such a broad definition could encompass numerous digital services that interact with technology products. Furthermore, incorporating related services risks creating an uneven liability framework if the digital delivery of a service (such as an app) entails no-fault liability, while offering the same service non-digitally falls outside the scope. Imagine an online marketplace selling electronics where a defective product causes harm. If the platform also offers payment processing, the ‘related services’ concept could extend liability protection to payment processing, despite no direct link to the defect. This definition risks muddling responsibility, overburdening unrelated services with liability, and making it more difficult for businesses and consumers to seek compensation. 

Similarly, the definition of ‘damage’ and what it could cover is problematic for startups. Whereas some agree with the Commission to extend the definition to psychological harm and data loss or corruption, others argue for a narrower definition. Since strict liability is suitable primarily for evident cases of physical injury and direct property damage that profoundly affect individuals, we are of the opinion that extending the definition of damage to data loss or corruption will prove extremely challenging for economic operators and opens the door to a broader range of claims with potentially far-reaching financial implications for businesses and developers. Consider a graphic designer who stores their client project files on a specific software platform. If a technical issue causes data loss, leading to the designer being unable to deliver their projects on time, it could result in loss of client trust and financial penalties for breach of contract. The designer might then seek compensation from the software developer for the consequential losses, such as lost income and harm to their professional reputation.

What’s next?

As MEPs are still discussing their amendments in order to agree on compromise amendments, the vote in committee, originally planned in September, should be taking place ‘after October’. We will continue to monitor for changes and updates, and keep both our members and MEPs aware of the changes and how they affect our community as they arise.