Software License Agreement Review: What SaaS Lawyers Actually Check

A mid-size retailer licensed an inventory management system under a perpetual license. Three years in, the vendor announced end-of-life for the product — no more updates, no more support, no migration path. The license agreement said nothing about end-of-life obligations. The retailer was stuck: switch systems (six figures in migration costs) or keep running unsupported software with growing security vulnerabilities.

According to Synopsys’ 2025 Open Source Security and Risk Analysis (OSSRA) report, 56% of audited applications contained open source license conflicts — meaning the software your client is licensing may carry hidden obligations that flow through to them. Meanwhile, the ABA’s 2024 TechReport shows that technology-related contract disputes continue to increase as businesses become more dependent on third-party software.

Software license agreements require a different review approach than typical commercial contracts. The licensing model dictates your exit options, your data rights, your security exposure, and your long-term costs. This article covers what experienced technology lawyers actually prioritize — and what most reviewers miss. Try Clause Labs free to run an AI analysis on any software agreement and flag missing provisions in under 60 seconds.

Software License vs. SaaS Subscription: Know Which You’re Reviewing

Before reviewing a single clause, confirm which licensing model you’re dealing with. The legal implications differ substantially.

Perpetual License (Traditional Software)

• One-time fee purchases the right to use a specific version of the software
• Software installed on the licensee’s own servers or devices
• Licensee controls the environment, updates, and data
• No ongoing access dependency on the vendor
• Risk: the software becomes obsolete without updates; no obligation for vendor to maintain

SaaS/Subscription License

• Recurring fee for ongoing access to vendor-hosted software
• Vendor controls the environment, updates, and infrastructure
• Licensee depends on vendor availability and continued operation
• Data resides on vendor’s servers (or their cloud provider’s)
• Risk: vendor discontinues the service, raises prices, or degrades performance

Hybrid Models

Some agreements combine elements: on-premise installation with subscription-based updates, or perpetual licenses with mandatory cloud components. These hybrids require reviewing both sets of provisions.

A critical drafting error: Using a traditional license agreement to govern a SaaS relationship — or vice versa. Legal practitioners consistently warn against this mismatch because license agreements assume the customer possesses the software, while SaaS agreements assume the vendor hosts everything. Using the wrong template creates gaps in data protection, availability obligations, and termination rights.

For a deeper comparison of SaaS-specific issues, see our guide on how to review SaaS agreements.

The 10 Provisions SaaS Lawyers Actually Check

These aren’t the only provisions in a software agreement — but they’re the ones where mistakes cost the most.

1. License Grant Scope

The license grant defines exactly what the licensee can do with the software. Read it as a whitelist: if a use isn’t explicitly granted, it’s prohibited.

What to check:

• Named users vs. concurrent users vs. site license: Named user licenses restrict usage to specific individuals. Concurrent licenses limit simultaneous users but allow sharing. Site licenses cover all users at a location. The cost difference between these models is substantial.
• Internal use only vs. external use: Can the licensee use the software to provide services to its own customers? Many licenses restrict usage to “internal business purposes,” which blocks service bureau, outsourcing, and consulting use cases.
• Affiliate access: Does the license extend to the licensee’s subsidiaries, parent company, and affiliates? If not, each entity may need a separate license.
• Geographic restrictions: Some licenses restrict usage to specific territories.
• Version lock: Is the license for a specific version, or does it cover all versions? If version-specific, upgrades may require new licenses.

Red flag: A license grant that uses “solely for” language combined with a broad restriction on “any other purpose” creates a trap — any use case the licensee didn’t anticipate at signing may constitute a breach. For more on how restrictive clauses create financial exposure, see our analysis of contract clauses that create costly mistakes.

2. Usage Restrictions

Every license grant comes with restrictions. The question is whether they’re reasonable.

Common restrictions that matter:

• Reverse engineering: Standard in most licenses, but may conflict with laws that permit reverse engineering for interoperability (EU Computer Programs Directive; DMCA interoperability exceptions)
• Competitive benchmarking: Some licenses prohibit publishing benchmark comparisons. This is especially common in database and enterprise software licenses.
• Multi-tenancy: In SaaS agreements, can the licensee’s own customers access the platform through the licensee’s account? Some licenses prohibit this.
• API access: If the licensee needs to integrate the software with other systems, API access rights must be explicitly granted.

