The Importance of Software Liability

Yesterday, I had an insightful conversation with a seasoned software product leader, and one phrase stuck with me: Code is liability. At first, it sounds counterintuitive. We often think of code as an asset—something that brings value to a company. But the reality is that every line of code written comes with inherent costs and risks. Here’s why: 1. Maintenance Burden – Code isn’t a one-time investment. Every feature added increases the surface area for bugs, security vulnerabilities, and technical debt. The more code you have, the more effort it takes to maintain. 2. Complexity & Fragility – The more code you write, the harder it becomes to make changes without breaking something else. What starts as a simple solution can quickly turn into a tangled mess requiring extensive rework. 3. Scalability Risks – As software evolves, poorly designed or unnecessary code can bottleneck performance. What works today may slow you down tomorrow, requiring costly refactoring or complete rewrites. 4. Opportunity Cost – Time spent managing and debugging bloated codebases is time not spent on innovation. The best software companies minimize unnecessary code and focus on delivering value efficiently. 5. Security Vulnerabilities – Every additional line of code is a potential attack vector. The larger the codebase, the more opportunities for exploits. This conversation reinforced something I’ve seen firsthand: The best engineers and product leaders aren’t the ones who write the most code—they’re the ones who write the least necessary code. In a world where we celebrate shipping new features, we often overlook the cost of what we’ve built. Sometimes, the best decision isn’t to add more—it’s to simplify, refactor, or even delete.

AI liability is about to get real. The lawsuit against OpenAI over a teenager’s ChatGPT-assisted death isn’t just about one tragic case. It could redefine how enterprises must treat AI. If courts accept these claims, AI will no longer be “just software.” It will be judged like a dangerous product - with strict liability, duty to warn, and negligence standards applied. For enterprises, the ripple effects are enormous: 1. Product liability exposure - Deploying AI could carry the same legal risks as selling a defective car or medical device. “Use at your own risk” disclaimers won’t be enough. 2. Duty to warn - Expect mandatory disclaimers, onboarding risk screens, and context-specific safety alerts when AI is used in HR, finance, or healthcare. 3. Governance as legal defense - Companies will need documented AI safety frameworks (NIST/ISO-style) to prove they took “reasonable care.” 4. Unlicensed practice risk - If courts rule AI engaged in psychology, similar arguments could apply to AI in law, medicine, or finance. Human oversight may become legally required. 5. Insurance shake-up - AI-specific liability coverage will become a must-have, not an afterthought. This could be the moment where AI moves from “experimental software” to regulated, high-liability product. Enterprise leaders should start planning now: • Demand transparency from vendors on safety testing and controls. • Implement “safety by design” in internal AI programs. • Review insurance, compliance, and risk frameworks before lawsuits force the issue. The question is no longer if AI liability will hit enterprises, it’s when, and how prepared you’ll be.

