Free template
License Compatibility Matrix Template
Standardize OSS license decisions by documenting compatibility rules and escalation paths with this License Compatibility Matrix Template.
Downloaded 2786 times
Download template
License Compatibility Matrix Template
This License Compatibility Matrix (the “Matrix”) is adopted by [Company Name] as of [Effective Date].
1. Purpose
1.1 Purpose. This Matrix provides internal guidance on how common open source license types may be used and combined in Company software, and when legal/compliance approval is required.
1.2 Scope. This Matrix applies to all open source and third-party software components used in Company products, services, and internal tooling.
2. How to Use This Matrix
2.1 Not Legal Advice. This Matrix is internal guidance and does not replace legal review.
2.2 Usage Context Matters. Compatibility can depend on: static vs. dynamic linking, distribution vs. SaaS delivery, bundling, and whether code is modified.
2.3 Escalation. If unsure, escalate to: [OSS Committee/Legal/Compliance] before shipping or distributing software.
3. License Categories
3.1 Permissive Licenses. Examples: MIT, BSD, Apache 2.0, ISC.
3.2 Weak Copyleft Licenses. Examples: LGPL, MPL.
3.3 Strong Copyleft Licenses. Examples: GPL.
3.4 Network Copyleft Licenses. Examples: AGPL.
3.5 Source-Available/Non-OSI Licenses. Examples: SSPL, BSL, custom licenses.
3.6 Proprietary/Commercial Licenses. Vendor terms and paid licenses.
4. Compatibility Rules (Guidance)
4.1 Permissive + Permissive. Generally compatible; requires notices and license texts as required.
4.2 Permissive + Weak Copyleft. Often compatible, but obligations may apply to modified files or certain linking scenarios; approval recommended for distributed products.
4.3 Permissive + Strong Copyleft (GPL). High risk for distributed products; often incompatible with closed-source distribution unless the combined work can comply with GPL requirements. Requires Legal approval.
4.4 Permissive + Network Copyleft (AGPL). High risk for SaaS and distribution; requires Legal approval.
4.5 Weak Copyleft + Proprietary. May be possible with careful linking/segregation; requires Legal approval for distribution.
4.6 Strong/Network Copyleft + Proprietary. Generally not allowed for proprietary distribution without a specific compliance path; requires Legal approval and documented justification.
4.7 Source-Available Licenses. Treat as restricted; requires Legal approval and review of commercial restrictions.
5. Use Cases and Approval Requirements
5.1 Internal Use Only (No Distribution).
Permissive: ☐ Allowed ☐ Approval required (optional)
Weak copyleft: ☐ Allowed with tracking ☐ Approval required
Strong/network copyleft: ☐ Restricted ☐ Approval required
Source-available: ☐ Restricted ☐ Approval required
5.2 SaaS/Hosted Service.Permissive: Generally allowed with tracking
Weak copyleft: Review recommended
Strong copyleft: Review required
Network copyleft (AGPL): Review required (high risk)
Source-available: Review required
5.3 Distributed Software (Apps, On-Prem, Containers).Permissive: Allowed with notices
Weak copyleft: Allowed only with defined compliance steps
Strong copyleft: Restricted; Legal approval required
Network copyleft: Restricted; Legal approval required
Source-available: Restricted; Legal approval required
5.4 Embedded/Device Distribution. Consider additional obligations (installation information, written offers) depending on license; Legal review required for copyleft.
6. Required Artifacts
6.1 SBOM. Maintain an SBOM for releases: ☐ Required ☐ Recommended.
6.2 Third-Party Notices. Provide required notices for distribution: ☐ Required ☐ Recommended.
6.3 Approval Records. Store approvals in: [Tool/Tracker].
6.4 Source Code Availability (If Required). If required by license, publish source at: [Location], and document the process.
7. Exceptions Process
7.1 Exception Request. Any exception to this Matrix must be requested in writing with: component details, use case, distribution model, risk summary, and mitigation plan.
7.2 Approver. Exceptions must be approved by: [Legal/OSS Committee].
7.3 Expiration. Exceptions must include an expiration date and review trigger.
8. Maintenance and Review
8.1 Owner. Matrix owner: [Team/Role].
8.2 Review Cadence. Review this Matrix: ☐ Quarterly ☐ Semiannually ☐ Annually.
8.3 Updates. Update when: new license types are used, product distribution model changes, or compliance requirements change.
Signatures
By signing below, the undersigned acknowledge and adopt this License Compatibility Matrix as internal guidance for OSS license decisions.
Company Representative: [Name]
Title: [Title]
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
License Compatibility Matrix 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.
LICENSE COMPATIBILITY MATRIX TEMPLATE FAQ
What is a license compatibility matrix?
A license compatibility matrix is an internal reference that helps teams understand whether different open source licenses can be combined in a single product or codebase. It supports consistent decisions by summarizing common compatibility outcomes and defining who must approve higher-risk licenses.
Why do companies use a compatibility matrix?
It reduces accidental license conflicts (for example, mixing copyleft and proprietary distribution in the wrong way), speeds up approvals, and creates a repeatable process for engineering teams. It’s also useful for audits and vendor questionnaires because it shows you have a defined approach to OSS licensing.
What should a license compatibility matrix include?
It should list license categories (permissive, weak copyleft, strong copyleft, network copyleft, “source available”), define typical usage scenarios (internal use, SaaS, distribution), note common obligations (notice, source availability, license text), and state clear approval requirements and escalation paths.
Is a license compatibility matrix legal advice?
No. License compatibility can depend on how software is combined (linking, static vs. dynamic, distribution model) and on specific license versions and exceptions. A matrix should be treated as internal guidance and paired with a review process for edge cases.
How do you keep a matrix accurate over time?
Assign an owner, set a review cadence, and update it when your product distribution model changes, when you adopt new license types, or when customers require different disclosure standards. Many teams link the matrix to the OSS approval workflow and SBOM generation.
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