Red flag: Restrictions that give the vendor subjective enforcement discretion, such as “Licensee shall not use the Software in any manner that Licensor deems inappropriate.”

3. Acceptance Testing and Warranty

For on-premise software, acceptance testing determines when the licensee formally accepts the product — and when the warranty period starts.

What to check:

• Acceptance criteria: Defined, objective, measurable criteria (not “licensee is satisfied”) tied to documented specifications
• Testing period: Sufficient time to test all material functionality (30-60 days is typical; complex enterprise software may require 90 days)
• Failure remedy: What happens if the software fails acceptance? Cure period, re-testing, and ultimately the right to reject and receive a full refund
• Warranty period: Typically 90 days to 1 year post-acceptance. The software will perform materially in accordance with the documentation.
• Warranty remedies: Repair, replace, or refund. Avoid “reasonable efforts to correct” without a backstop remedy.
• Disclaimer of implied warranties: Standard, but the licensee should ensure that the express warranty covers the material performance requirements

For SaaS: Acceptance testing is less common. Instead, focus on the SLA (service level agreement) as the ongoing performance commitment.

4. Maintenance and Support Commitments

Maintenance and support are where the ongoing relationship — and ongoing costs — live.

What to check:

• What’s included: Bug fixes, patches, security updates, minor version updates. Are major version upgrades included or separately priced?
• Support tiers: Response times for different severity levels (critical system down: 1-4 hours; high: 8 hours; medium: 1 business day; low: 3 business days)
• Support channels: Phone, email, ticket system, dedicated account manager
• Support hours: 24/7 for critical issues? Business hours only? Which time zone?
• Maintenance fees: For perpetual licenses, annual maintenance typically costs 18-22% of the license fee. This means a $100,000 license costs $18,000-$22,000 per year in maintenance — the vendor recovers the full license fee every 5-6 years.
• Maintenance termination and reinstatement: If the licensee stops paying maintenance, can they reinstate later? Most vendors require back-payment of all skipped maintenance fees plus a reinstatement penalty.

Red flag: A maintenance agreement that the vendor can terminate with 30 days’ notice — effectively converting a perpetual license into a subscription with no recourse.

5. Source Code Escrow

Source code escrow protects the licensee if the vendor goes bankrupt, is acquired, or stops maintaining the product.

How it works: The vendor deposits their source code with a third-party escrow agent. If specified release conditions occur, the escrow agent releases the source code to the licensee so they can maintain the software independently.

What to check:

• Release conditions: Vendor bankruptcy, insolvency, cessation of business operations, material breach of maintenance obligations, or failure to maintain the software. Also include acquisition by a competitor of the licensee.
• What’s deposited: Source code alone is insufficient. The deposit should include compilation tools, build scripts, documentation, test suites, and deployment instructions — everything needed to independently build and maintain the software.
• Verification: The escrow agent should periodically verify that the deposited materials are complete and can actually be compiled. Unverified escrow is common and nearly useless.
• Update frequency: The deposit should be updated with each major release, not just deposited once at contract signing.
• License to use: The escrow clause must grant the licensee a license to use, modify, and maintain the source code upon release.

Federal protection: The Intellectual Property Bankruptcy Protection Act of 1988 (codified at 11 U.S.C. s. 365(n)) provides some protection for licensees when a software vendor files for bankruptcy, but the protections are not absolute. Escrow remains the strongest practical safeguard.

When to require escrow: Any software that is critical to business operations where switching costs are high. If the licensee is paying $50,000+ per year for enterprise software that runs core business functions, the $5,000-$10,000 annual escrow cost is straightforward insurance.

6. Data Rights

Data rights define who owns the data that flows through the software — and what happens to it when the relationship ends.

What to check:

