Open Source Software Use Policy
Open Source Software Use Policy template for reviewing, approving, using, and attributing open source code in products and internal systems. It helps set clear approval steps, license checks, and escalation paths before code is merged or shipped.
Trusted by frontline teams 15 years of frontline software AI customization in seconds
Built for: Saas · Software Development · Fintech · Healthcare Technology · Enterprise It
Overview
This Open Source Software Use Policy template sets the rules for how employees request, review, approve, include, modify, and attribute open source software in company products and internal systems. It is meant for organizations that rely on third-party libraries, frameworks, tools, or code snippets and need a consistent way to manage license obligations, security review, and release approvals.
Use this template when your teams regularly add dependencies, reuse code from public repositories, or distribute software to customers and partners. It is especially useful when different licenses carry different obligations, when legal or security review is required before release, or when the company wants a documented approval trail for audits and vendor reviews. The policy also helps define who can approve use, what records must be kept, and when attribution or source disclosure is required.
Do not use this template as a substitute for product-specific legal advice or a full software supply chain program. If your company never distributes software, uses only tightly controlled internal tools, or has a separate open source governance standard, you may need to narrow the scope. It is also not the right fit if you need a broader information security policy, a code of conduct, or an employee invention assignment policy. The value of this template is that it gives you a practical, repeatable process for open source use without turning every dependency decision into an ad hoc exception.
Standards & compliance context
- This template supports license compliance and internal governance, but legal review should confirm obligations under the specific open source license before distribution.
- If open source code is bundled into a product that handles personal data, privacy review should consider GDPR and CCPA obligations for data collection, retention, and disclosure.
- If the policy is used alongside employee conduct rules, keep it separate from NLRA-protected concerted activity issues and avoid language that restricts lawful employee discussions about working conditions.
- Where software is used in regulated environments, align the approval process with security and recordkeeping controls that support audit readiness and incident response.
- If the company also maintains workplace policies on confidentiality, trade secrets, or acceptable use, make sure this policy does not conflict with those rules.
General regulatory context for orientation only — verify current requirements with counsel or the relevant agency before relying on this template for compliance.
What's inside this template
Purpose
Explains why the policy exists and what risks it is designed to control.
-
The purpose of this policy is to ensure that any open source software (OSS) used in company products, services, tooling, or internal systems is reviewed, approved, tracked, and attributed in a manner that protects company intellectual property, security, product integrity, and legal compliance. This policy establishes a good-faith review process for license compatibility, security risk, and attribution requirements before OSS is introduced into source code, build pipelines, containers, infrastructure-as-code, or internal applications.
Scope
Defines which people, systems, products, and code uses are covered by the policy.
-
This policy applies to all employees, contractors, consultants, interns, and temporary workers who develop, maintain, procure, or approve software or technology systems on behalf of the company. It applies to: - Company-owned products and services - Internal tools and systems - Source code repositories, packages, dependencies, and build artifacts - Third-party libraries, frameworks, snippets, and sample code - Container images, scripts, templates, and infrastructure code California employees: nothing in this policy is intended to restrict rights protected by the California Labor Code, including lawful off-duty conduct protections where applicable. This policy must also be applied consistently with EEOC requirements, FLSA classification and overtime rules, and NLRA Section 7 rights regarding protected concerted activity.
Definitions
Clarifies terms like open source software, modification, distribution, attribution, and approval.
-
For purposes of this policy: - **Open source software (OSS):** Software distributed under a license that permits use, modification, and redistribution subject to stated conditions. - **Approved OSS:** OSS that has completed the required legal, security, and technical review and has been authorized for use. - **Copyleft license:** A license that may require derivative works or combined works to be distributed under the same or compatible license terms. - **Attribution notice:** A required notice, copyright statement, or license text that must be included with the software or documentation. - **Essential function:** A core job duty for a role; this policy does not change classification, overtime, or accommodation obligations under the FLSA or ADA. - **Interactive process:** The good-faith process used to evaluate a request for reasonable accommodation under the ADA when a policy requirement may need adjustment. - **Policy holder:** The department owner responsible for maintaining this policy, typically Legal, Security, or Engineering Operations.
Policy Statement
States the core rules for when open source software may be used and what approvals are required.
-
1. OSS may be used only when its license, security posture, and operational impact have been reviewed and approved in advance by the designated approvers. 2. No employee may introduce OSS into production code, internal systems, or distributed products without following the review procedure in this policy. 3. The company will maintain a record of approved OSS components, versions, licenses, attribution requirements, and any exceptions granted. 4. OSS must not be used if its license terms conflict with company distribution, confidentiality, patent, indemnity, export, or customer contract obligations unless Legal approves an exception in writing. 5. Employees must not remove, obscure, or alter required copyright notices, license texts, or attribution statements. 6. OSS use must not create avoidable security risk, including known critical vulnerabilities, abandoned projects, or unmaintained dependencies, unless a documented exception is approved and compensating controls are implemented. 7. This policy is intended to regulate software governance and does not prohibit employees from engaging in protected concerted activity under NLRA Section 7, discussing wages or working conditions, or reporting concerns about software practices in good faith.
Procedure
Lays out the step-by-step workflow for requesting, reviewing, approving, documenting, and releasing open source code.
-
### 1) Pre-use review Before OSS is added to a repository, build pipeline, product, or internal system, the requesting team must submit a review request that includes: - Package or project name - Version and source location - Intended use case and deployment context - License type and any known dependencies - Security scan results, if available - Whether the code will be modified, redistributed, or embedded in a shipped product ### 2) Approval workflow The request must be reviewed by the appropriate approvers, which may include Engineering, Security, and Legal. Approval must be documented before use. ### 3) License and attribution check The reviewer must confirm: - The license is compatible with the intended use - Required notices, source disclosures, or attribution text are identified - Any reciprocal or copyleft obligations are understood and accepted ### 4) Security review The reviewer must assess known vulnerabilities, maintenance activity, release cadence, and supply-chain risk. High-risk components may require additional controls, such as version pinning, sandboxing, or replacement. ### 5) Recordkeeping Approved OSS must be recorded in the company OSS inventory or software bill of materials (SBOM), including version, license, owner, and attribution obligations. ### 6) Changes and updates Material changes to an approved OSS component, including major version upgrades or license changes, require re-review before deployment. ### 7) Exceptions If a team needs to use unapproved OSS or accept a license conflict, the team must request a written exception that states the business justification, risk assessment, mitigation plan, expiration date, and approving authority. ### 8) Removal or remediation If unapproved OSS is discovered, the responsible team must notify Security and Legal promptly, assess exposure, and either remove, replace, or remediate the component according to the approved plan.
Roles & Responsibilities
Assigns ownership for intake, review, approval, recordkeeping, and exception handling.
-
- **Requesting employee / team:** Identifies OSS, submits review requests, follows approval conditions, and maintains required attribution in code and documentation. - **Engineering Manager:** Ensures team compliance, confirms technical necessity, and prevents deployment of unapproved OSS. - **Security Team:** Reviews supply-chain and vulnerability risk, defines compensating controls, and tracks remediation of risky components. - **Legal Counsel:** Reviews license terms, attribution obligations, distribution restrictions, and exception requests with legal impact. - **Policy holder:** Maintains the policy, updates standards, and coordinates periodic review. - **Compliance Officer:** Oversees documentation, audit readiness, and escalation of repeated or material violations.
Compliance and Discipline
Describes what happens when the policy is not followed and how violations are escalated.
-
Failure to follow this policy may result in removal of the OSS component, rollback of releases, mandatory remediation, retraining, documented warning, PIP, loss of deployment privileges, or other corrective action up to and including termination, consistent with applicable law and company policy. The company will apply this policy consistently and without discrimination in accordance with Title VII of the Civil Rights Act of 1964 and applicable EEOC guidance. Nothing in this policy limits rights protected by the NLRA, FLSA, ADA, or FMLA, including the right to request a reasonable accommodation through the interactive process when a policy requirement creates a disability-related need. Employees are expected to report suspected violations in good faith. Retaliation for good-faith reporting is prohibited.
Review and Revision
Sets the effective_date, version control, and annual review cadence so the policy stays current.
-
This policy will be reviewed at least annually and updated as needed to reflect changes in licensing practices, security standards, product architecture, and applicable law. The policy holder must document revisions, obtain required approvals, and communicate material changes to affected roles. California employees, New York employees, and other jurisdiction-specific groups may receive supplemental guidance where state law or local requirements impose additional obligations.
How to use this template
- 1. Fill in the effective_date, version, applicable_jurisdictions, applicable_roles, and policy holder fields so the document is tied to your organization and review cycle.
- 2. Define which open source uses require pre-approval, which licenses are allowed by default, and which cases must be escalated to legal, security, or engineering leadership.
- 3. Assign the intake and review workflow to the people who will actually run it, such as engineering managers, security reviewers, and legal counsel, and connect it to your ticketing or pull request process.
- 4. Publish the procedure for requesting approval, documenting license terms, recording attribution requirements, and handling modifications or redistribution obligations.
- 5. Train developers and release owners on the policy, then audit a few real dependency additions to confirm the process works before you rely on it in production.
- 6. Review exceptions, incidents, and policy changes annually, and update the approval matrix whenever your product distribution model or license risk profile changes.
Best practices
- Require pre-approval before a new dependency is merged into a production branch, not after release.
- Maintain a simple license whitelist and a separate escalation path for copyleft or source-disclosure obligations.
- Document the exact package name, version, license, and intended use for every approved component.
- Tie open source review to the same pull request or ticket that introduces the code so the audit trail is complete.
- Require attribution notices and source code notices to be checked at release time, not left to memory.
- Re-review dependencies after major version upgrades, because license terms, transitive dependencies, and security exposure can change.
- Route privacy-sensitive tools through data protection review when they process personal data or telemetry.
What this template typically catches
Issues teams running this template most often surface in practice:
Common use cases
Frequently asked questions
What does this Open Source Software Use Policy template cover?
It covers how employees request, review, approve, include, modify, and attribute open source software in company products and internal systems. The template also sets expectations for license review, security review, and recordkeeping before code is used. It is designed to reduce licensing, security, and ownership risk without blocking routine engineering work.
Who should use and enforce this policy?
Engineering, product, security, legal, and procurement typically share responsibility, with a policy holder in HR, legal, or compliance coordinating the process. Developers should follow the procedure before adding new dependencies or copying code into company repositories. Security and legal should review higher-risk components, especially where copyleft terms, attribution duties, or distribution obligations may apply.
How often should this policy be reviewed?
Review it at least annually, and sooner when the company changes its product distribution model, security controls, or license approval process. A review is also appropriate after a significant incident, such as a license conflict, a security vulnerability in a dependency, or a customer contract requiring stricter software provenance. The template includes review_frequency and effective_date fields so the policy stays current.
Does this policy address regulatory or legal compliance?
Yes, it is written to support compliance with open source license obligations and internal governance, while also aligning with broader employment and workplace policy controls. Depending on the facts, related obligations may intersect with confidentiality, trade secret protection, data handling, and security requirements. The policy should be paired with legal review for specific licenses and with privacy review when code or tools process personal data under GDPR or CCPA.
What are the most common mistakes this template helps prevent?
The most common issues are adding dependencies without approval, missing attribution notices, failing to track license terms, and shipping code that creates unintended disclosure obligations. Teams also often forget to document modifications, source notices, or downstream distribution requirements. This template gives you a repeatable process so those checks happen before release rather than after a problem is discovered.
Can this policy be customized for different teams or products?
Yes, it should be customized for your product stack, release model, and risk tolerance. For example, a SaaS company may focus on internal use and hosted services, while a software distributor may need stricter controls for binaries, source delivery, and notices. You can also add separate approval paths for low-risk permissive licenses versus higher-risk copyleft licenses.
How does this policy fit with security and engineering workflows?
It can be tied to pull request checks, dependency scanning, ticketing, and release approvals so review happens where developers already work. Many teams route requests through a ticket or intake form, then record the license decision and required notices in the repository or release checklist. That makes the policy easier to follow and easier to audit.
Should internal tools and third-party libraries be treated the same way?
No, the policy should distinguish between external distribution, internal-only use, and code embedded in customer-facing products. Internal tools may still create license, security, and attribution obligations, but the approval threshold can be different from shipped software. The template helps you define those distinctions clearly so teams do not apply one rule to every use case.
Related templates
Ready to use this template?
Get started with MangoApps and use Open Source Software Use Policy with your team — pricing built for small business.
