Free template
Open Source Software Policy Template
Manage open source risk and compliance by defining how your team selects, reviews, and documents open source software with this Open Source Software Policy Template.
Downloaded 4102 times
Download template
Open Source Software Policy Template
This Open Source Software Policy (the “Policy”) is adopted by [Company Name] as of [Effective Date].
1. Purpose
1.1 Goal. This Policy sets rules for selecting, using, modifying, and distributing open source software (“OSS”) to reduce legal, security, and operational risk.
1.2 Scope. This Policy applies to all employees, contractors, and vendors who develop, deploy, or distribute software for or on behalf of [Company Name].
2. Definitions
2.1 Open Source Software (OSS). Software released under an open source license that grants rights to use, modify, and distribute subject to license terms.
2.2 Dependency. Any OSS library, package, module, framework, or tool included in, linked to, embedded in, or used to build Company software.
2.3 Distribution. Providing software to third parties, including SaaS delivery (to the extent an OSS license treats network use as distribution), downloads, mobile apps, on-prem installations, or source releases.
2.4 SBOM. Software Bill of Materials listing software components, versions, and licenses.
3. Roles and Responsibilities
3.1 Engineering/Developers. Select OSS responsibly, follow approval rules, and keep dependency records current.
3.2 Security Team (Optional). Define scanning requirements, review vulnerabilities, and approve exceptions related to security.
3.3 Legal/Compliance (Optional). Review license obligations, approve restricted licenses, and maintain compliance guidance.
3.4 OSS Approver/Committee. The designated approver(s) for OSS requests: [Role/Name/Team].
3.5 Product Owners. Ensure OSS compliance is considered for releases and distribution plans.
4. General Rules
4.1 Tracking Required. All OSS dependencies must be documented in an inventory/SBOM, including name, version, source, license, and where it is used.
4.2 No Unapproved OSS. OSS may not be added to production or shipped products without approval under Section 5, unless it is on the pre-approved list in Exhibit A.
4.3 Use for Evaluation. OSS may be used for local evaluation/testing without approval if it is not committed to shared repos or shipped; once committed or shipped, approval is required.
4.4 License Compliance. Teams must follow license obligations, including attribution, notice files, and source-code availability obligations where required.
4.5 Security Hygiene. OSS must be scanned for known vulnerabilities and maintained with reasonable updates.
5. Approval Workflow
5.1 Request. Before adding a new OSS dependency, the requester must submit:
project/repo name and owner,
OSS name, version, and source URL,
intended use (build-time, runtime, client-side, server-side),
distribution model (SaaS, app, on-prem, open source), and
license type (if known).
5.2 Review. The approver(s) will review for license compatibility, security posture, and operational risk.
5.3 Decision. Approval outcomes: ☐ Approved ☐ Approved with conditions ☐ Rejected.
5.4 Turnaround Time (Optional). Target review time: [__] business days.
5.5 Recordkeeping. Approved requests must be logged in: [Tool/Tracker], with date, approver, and any conditions.
6. License Categories (Customize)
6.1 Generally Permitted Licenses (Examples).
☐ MIT ☐ BSD ☐ Apache 2.0 ☐ ISC
6.2 Restricted Licenses (Approval Required).
☐ GPL ☐ LGPL ☐ AGPL ☐ SSPL ☐ Other: [List]
6.3 Prohibited Licenses (Optional).
☐ Licenses not approved by Legal/Compliance
☐ Custom or “source available” licenses without review
☐ Other: [List]
6.4 Compatibility Checks. Before shipping, the release owner must confirm license compatibility for combined works, linking, and distribution context.
7. Distribution and Release Requirements
7.1 Notice File. Products that include OSS must include required attributions/notices in: ☐ NOTICE file ☐ About screen ☐ Documentation ☐ Other: [Location].
7.2 Source Code Offer (If Required). If a license requires source disclosure or an offer, the release owner must ensure the required source code and instructions are available in the required format and timeframe.
7.3 Third-Party Requests. Requests for OSS source/notice information are handled by: [Team/Role], within [__] business days.
7.4 Customer Contracts. If customer terms require OSS disclosures (e.g., enterprise buyers), provide SBOM/notice as required.
8. Modifying Open Source Software
8.1 Modification Rules. Modifying OSS is allowed only if:
the change is documented,
the modified component remains tracked in the inventory/SBOM, and
license obligations for modified works are followed.
8.2 Upstream Contributions (Optional). Contributions back to the upstream project require: ☐ Approval ☐ No approval, but must follow contribution guidelines.
8.3 Patch Management. Teams must keep a record of patches and rebasing plans to avoid long-term fork risk.
9. Security and Vulnerability Management
9.1 Scanning Tools. Approved scanning tools: [SCA tool, SAST tool, container scanning].
9.2 Severity Thresholds. Vulnerability thresholds for release: [Define CVSS threshold and exceptions process].
9.3 Response Times. Target remediation timelines:
Critical: [__] days
High: [__] days
Medium: [__] days
Low: [__] days
9.4 Exceptions. Exceptions require written approval by: [Role], documented with mitigation steps and an expiration date.
10. Audits and Compliance
10.1 Internal Audits. [Company Name] may perform periodic OSS compliance reviews. Teams must cooperate and provide requested documentation.
10.2 Non-Compliance. If non-compliance is found, the responsible team must remediate within [__] days or follow an approved remediation plan.
10.3 Training. Required training frequency: ☐ Onboarding only ☐ Annual ☐ Other: [Frequency].
11. Exceptions
11.1 Exception Requests. Exceptions to this Policy must be requested in writing and approved by: [Approver/Committee].
11.2 Documentation. Exceptions must include scope, reason, risk assessment, mitigation steps, and an expiration date.
12. Policy Administration
12.1 Owner. Policy owner: [Name/Role/Department].
12.2 Review Cycle. This Policy will be reviewed: ☐ Annually ☐ Every [__] months ☐ As needed.
12.3 Updates. Updates must be approved by: [Approver/Role].
Signatures
By signing below, the undersigned acknowledge they have read and agree to comply with this Open Source Software Policy.
Company Representative: [Name]
Title: [Title]
Date: [Date]
Signature: ___________________________
Employee/Contractor: [Name]
Title/Role: [Role]
Date: [Date]
Signature: ___________________________
Flash deal
Flash deal
Today
Today
No time to fill it up? Generate your custom agreement with AI Lawyer in seconds
What’s Included
Legal Research
Legal Research
Legal Research
Contract Drafting
Contract Drafting
Contract Drafting
Document Review
Document Review
Document Review
Risk Analytics
Risk Analytics
Risk Analytics
Citation Verification
Citation Verification
Citation Verification
Easy-to-understand jargon
Easy-to-understand jargon
Easy-to-understand jargon
Details
Learn more about
Open Source Software Policy Template
Click below for detailed info on the template.
For quick answers, scroll below to see the FAQ.
Click below for detailed info on the template.
For quick answers, scroll below to see the FAQ.
OPEN SOURCE SOFTWARE POLICY TEMPLATE FAQ
What is an open source software policy?
An open source software policy is a set of internal rules that explain how an organization can use, modify, and distribute open source software (OSS). It helps teams avoid license violations, keep accurate records of dependencies, and reduce legal and security risks while still benefiting from open source tools.
Who should follow an open source software policy?
Anyone who selects, installs, builds, or ships software on behalf of the organization should follow it — especially engineers, product teams, DevOps, security, and legal/compliance. It can also apply to contractors and vendors who deliver software that includes OSS components.
What should an OSS policy include?
It should define roles (who approves), allowed and restricted license types, how to review new dependencies, how to document and track OSS (SBOM/dependency lists), security scanning expectations, rules for modifying OSS, rules for distributing products that include OSS, and how to handle notices and attribution.
How does an OSS policy reduce risk?
It reduces risk by making license compliance and security checks routine. The policy sets a consistent approval workflow, ensures teams know what they can and cannot ship, and creates an audit trail (approvals, versions, and notices) so problems can be fixed quickly.
What are the most common OSS compliance mistakes?
Common mistakes include using dependencies without tracking them, mixing incompatible licenses, distributing software without required notices, failing to provide source code when required, and not scanning for known vulnerabilities. A clear policy prevents these issues by standardizing review and documentation.
What is AI Lawyer?
AI Lawyer is an AI-powered assistant that helps you create and customize legal and business document templates online. It guides you through key sections, suggests wording, and explains complex concepts in simple language. AI Lawyer does not replace a licensed attorney or provide legal advice, but helps you prepare better documents faster and more confidently.
Similar templates
Other templates from
Policy and Compliance Documents
Money back guarantee
Free trial
Cancel anytime
AI Lawyer protects
your rights and wallet
Money back guarantee
Free trial
Cancel anytime
AI Lawyer protects
your rights and wallet
Money back guarantee
Free trial
Cancel anytime
AI Lawyer protects
your rights and wallet
Money back guarantee
Free trial
Cancel anytime