Practical examples of limitation of liability in software licenses

When lawyers and developers negotiate software deals, the conversation almost always lands on one thing: the limitation of liability clause. If you’re looking for real, plain‑English examples of limitation of liability in software licenses, you’re in the right place. These clauses decide how much financial risk a software vendor is actually taking on when something goes wrong. In modern SaaS and on‑premise agreements, examples of limitation of liability in software licenses usually cap damages, exclude certain categories of losses, and sometimes tie the cap to the fees you’ve paid. The exact wording matters a lot, especially as 2024–2025 trends push vendors to tighten their risk exposure while large customers demand broader remedies. This guide walks through realistic wording, explains why companies use it, and shows how courts tend to treat these provisions so you can spot red flags, negotiate better terms, and avoid expensive surprises when a system outage or data loss hits.
Written by
Jamie
Published
Updated

Real‑world examples of limitation of liability in software licenses

Lawyers rarely admit it, but most limitation of liability clauses are variations on the same small set of patterns. To make this concrete, here are realistic examples of limitation of liability in software licenses, written in the kind of language you actually see in SaaS and enterprise contracts.

These are illustrative samples, not legal advice. If you’re drafting or signing anything serious, you want a qualified attorney looking at your specific facts.


Example of a basic aggregate liability cap

A very common example of limitation of liability in software licenses is the aggregate cap tied to fees paid:

Sample clause:
“Except for Customer’s payment obligations, each party’s total aggregate liability arising out of or related to this Agreement shall not exceed the amounts actually paid by Customer to Provider under this Agreement during the twelve (12) month period immediately preceding the event giving rise to the claim.”

This kind of clause does two big things:

  • It puts a hard ceiling on total exposure.
  • It pegs that ceiling to a look‑back period (often 12–24 months of fees).

In practice, if you pay \(100,000 a year for a SaaS platform and something goes wrong, this example of a limitation of liability clause aims to cap the provider’s exposure at about \)100,000, regardless of how large your downstream business losses might be.


Example of excluding indirect, consequential, and special damages

Another classic example of limitation of liability in software licenses is the damage exclusion paragraph:

Sample clause:
“In no event shall either party be liable for any indirect, incidental, consequential, special, exemplary, or punitive damages, or for any loss of profits, revenue, data, or business opportunities, whether arising in contract, tort, or otherwise, even if advised of the possibility of such damages.”

This is the vendor’s way of saying: We’ll pay for direct, provable harm up to the cap, but not for your entire business model collapsing because our system went down for three hours.

Courts in the U.S. and U.K. often enforce these exclusions as long as they’re clearly written and not unconscionable. The line between direct and consequential damages is heavily litigated, but the structure of this example is extremely common.


Combined example: Cap plus exclusions in a SaaS license

Most modern cloud contracts combine a cap and exclusions. Here’s a realistic combined example of limitation of liability in software licenses for a mid‑market SaaS product:

Sample clause:
“Except for (a) Customer’s obligation to pay fees, and (b) each party’s indemnification obligations, each party’s total aggregate liability arising out of or related to this Agreement shall not exceed an amount equal to the fees paid or payable by Customer to Provider under this Agreement in the twelve (12) months immediately preceding the event giving rise to the claim.

In no event shall either party be liable for any indirect, incidental, consequential, special, or punitive damages, or for any loss of profits or revenue, even if such party has been advised of the possibility of such damages.”

A few things to notice in this example:

  • Indemnification carve‑out. Indemnity obligations (for IP infringement, third‑party claims, etc.) are often excluded from the cap, especially in large enterprise deals.
  • Fee‑based cap. Tying the cap to 12 months of fees is nearly standard in SaaS.
  • Mutuality. The clause protects both parties, which makes it more acceptable in negotiation.

Industry‑specific examples of limitation of liability in software licenses

The best examples of limitation of liability in software licenses don’t all look the same. They shift depending on regulatory risk, data sensitivity, and bargaining power.

Healthcare software: Higher stakes, higher caps

For an electronic health record (EHR) platform used in U.S. hospitals, you might see language like:

Sample clause:
“Provider’s total aggregate liability arising from or relating to this Agreement shall not exceed two (2) times the fees paid by Customer to Provider in the twelve (12) months preceding the event giving rise to the claim. Notwithstanding the foregoing, Provider’s aggregate liability for breaches of its obligations under the Business Associate Agreement or for violations of applicable privacy laws shall not exceed three (3) times such fees.”

