What Is an Open-Source Clause? Definition, Copyleft Risks & Red Flags
An open-source clause governs how open-source software components may be used inside the work a contractor or vendor delivers to you. It sounds technical, but the stakes are high: certain open-source licenses — particularly GPL and AGPL — carry 'copyleft' obligations that can legally require your entire proprietary product to be released as open source if the rules aren't followed. If you're buying custom software, hiring a development team, or acquiring a tech company, this clause directly protects your IP. Here's what to watch for.
Upload your software development or vendor contract to Contrivox and get an instant analysis of whether your open-source clause adequately protects your IP — including copyleft exposure, missing BOM requirements, and indemnification gaps.
Analyze My Contract →What Is a Open-Source Clause?
Plain English
An open-source clause sets the rules for if, when, and how a contractor or vendor can use open-source software components when building something for you. It typically requires them to disclose which open-source components they've used and to confirm that none of those components carry license terms that could undermine your ownership of the final product.
Legal Context
From a drafter's perspective, this clause serves two purposes: it protects the buyer from inadvertent copyleft exposure by requiring disclosure and compliance representations, and it allocates risk — making clear that if an open-source license obligation is triggered through the vendor's choices, the vendor bears liability for remediation. It often appears in software development agreements, technology acquisition contracts, and M&A due diligence schedules.
How It Appears in Contracts
Open-source clauses are most common in custom software development agreements, SaaS vendor contracts, and IP assignment agreements. They can be a standalone section or embedded within IP ownership or representations and warranties provisions.
What to look for in the actual clause text:
- Whether the clause requires a full open-source bill of materials (BOM) — a list of every open-source component used and its license type
- Whether 'copyleft licenses' are defined and whether AGPL is explicitly included, since AGPL has broader triggers than GPL
- Whether the vendor's indemnification obligation covers third-party license claims, not just the cost of replacing the component
Risks & Red Flags
GPL Copyleft Infection
If a developer links your proprietary code with a component licensed under the GNU General Public License (GPL), the GPL's terms may require the combined work to be released publicly under GPL. This can effectively strip you of trade secret and proprietary IP protections in your own product. The risk is not theoretical — it has caused real compliance crises for technology companies, and the remedy is often expensive re-engineering.
AGPL Network-Use Trigger
The GNU Affero General Public License (AGPL) goes further than GPL: it requires open-source release even when software is merely offered over a network (e.g., as a SaaS product) without any traditional 'distribution.' Many developers are unaware of this distinction. If your product runs as a cloud service and any component is AGPL-licensed, you may face an obligation to publish your source code even though you never shipped a binary to anyone.
No Disclosure Obligation for Existing Components
Some contracts only require the vendor to seek approval for future open-source use, leaving components already in the codebase undisclosed. If you later sell the software or raise investment, a hidden GPL or AGPL dependency discovered during due diligence can delay or kill the deal, or create representations breach liability under the acquisition agreement.
Perpetual Attribution and Notice Obligations
Many open-source licenses — including MIT, Apache 2.0, and BSD — require that copyright notices and license texts be preserved in all copies and distributions, in perpetuity. If your team removes or fails to include these notices in a product release or resale, you may be in breach of the underlying license, exposing you to copyright infringement claims from the original open-source project maintainers.
Weak or Missing Indemnification
An open-source clause without a vendor indemnification obligation leaves all remediation costs with you. If a copyleft trigger is discovered post-delivery, you may have to pay independently to re-engineer the infringing component, defend against license enforcement actions, or delay a product launch — with no contractual recourse against the party who created the problem.
Permissive vs. Copyleft Not Distinguished
Contracts that simply say 'no open-source software without approval' treat MIT-licensed utilities and AGPL-licensed frameworks identically, which is operationally unworkable and often leads to blanket non-compliance. A well-drafted clause distinguishes between permissive licenses (MIT, Apache 2.0) that carry minimal risk and copyleft licenses (GPL, LGPL, AGPL, EUPL) that require active management.
Enforceability
Open-source clauses themselves are standard commercial contract provisions and are generally enforceable in most jurisdictions. However, the underlying open-source license obligations — GPL, AGPL, MIT, etc. — are copyright-based licenses governed by the laws of the country where enforcement is sought, and they exist independently of whatever the contract says. Contractual compliance obligations can stack on top of statutory copyright law, but a contract cannot override a license obligation owed to a third-party licensor.
In the United States, open-source license enforcement is primarily a matter of copyright law under federal statute, with enforcement actions typically brought in federal court. In the EU, the EUPL (European Union Public Licence) adds an additional copyleft license to watch for in European vendor relationships. Courts in Germany have been notably active in enforcing GPL obligations, while US enforcement has historically been handled more through community pressure and compliance programs than litigation — though that landscape continues to evolve. Consult a lawyer familiar with IP law in your specific jurisdiction for advice on your situation.
Negotiation Tips
- Require a complete open-source bill of materials (BOM) as a deliverable — not just at project end, but at each major milestone. Specify that it must identify component name, version, source repository URL, and SPDX license identifier.
- Explicitly list prohibited license categories in the contract. At minimum, name GPL v2, GPL v3, AGPL v3, LGPL (unless dynamically linked under specific conditions), and EUPL as licenses requiring prior written approval.
- Push for a standalone indemnification obligation tied specifically to open-source license breaches, covering the cost of re-engineering, legal defense, and any licensing fees required to remediate — not just a general 'breach of warranty' indemnity.
- If the vendor insists on LGPL components, negotiate a technical requirement for dynamic linking rather than static linking, which is often sufficient under LGPL v2.1 to avoid copyleft infection of your proprietary code — but confirm this with a lawyer for your specific architecture.
- Ask whether any development tools, build systems, or CI/CD pipeline components are AGPL-licensed. AGPL's network-use trigger can theoretically apply to internal tooling if it is exposed through a network interface, and this is frequently overlooked.
- Request a 'clean-up period' right: if an undisclosed or non-compliant open-source component is discovered after delivery, the contract should require the vendor to replace or remediate it at their cost within a defined timeframe — typically 30 to 60 days — before your indemnification rights fully activate.
Upload your software development or vendor contract to Contrivox and get an instant analysis of whether your open-source clause adequately protects your IP — including copyleft exposure, missing BOM requirements, and indemnification gaps.
Analyze My Contract →Frequently Asked Questions
What is an open-source compliance clause in a software contract?
An open-source compliance clause (also called an OSS clause or open-source clause) requires the vendor or contractor to track, disclose, and comply with the license terms of any open-source software used in the deliverables. It protects the buyer by ensuring that open-source components don't carry license obligations — like copyleft requirements — that could compromise the buyer's ownership or control of the finished product.
What does 'copyleft infection' actually mean?
Copyleft infection refers to the way certain open-source licenses — most notably the GPL and AGPL — can spread their terms to a larger work that incorporates them. If your vendor builds your proprietary software using a GPL-licensed component and the integration crosses certain technical thresholds (such as static linking), the GPL's terms may legally require the entire combined work to be released publicly as open source. 'Infection' is informal language, but the legal mechanism it describes is real and has been the subject of enforcement actions.
How is an AGPL clause different from a GPL copyleft provision?
The AGPL (GNU Affero General Public License) adds a critical trigger beyond standard GPL: it requires source code disclosure when software is provided over a network, even if the software is never distributed as a binary. This means that if you run AGPL-licensed code as part of a SaaS or cloud service, you may be required to make your source code available to users — even internal users. Standard GPL only triggers on distribution, making AGPL significantly more dangerous for cloud-based businesses.
Does an open-source clause affect my ownership of the final deliverable?
Yes, potentially. An IP assignment clause or work-for-hire provision in your contract may grant you full ownership of the deliverables, but that ownership is subject to the license terms of any open-source components embedded in the code. If a copyleft license applies to part of the codebase, your 'ownership' of that portion may be legally constrained — you may be required to sublicense it under open-source terms regardless of what your contract says. This is why open-source clauses and IP assignment clauses need to be read together.
What open-source licenses are generally considered 'safe' for commercial software?
Permissive licenses — including MIT, Apache 2.0, and BSD 2-Clause and 3-Clause — are widely considered lower risk for commercial use because they impose few conditions beyond attribution and notice preservation. Copyleft licenses (GPL, LGPL, AGPL, EUPL, MPL) require more careful management and may impose significant obligations depending on how the component is integrated. 'Safe' is always context-dependent, so consult a lawyer or qualified IP counsel for an assessment specific to your product architecture and business model.
What should an open-source bill of materials (BOM) include?
A comprehensive open-source BOM should list every open-source component in the deliverable, including its full name, version number, source URL or repository, and the exact license under which it is used (ideally using the SPDX license identifier format). For components with multiple license options, the BOM should specify which license applies. The BOM should be updated at each milestone and provided in a machine-readable format where possible to facilitate future due diligence.
Can I be held liable for open-source license violations in software I bought, not built?
Yes. If you acquire software — whether through purchase, as part of a company acquisition, or as a deliverable under a development contract — and that software contains open-source components with unmet license obligations, you may inherit those compliance obligations as the distributor or operator of the software. This is why open-source due diligence is a standard part of software M&A and why representations and warranties clauses in acquisition agreements routinely include open-source compliance representations.
What happens if an open-source compliance clause is missing from my contract entirely?
If there is no open-source clause, the underlying open-source license obligations still exist — they are a matter of copyright law, not just contract terms. However, you lose the contractual right to require disclosure, demand remediation, or seek indemnification from the vendor if a problem arises. You would be left relying on general breach of contract or misrepresentation claims, which are harder to prove and less certain in outcome. Adding an open-source clause before signing is strongly preferable to pursuing remedies after a violation is discovered.