In plain English, the Law Commission is asking if companies should be legally responsible when software causes harm. The biggest problem is that it makes code responsible instead of the people and companies that chose how it was built, configured, deployed, monitored and used. Software isn’t like a defective toaster. The same code can be safe in one situation and dangerous in another. The risk comes from decisions about what the software can access, what permissions it has, what systems it connects to, how it’s configured, how it’s monitored and what people allow it to do. Product liability can hide who actually made those decisions. The open source proposal also draws an artificial line. The same code could create liability when released by a business but not when released privately. The code and technical risk are the same. Only the legal status of the person publishing it changes. Repositories like GitHub and Hugging Face would still be protected because they’re treated as hosts. That means a developer could face liability for releasing code while the platform distributing the same code to millions of people remains protected. If the concern is dangerous models being distributed widely, the proposal leaves the main distribution channel untouched. There’s also a serious chilling effect on open source. A small company or developer could face product liability simply because code was released as part of commercial activity, while a massive hosting platform continues distributing it under an exemption. That creates more legal risk for builders than for the infrastructure distributing their work to millions of people. Treating recommender algorithms as products creates another problem. Harm from recommendation systems rarely comes from one algorithm in isolation. It comes from the complete service: objectives chosen by executives, engagement metrics, training data, ranking systems, interface design, notifications, advertising incentives and decisions about what behaviour the company optimises for. Calling the algorithm itself the defective product can make accountability less precise. Causation then becomes extremely difficult. If someone claims a recommendation system caused addiction, depression or another harm, the court has to separate the effect of the software from every other relevant factor. The consultation itself appears to recognise that causation will be difficult. There’s also a danger that companies use this framework defensively. If the law starts describing AI and algorithms as products capable of causing harm, executives can blame the “defective AI product” instead of the people who approved its design, deployment and operating conditions. Product liability makes sense when the software itself is defective. It’s the wrong framework when the harm comes from people deciding to give AI access, permissions, data, tools or authority without proper testing, monitoring and control. In those cases, the responsibility belongs with the people and companies that made those decisions, not the code.