SaaS agreements do not fit neatly into the traditional IP buckets. Nothing gets copied to the customer's computer in a pure hosted deal, yet the contracts arrive full of license grants, open source warranties, and third-party component terms borrowed from the on-prem world. Lawyers on both sides end up fighting over provisions that may not match the deal at all.
How to Contract took on these issues in a recent webinar hosted by Laura Frederick, Founder of How to Contract. She was joined by Akiva Miller, Owner of Akiva Miller Law, who spoke from the vendor side, and Brian Chang, Lead Counsel at Airwallex, who spoke from the customer side. Between them, the panel brought experience from SaaS vendors, patent litigation, big tech procurement, and financial services, so every provision got tested from both ends of the deal.
The conversation worked through sample AI-drafted provisions for IP grants, open source licenses, and third-party components. Along the way the speakers covered when license language belongs in a SaaS agreement, how copyleft licenses actually work, why software bills of materials are harder to deliver than they look, and how to draft feedback clauses without giving away your patent portfolio.
Here are our top ten takeaways from the speakers' comments during the webinar:
Understand the deal before you draft. SaaS covers everything from a login on a dashboard to a white-label build with custom development. The IP, open source, and third-party terms that fit one end of that range fail badly at the other. Talk to the engineers and the business team about what they actually plan to do with the product. That conversation tells you which provisions matter and which fights to skip.
Save the word license for real IP grants. A purely hosted product never gets copied to the customer, so nothing is licensed. Write access and use rights instead. The label carries real consequences, including whether the bankruptcy code protections for IP licensees apply. Sloppy terminology invites risk you never priced.
Split hybrid products into their parts. Many products pair a downloadable client with a hosted service. Give the downloaded piece a true license and the hosted piece access rights, each with its own defined term. Within the license, grant copyright and patent rights separately. Software patents remain alive in the US, and a copyright-only grant leaves a gap you may not see until it hurts.
Delete the vague catch-alls. Language like all accompanying tools and components reads as an invitation to argue about what the customer can reach. Define software precisely and keep defined terms consistent across the provision. Sloppy grants get flagged fast, and every flag delays the deal.
Negotiate data rights around what each side actually needs. Raw data rarely fits the IP categories, so skip the theory and focus on who gets to use the data and for what. Vendors need aggregated usage data to keep developing the product, and customers should ask whether the data they hand over matches the value they get back. Data deserves its own section, not a sentence buried in the IP grant.
Respect what copyleft actually does. Permissive licenses mostly want attribution. Copyleft licenses require redistributed modifications to carry the same license, so blended proprietary code becomes one work that distribution can force open. The AGPL treats network-hosted use as distribution, which puts SaaS squarely in scope. Know which family you are dealing with before you warrant anything.
Think hard before promising a software bill of materials. A complete and accurate bill of materials is a difficult artifact that often needs hand curation by the engineering team. Vendors should resist warranting one casually and should build in cure rights, since a problem component can often be removed or swapped with no consequence. Customers should ask for the minimum data they need, which is usually about security scanning rather than IP.
Push the vendor to stand behind the whole stack. The vendor holds the third-party relationships, so the vendor should absorb those terms into a single contract rather than passing them through. Never accept a blanket obligation to comply with third-party terms you have not seen, and do not let a breach of some third party's terms become breach exposure back to the vendor. From the vendor side, keep third parties under the hood and never give one customer veto power over your components.
Draft feedback as a confidentiality exception. Say that feedback about the vendor's product cannot be treated as the customer's confidential information, and stop there. A broad feedback license can scoop in existing patents on the strength of an engineer's offhand remark. Asking for one also invites a mutual clause that nobody ends up wanting.
Size the real-world risk before you spend leverage on it. Open source disputes rarely show up as litigation. The damage appears in acquisition diligence, where non-compliance knocks down valuations, and in warranty claims used as a backdoor out of a contract. AI-generated code adds a new blind spot that scanning tools can miss. Weigh those risks honestly, because knowing when to leave something out of a contract matters as much as knowing how to word it.
Subscribe to Stay in the Loop
Our weekly newsletter delivers takeaways like these from every How to Contract webinar, along with links to register for the ones coming up. Subscribe now so the next set of insights lands in your inbox.