Here the vendor accepts a higher cap for privacy and security failures because the regulatory exposure under HIPAA is significant. For context, the U.S. Department of Health and Human Services publishes enforcement data and settlement information that shows how expensive privacy failures can be in healthcare settings (see: HHS enforcement data).

This is a good real example of how risk profile drives the structure of a limitation of liability clause.


Fintech and payments: Carve‑outs for regulatory fines

In fintech, you often see examples of limitation of liability in software licenses that exclude regulatory fines from the standard cap, or that handle them in a separate bucket:

Sample clause:
“Provider’s aggregate liability under this Agreement shall not exceed the greater of (a) the total fees paid by Customer to Provider in the twelve (12) months preceding the event giving rise to the claim, or (b) \(500,000. This limitation shall not apply to (i) Provider’s gross negligence or willful misconduct, or (ii) third‑party claims arising from Provider’s violation of applicable financial services regulations, for which Provider’s aggregate liability shall not exceed \)2,000,000.”

Two trends show up here that have become more common in 2023–2025:

  • A floor (e.g., $500,000) to avoid a very low cap for smaller customers.
  • A separate, higher cap for regulatory‑driven third‑party claims.

Open‑source licenses: Near‑total disclaimers

Open‑source licenses provide some of the starkest examples of limitation of liability in software licenses. The classic wording from permissive licenses is very aggressive.

For instance, the MIT License includes this language:

“IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.”

You can read the full text at the Open Source Initiative.

This is an example of a near‑total no‑liability stance: if you use the code, you do so almost entirely at your own risk. Courts can still limit these clauses in some jurisdictions, especially for consumer use or personal injury, but for commercial users this language is often enforced.


How modern SaaS contracts structure limitation of liability

By 2024–2025, most mature SaaS vendors have settled into a few patterns. When you look at real examples of limitation of liability in software licenses for cloud services, you’ll usually see some mix of:

  • Fee‑based cap (12–24 months of fees; sometimes 1.5x–3x multiplier for specific risks).
  • Excluded damages (indirect, consequential, loss of profits, loss of data).
  • Carve‑outs for:
    • Confidentiality breaches
    • Data security incidents
    • IP infringement indemnity
    • Personal injury or death caused by physical products or devices

A realistic SaaS enterprise clause might look like this:

Sample clause:
“Except for Excluded Claims, each party’s total aggregate liability arising out of or relating to this Agreement shall not exceed an amount equal to one and one‑half (1.5) times the fees paid by Customer to Provider under this Agreement in the twelve (12) month period immediately preceding the event giving rise to the claim.

“Excluded Claims” means (a) Customer’s payment obligations; (b) either party’s breach of its confidentiality obligations; (c) either party’s indemnification obligations; and (d) Customer’s violation of Provider’s intellectual property rights. For Excluded Claims, each party’s total aggregate liability shall not exceed three (3) times such fees.

In no event shall either party be liable for any indirect, incidental, consequential, special, or punitive damages, or for any loss of profits or revenue, arising from or related to this Agreement.”

This is the sort of negotiated language you’ll see where both parties have real bargaining power.


Looking across recent contract playbooks, tech M&A deals, and SaaS negotiations, a few trends stand out.

Higher caps for cybersecurity and privacy incidents

As cyber incidents keep climbing and regulators sharpen their teeth, many customers now insist on higher caps for security breaches. Several large‑enterprise templates in 2024 include:

  • Standard cap of 12 months of fees.
  • Security/privacy cap of 2x–3x that amount for data breach‑related claims.

This aligns with increased focus from regulators and guidance from agencies like the Federal Trade Commission on data security practices and enforcement (see FTC data security resources).

AI and ML tools: New risk categories

AI‑powered software introduces oddball risks: hallucinated outputs, bias, and compliance failures. Some of the best examples of limitation of liability in software licenses for AI tools now include explicit exclusions or limitations for:

  • Decisions made by the customer based on AI‑generated recommendations.
  • Accuracy or completeness of AI outputs.

For example:

Sample clause:
“Provider shall have no liability arising from Customer’s decisions or actions based on the outputs generated by the Services. Customer is solely responsible for verifying the accuracy and suitability of such outputs for Customer’s use cases.”

You may also see AI‑specific carve‑outs where the provider accepts a limited cap for third‑party IP claims arising from training data, while still excluding broader consequential damages.

