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: ___________________________