Open-source software warranties: what suppliers should check before signing

A supplier can give warranties for a product that includes open-source software. The promises need to match the rights it holds and the licence conditions its delivery triggers. Permission to use a component does not establish ownership of that component, or make every customer warranty accurate.

Suppose a customer's draft contains three promises: the supplier owns all software, the deliverables contain no open-source components, and no source code will need to be disclosed. These are illustrative terms, not extracts from a client agreement. They raise three different questions. A product could comply with every applicable licence and still fail the second promise.

In a review, I would connect each promise to a product fact, supporting evidence and a decision. This note shows that approach using selected licence provisions. It is not a complete compliance checklist for every open-source licence.

Start with what the customer receives

Ask the technical lead to describe the release being contracted for.

{ }

On your servers

Which parts never leave your infrastructure?

</>

With the customer

What does it download, install, embed in its own product or receive as source code?

Include dependencies and modified components, not just code your team wrote.

A hosted service may also deliver browser code, a client agent, an SDK or a container image. An on-premises product might include third-party packages inside its installer. These facts matter more than the sales label alone. AGPLv3, for example, distinguishes interaction over a network without transferring a copy from conveying a copy. AGPLv3, section 0.

Then record the customer's intended uses: operating the product, modifying it, appointing a replacement maintainer or distributing it to others. The review needs to cover those uses, including any limits already agreed in the contract.

For software supplied inside a device, my note on GPLv3 firmware and distributor warranties connects source delivery and installation rights to the supplier's support commitments.

Check the three promises separately

Read the definitions of Software, Deliverables and Customer Materials before assessing the warranties. A narrow exception in the ownership clause may leave a broader promise elsewhere untouched.

Open source is a licensing model, not proof that somebody else owns the code: a supplier may own software it publishes under an open-source licence. Equally, receiving somebody else's code under a licence does not, by itself, transfer that person's copyright. For the separate chain of rights from developers, see ownership of contractor-written code under English law.

Notices, warranties and source code are different issues

MIT

The MIT licence permits broad use, modification and distribution, including selling copies. It requires the copyright and permission notices in copies or substantial portions of the software. Its text does not itself require publication of source code. A missing notice can therefore be a compliance issue without creating a requirement to publish the whole product. MIT licence.

Apache License 2.0

Section 4 requires a licence copy for recipients, prominent notices of changed files, and retention of relevant notices in distributed derivative source. If the original distribution includes a NOTICE file, relevant attribution notices must accompany distributed derivatives in a permitted form. It does not impose a general requirement to publish source code. Apache License 2.0, section 4.

Section 7 disclaims upstream warranties, including title and non-infringement. Under section 9, a distributor may offer additional warranty or indemnity commitments on its own behalf and responsibility. It must agree to indemnify and defend each Contributor and hold them harmless against liability or claims resulting from those additional commitments. The commitments must remain consistent with the licence. The upstream disclaimer does not protect the supplier against its own customer promises. Apache License 2.0, sections 7 and 9.

My drafting conclusion: a customer may expect support and remedies from the supplier even where upstream authors provide none. Define that commitment and price the responsibility you are accepting. Licence compliance also does not establish that every possible third-party IP claim is covered; a broader non-infringement warranty needs its own review.

What changes with AGPL?

If you modify an AGPL-covered program and users interact with that modified version remotely over a network, section 13 requires a prominent offer of its Corresponding Source, available to copy free of charge. That obligation can matter even without delivery of a copy to the user. AGPLv3, section 13.

Leaving an AGPL library's own files unchanged does not necessarily settle the issue. Section 0 defines “modify” to include copying from or adapting all or part of a work where copyright permission is required, other than making an exact copy. If the integration creates a modified version of the AGPL-covered program, section 13 may require a source offer to users interacting with that version over a network. Check the integration and applicable law before giving a no-disclosure warranty. AGPLv3, sections 0 and 13.

Corresponding Source is a defined set of materials, including what is needed to build, install, run and modify the covered work, subject to stated exceptions. It can extend beyond your patch. It does not automatically mean the whole company's repository. If object code is conveyed, section 6 separately specifies ways of providing the required source. AGPLv3, sections 1 and 6.

Before negotiating a source-disclosure warranty, I would ask the technical lead to identify the covered program, changes and connected components, and explain how users interact with it. Calling a dependency a “library”, putting it in a container or using a separate process is not enough information for a legal conclusion. Establish the facts before deciding which parts of the product and which recipients are affected.

Build an evidence record, not just a licence list

A software bill of materials, or SBOM, is a useful starting inventory. My review would add the facts needed to apply the licences and assess the contract:

A scanner result helps locate issues; it does not decide what the customer contract means. A licence name in a spreadsheet also does not show that a notice was delivered or that a source offer works. Tie the record to a specific release and have someone own each unresolved action.

For AI-assisted development, check known reproduced code and identified third-party material as well as package dependencies. My note on AI-generated code and third-party licences explains why a tool's output terms do not settle that question.

An illustrative contract review

Consider an invented example: a supplier delivers an application containing its own project code and a third-party MIT-licensed utility. The customer's draft says both that the supplier owns all Deliverables and that they contain no open-source software.

I would first confirm the actual version, provenance, licence and delivery. Assuming the MIT permission and required notices are in place, that still does not make the third-party utility supplier-owned or remove it from the deliverables.

A possible negotiation structure would:

1. Identify the customer-specific code whose copyright is to be assigned, subject to confirming the supplier's title.
2. List the utility as third-party material and identify its licence.
3. Make the relevant ownership and no-open-source warranties expressly subject to the agreed exception.
4. Check that the customer can use and maintain the delivered application as agreed, and supply the required materials.

Putting a package in a schedule is not enough if the operative warranty still says there are no exceptions. If the customer will not accept the component, the supplier needs a different delivery decision. This example illustrates a review method, not wording suitable for every contract.

Agree the response to a problem

The available decisions may include completing licence compliance, obtaining the customer's agreement to an exception, securing an appropriate alternative licence from an authorised rightsholder, or replacing the component. These solve different problems. A customer's consent cannot waive another rightsholder's licence conditions.

Replacing a component in the next release does not automatically resolve earlier use or deliveries. Assess the previous versions and any outstanding obligations separately. AGPLv3, for example, has its own termination and reinstatement provisions. AGPLv3, section 8.

The customer contract should then address who investigates, what remedy is available, who controls any claim or settlement, and how liability is allocated. Agree any approval process for component changes during support, so that an accurate warranty at signing does not become an unsupported promise about every future release.

Before you sign

1. Fix the product version, delivery model and intended customer uses.
2. Identify the exact components, licences, modifications and missing evidence.
3. Check ownership, licence compliance, source-disclosure and non-infringement promises separately.
4. Make agreed exceptions effective in the relevant clauses, with the required materials ready for delivery.
5. Assign responsibility for unresolved issues, future changes and any earlier non-compliance.

The useful result is a contract the product can actually support, with a short record showing why the supplier can make each promise and what still needs to happen.

Reviewing open-source terms in a customer contract?

I review software rights and customer contracts, including how open-source components affect warranties and delivery obligations. Code rights review · My experience · Contact.

This note explains a general review approach using selected licence provisions checked on 6 October 2026. The outcome depends on the complete licences, product, contracts and applicable law. The examples are hypothetical.