The revision of the Product Liability Directive (PLD) was presented as a targeted update of the harmonized framework for a strict liability regime for products in the EU. The proposal extends the scope of the regime to all kinds of software, including AI, and even to digital services, alongside other significant changes. This means software developers will be legally liable if the software they provide in the EU is defective, without a finding of fault (no intention to cause the damage). This risks undue legal exposure and associated costs for all software developers.
Both the Council and European Parliament’s positions put forward certain amendments that improve the text and alleviate the legal uncertainty. As the legislative process enters a decisive phase, Developers Alliance reminds EU lawmakers that the PLD revision must avoid disproportionate and burdensome rules. We also reiterate the impact on the price of insurance and correspondingly on the cost of doing business for software developers and the prices for consumers in the EU.
Key points:
Proportionate software liability
- The definition of product should cover only software with a direct impact on the functioning and safety of a device. Standing alone, software cannot cause the types of damage that product liability contemplates, and is much more akin to a service than a product.
- Digital content should be out of the scope. Any consumer protection concerns related to it are already covered by other legislation. It should be clear that information, such as media files, e-books or source code, does not constitute a product for the purpose of this directive.
- A proper exception for free and open source software is needed to protect those developers who are contributors to open source and not making a profit. Developers of freeware and open-source software should not be treated as manufacturers. Otherwise, proprietary software will be more and more prevalent, with a negative impact on the cost of software and innovation, as open source developers are forced to accept liability without any expectation of profit.
- The notion of ‘defectiveness’ should only cover safety requirements, as these are pertinent in relation to the assessment of defective products. Other consumer and data protection standards are already covered by other legal frameworks.
- Diligent software developers should benefit from proportionate rules and legal certainty. There is no such thing as a ‘bug-free’ code, and software is not defective just because of minor bugs, glitches, flaws, crashes, etc, which are inherent to software and for which the industry has established mitigation practices. Software is particularly sensitive to changes in the surrounding hardware and software system – changes which might be caused by unrelated software or hardware from 3rd parties.
- Reasonable limits (including time limits) for software updates or upgrades are necessary. A developer should not be liable if a defect was caused by a user not installing a software update or upgrade. Also, software updates should not be considered as substantially modifying a product, and triggering a restart of the liability period for the manufacturer. Such a requirement would actually discourage developers from improving product performance over time.
Safeguards against frivolous litigation:
- Legal clarity with regard to immaterial damages such as ‘psychological harm’ and ‘data loss’ could be ensured by a clear definition and scope of the two notions. Only medically recognized damage to psychological health related to physical harm should be covered, otherwise anybody could make a claim against a software application for minor distress. The legal frameworks for data protection, privacy and cybersecurity are already protecting consumers in relation to their data, so any overlaps should be avoided.
- Disclosure orders must ensure that the requested evidence is strictly necessary and proportionate to the request. Otherwise so-called ‘fishing expeditions’ will be incentivized and trade secrets will risk exposure.
- Easing the burden of proof should be limited so as to avoid an unintended reversal of the burden of proof. Software developers should not be placed in the position of having to rebut presumed defects, while the claimants are exempt from showing any evidence related to the defectiveness and the causal link between defectiveness and the damage.
- The lack of upper and lower thresholds presents a high risk to overburdening both businesses and courts with small claims or speculative or fraudulent actions.
