As Is: How Software Became the Only Product You Could Legally Sell Broken

By Oleg

Buy a refrigerator that does not keep food cold and the law is on your side before you say a word. Two warranties come attached automatically — that the thing is of merchantable quality, and that it is fit for the purpose it was sold for. Nobody negotiates them. They are the default, and a seller who wants out has to say so explicitly.

The software industry said so explicitly. It has been saying so, in nearly identical words, since the early 1980s.

The sentence that did the work

Here is the operative language from the Lotus 1-2-3 licence, and it is worth reading slowly:

“Lotus makes no warranty or representation, either express or implied, with respect to this program or documentation, including their quality, performance, merchantability, or fitness for a particular purpose.”

Quality. Performance. Merchantability. Fitness for a particular purpose. That is not a lawyer being thorough. It is a precise strike on the two warranties the Uniform Commercial Code supplies by default, plus the two words a customer might reach for if the first strike missed.

Shrinkwrap contracts spread through the industry in the 1980s for exactly this reason: to impose restrictions and to escape the standard warranty regime that came with selling goods. The manoeuvre had a second half. Software was licensed rather than sold, which raised the argument that the UCC’s rules for goods did not apply in the first place. Belt and braces.

For roughly a decade it was unclear whether any of this worked. Courts in the United States were reluctant to enforce agreements the buyer could not read until after paying — the classic form of the contract of adhesion. Then the question reached the Seventh Circuit.

June 20, 1996

ProCD, Inc. v. Zeidenberg was, on its face, about a phone-directory CD-ROM. ProCD had spent more than $10 million compiling over 3,000 local telephone directories into a product called SelectPhone. Matthew Zeidenberg bought a consumer copy and put the data on the web, which the licence inside the box forbade. The district court sided with Zeidenberg. Judge Frank Easterbrook reversed, and the sentence he wrote has governed the industry ever since:

“Shrinkwrap licenses are enforceable unless their terms are objectionable on grounds applicable to contracts in general.”

That is a very low bar. It means terms inside the box bind you unless they would be unenforceable in any contract at all — unconscionable, or illegal outright. Merely unread does not qualify.

Easterbrook’s reasoning was pragmatic rather than formalist. Commerce, he pointed out, is full of transactions where money changes hands before terms are read. You buy insurance and the policy arrives afterwards. You pay for an airline ticket and the conditions of carriage come with it. “The back of the ticket states that the patron promises not to record the concert; to attend is to agree.” The arrangement, he wrote, of “notice on the outside, terms on the inside, and a right to return the software for a refund if the terms are unacceptable” could be “a means of doing business valuable to buyers and sellers alike.”

The opinion even reaches for the exact analogy that matters here. Someone buys a radio, walks out with a box, and inside is a leaflet with terms — “the most important of which usually is the warranty, read for the first time in the comfort of home.”

The difference, of course, is that the radio’s leaflet contains a warranty. The software’s leaflet contains its cancellation.

The law that failed, and did not need to succeed

Having won in court, the industry tried to win in statute. The effort began as a proposed Article 2B of the UCC — a whole new division of American commercial law purpose-built for software transactions. It did not survive drafting. Reworked and renamed the Uniform Computer Information Transactions Act, it went to the states in 1999.

That same year the American Law Institute, co-sponsor of the entire Uniform Commercial Code, took the extraordinary step of withdrawing its support from a project it had helped launch. UCITA went on to be enacted in two states: Virginia and Maryland. Several others passed statutes specifically designed to blunt it.

By any ordinary measure that is a defeat. It changed nothing, because the industry did not need the statute. ProCD and the cases that followed had already settled the point that mattered, and the disclaimer was by then simply what a software licence said. Forty years on, “AS IS, WITHOUT WARRANTY OF ANY KIND” sits in the licence of nearly everything you run, including most of the open-source dependencies underneath it, and no one reads it because everyone knows what it says.

This is the part worth being clear about. Shipping software that breaks was never evidence that engineers stopped caring. It was the rational response to a price signal. Defects were, in the ordinary case, free to the company that shipped them and expensive only to the person who ran them. Every argument for spending another sprint on hardening had to be made against a legal baseline of zero exposure.

December 9, 2026

That baseline is now being removed, and not by the route anyone spent twenty years arguing about.

Directive (EU) 2024/2853 — the revised Product Liability Directive — was adopted on 23 October 2024 and entered into force that December. Member states must transpose it into national law by 9 December 2026, and it applies to products placed on the market after that date. It replaces a directive written in 1985, when the products in question were physical objects that could be dropped on your foot.

The new text redefines “product” to include software: embedded, standalone, and supplied as a service, along with AI systems and digital manufacturing files. Software is back inside the strict-liability regime it was carved out of.

Three consequences follow, and they are structural rather than cosmetic.

A defect now includes a cybersecurity vulnerability, and it includes the failure to supply security updates for a vulnerability you know about. Defectiveness is measured against the safety a person is entitled to expect — not against what your release notes promised.

The burden of proof shifts. Where establishing defectiveness would require the claimant to understand a technically complex product, courts may apply rebuttable presumptions of defect and causation, and may order disclosure of evidence.

And the operation the whole edifice rested on stops working: liability cannot be contractually excluded or limited. The disclaimer is not narrowed or made harder to invoke. For products within the directive’s scope, it simply has no effect.

What actually became expensive

The Product Liability Directive works through claimants and courts — someone has to be harmed and bring a case. The EU’s other instrument does not wait for that.

The Cyber Resilience Act entered into force on 10 December 2024. From 11 September 2026, manufacturers must send an early warning to ENISA and the relevant national CSIRT within 24 hours of learning that a vulnerability in their product is being actively exploited, followed by a fuller notification at 72 hours and a final report at 14 days. Full compliance, including CE marking, follows on 11 December 2027. Manufacturers must declare a support period reflecting the product’s expected lifetime — generally not less than five years — and supply free security updates throughout it, remediating discovered vulnerabilities without undue delay. Serious breaches carry fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

The pattern is not confined to Europe. Section 524B of the US Food, Drug and Cosmetic Act, in force since 29 March 2023, made “reasonable assurance of cybersecurity” a condition of market entry for connected medical devices: a software bill of materials, a secure product development framework, and a postmarket surveillance plan, all reviewable. The FDA can refuse a 510(k) or PMA submission on the strength of the security documentation alone. We have written before about how software became a medical device — 524B is the same movement arriving in the security column.

It is worth resisting the temptation to call this the end of impunity, because it is not. Nobody is now liable for every bug. The Product Liability Directive addresses harm caused by defective products, not disappointment. The CRA governs process — updates, support periods, disclosure timelines — and says almost nothing about whether your software is any good.

What changed is narrower and more consequential than a general reckoning. Three specific things stopped being free: knowing about a vulnerability and not fixing it, ending support whenever it suits the roadmap, and writing a sentence in a licence that makes both of those someone else’s problem. Those were the load-bearing elements of ship-and-forget, and the load has moved.

For most teams the practical question this raises is not legal but archaeological. Which of your products are in scope, what is actually in them, and how long did you tell anyone you would support them? Those answers used to live in marketing copy. After December 2026 they live in your liability exposure — and the mapping exercise underneath them is the same one that any serious compliance programme starts with. Companies that already know what is in their dependency tree will find this a documentation problem. The rest will find it something else. As twenty years of supply chain incidents suggest, the second group is larger.