Open-source software clause: Copy, customize, and use instantly
Introduction
An open-source software clause sets out how open-source components may be used, integrated, and managed within a contract’s deliverables or services. It helps ensure license compliance, clarify usage boundaries, and mitigate legal or operational risks associated with open-source licenses.
Below are templates for open-source software clauses tailored to different scenarios. Copy, customize, and insert them into your agreement.
Standard open-source software clause
This version provides general approval and compliance terms.
The [Provider] shall ensure that any open-source software included in the deliverables is properly licensed, complies with applicable license terms, and does not impose obligations inconsistent with this Agreement.
Open-source software clause with prior approval requirement
This version restricts usage without consent.
The [Provider] shall not include any open-source software in the deliverables without the [Customer]’s prior written consent, which may be withheld at the [Customer]’s discretion.
Open-source software clause with warranty disclaimer
This version limits liability for OSS risks.
The [Provider] makes no warranty as to the performance, security, or reliability of any open-source software included in the deliverables beyond that provided by the open-source license itself.
Open-source software clause with license type restrictions
This version prohibits viral or reciprocal licenses.
The [Provider] shall not use any open-source software subject to copyleft, viral, or reciprocal license terms (including GPL, AGPL, or similar) without the [Customer]’s express written approval.
Open-source software clause with OSS inventory disclosure
This version requires transparency of components.
The [Provider] shall deliver a full inventory of all open-source software used in the deliverables, including version numbers, licenses, and usage context.
Open-source software clause with license compatibility assurance
This version prevents conflicting obligations.
The [Provider] shall ensure that any open-source software included is license-compatible with other software components and does not create conflicting obligations.
Open-source software clause with update and patch management
This version addresses security maintenance.
The [Provider] shall monitor and apply security patches and updates for any open-source software used in the deliverables on a timely basis.
Open-source software clause with pre-approved OSS list
This version limits selection scope.
Only open-source software components from the pre-approved list in [Schedule X] may be included in the deliverables, unless otherwise agreed in writing.
Open-source software clause with documentation of modifications
This version requires tracking changes.
Any modifications made by the [Provider] to open-source software shall be clearly documented and disclosed to the [Customer] along with the deliverables.
Open-source software clause with mandatory attribution tracking
This version ensures license compliance.
The [Provider] shall maintain a record of all attribution notices required by open-source licenses and include them in the documentation provided to the [Customer].
Open-source software clause with internal-use only restriction
This version limits scope of usage.
The [Customer] may use open-source software included in the deliverables for internal purposes only, unless broader use is permitted under the applicable license.
Open-source software clause with GPL/AGPL exclusion
This version prohibits strong copyleft licenses.
The [Provider] shall not include any open-source software licensed under GPL, AGPL, or similar licenses without prior written approval from the [Customer].
Open-source software clause with license summary appendix
This version supports due diligence.
A summary of all open-source software license terms applicable to the deliverables shall be included as an appendix to this Agreement.
Open-source software clause with post-termination use limitations
This version sets license continuation rules.
Upon termination of this Agreement, the [Customer] shall only retain rights to use open-source software components under their original license terms.
Open-source software clause with OSS component isolation requirement
This version mandates technical segregation.
The [Provider] shall integrate open-source software in a manner that technically isolates it from proprietary components to avoid license contamination.
Open-source software clause with OSS lifecycle management
This version governs upgrade planning.
The [Provider] shall manage the lifecycle of open-source software components, including monitoring deprecation, replacement planning, and future support.
Open-source software clause with open-source software approval board
This version creates a formal governance process.
The parties may establish a joint open-source approval board to review and approve any OSS components proposed for use in the deliverables.
Open-source software clause with audit cooperation obligation
This version enables external review.
The [Provider] shall cooperate with any audit by the [Customer] or third-party consultant to verify compliance with open-source license obligations.
Open-source software clause with fallback component requirement
This version plans for license risk.
For any open-source software included, the [Provider] shall identify fallback proprietary or alternative components to mitigate licensing risk.
Open-source software clause with OSS contribution disclosure
This version addresses external contributions.
The [Provider] shall disclose any contributions it makes to open-source projects using code developed under this Agreement.
Open-source software clause with non-assertion of OSS-related patents
This version reduces legal risk.
The [Provider] shall not assert any patent rights that would restrict the use of open-source software incorporated into the deliverables.
Open-source software clause with OSS component approval threshold
This version sets criteria for inclusion.
No open-source software component shall be included unless it meets performance, compatibility, and license standards outlined in [Schedule Y].
Open-source software clause with warranty disclaimer acknowledgment
This version manages expectations.
The [Customer] acknowledges that open-source software included in the deliverables is provided under “as-is” conditions, and the [Provider] makes no additional warranties.
Open-source software clause with OSS attribution format standard
This version governs documentation format.
All open-source license attributions shall follow a standard format and be consolidated in a centralized OSS disclosure file delivered with the software.
Open-source software clause with direct license engagement rights
This version supports customer access.
The [Customer] may contact licensors of any open-source software used in the deliverables to seek clarification or direct licensing for extended use.
Open-source software clause with license remediation procedure
This version governs how to handle issues.
If any open-source license compliance issue arises, the [Provider] shall implement remediation steps within [10 business days] of written notice.
Open-source software clause with quarterly OSS review
This version supports ongoing governance.
The [Provider] shall participate in quarterly reviews of OSS usage, license updates, and potential conflicts as part of project governance.
Open-source software clause with liability allocation for OSS violations
This version assigns risk ownership.
The [Provider] shall be liable for any claims arising from failure to comply with open-source software license terms included in the deliverables.
Open-source software clause with post-delivery compliance handover
This version ensures transition clarity.
Upon delivery, the [Provider] shall provide the [Customer] with a full OSS compliance pack including licenses, obligations, and source code access where required.
Open-source software clause with version lock agreement
This version prevents uncontrolled upgrades.
The [Provider] shall not upgrade any open-source software components beyond the version approved in the design specifications without written consent.
Open-source software clause with OSS license term mapping
This version aids internal risk analysis.
The [Provider] shall map all open-source software licenses used in the deliverables to their respective risk categories in accordance with [Schedule X].
Open-source software clause with cloud deployment compatibility assurance
This version manages SaaS license exposure.
The [Provider] shall ensure all open-source software used is compatible with cloud deployment models and does not trigger additional distribution obligations.
Open-source software clause with OSS usage transparency to end users
This version supports compliance visibility.
The [Provider] shall ensure that required OSS license notices are made available to all end users through appropriate documentation or application interface placement.
Open-source software clause with license sunset notification
This version enables forward planning.
The [Provider] shall notify the [Customer] if any open-source software license used in the deliverables has a known sunset date or pending change in terms.
Open-source software clause with standard attribution placement protocol
This version promotes consistency.
All open-source software attribution shall be included in a standardized location within the product, such as an "About" page or documentation appendix.
Open-source software clause with license-specific usage log
This version tracks component usage.
The [Provider] shall maintain a usage log identifying each open-source software component used, the purpose, and where it is integrated within the deliverables.
Open-source software clause with code isolation architecture requirement
This version enforces architectural separation.
Open-source software must be integrated through isolated service layers or containers to ensure clean separation from proprietary logic.
Open-source software clause with license re-validation protocol
This version supports policy updates.
The [Provider] shall review all OSS licenses annually to confirm ongoing compliance with evolving internal and industry policy requirements.
Open-source software clause with downstream compliance responsibility
This version limits redistribution risk.
If the [Customer] redistributes the deliverables, it assumes full responsibility for continuing compliance with open-source software licenses.
Open-source software clause with OSS exception approval process
This version supports flexibility.
If the [Provider] proposes to use an OSS license outside the standard approval list, it must submit a written justification and obtain approval through a defined escalation process.
Open-source software clause with OSS risk scoring requirement
This version enables license risk classification.
Each open-source software component shall be assigned a risk score based on license type, integration method, and update status, documented in [Schedule Y].
Open-source software clause with OSS supply chain verification
This version addresses indirect risks.
The [Provider] shall verify that any subcontracted development work includes proper vetting and licensing of any open-source software used by third-party contributors.
Open-source software clause with code provenance tracking
This version builds traceability.
The [Provider] shall track and document the origin of all open-source code integrated into the deliverables, including source URLs and contributor records.
Open-source software clause with OSS training certification
This version supports workforce compliance.
The [Provider] shall ensure that team members responsible for integrating OSS components complete training in license compliance and usage obligations.
Open-source software clause with OSS aggregation control
This version manages licensing boundaries.
The [Provider] shall avoid combining open-source software with proprietary code in a way that creates aggregation or licensing conflict under copyleft terms.
Open-source software clause with legal review requirement
This version supports risk oversight.
All open-source licenses proposed for use in the project must be reviewed and approved by legal counsel prior to integration.
Open-source software clause with distribution method limitation
This version narrows exposure.
The [Provider] shall not use any open-source software that triggers license obligations based on network distribution or SaaS delivery unless pre-approved.
Open-source software clause with separate OSS repository storage
This version enhances audit readiness.
The [Provider] shall store all open-source software components in a separate, identifiable repository to simplify auditing and compliance checks.
Open-source software clause with zero-dependency fallback
This version adds mitigation.
Where feasible, the [Provider] shall design components with fallback options that do not rely on external OSS packages for basic functionality.
Open-source software clause with OSS scanning tool requirement
This version mandates automated license checks.
The [Provider] shall use automated open-source scanning tools to detect, document, and track all OSS components included in the deliverables.
Open-source software clause with minimum support commitment
This version ensures basic maintenance.
The [Provider] shall ensure that all OSS components included in the deliverables are actively maintained or supported by a recognized community or vendor.
Open-source software clause with pre-release compliance verification
This version supports release readiness.
Prior to final delivery, the [Provider] shall verify that all open-source software used is properly licensed, attributed, and disclosed to the [Customer].
Open-source software clause with independent code review option
This version allows audit of OSS integration.
The [Customer] reserves the right to commission an independent code review to verify compliance with OSS licensing obligations.
Open-source software clause with OSS upgrade planning schedule
This version aligns future maintenance.
The [Provider] shall provide an upgrade plan for major open-source software components, outlining timelines, risks, and cost implications.
Open-source software clause with OSS-specific SLA
This version defines service obligations.
The [Provider] shall include open-source software performance, security patching, and issue response times within the scope of the service level agreement (SLA).
Open-source software clause with community dependency disclosure
This version increases visibility into support model.
The [Provider] shall disclose any OSS dependencies that rely primarily on volunteer communities rather than institutional or vendor backing.
Open-source software clause with change management notification
This version tracks OSS revisions.
Any change to open-source software versions or dependencies during the project must be notified to the [Customer] in advance with supporting rationale.
Open-source software clause with license audit trail maintenance
This version improves accountability.
The [Provider] shall maintain a complete audit trail of OSS license acquisition, use, and compliance for the duration of the Agreement.
Open-source software clause with platform compatibility assurance
This version ensures cross-environment performance.
The [Provider] shall verify that all OSS components function consistently across the deployment platforms specified in [Schedule X].
Open-source software clause with license risk disclosure rating
This version flags legal exposure.
Each OSS component used shall include a risk rating based on license type and redistribution obligations, submitted alongside the technical documentation.
Open-source software clause with OSS deprecation timeline disclosure
This version manages lifecycle awareness.
The [Provider] shall disclose any known or forecasted deprecation timelines for OSS components used and provide suggested replacement paths.
Open-source software clause with industry standard OSS policy alignment
This version standardizes governance.
The [Provider] shall comply with recognized OSS governance standards such as OpenChain or SPDX in managing software components.
Open-source software clause with runtime dependency tracking
This version identifies operational risks.
The [Provider] shall identify all OSS runtime dependencies and ensure their licensing terms do not conflict with the intended commercial use.
Open-source software clause with commercial alternative consideration
This version encourages low-risk selection.
Before using OSS with high-risk licenses, the [Provider] shall consider commercial alternatives and document its rationale for final component selection.
Open-source software clause with shared OSS compliance register
This version enables collaboration.
A shared OSS compliance register shall be maintained by both parties to track licensing, updates, and required attributions throughout the project.
Open-source software clause with feature-critical component review
This version adds scrutiny for core dependencies.
All OSS components that are critical to core functionality shall be subject to heightened legal and technical review before inclusion.
Open-source software clause with usage limit per component
This version restricts component usage.
The [Provider] shall not use any OSS component in more than [X] modules or functionalities without prior approval from the [Customer].
Open-source software clause with OSS component sunset replacement plan
This version promotes long-term stability.
The [Provider] shall prepare and maintain a replacement plan for OSS components known to be in sunset or maintenance-only mode.
Open-source software clause with codebase modularity for OSS containment
This version improves risk segregation.
The [Provider] shall implement modular development architecture to contain OSS use within isolated code blocks or libraries.
Open-source software clause with supplier OSS sourcing verification
This version checks upstream contributors.
The [Provider] shall verify that any subcontractor-supplied software meets the same OSS compliance and licensing requirements.
Open-source software clause with OSS-specific incident response protocol
This version governs issue handling.
A dedicated OSS incident response protocol shall be implemented to manage any vulnerabilities or compliance issues arising post-deployment.
Open-source software clause with centralized OSS license repository
This version centralizes governance.
All OSS license texts shall be stored in a centralized, version-controlled repository accessible to both parties throughout the contract term.
Open-source software clause with high-severity license escalation path
This version enables prompt risk response.
Any OSS component identified with a high-severity license risk shall be escalated to senior stakeholders for risk mitigation and potential removal.
Open-source software clause with digital signature verification for OSS
This version validates source integrity.
The [Provider] shall verify the authenticity of all OSS components via digital signature or checksum validation before use in the deliverables.
Open-source software clause with proprietary-OSS interaction protocol
This version defines boundaries between systems.
Where OSS interacts with proprietary software, the [Provider] shall implement APIs or wrappers to prevent license contamination.
Open-source software clause with real-time OSS license monitoring
This version introduces automation.
The [Provider] shall utilize tools to monitor license changes or reclassifications of OSS components in real time and notify the [Customer] accordingly.
Open-source software clause with cost attribution disclaimer
This version separates liability.
The [Customer] acknowledges that open-source software is provided at no cost, and any downstream costs related to use are excluded from the [Provider]’s responsibility.
Open-source software clause with OSS rollback procedure
This version supports risk mitigation.
If any OSS component is found to conflict with this Agreement, the [Provider] shall initiate a rollback process and restore the prior compliant version.
Open-source software clause with future-proofing obligation
This version encourages sustainable selection.
The [Provider] shall select OSS components that demonstrate community activity, version support, and a clear roadmap for future development.
Open-source software clause with downstream license cascade tracking
This version monitors license flow.
The [Provider] shall track and document any cascading license obligations resulting from inclusion of OSS components within compiled code.
Open-source software clause with OSS replacement threshold definition
This version defines risk boundaries.
Any OSS component exceeding the defined licensing risk threshold shall be subject to mandatory replacement before final delivery.
Open-source software clause with OSS source repository access
This version provides transparency.
The [Provider] shall provide the [Customer] with read-only access to all source repositories containing open-source software included in the project.
Open-source software clause with project-specific OSS compliance summary
This version summarizes risks.
A summary of OSS compliance, including component list, license type, risk rating, and attribution status, shall be included with each project milestone.
Open-source software clause with cross-border OSS restriction notice
This version highlights regional limitations.
The [Provider] shall disclose if any OSS component includes geographic use limitations or export control restrictions under the license.
Open-source software clause with phased OSS onboarding procedure
This version structures implementation.
All OSS components must go through a structured onboarding process including technical, legal, and compliance reviews before integration.
Open-source software clause with application layer usage limitation
This version restricts OSS placement.
The [Provider] shall only include OSS at the application layer and shall not embed it in core infrastructure components without prior approval.
Open-source software clause with non-production use waiver
This version allows exceptions for testing.
The [Provider] may use non-approved OSS components in development or testing environments only, subject to removal prior to production deployment.
Open-source software clause with license migration notification
This version tracks evolving licensing terms.
The [Provider] shall notify the [Customer] if any OSS component changes its license model or terms during the Agreement period.
Open-source software clause with delivery artifact license inclusion
This version ensures completeness.
The [Provider] shall include all OSS license texts, notices, and attribution files with each final deliverable package or deployment artifact.
Open-source software clause with zero-aggregation policy
This version prevents mixed licensing.
The [Provider] shall not aggregate OSS components with proprietary code in a way that creates derivative works under reciprocal license obligations.
Open-source software clause with independent license counsel review option
This version enables legal verification.
The [Customer] may request a review of OSS licenses by independent counsel prior to acceptance of deliverables.
Open-source software clause with OSS removal trigger event definition
This version enables proactive removal.
OSS components shall be removed if any trigger event occurs, including security vulnerabilities, license violations, or community project abandonment.
Open-source software clause with AI model training exclusion
This version governs AI usage.
The [Provider] shall not use OSS components with restrictions on AI/ML training datasets without the [Customer]’s written consent.
Open-source software clause with non-contamination declaration
This version ensures clean IP boundaries.
The [Provider] shall declare that all proprietary code is free from OSS contamination that could compromise ownership or licensing terms.
This article contains general legal information and does not contain legal advice. Cobrief is not a law firm or a substitute for an attorney or law firm. The law is complex and changes often. For legal advice, please ask a lawyer.