𝗢𝗽𝗲𝗻 𝗦𝗼𝘂𝗿𝗰𝗲 & 𝗟𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆: 𝗧𝗵𝗲 𝗨𝗻𝗰𝗼𝗺𝗳𝗼𝗿𝘁𝗮𝗯𝗹𝗲 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻 𝗶𝗻 𝗔𝘂𝘁𝗼𝗺𝗼𝘁𝗶𝘃𝗲 (𝘗𝘦𝘳𝘴𝘰𝘯𝘢𝘭 𝘷𝘪𝘦𝘸; 𝘰𝘱𝘪𝘯𝘪𝘰𝘯𝘴 𝘢𝘳𝘦 𝘮𝘺 𝘰𝘸𝘯) Open-source software (OSS) already represents 𝘂𝗽 𝘁𝗼 𝟳𝟬% 𝗼𝗳 𝘁𝗵𝗲 𝗰𝗼𝗱𝗲 𝗶𝗻 𝗺𝗼𝗱𝗲𝗿𝗻 𝘃𝗲𝗵𝗶𝗰𝗹𝗲𝘀. The trend is irreversible - driven by the need for faster innovation, transparency, and reduced vendor lock-in. But as OSS moves from the toolchain to the in-vehicle stack, it raises an uncomfortable question: When a component with no warranty contributes to a failure, who is liable? This tension will define the next chapter of the Software-Defined Vehicle. 𝟭. 𝗧𝗿𝗮𝗻𝘀𝗽𝗮𝗿𝗲𝗻𝗰𝘆 𝗶𝘀 𝘁𝗵𝗲 𝗡𝗲𝘄 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱 Safety doesn’t come from secrecy - it comes from process, evidence, and traceability. When code is open, quality can be verified, security audited, and interoperability improved by design. Initiatives like Automotive Grade Linux (AGL) and the Eclipse SDV Working Group already prove that openness and safety are not mutually exclusive. 𝟮. 𝗧𝗵𝗲 𝗜𝗻𝗲𝘀𝗰𝗮𝗽𝗮𝗯𝗹𝗲 𝗟𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻 Most OSS licenses explicitly disclaim warranties - a stark contrast to a regulated industry where accountability is non-negotiable. The real challenge isn’t if we should use OSS, but how we build a framework of responsibility around it. 𝗪𝗵𝗼 𝗶𝘀 𝗮𝗰𝗰𝗼𝘂𝗻𝘁𝗮𝗯𝗹𝗲? The OEM? The Tier-1 integrator? The community? 𝟯. 𝗧𝘄𝗼 𝗠𝗼𝗱𝗲𝗹𝘀 𝗪𝗶𝗹𝗹 𝗘𝗺𝗲𝗿𝗴𝗲 We’re heading toward a hybrid future: 𝗢𝗘𝗠-𝗠𝗮𝗶𝗻𝘁𝗮𝗶𝗻𝗲𝗱 𝗢𝗦𝗦: Automakers will own, qualify, and maintain critical parts of the open-source stack internally. 𝗖𝗼𝗺𝗺𝗲𝗿𝗰𝗶𝗮𝗹 𝗗𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗼𝗻𝘀: Partners - much like Red Hat for enterprise Linux—will provide validated OSS stacks with long-term support, security patches, and, crucially, contractual liability. 𝟰. 𝗜𝗻𝗶𝘁𝗶𝗮𝘁𝗶𝘃𝗲𝘀 𝗣𝗮𝘃𝗶𝗻𝗴 𝘁𝗵𝗲 𝗪𝗮𝘆 The Eclipse SDV ecosystem is already shaping this accountable future with projects like:  • 𝗘𝗰𝗹𝗶𝗽𝘀𝗲 𝗦-𝗖𝗼𝗿𝗲 – a reference architecture for certifiable, modular vehicle software.  • 𝗘𝗰𝗹𝗶𝗽𝘀𝗲 𝗢𝗽𝗲𝗻𝗦𝗢𝗩𝗗 – an open standard for vehicle diagnostics and off-board interaction.  • 𝗘𝗰𝗹𝗶𝗽𝘀𝗲 𝗢𝗽𝗲𝗻𝗕𝗦𝗪 – open implementations for essential Base Software modules, defining the next frontier of in-vehicle OSS. 𝗧𝗵𝗲 𝗙𝘂𝘁𝘂𝗿𝗲 𝗶𝘀 𝗢𝗽𝗲𝗻 - 𝗕𝘂𝘁 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗹𝗲 The shift to open source is unstoppable. The challenge now is to make it 𝘀𝗮𝗳𝗲, 𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻𝗮𝗯𝗹𝗲, 𝗮𝗻𝗱 𝗹𝗲𝗴𝗮𝗹𝗹𝘆 𝘀𝘂𝘀𝘁𝗮𝗶𝗻𝗮𝗯𝗹𝗲. 𝗧𝗵𝗲 𝗳𝘂𝘁𝘂𝗿𝗲 𝗼𝗳 𝗮𝘂𝘁𝗼𝗺𝗼𝘁𝗶𝘃𝗲 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝘄𝗶𝗹𝗹 𝗯𝗲 𝗼𝗽𝗲𝗻 -  𝘄𝗶𝘁𝗵 𝗹𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗱𝗲𝘀𝗶𝗴𝗻𝗲𝗱 𝗶𝗻, 𝗻𝗼𝘁 𝗯𝗼𝗹𝘁𝗲𝗱 𝗼𝗻. What’s your view? How is your organization preparing for this shift? #Automotive #SoftwareDefinedVehicle #OpenSource #AutomotiveIndustry #Liability #TechLeadership #EmbeddedSystems #EclipseSDV

