[AI-generated image: just like Neo dodging bullets in the Matrix, software companies are somehow able to evade lawsuits.]
Introduction
Software is an anomalous industry. There aren't many types of businesses that can get away with releasing products or services to the public with the assumption that there could be a high likelihood of significant flaws and defects. If Tesla were to release a car with faulty brakes with the attitude of, "We can just fix this later,” they’d be sued into bankruptcy. Yet software companies don’t face an onslaught of lawsuits for products that could be laden with flaws, and if they are sued, they frequently get such cases thrown out or settled for nominal amounts.
Ever wonder why software companies get away with that and why, as users, we are constantly asked to update software and accept and agree to updates in the terms of use and privacy policy? In this article, we'll explore the legal barriers and norms shielding tech companies from an onslaught of civil litigation from private parties, the points of negotiation you should try to push for if you have any leverage with a software company, and the recent case law trends. Buckle up, let’s go beyond the firewall, and get “wired in.”
Creating bug-free software is challenging because of its complexity and whether software is classified as a service or a product affects how liability is determined.
Software companies are shielded by a "tech veil" that includes legal defenses like litigation hurdles, contractual terms, and structural protections.
The terms of use and licensing agreements include disclaimers of warranties, liability limits, and indemnification clauses to protect software companies. Courts usually uphold these terms, so consumers should negotiate exceptions for express warranties, liability caps, and limit indemnification.
Case law shows that courts often favor software companies in liability cases.
Meanwhile, new regulatory efforts are emerging to hold software companies to higher standards, especially re AI, crypto, and cybersecurity.
I. What Is a Bug? Why Is It So Hard to Create Glitch-Free Software?
A software bug is a mistake or glitch in a program that prevents it from working correctly. Imagine baking a cake with a typo in the recipe calling for 1 tablespoon instead of 1 teaspoon of salt, making it too salty. Now, if this cake is a layer in a multi-tiered cake, the mistake affects the entire dessert. Similarly, minor software errors can escalate due to dependencies (external libraries or modules a software relies on) and integrations (connecting different software systems), causing widespread issues in connected systems.
[AI-generated image: trying to design software is like trying to execute a successful, massive domino toppling. One wrongly placed tile can lead to an epic fail.]
Writing flawless software is also like setting up a massive line of falling dominos: if one tile is out of place, the entire chain reaction may fail. Even a tiny mistake, like a misplaced character or minor logical error in the code, can lead to crashes, data loss, or security vulnerabilities. Working code in one part of a program might break when edits are made elsewhere. Software must also be compatible with different devices and systems and requires regular updates, which can introduce new problems. These factors make it incredibly challenging to ensure software is entirely fault-free.
II. Is Software a Service or a Product?
So now that we understand why software is complex as a technology, let’s explore why it’s tricky to hold software companies liable. As a starting point, let's consider whether software is (i) an intangible good/product or (ii) a service. Frustratingly, software could be both!
Software as a service
In the US, contracts for services (and real property) fall under common law (i.e., case law and judicial decisions). Software may be considered a service if custom-designed for a specific customer, licensed in cloud applications (SaaS or software-as-a-service), or involved maintenance and support services.
Software as a product
Contracts for tangible and movable products or goods fall under state commercial laws (known as the Uniform Commercial Code (UCC)). The UCC provides a standardized, predictable framework for commercial transactions involving movable goods and products, which, in the context of software, we can think of as "off-the-shelf" products, software included in hardware, software sold on physical mediums, or any mass-marketed software. For more on the UCC and how commercial law works in the US, I recommend my prior post.
Of course, it's often difficult to classify software as a product OR a service as it may have elements of both. In which case, software that is a mixture of product and service will require a court to analyze which predominates. That analysis matters because whether the software is a service or a product can determine the available legal routes for a lawsuit.
III. Tech Veil Protects Software Companies from an Onslaught of Class Action Lawsuits
[AI-generated image: the tech veil shields software companies from legal responsibility.]
Like the corporate law concept of the “corporate veil” that shields stockholders from personal liability for a corporation’s legal infractions, software companies are protected against broad liability by a “tech veil.”
Coined by Jenny Leung, the "tech veil" helps software companies and developers avoid liability for bugs, vulnerabilities or third-party misuse of their code. Indeed, various legal tactics have created moats (i.e., a competitive advantages deterring adversaries) that shield software companies from the wrath of litigants. I classify these moats into three broad categories:
A. Litigation Moats
B. Contractual Moats
C. Structural Moats
[AI-generated image: just as moats protect the castle, layers of moats protect software companies]
A. Litigation Moats
In general, software companies can be sued under claims for a (1) breach of warranty, (2) negligence, or (3) strict liability. The factors that lead you to decide upon which legal theory to sue a software company depend on whether:
the software is considered a good or service,
the damage is economic, personal, or property-related,
there is a contract in place, and
the software is part of something abnormally dangerous.
1. Breach of Warranty
What is a breach of warranty?
When software fails or isn't delivered correctly, a user with a contract can sue the software company for breaching or violating the contract. This breach occurs when the company fails to fulfill its contractual obligations.
Contracts typically include promises or guarantees about the quality of the product or service, known as warranties. If the software doesn't meet the standards or specifications outlined in the warranties, it constitutes a breach of warranty. Often, when a software customer sues for breach of contract, the underlying issue is actually a breach of warranty. [Note: A breach of warranty is a specific type of breach of contract, but not all breaches of contract involve a breach of warranty. For simplicity, consider a breach of warranty claim as also being a breach of contract.]
There are two types of warranties:
“Express warranties” are specific promises made by the seller or service provider in the contract. For example, I promise to deliver you working software by Tuesday.
“Implied warranties” are legal protections that the law automatically applies to goods and services, regardless of whether stated or not in the contract. There are two types: (i) "fitness for particular use" (when the seller knows the buyer needs the goods for a specific purpose and the buyer relies on the seller to provide the correct goods for that purpose) and (ii) "merchantability" (goods are good enough to be sold and used for their usual purpose without any issues). Here’s an example of a warranty:
When it comes to determining if the seller has done what's required under the contract, the standards are different for product contracts versus service contracts. For product contracts, the seller must meet all the specifications, descriptions, and promises outlined in the contract exactly - this is called "perfect tender." Even a minor deviation from any contract term is considered a breach.
However, for service contracts, the requirements are not as strict. Instead, they only need to provide a service that substantially meets the main contractual requirements, even if there are some minor issues or deficiencies. As long as the essential parts of the contract are reasonably fulfilled and the service is fit for its intended purpose, it is generally considered acceptable.
Why can’t plaintiffs extract a lot of money against software companies for breach of warranty (contract) claims when there are issues with the software?
When software fails and causes only financial losses, lawsuits are typically limited to breach of contract claims. Recovery is usually restricted to direct damages, which means compensating the customer for their actual losses, such as the cost or value lost. The goal is to place the non-breaching party in the position they would have been in if the contract had been fulfilled. This often makes lawsuits unattractive because legal costs can exceed potential recovery.
The rationale is that parties can manage risks through contract terms, with economic risks best handled within the contract framework and often mitigated with insurance. Contract law aims to facilitate fair exchanges (not punishment), focusing on restoring the parties to their expected positions if the contract were honored. We’ll see how the language of the contract itself can limit recovery.
[AI-generated image: most software doesn’t cause physical or personal damage…unless it involves gremlins.]
If the damage involves an accident or physical harm, that’s better suited for the next two litigation moats.
2. Negligence
What is negligence as it relates to software as a product vs. service?
If damages from software include damages to property or a person, a negligence lawsuit can be brought. Negligence occurs when someone fails to take reasonable care to prevent harm to others. Unlike contract related claims, negligence claims do not require a direct contractual relationship between the consumer and the manufacturer; liability is imposed by law. For example, let’s say a software bug led to an accident in a factory, in which some of the workers were injured. Those workers could potentially sue the software company for negligence, even though they didn't directly purchase the software from or or have a contract with that company.
Negligence claims for software products can be based on defects, which fall into these categories:
(i) design defects (where the product’s design is itself unsafe),
(ii) manufacturing defects (where the product deviates from design specifications), or
(iii) information defects (where there is a failure to provide proper instructions or warnings).
For software as a service, negligence involves failing to perform services with reasonable care. Negligence allows for compensation if it can be shown that a software defect arose from the service provider's lack of proper care in designing or developing the software. Under this principle, a service provider isn't liable for every defect that causes loss but only for harmful defects that could have been identified and remedied through reasonable software practices.
Why is it so hard to bring a negligence claim against a software company?
To succeed in a negligence claim, you must prove all of the following 4 elements: (1) there was a legal duty, (2) that duty was breached, (3) the breach of that duty caused harm, and (4) that harm led to damages. Pretty simple, right? Well, for software, this is hard to prove:
Duty and Breach of Duty (Element 1 & 2): Software developers are not held to a higher "professional" standard of care like doctors or lawyers. They have a duty to act with the reasonable care of an average person, which is a low bar. Proving a breach of this minimal duty is tricky because an ordinary person would not catch every possible defect (we are only human and flawed, just like software).
Causation (Element 3): Proving the software defect directly caused the harm is also challenging. Users must prove the software defect itself caused the harm, rather than any user-related contribution, like failure to install updates, improper installation, or unauthorized modifications to the software. The involvement of multiple intermediaries (developer -> third-party vendor -> end-user) further complicates assigning blame. Additionally, as software often interacts with other hardware or software, pinpointing the defect as the direct cause (known as ‘proximate cause’) becomes difficult. Proving who caused the harm gets complicated!
Damages (Element 4): Most software products don't cause tangible injuries or property damage. While exceptions exist like self-driving car software failures, these are rare cases. So, proving damages can be pretty remote.
[AI-generated image: trying to impose liability on software companies is like trying to catch a greased pig on ice.]
Remember, a litigant needs to prove all four elements (duty, breach, causation, and damages) to win – an uphill battle.
In cases where there was a contract between the user and the company, the “Economic Loss Doctrine” can prohibit plaintiffs from seeking compensation for negligence (and also strict liability) for solely economic losses. Recovery is limited to claims involving property or personal damage. It ensures that parties stick to the remedies specified in their contract, preventing them from seeking additional compensation through negligence claims.
Let's turn to strict liability, which focuses on the product's inherent danger rather than the developer's level of care.
3. Strict Liability
What is strict liability?
If a software product is inherently, abnormally, or imminently dangerous (ex., software embedded in a medical device that could cause injury if it malfunctions), lawsuits might be brought under a strict liability standard. Strict liability doesn't take fault into account. Under strict liability, a software developer is automatically held accountable for all physical injuries and associated losses caused by a defective product it produces, regardless of whether it was negligent in its design or manufacturing decisions. The idea is that when dealing with inherently dangerous products, the responsibility for any resulting harm should rest with the producer to ensure higher safety standards and protect public welfare.
Is it easy to succeed in a lawsuit against software companies for strict liability? Who else can be liable?
You can sue anyone in the commercial chain of sale for strict liability as long as the product was defective when it left the defendant’s control. To succeed, you must prove that: (i) the defendant was the supplier who produced or sold a defective product, (ii) the defective product was the cause of a physical injury or property damage, and (iii) the consumer suffered those damages. Again, most software doesn't result in physical or personal damages, so this is more of an edge case.
Will strict liability apply to software as a service and a product?
Note that strict liability typically applies to defective products, not services, because services do not have the same characteristics that justify strict liability. When customers hire service providers to create custom software, they are more involved and have better visibility into how the software is made. Because of this, strict liability, which holds manufacturers responsible for defective products regardless of fault, usually does not apply to custom-developed software.
That brings us to the end of the litigation moats. Let's talk about contractual moats.
Decision Tree: Which Kind of Harm Leads to What Type of Lawsuit
B. Contractual Moat
1. Terms of Contract
Software companies use various contractual techniques to protect themselves, deployed in the terms of use (TOU), privacy policies, licensing agreements, and end-user licensing agreements (EULA).
When you buy off-the-shelf software, the agreement you sign (or click "I agree") is usually one-sided. It states that the software company isn't responsible if something goes wrong and restricts the use. If you don't like the terms, too bad; you can take it or leave it. Basically, the company is passing on all the risks to you, and the courts have generally upheld these clickwrap agreements as valid, enforceable contracts. You probably click "I agree" without much thought, but remember that the TOU is a binding contract. Since the rise of the internet, courts have supported software companies' ability to contract away most liability for defects in their products. The law assumes you can make your own contracts and will only nullify a contract under rare circumstances.
Whether you are entering into terms of use (TOU) or end-user licensing agreements (EULA), you’ll notice certain boilerplate language, including disclaimers of warranties, indemnification, waivers, limitation of liability, barring consequential damages, dispute resolution, insurance requirements, assumption of the risk, force majeure clauses, among others. These risk-shifting provisions transfer certain risks from the company to the user. Tech companies are constantly updating and improving these terms, which is why you are frequently asked to accept any updates to the TOU and privacy policies. You can see how crucial it is to negotiate software agreements if you have any leverage.
This risk-shifting does come with a price. Harrison Hawkes, my former colleague, pointed out to me that software providers are able to include such blanket disclaimers and risk-shifting provisions partly because they've priced their offerings accordingly. In other words, software companies may be able to provide lower prices by shifting the risk to the consumer. One additional factor to consider when negotiating a contract.
Let’s look at a few examples of disclaimers of warranties, limitation of liability, and indemnification and see points where you can push back in your negotiations.
i. Disclaimer of Warranty
What is a disclaimer?
Interestingly, a software provider can disclaim express and implied warranties by including a clear and noticeable disclaimer in the contract. For implied warranties, you'll often see phrases like "as is" or "with all faults." You've likely encountered this language in the TOU for many websites. Here's an example of warranty disclaimer from Google:
One way for you or your lawyer to push back on the disclaimers is to add a phrase saying, “EXCEPT AS EXPRESSLY SET FORTH IN THE REPRESENTATIONS AND WARRANTIES SECTION.” “Representations and warranties” (R&W) is a section where a party states to the other party that a particular fact is true (a representation) or will be true (a warranty). Sometimes, they are mutual (both sides make them), and sometimes, they are one-sided. A representation looks backward in time, and a warranty is future-facing. If the rep or warranty is not true, then the party making the rep or warranty has breached the contract, and you could sue. R&W are often connected to an indemnification provision (see below). Thus, by saying the disclaimer doesn’t apply to the R&W section, you limit what can be disclaimed.
ii. Limitation of Liability
Most software companies will limit their liability by (1) excluding indirect damages, consequential, lost profits, special damages, punitive damages, etc. (basically anything that’s not direct damages) and (2) putting a cap (a monetary limit) on the amount of damages. Here’s an example from Microsoft:
If you have any wiggle room to negotiate the contract with a software company, add a carveout to the liability cap for (1) breaches of confidentiality; (2) indemnification obligations; and (3) gross negligence, willful misconduct, and fraud. You can negotiate a higher monetary limit or cap for better coverage or require the software company to obtain insurance.
iii. Indemnification
Software contracts often include an indemnification clause, where one party agrees to compensate the other for legal defense costs. This could be mutual or one-sided. If the consumer is indemnifying the software company, that means the consumer must protect the software company if the company is sued due to the consumer's use of the software, whether for legitimate or unlawful reasons. Here’s an example from Ironclad:
You can try to remove the indemnification provision altogether, but if that’s a non-starter for the software company, you can try to limit it in the following ways:
Only agree to indemnify the company for your own gross negligence or willful misconduct.
Exclude indemnification claims that arise due to the software company's negligence, breach of contract, or intellectual property violations.
Cap the indemnification amount to a reasonable sum covering only direct damages, excluding indirect or consequential damages.
Ensure the indemnification only covers losses from an actual (not exploratory) lawsuit or claim brought by a third party against the software company. Be careful as you could end up indemnifying the software company for suing you! If possible, limit losses to amounts paid or payable to third parties, avoiding internal costs incurred by the indemnified party.
Consider pushing for mutual indemnification (i.e. both parties agree to indemnify each other) under similar terms. This tactic can help balance and defang an otherwise one-sided provision.
Note from the perspective of the party being indemnified (getting compensated): this is the best risk-shifting provision for the party being indemnified because, in theory, you can be made whole.
Since UCC and contract law principles believe in the freedom to contract and only void a contract under certain edge cases, courts have upheld these risk-shifting provisions. It's one of many things that have become the industry norm.
[AI-generated image: trying to hold software companies liable may be like trying to catch a rainbow — with a leprechaun just laughing at you.]
C. Structural Moat
1. Industry Norms and Illustrative Cases
After decades of improvement in software safety and quality, most commercial software is still shipped with serious flaws and defects, and as users, we’ve come to just accept this.
Software industry argues flaws are inevitable
The software industry pushes the idea that such defects are unavoidable, and it tries to ameliorate those weaknesses by continuing to update the software. If a higher standard were imposed on software providers, the industry argument is that it would lead to (i) slower development inhibiting innovation and (ii) higher prices for consumers. Not to mention, software doesn't exist in a vacuum, and it must interact with the rest of the world. Issues that cannot be mitigated by simple bug fixes, and which can only be discovered via thorough reviews and testing (or revealed when the software fails or is successfully hacked after deployment), are unlikely to ever be addressed. This may be a form of Stockholm syndrome…
Apple Siri lawsuit: dodging a breach of implied warranty claim
Here's a classic example (Fazio v. Apple, Inc.) – in 2013, Apple was sued for breach of implied warranties for misrepresenting the capabilities of the voice-activated iPhone “Siri” assistant so that consumers would be encouraged to pay a premium for the iPhone 4S. However, the court noted that the plaintiffs admitted Siri could perform basic functions like finding gas stations or restaurants. Because Siri could still perform these tasks, the court concluded that the iPhone 4S was not entirely unfit for ordinary use. Therefore, the plaintiffs did not provide enough evidence that Apple breached the implied warranty.
[AI-generated image: just like Rip Van Winkle, we just accept that we must wait forever for software to load only to wake up 20 years later and find it still loading.]
Third-party bad actors complicate pinpointing liability
Additionally, courts have been reluctant to hold a software company liable for a security vulnerability involving third-party bad actors. While there is a logic to holding the wrongdoer liable for a hack, when do you hold a software company (the toolmaker) liable for someone else's nefarious actions? The software company can also be seen as a victim in these situations, making secondary liability tenuous. Furthermore, plaintiffs must demonstrate that the security breach caused actual harm or poses a substantial risk of imminent harm. Courts often dismiss cases where plaintiffs only allege an increased risk of future identity theft or preventive costs, like credit monitoring, without showing concrete injury.
Sony data breach lawsuit: evading negligence and breach of implied warranty
In 2014, Sony faced a data breach lawsuit (In re Sony Gaming Networks & Customer Data Sec. Breach Litig.) with the court dismissing 43 of the 51 claims. Most negligence, negligent misrepresentation, and consumer protection claims were dismissed due to insufficient evidence of real harm. Plaintiffs argued for a “special relationship” with Sony, implying a higher duty to protect their data, but the court found no such relationship existed, citing typical consumer transactions and Sony's disclaimers. The Economic Loss Doctrine barred claims in California and Massachusetts, and the loss of free services was not considered an injury. Breach of implied warranty claims were dismissed due to effective disclaimers provided during registration. Ultimately, Sony settled the remaining claims for $15 million in games, online currency, and identity theft reimbursement.
Hidden complexities beneath software’s surface
Software is often a black box, making it difficult for laypeople to understand its inner workings. Assigning blame is challenging because errors are not easily visible, and it is hard to determine whether the problem lies within the software or another component it interacts with. If you leave a banana peel on the sidewalk and someone slips on it (breaking his arm), it’s pretty obvious that the banana peel led to the accident. The complexity and lack of transparency with software make pinpointing the source of issues and holding the correct party accountable particularly difficult.
[AI-generated image: pretty obvious slipping on a banana peel causes one to fall. In fact, there are a ton of lawsuits on banana peel falls.]
Hewlett-Packard Co.: breach of warranty dropped because hard to prove the cause
As an illustration, Hewlett-Packard was sued in 2012 (Wilson v. Hewlett-Packard Co.) for breach of contract for violating its warranty due to its Pavilion and TouchSmart computers overheating and creating a danger to consumers. The court dismissed these claims, saying the plaintiffs failed to explain how laptops without power could catch fire. Without any proof, it was an implausible defect.
2. No Privity of Contract
End users may lack a formal relationship with software company
In business-to-business scenarios, the end user often lacks a direct, contractual relationship (“privity of contract”) with the software developer. This complicates accountability. Not having privity of contract often discourages consumers from pursuing tort or product liability claims against developers. Additionally, contracts between vendors and manufacturers may limit the manufacturer's liability for end-user complaints.
Free products may not create a contractual relationship
A contract requires (i) an offer, (ii) acceptance, and (iii) payment (“consideration”). Many consumers don't pay directly for software; for example, Gmail users provide data instead of money, making them the product and ad companies the customers. Without a payment or consideration, there is no contract between users and the software company. This helps software companies avoid liability for breach of contract claims and can make users ineligible to bring claims under certain state consumer protection laws meant for paying customers.
[AI-generated image: to software companies, users are often not customers or clients.]
Facebook privacy lawsuit - nonpaying users are not “consumers”
In a consumer protection class action suit brought against Facebook in 2011 (In re FACEBOOK PRIVACY LITIGATION) for a data breach, the court dismissed the lawsuit because the plaintiff hadn’t paid to use Facebook and was not protected by the California general consumer statute on point. Without paying for services, the user was not considered a "consumer" under state law. The law was designed to protect consumers. Apple had a similar case dismissed.
Note, software lacks specific consumer protection laws and is not highly regulated like banks or drug companies. General consumer protection laws apply in some cases, but they don't address the unique safety and security challenges of software.
IV. Recent Case Law Trends in the US and UK
There is a clear desire by US courts to address data breaches. While there are data protection laws in each of the states, which in theory can lead to a successful lawsuit for a plaintiff, winning a case against a software company for data breaches can still be challenging. Judges are leveraging all available legal resources to protect consumers.
Here are a few notable cases that illustrate the complexity and some positions the courts have taken:
Liability upheld despite free service. In a 2018 class action lawsuit in California against Facebook for a data breach affecting 29 million users (Echavarria v. Facebook, later Schmidt v. Facebook), Judge Alsup rejected Facebook’s claim that it shouldn't be liable because its service was free. He emphasized that Facebook's business platform monetized users’ personally identifiable information (PII) by selling it to advertisers. The judge noted that no previous case directly addressed this question and looked to be trying to find some logic to protect users. The case was ultimately settled for $6.5 million--a drop in the bucket for Facebook.
Bailment theory applied to electronic data mishandling. A 2022 Indiana class action suit (Krupa v. TIC International Corp.) recently held software developers liable under a bailment theory (i.e., you temporarily hand over your belongings to someone else for a specific reason, with the understanding that they'll return them to you later). The court recognized that bailment applies to electronic data, not just physical goods. The Krupa court found that the defendant negligently exposed the plaintiff's personal data, which was held under an agreement of confidentiality. Similarly, a 2021 New York case (Wallace v. Health Quest Systems, Inc.) denied a motion to dismiss a constructive bailment claim for a data breach, affirming that New York courts would extend bailment to intangible information.
Let's look at some examples from the crypto industry where there have been cases exploring whether developers owe a fiduciary duty to users. A fiduciary duty is a legal obligation requiring one party (the fiduciary) to act in the other party's best interests (the beneficiary). Fiduciaries must avoid conflicts of interest, act in good faith, act with care and loyalty, put the beneficiary's interests above their own, and fully disclose relevant information.
Economic loss rule bars negligence claims. In Singh v. Illusory Systems, Inc., the software developers of the Nomad Bridge were sued for the theft of crypto assets due to a vulnerability in the underlying software. The judge dismissed the negligence claims because the economic loss rule bars recovery for purely economic damages when a contract governs the dispute. The plaintiffs were bound by agreements (the Terms of Use (TOU) and Apache License (a type of software license)) that covered the risks and limited liability for issues like security breaches and hacks. Additionally, the court found no independent duty of care outside these contracts, particularly since the plaintiffs were sophisticated parties capable of understanding and negotiating risk allocation. Lastly, the defendants weren't directly connected to the plaintiffs, so they didn't owe the plaintiffs any special care. The negligence claims were dismissed as a result.
Special relationship establishes duty of care. While not a case pushing a breach of fiduciary duty, the following case goes into software companies and developers of a decentralized protocol having a duty of care towards the users of its protocol. In Sarcuni v. bZx DAO, a major security breach of the bZx crypto protocol resulted in the theft of around $55 million in cryptocurrency. The breach occurred due to a phishing attack that compromised a bZx developer's private seed phrase, allowing the hacker to drain funds from the protocol. The court determined that a “special relationship” existed between the plaintiffs and the defendants (who included the software developers, development company, and DAO, among others), establishing a duty of care. Unlike in Illusory, the judge ruled the terms of use / click wrap agreements were not conspicuous enough to be enforceable: “Plaintiffs had neither actual nor constructive notice of the Terms of Use and, therefore, aren't bound by them.” The terms were located at the bottom of the page so you had to scroll all the way to the bottom. The case was ultimately settled, so it’s unclear if the negligence claim, if tried, would have succeeded. While software companies and developers may not rise to the level of being fiduciaries, the law seems to want to put some sort of duty on them and hold someone accountable even in the case of a decentralized blockchain, which in theory has no intermediaries.
[AI-generated: software companies seem to have endless "Get Out of Jail Free" Cards. Big fans of Monopoly?]
Fiduciary duty on trial in UK. There is one case worth watching presently in the UK. The case of Tulip Trading v Wladimir van der Laan & Ors asks whether Bitcoin developers owed fiduciary duties to cryptocurrency owners. In March 2022, the UK High Court ruled that Bitcoin developers did not owe any fiduciary duties, but in 2023, the Court of Appeal overturned that decision, saying it is a "serious issue to be tried." The case moved to a full trial to try this question. But in an odd turn of events, Craig Wright who brought the Tulip lawsuit against Bitcoin developers and also falsely claimed to be Satoshi Nakamoto (the inventor of Bitcoin), dropped the lawsuit after it came out that he lied about being Satoshi… We’ll have to wait to see how the UK looks at this issue in a future lawsuit.
V. Conclusion
It's clear that existing laws need an upgrade if society feels consumers need greater protections. That could look like providing a professional standard of duty on software companies (some people even think we should hold software developers to a reasonable computer standard).
VI. Extra Credit (Government Actors v. Software Developers)
With AI and crypto pushing the boundaries and raising novel questions of our legal systems, we are starting to see lawmakers take action to regulate Big Tech – although folks have been saying this for years. Where conduct rises to the level of fraud or Bank Secrecy Act violations (money laundering / illicit finance), the government is flexing its muscle on these types of cases:
Unfair or deceptive trade practices: The Federal Trade Commission (FTC) has broadened its scope beyond lawsuits for unfair competition against tech companies. It now also takes action against unfair or deceptive trade practices, including software misrepresentation. Notably, the FTC has taken legal action against companies like D-Link, TRENDnet, and ASUS for vulnerabilities in internet-connected devices.
Liability for end user scams or misuse:
The FTC a few months ago proposed a rule that would impose liability on anyone that provides the tools and services that they know or should have reason to know are being used in AI impersonation scams -- i.e. AI software companies and developers. For more info, please read my comment letter to the FTC.
Commodity Futures Trading Commission (CFTC) Commissioner Brian Quintenz warned if "code developers could reasonably foresee, at the time they created the code, that it would likely be used by U.S. persons in a manner violative of CFTC regulations," they could be prosecuted for aiding and abetting such violations.
Unregistered security offering: The Securities and Exchange Commission (SEC) in 2018 charged Zachary Coburn (founder of EtherDelta and writer/deployer of the EtherDelta smart contract) with operating an unregistered national securities exchange.
Mixers and money laundering: The Department of Justice has brought criminal prosecutions against individual crypto software developers for cryptocurrency mixing services (U.S. v. Rodriguez and Hill) that involve charges for alleged unlicensed money transmitter business and conspiracy to commit money laundering. Case is pending.
Accountability for negligence or deficient cybersecurity:
The Department of Justice's Civil Cyber-Fraud Initiative will hold government contractors accountable for software insecurity resulting from negligent or fraudulent practices, such as providing deficient cybersecurity products or misrepresenting their cybersecurity practices.
In May 2021, President Biden issued the Executive Order on Improving the Nation's Cybersecurity, which mandates that software companies selling to the federal government meet new security standards. These standards include providing greater transparency about their software development processes and cooperating in vulnerability disclosure programs to ensure the security of their products.
In March 2023, President Biden's administration announced its National Cybersecurity Strategy, which aimed to hold software vendors accountable for cyberattacks by proposing legislation that shifts liability to companies that fail to secure their software adequately. This initiative included a safe harbor for companies following best practices and aims to drive the market toward producing safer software while supporting innovation and competition among smaller businesses. Thus far, there’s been no legislative action.
[Special thanks to Jason Gottlieb and Emma McGrath (for doing some pro bono research confirming that the case law is truly all over the place) as well as Harrison Hawkes (for his review as a tech transactions expert)!]
Image of Software Developer Dodging Bullets created by Pixlr, Firefly, BeFunky, and DreamStudio
Image of Get out of Jail Free Card created by Pixlr and Firefly
Image of Castle with 3 Moats created by Dall-E and Firefly
Image of Tech Veil bride created with Dall-E, Firefly, and Pixlr
Image of Chasing the Rainbow created with Dall-E and Pixlr
Image of Rip Van Winkle created by Dall-E, Firefly, and Pixlr
Image of Alligator Purse created by Dall-E, Firefly, and Pixlr
Image of Computer on the Stand by Dall-E, Firefly and Pixlr
Disclaimer:This post is for general information purposes only. It does not constitute legal advice. This post reflects the current opinions of the author(s). The opinions reflected herein are subject to change without being updated.
So many lawsuits and so much lobbying. I can't imagine when America will have rule of law regarding generative AI.
In China they're trying to make it illegal for AI to deceive and manipulate humans. In America this seems to be the primary business model.