Software companies
Warranties to give and avoid when licensing code or tickets
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
When licensing code or support tickets, a seller should give warranties about facts it controls, qualify warranties about facts it cannot fully verify, and refuse warranties about outcomes. Warrant authority and your own preparation process; qualify non-infringement and lawful collection by knowledge; refuse promises of accuracy, completeness or model performance.
Key takeaways
- Warrant what you control: authority, the scope of records and the preparation steps you performed.
- Qualify what you cannot fully verify, such as non-infringement and historical compliance, with knowledge and a disclosure schedule.
- Refuse outcome promises: accuracy, completeness, fitness for training and model performance.
- Replace an absolute no-personal-data warranty with a process warranty plus a remove-and-replace remedy.
Why are warranties harder in a data license than a software license?#
Warranties are harder in a data license because the seller did not build the data the way a software vendor builds a product. Code reviews, issues and support tickets were written over years by employees, contractors, customers and tools, and no one at the company has read all of them.
A buyer's first draft often asks the seller to promise that records are accurate, complete, lawful and free of personal data. Those promises shift every unknown in a long history onto the seller, and a breach usually connects to indemnities and liability caps. The task is to warrant what you control and qualify the rest.
The positions here are general information, not legal advice. Governing law and deal context vary, so warranty language is settled deal by deal with counsel.
Give, qualify or refuse: ten common warranties#
The table sorts ten warranties that commonly appear in buyer drafts for code and ticket licenses. Positions are starting points for negotiation, not fixed rules.
Notice the pattern. Every warranty marked give describes something the seller did or decided. Every warranty marked refuse describes a quality of the records or a result in the buyer's hands, which the seller cannot control.
| Warranty | Position | How to word or limit it |
|---|---|---|
| Authority to enter the license | Give | Standard corporate authority and due execution |
| Right to license the scheduled records | Give | Tie it to a schedule listing systems, record families and date ranges |
| No conflicting exclusive grant | Give | Limit it to grants covering the same records and use |
| Preparation performed as agreed | Give | Describe de-identification and secret scanning steps in a schedule |
| Free of all personal data | Refuse | Replace with the preparation warranty plus a removal remedy |
| Lawful collection of the records | Qualify | To the seller's knowledge, in material respects |
| Non-infringement of third-party rights | Qualify | To knowledge, with open source and third-party code disclosed |
| No secrets or credentials | Qualify | Scanned with named tools; secrets found were removed and rotated |
| Accuracy and completeness | Refuse | Records provided as kept in the ordinary course of business |
| Fitness for training or model performance | Refuse | No warranty of results; the buyer decides suitability |
How does a knowledge qualifier work?#
A knowledge qualifier limits a warranty to what specific people know, so the seller is not liable for facts buried in records nobody has read. The wording matters: name the knowledge group, such as the CEO, CTO, head of support and general counsel, and say whether knowledge means actual knowledge or knowledge after reasonable inquiry.
If the buyer insists on reasonable inquiry, define it as the review described in the preparation schedule rather than an open-ended duty. Add a materiality qualifier where minor exceptions should not count as a breach.
Pair qualifiers with a disclosure schedule. Known issues, such as open source components under copyleft licenses, legacy customer contracts with use limits, or tickets from a region you excluded, are listed there and carved out of the warranties.
Which warranties are specific to code?#
Code licenses add warranties about what sits inside the repositories. Each one is easier to give when it points to a documented scan rather than a general promise.
Keep the scan outputs. A license scan report, a secret scan report and a list of excluded repositories turn qualified warranties into statements the seller can support with records.
- Open source: disclose components and licenses from a license scan, and pass them through as is under their own terms.
- Third-party and customer code: exclude vendored SDKs, customer-specific code and anything under a client contract, and warrant the exclusion process.
- AI-generated code: disclose that some code may have been written with AI assistants, and check those tools' terms on outputs.
- Secrets: warrant that named scanners were run and that live credentials found were rotated.
- Export controls: exclude restricted code before scoping rather than warranting around it.
Which warranties are specific to support tickets?#
Ticket licenses turn on privacy and customer contracts. Warrant that the agreed de-identification was performed and that a human reviewed a sample, not that every identifier is gone, and attach the privacy record that shows the method.
Warrant that customer contracts were reviewed for the customers included, with excluded customers listed. Do not warrant that agents gave correct answers. Tickets show real work, including mistakes and corrections, and that is part of why they are useful.
Attachments deserve their own line. Screenshots, log files and exported spreadsheets inside tickets are harder to clean than text, so either exclude them or warrant only the specific review applied to them.
Which promises hide outside the warranty section?#
Promises outside the warranty section can create the same exposure as a warranty, so read the whole draft with the same eye. The data description schedule is the usual suspect: if it states volumes, date ranges or field completeness as facts, a shortfall can be argued as a breach even when the warranty section is narrow.
Watch also for covenants that create ongoing duties, such as a promise to update the data, to notify the buyer of any customer complaint, or to comply with the buyer's internal AI policies. Each may be reasonable in a narrow form, but each should be deliberate. Describe volumes as approximate, tie any update duty to a defined delivery, and accept policies only where you have read them and can follow them.
Illustrative: a developer tools company marks up a buyer's draft#
Illustrative: a fictional developer tools company receives a buyer's draft for a package of code reviews, issues and support tickets. The draft warrants that the data is accurate, complete, free of personal data, non-infringing and fit for training.
The general counsel keeps the warranties on authority, scheduled records and no conflicting grants. Free of personal data becomes a warranty that preparation followed the attached schedule, plus a remedy: the seller removes any personal data the buyer later finds, and the buyer deletes and replaces the affected files. Non-infringement is qualified to knowledge, with the open source scan attached. Accuracy and fitness are deleted, and the records are provided as kept in the ordinary course.
The negotiation then moves to the liability cap and the indemnity, which is where risk allocation belongs.
How SourceX supports narrower, provable warranties#
SourceX helps a seller warrant what it did rather than what it cannot know. The SourceX Evidence Packet documents provenance, licensing rights, permitted use, the privacy record and release authorization, which are the facts most process warranties rest on.
Those documents come from the Rights and Preparation steps of the SourceX five-step transaction, and the company approves each step before delivery. Data is licensed, not sold, and the company keeps ownership of its records.
Frequently asked questions
Should a data license be provided as is?
As is works well for quality, accuracy and fitness, but a license with no warranties at all is rarely acceptable to a buyer. The common middle ground is as is for content, with specific warranties on authority, rights to the scheduled records and the preparation process.
How do warranties relate to indemnities?
A warranty is a statement of fact; an indemnity shifts the cost of third-party claims. Buyers often seek indemnities for intellectual property and privacy claims tied to the warranties. Negotiate them together, with caps and clear procedures, and review both with counsel.
What is a practical remedy if personal data turns up after delivery?
A remove-and-replace process: the buyer notifies the seller, the seller supplies a corrected file, and the buyer deletes the affected records from its copies. Because data already used in training may not be removable from a model, agree in advance what the buyer must do in that case.
How long should warranties survive?
Warranties usually survive for a defined period after delivery rather than indefinitely. The right period depends on the deal, the governing law and how claims would arise, so set it with counsel rather than accepting an open-ended survival clause.
Who inside the company should confirm the warranties?
Everyone named in the knowledge group should confirm in writing that they know of no exceptions beyond the disclosure schedule. Typically that includes the CTO for code, the head of support for tickets and the general counsel for contracts.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.