Stronger pushback from large customers

On the customer side, Fortune 500 legal teams are increasingly unwilling to accept tiny caps for mission‑critical systems. In 2024–2025 negotiations, patterns include:

  • Demanding super‑caps (e.g., 5x–10x fees) for outages that exceed specific SLAs.
  • Requiring a separate cap for data restoration costs after a loss event.

Even if vendors start with aggressive boilerplate, the final signed examples of limitation of liability in software licenses for these deals look much more balanced.


How to read and negotiate these clauses

When you’re staring at a dense paragraph of all‑caps legalese, here’s how to break it down.

Step 1: Find the cap

Look for phrases like “total aggregate liability” or “shall not exceed.” Ask:

  • Is the cap a fixed dollar amount, a multiple of fees, or both?
  • What’s the look‑back period (12 months, 24 months, contract term)?

If you’re paying $50,000 a year but your potential exposure from system failure is in the millions, a low cap might be commercially unreasonable.

Step 2: Spot the carve‑outs

In the better examples of limitation of liability in software licenses, the carve‑outs are spelled out clearly. Common ones include:

  • Confidentiality breaches
  • Data protection/security incidents
  • IP infringement indemnity
  • Personal injury/property damage

Decide where you actually need more protection. For a non‑critical marketing tool, a simple fee‑based cap might be fine. For a core payments engine, you probably want more.

Step 3: Read the damage exclusions carefully

The classic “no indirect or consequential damages” line can wipe out a big chunk of what you thought you could recover. Pay attention to whether the clause excludes:

  • Loss of profits
  • Loss of revenue
  • Loss of data
  • Business interruption

Sometimes you can negotiate limited exceptions, such as allowing recovery of direct data restoration costs even if other consequential damages are excluded.

Step 4: Watch for non‑negotiable consumer protections

In consumer‑facing software, statutory protections can override aggressive limitation of liability language. For example, U.S. consumer law and state unfair‑practice statutes can limit how far a company can go in disclaiming liability for personal injury or deceptive practices.

The Federal Trade Commission provides general guidance on unfair or deceptive practices that can intersect with contract terms (see FTC policy statements). While business‑to‑business software contracts get more leeway, consumer software can’t simply contract around every form of liability.


FAQ: examples of limitation of liability in software licenses

Q1. Can you give a short example of a limitation of liability clause for a small SaaS tool?
A straightforward example of limitation of liability in software licenses for a small SaaS vendor might be: “Provider’s total liability arising out of this Agreement shall not exceed the fees paid by Customer to Provider under this Agreement in the six (6) months preceding the event giving rise to the claim, and in no event shall Provider be liable for any indirect, incidental, or consequential damages, or any loss of profits or revenue.” It’s short, fee‑based, and excludes indirect damages.

Q2. What are some common examples of carve‑outs from the liability cap?
Common examples include: confidentiality breaches, data security incidents, IP infringement indemnity, and a party’s gross negligence or willful misconduct. In higher‑risk industries like healthcare and finance, real examples of limitation of liability in software licenses often add carve‑outs for specific regulatory violations or data breach costs.

Q3. Are there examples where a vendor accepts unlimited liability?
Yes, but they’re narrow. One frequent example of unlimited liability is for personal injury or death caused by the vendor’s hardware or on‑site services. Another is liability that cannot be limited by law in a given jurisdiction. Outside of those categories, unlimited liability is rare in commercial software licenses.

Q4. How do open‑source licenses handle limitation of liability?
Many open‑source licenses use extremely broad disclaimers. For instance, the MIT and BSD licenses include language stating that the authors are not liable for any claim, damages, or other liability arising from the software. These are some of the starkest examples of limitation of liability in software licenses you’ll see, effectively pushing all usage risk onto the user, subject to whatever statutory limits apply.

Q5. Where can I find more real examples of limitation of liability clauses?
You can find public examples in open‑source licenses at the Open Source Initiative and in academic or government contract templates posted online. While many commercial software contracts are private, these publicly available templates give a solid sense of how limitation of liability clauses are structured and negotiated.


Legal notice: This article provides general information and illustrative examples of limitation of liability in software licenses. It is not legal advice and does not create an attorney‑client relationship. Always consult qualified counsel before drafting, signing, or relying on any contract language.

Explore More Limitation of Liability Disclaimers

Discover more examples and insights in this category.

View All Limitation of Liability Disclaimers