The Open Source Software Clause Explained (2026)

An open source software clause sets the rules for using, disclosing and controlling open source and third party components inside the software a vendor delivers. It usually requires the vendor to list the open source it uses, to comply with the relevant licences, and to make sure that no open source is combined with the delivered software in a way that forces the customer to release its own proprietary or confidential code. It matters because almost every modern application is built partly from open source, and the wrong licence in the wrong place can create obligations the customer never agreed to. This page explains the clause in plain language, gives a sample you can adapt, and sets out the terms that are genuinely worth negotiating. It is general information, not legal advice. ## What the clause actually does Most software today is assembled, not written from scratch. Studies of commercial codebases routinely find that the large majority contain open source components, and that a meaningful share carry licence conflicts or security issues. An open source software clause gives the customer three things: - Disclosure. The vendor tells you which open source components are in the product, and under which licences. In mature deals this is delivered as a software bill of materials (SBOM).

• Compliance. The vendor promises it is meeting each licence's conditions, for example preserving copyright notices, passing on licence text, or offering source code where required.
• Protection against copyleft contamination. The vendor promises not to incorporate open source under a strong copyleft licence (such as the GPL family or AGPL) in a way that would require the customer to disclose, license or give away its own proprietary code. The clause is really about allocating a risk: the risk that an open source licence attaches conditions to code the customer thought it owned or controlled outright. ## Why both sides care For the customer or buyer. Open source is not free of obligations. A permissive licence like MIT, BSD or Apache 2.0 mainly asks you to keep notices and disclaimers. A strong copyleft licence like the GPLv3 or AGPLv3 can require that if you distribute (or, for AGPL, even make available over a network) software that includes the licensed code, you offer the complete corresponding source under the same terms. For a company whose product is its proprietary code, that is a serious outcome. The clause is how the buyer makes sure it does not inherit obligations it never signed up for. For the vendor. The vendor wants the obligation to be reasonable and bounded. It cannot realistically promise that no component anywhere has any issue forever, so it will push to limit the promise to the components it knowingly includes, to a defined compliance standard, and to a sensible remedy if something is found. ## The licence families, in plain terms | Family | Examples | Core obligation | Typical risk level | |---|---|---|---| | Permissive | MIT, BSD, Apache 2.0 | Keep notices; Apache adds a patent grant | Low | | Weak copyleft | LGPL, MPL 2.0 | Share changes to the component itself | Medium | | Strong copyleft | GPLv2, GPLv3 | Distributing a combined work can require releasing your source | High | | Network copyleft | AGPLv3 | Even offering the software over a network can trigger source release | High for SaaS | The Open Source Initiative approves licences against its Open Source Definition, and the SPDX project maintains the standard list of identifiers used in SBOMs. Those two references are the common language for any serious open source clause. ## A sample clause to adapt > Open Source Software. "Open Source Software" means software licensed under any licence approved by the Open Source Initiative or otherwise made available under terms that require the licensee, as a condition of use, modification or distribution, to make source code available, to license derivative works on specified terms, or to refrain from restricting further use. The Supplier shall: (a) provide the Customer, on delivery and on request, with a current software bill of materials listing each Open Source Software component, its version and its licence identifier; (b) comply with the terms of each applicable Open Source Software licence; and (c) not incorporate, link or combine any Open Source Software with the Deliverables in a manner that would require the Deliverables, or any of the Customer's own software, confidential information or proprietary code, to be licensed, disclosed or made available under an Open Source Software licence. If the Supplier breaches (c), it shall, at its own cost and the Customer's option, procure a compliant replacement, modify the Deliverables to remove the triggering component, or obtain the rights the Customer needs. Adapt the definition, the remedy and the SBOM cadence to the deal. The sample is a starting point, not a finished clause for every situation. ## The points worth negotiating ### 1. Scope of the disclosure Agree what the SBOM must cover: direct dependencies only, or transitive dependencies too. Transitive (the dependencies of your dependencies) is where most surprises hide, so a buyer should push for it, while a vendor may ask for a reasonable-efforts standard on deep transitive layers. ### 2. The copyleft carve-out The heart of the clause is part (c): no open source may be combined in a way that forces disclosure of the customer's own code. Vendors sometimes ask to carve out components the customer specifically requested, or standard development tools that are not shipped in the product. Those carve-outs are reasonable if they are written down. ### 3. The standard: knowing vs strict Does the vendor promise compliance absolutely, or only for components it knowingly includes and using commercially reasonable diligence? Buyers want closer to strict; vendors want a knowledge and diligence qualifier. A common middle ground is strict on the copyleft carve-out and reasonable-efforts on the full compliance sweep. ### 4. The remedy If a bad component is found, what happens? The strongest buyer remedy is a cure obligation at the vendor's cost: replace, re-engineer, or obtain rights. Weaker versions just give a warranty claim. Spell out who pays and how fast. ### 5. Indemnity Decide whether an open source breach feeds the IP indemnity. If a copyleft component triggers a third party claim, the customer will want it covered. Vendors often resist uncapped open source indemnities, so this is frequently where the real negotiation lands. ### 6. Audit and updates For long term or SaaS deals, agree how often the SBOM is refreshed, and whether the customer can audit or require a scan. New components arrive with every release, so a one-time disclosure ages quickly. ## How the clause differs by context - On-premise or distributed software. Distribution is the trigger for most copyleft licences, so the clause does heavy work here.
• SaaS. Ordinary GPL distribution triggers may not fire because nothing is distributed, but AGPL's network provision can still apply. A SaaS buyer should keep the AGPL carve-out explicit.
• India and other jurisdictions. Open source licences are contracts and are generally enforced as such, but there is less settled case law in India than in the US or Germany on specific copyleft enforcement. Treat the licence terms as binding and do not rely on local under-enforcement. Where governing law matters to you, say so in the contract. ## A quick checklist before you sign - Is there an SBOM, and does it cover transitive dependencies?
• Is there a clear ban on copyleft contamination of your code?
• Is the compliance standard (strict vs knowing) acceptable to you?
• Is there a real cure remedy, at the vendor's cost?
• Does the IP indemnity reach open source claims?
• For SaaS, is AGPL addressed, not just GPL? ## Managing the clause after signature An open source clause is only as good as the tracking behind it. The SBOM has to be stored, read and refreshed; the copyleft carve-out has to be checked against each new release; and the obligation has to be remembered at renewal and audit time. In practice this work is scattered across the signed PDF, a spreadsheet of components, and someone's memory. This is the kind of work an AI contract workspace is built to hold in one place: the signed contract, the clauses that carry open source obligations, the key dates, and a plain-English view of what each clause requires, so the obligation does not fall through the cracks between the deal team and engineering. If you want to see that single workspace idea, Adira is one example. The point is simply that the clause, its SBOM and its deadlines belong together, not in three disconnected tools.