• Ownership: The licensee should own all data it inputs into the system and all data generated by the system from the licensee’s inputs. This sounds obvious, but some agreements grant the vendor a broad license to “data generated through use of the Software” — which could include the licensee’s proprietary business data.
• Portability: Can the licensee export all their data in a standard, usable format? At any time, or only at the end of the term? What format — CSV, SQL dump, API access, proprietary format that requires the vendor’s tools to read?
• Post-termination access: How long does the licensee have to retrieve their data after the agreement ends? 30 days is standard; anything less is a red flag.
• Deletion: The vendor should certify destruction of all licensee data within a defined period after termination, with written confirmation.
• Data use by vendor: Does the vendor use licensee data for training machine learning models, analytics, product improvement, or aggregated benchmarking? Increasingly common — and increasingly problematic under ABA Model Rule 1.6 confidentiality obligations if the licensee is a law firm.
• Data location: Where is data stored? Which jurisdictions? Does the vendor use sub-processors in other countries? This matters for GDPR compliance and data sovereignty requirements.

Red flag: A clause granting the vendor a “perpetual, irrevocable, worldwide license” to data submitted to or generated by the platform. This is essentially an assignment dressed up as a license.

7. Open Source Components

This is the provision most non-tech lawyers miss entirely — and it can carry the most serious long-term consequences.

Most modern software contains open source components. According to the Black Duck OSSRA report, 96% of audited codebases contained open source, and 56% had license conflicts. Open source licenses carry legal obligations that flow through to users.

The copyleft risk: Strong copyleft licenses like GPL (GNU General Public License) require that derivative works be distributed under the same license terms. If proprietary software incorporates GPL-licensed code and is distributed, the entire work may need to be open-sourced. This is sometimes called the “viral” effect.

• GPL v2/v3: Strong copyleft. If GPL code is linked into proprietary software that is distributed, the proprietary code must also be released under GPL.
• LGPL: Weak copyleft. Allows linking with proprietary software without triggering the copyleft requirement, but modifications to the LGPL-licensed component itself must be shared.
• MIT, BSD, Apache 2.0: Permissive licenses. Allow incorporation into proprietary software with minimal obligations (attribution, license notice preservation).

What to require in the agreement:

• Disclosure: Vendor must disclose all open source components used in the software, including their licenses, in a Software Bill of Materials (SBOM)
• No copyleft contamination: Vendor represents that no component is licensed under terms that would require the licensee to disclose its own proprietary information or code
• Indemnification: Vendor indemnifies the licensee against claims arising from open source license violations (for deeper coverage of how indemnification provisions work, see our indemnification clauses guide)
• Ongoing updates: Vendor will update the open source disclosure with each new version
• Compliance responsibility: Vendor assumes responsibility for compliance with all open source license obligations

For law firms specifically: If you’re licensing software that will process client data, open source licensing compliance isn’t just a business concern — it touches ABA Model Rule 1.6 (Confidentiality) obligations if a license violation could result in forced disclosure of client data.

8. Third-Party Components and Sub-Licensing

Beyond open source, the vendor’s software likely incorporates third-party commercial components — databases, libraries, APIs, cloud services.

What to check:

• Disclosure: Which third-party components are embedded in the software?
• Sub-license rights: Does the vendor have the right to sub-license these components to the licensee? If not, the licensee may need separate licenses.
• Flow-down obligations: Third-party license terms may impose restrictions that flow through to the licensee (usage limits, audit rights, export controls)
• Vendor responsibility: The vendor should represent that it has all necessary rights to sublicense third-party components and indemnify against infringement claims

Red flag: “Licensee shall be solely responsible for obtaining any third-party licenses necessary for use of the Software.” This shifts responsibility for the vendor’s supply chain to the customer. This kind of one-sided risk allocation is one of the most common red flags in contract review.

9. Update and Upgrade Rights

The distinction between updates (minor, included) and upgrades (major, separately priced) is where vendors create upsell opportunities — and where licensees get surprised by costs.

What to check:

• Definitions: Clear definitions of “update” (bug fixes, patches, security fixes, minor version increments) vs. “upgrade” (major version increments, new features, architectural changes)
• Included vs. extra cost: Are updates included in the license or maintenance fee? At what point does an “update” become an “upgrade” that requires additional payment?
• Compatibility: If the licensee declines an upgrade, will the vendor continue supporting the older version? For how long?
• Forced migration: Can the vendor force the licensee to upgrade to continue receiving support? This is common and often creates significant unexpected costs (new hardware requirements, retraining, integration rework).