My latest article, now featured on the IAPP AI Governance Dashboard, offers a brief assessment of the evolving EU liability landscape for AI, contrasting strict liability with fault-based regimes. I explore how the EU AI Act and the revised Product Liability Directive extend strict liability to AI systems and software, aligning with traditional product safety frameworks. This regime, historically designed for uniform, mass-produced goods, now holds broadly defined “manufacturers” (including developers and importers) liable for harm caused by defective AI products, without requiring proof of fault. However, I highlight a critical regulatory gap: the withdrawal of the AI Liability Directive has left fault-based liability for AI, particularly in service-based deployments, unharmonized across the EU. When harm stems from the actions of deployers, integrators, or service providers, victims must navigate fragmented national tort laws, often facing higher evidentiary burdens. In this context, whether AI is classified as a product or a service has profound legal implications. A coherent, harmonized liability framework is essential to ensure effective redress, legal certainty, and public trust in AI innovation across the EU. https://lnkd.in/db-CZs3s #AIRegulation #ProductLiability #StrictLiability #AIGovernance #AIAct #EULaw #DigitalRegulation #TechLaw

Major update for tech companies, software developers, and AI builders in Germany! Tomorrow, March 4, 2026, the German Bundestag holds the first reading of a landmark draft law (Drucksache 21/4297) that could radically modernize product liability. This legislation transposes the revised EU Product Liability Directive (PLD) into German law ahead of the December 9, 2026, deadline. It represents a paradigm shift, adapting consumer protection for the digital economy, the circular economy, and global supply chains. Key Implications of the Draft Law • Software as a Standalone Product: Historically, product liability was geared toward physical goods (like a faulty toaster or defective car brakes). Explicitly categorizing standalone software—whether downloaded, accessed via the cloud (SaaS), or embedded—as a "product" closes a major gap in modern consumer protection. • Accountability for AI Systems: By establishing strict liability for AI, the law ensures that if an AI system causes harm (e.g., a flawed medical diagnostic AI or an autonomous driving algorithm), the manufacturer is on the hook. This works in tandem with the broader EU AI Act to regulate the rapid deployment of machine learning models. • Continuous Post-Market Liability: The days of "ship it and forget it" are over. Manufacturers will be legally required to provide necessary security and functionality updates over the expected lifespan of the product. If a smart device or software becomes unsafe because a manufacturer failed to patch a known vulnerability, they can be held liable. • The Open-Source Safe Harbor: The exemption for non-commercial open-source software is a critical relief for the developer community. It ensures that hobbyists, independent contributors, and researchers aren't paralyzed by the threat of lawsuits, which protects the collaborative open-source ecosystem. The bill acknowledges that modern tech is too complex for an average consumer to reverse-engineer in court.  • Forced Disclosure: A court can order a manufacturer to disclose relevant, internal evidence if a claimant presents a plausible case. • Presumption of Defect: If a manufacturer refuses to hand over this evidence, the court will legally presume the product was defective.  • Complexity Clause: If technical or scientific complexity makes it "excessively difficult" for a consumer to prove a defect or causality (e.g., inside an AI "black box"), they only need to prove that a defect or causal link is likely. Since tomorrow is only the first reading (Erste Lesung), the bill will be introduced to the plenary and then referred to the relevant parliamentary committees (such as the Committee on Legal Affairs) for deeper scrutiny, expert hearings, and potential amendments before it returns to the floor for a second and third reading. #ProductLiability #TechLaw #ArtificialIntelligence #SoftwareDevelopment #Compliance #Bundestag #EULaw #Germany #AI #PLD