SaaS note: In SaaS agreements, updates and upgrades are typically automatic and included in the subscription. But check for material changes: can the vendor remove features the licensee relies on? Can the vendor change the interface in ways that require the licensee to retrain staff or modify integrations?

10. End-of-Life Provisions

End-of-life (EOL) is the provision that doesn’t matter until it’s the only one that matters.

What to check:

• Advance notice: How far in advance must the vendor notify the licensee of planned end-of-life? Minimum 12 months for critical business applications; 24 months is better.
• Continued support: What level of support does the vendor provide during the wind-down period? At minimum: security patches and critical bug fixes through the end-of-life date.
• Migration assistance: Does the vendor provide data migration tools, documentation, or services to help the licensee transition to a replacement system?
• Data export: The licensee must have the ability to extract all data in a standard format before end-of-life.
• Pricing protection: During the wind-down period, the vendor shouldn’t increase fees for the product being discontinued.
• Refund provisions: If the licensee paid for a multi-year term and the vendor discontinues mid-term, is there a pro-rata refund?

Red flag: No end-of-life provision at all. This means the vendor can discontinue the product tomorrow with no obligation to the licensee.

How Clause Labs Reviews Software License Agreements

Clause Labs’s AI identifies the provisions specific to software agreements that general contract review often overlooks:

• License grant analysis: Evaluates scope, restrictions, and whether the license model matches the delivery model (perpetual vs. SaaS)
• Missing provision detection: Flags absent escrow provisions, missing data portability rights, undefined end-of-life obligations, and absent open source disclosures
• Data rights evaluation: Identifies overly broad vendor data licenses, missing deletion obligations, and inadequate post-termination access windows
• IP risk factors: Detects provisions where IP ownership or licensing terms could create downstream liability

For a related analysis of how AI tools handle SaaS-specific agreement reviews, including SLA evaluation and auto-renewal detection, see our dedicated SaaS review guide.

Frequently Asked Questions

Do I need a lawyer to review a software license agreement?

For commodity SaaS subscriptions under $10,000/year with standard terms — a senior business person familiar with the provisions above can handle the review, potentially with AI-assisted analysis. For enterprise software deployments, custom development, or any agreement involving access to sensitive data (health records, financial data, legal files), attorney review is worth the investment. The stakes are simply too high: data breaches, IP disputes, and vendor lock-in cost far more than legal review fees.

What’s the difference between a license and a subscription?

A license grants the right to use a copy of the software, typically with a one-time fee and optional ongoing maintenance. Even if you stop paying maintenance, you keep the license to use the version you have. A subscription grants access to the software for a defined period. When you stop paying, access stops. The key practical difference: with a perpetual license, your worst case is frozen at an old version. With a subscription, your worst case is losing access entirely. For more on subscription-specific risks, see our guide to contract clauses that create costly mistakes.

Should I require source code escrow?

For any software that is critical to business operations with high switching costs, yes. The annual cost of escrow ($5,000-$10,000 for a basic three-party arrangement with verification) is negligible compared to the risk of losing access to software that runs core business functions. Escrow is most important for on-premise or hybrid software. For pure SaaS, escrow is less common because there’s nothing to install — but data portability provisions and termination assistance obligations serve a similar protective function.

Can software license terms be negotiated?

Enterprise software terms are almost always negotiable — vendors expect it. Volume, deal size, and competitive alternatives give leverage. Consumer and SMB SaaS terms are typically non-negotiable unless the deal crosses a revenue threshold the vendor considers “enterprise” (often $50,000+/year). Even with standard terms, you can negotiate: payment terms, SLA commitments, data handling provisions, and termination rights. The vendor’s willingness to negotiate often reveals how much they value the deal.

---

This article is for informational purposes only and does not constitute legal advice. Software licensing law involves complex IP, contract, and regulatory issues. Consult a qualified technology attorney for advice specific to your situation.

Reviewing a software license or SaaS agreement? Upload it to Clause Labs for AI-powered risk analysis — the tool flags missing data rights, escrow gaps, overly restrictive license grants, and open source risks in under 60 seconds. Start free with 3 reviews per month.