OPEN SOURCE SOFTWARE COMPLIANCE POLICY

[ORGANIZATION NAME]

Policy Number: ________________
Effective Date: ________________
Last Revised: 2026-01-22
Policy Owner: ________________
Approved By: ________________

1. PURPOSE AND SCOPE

1.1 Purpose

This Open Source Software (OSS) Compliance Policy establishes the framework, procedures, and governance structure for the use, contribution to, and distribution of open source software within [Organization Name]. The policy aims to:

(a) Enable the organization to leverage the benefits of open source software while managing associated legal, security, and operational risks;

(b) Ensure compliance with open source license terms and conditions;

(c) Protect the organization's intellectual property and proprietary software;

(d) Establish clear processes for OSS approval, use, and contribution;

(e) Support the generation and maintenance of Software Bill of Materials (SBOM) in accordance with industry standards.

1.2 Scope

This policy applies to:

☐ All employees, contractors, and third parties who develop, acquire, or use software on behalf of the organization
☐ All software products, services, and internal tools developed or used by the organization
☐ All open source software used in any capacity within the organization
☐ All contributions to open source projects made in the organization's name or using organization resources
☐ All business units, subsidiaries, and affiliated entities

1.3 Definitions

"Copyleft License" - An OSS license that requires derivative works to be distributed under the same license terms (e.g., GPL, AGPL, LGPL).

"Permissive License" - An OSS license that allows broad freedom in use, modification, and redistribution with minimal requirements (e.g., MIT, Apache 2.0, BSD).

"Open Source Software (OSS)" - Software distributed under a license approved by the Open Source Initiative (OSI) or meeting the Open Source Definition.

"Proprietary Software" - Software owned by the organization or third parties that is not distributed under an open source license.

"SBOM (Software Bill of Materials)" - A formal record containing details and supply chain relationships of components used in building software.

"SPDX (Software Package Data Exchange)" - An open standard (ISO/IEC 5962:2021) for communicating software bill of materials information.

"Derivative Work" - Any modification, enhancement, translation, or work based upon existing software.

2. GOVERNANCE STRUCTURE

2.1 Open Source Review Board (OSRB)

The organization shall establish an Open Source Review Board responsible for:

☐ Setting and maintaining OSS policies and procedures
☐ Reviewing and approving OSS usage requests
☐ Evaluating new licenses for compliance risk
☐ Overseeing OSS compliance audits
☐ Resolving OSS-related disputes and escalations
☐ Approving contributions to external OSS projects

OSRB Composition:

2.2 Roles and Responsibilities

Engineering/Development Teams:
☐ Identify and document all OSS components in projects
☐ Submit OSS usage requests through the approval process
☐ Comply with approved license obligations
☐ Generate and maintain accurate SBOMs
☐ Report potential compliance issues

Legal/Compliance:
☐ Review and interpret OSS license terms
☐ Assess legal risks associated with OSS usage
☐ Advise on license compatibility
☐ Support contract negotiations involving OSS

Security:
☐ Assess security risks of OSS components
☐ Monitor for vulnerabilities in approved OSS
☐ Establish security review criteria

IT Operations:
☐ Maintain inventory of OSS in production systems
☐ Ensure OSS patches are applied timely
☐ Support OSS scanning and monitoring tools

3. LICENSE CLASSIFICATION

3.1 License Categories

All OSS licenses shall be classified into the following categories:

Category A - Approved for General Use:
These licenses have minimal restrictions and are pre-approved for most use cases.

Category B - Approved with Conditions:
These licenses require additional review and specific compliance measures.

Category C - Restricted Use:
These licenses require OSRB approval before use.

Category D - Prohibited:
These licenses are not approved for use in any context.

3.2 License Compatibility

When combining OSS components, license compatibility must be verified:

☐ Category A licenses are generally compatible with each other and proprietary code
☐ Category B licenses may have specific combination requirements
☐ Category C licenses may require the entire work to be distributed under the same license
☐ Multiple copyleft licenses may be incompatible with each other

4. APPROVAL PROCESS

4.1 Pre-Approval Requirements

Before using any OSS component, the following information must be documented:

OSS Component Request Form:

4.2 Approval Workflow

Step 1: Automated Scanning
☐ Component scanned by approved OSS scanning tool
☐ License identified and verified
☐ Known vulnerabilities checked
☐ SBOM entry generated

Step 2: License Review
☐ Category A: Auto-approved (proceed to Step 4)
☐ Category B: Engineering Lead review required
☐ Category C: OSRB review required
☐ Category D: Automatically rejected

Step 3: Risk Assessment (for Category B/C)
☐ Legal risk evaluation completed
☐ Security risk evaluation completed
☐ Business impact assessment completed
☐ Remediation plan documented (if applicable)

Step 4: Approval
☐ Approval documented in OSS registry
☐ Compliance requirements communicated to requestor
☐ SBOM updated

4.3 Expedited Review Process

For urgent business needs, an expedited review process may be requested:

☐ Requestor submits expedited review justification
☐ OSRB Chair may approve expedited review
☐ Minimum 24-hour review period
☐ Full documentation must be completed within 7 days of approval

5. COMPLIANCE REQUIREMENTS

5.1 Attribution Requirements

For all OSS with attribution requirements:

☐ Include required copyright notices in product documentation
☐ Include required license text in product distribution
☐ Maintain attribution file (NOTICES, ATTRIBUTION, or similar)
☐ Display attributions in About/Legal sections of applications (where applicable)

Attribution Template:

This product includes software developed by [Copyright Holder].
Licensed under the [License Name].
[URL to License Text]

5.2 Source Code Obligations

For OSS with source code disclosure requirements:

☐ Maintain complete source code for modified OSS components
☐ Establish written offer mechanism for source code requests (where required)
☐ Ensure source code remains available for required period (typically 3 years)
☐ Document all modifications to OSS components

5.3 Copyleft Compliance

For copyleft-licensed OSS:

☐ Identify boundaries between copyleft and proprietary code
☐ Ensure proper isolation (dynamic linking, API separation, etc.)
☐ Document compliance architecture
☐ Obtain OSRB approval before distribution

5.4 Software Bill of Materials (SBOM)

All software products shall maintain an SBOM that:

☐ Follows SPDX 3.0+ specification (ISO/IEC 5962:2021)
☐ Includes all direct and transitive dependencies
☐ Contains SPDX license identifiers for all components
☐ Is updated with each release
☐ Meets NTIA minimum elements for SBOM

SBOM Minimum Fields:

6. CONTRIBUTION TO OPEN SOURCE

6.1 Types of Contributions

Individual Contributions (on behalf of organization):
☐ Bug fixes
☐ Documentation improvements
☐ Minor enhancements
☐ Test contributions

Significant Contributions:
☐ New features
☐ Major code contributions
☐ Architecture changes

Project Releases:
☐ Releasing organization-developed software as OSS
☐ Creating new open source projects

6.2 Contribution Approval Process

For Individual Contributions:

☐ Verify contribution does not include proprietary code
☐ Verify contribution does not reveal confidential information
☐ Ensure contribution is within scope of employee's role
☐ Manager approval required

For Significant Contributions and Project Releases:

☐ OSRB approval required
☐ Legal review of contribution agreement (CLA/DCO)
☐ Security review to prevent inadvertent disclosure
☐ Business approval for resource allocation

6.3 Contributor License Agreements

Before contributing to external projects:

☐ Review project's contribution requirements
☐ Obtain approval for Contributor License Agreement (CLA) signing
☐ Maintain record of signed CLAs
☐ Use Developer Certificate of Origin (DCO) sign-off where applicable

6.4 Outbound License Selection

When releasing organization software as OSS:

☐ Select license appropriate for business objectives
☐ Ensure compatibility with included OSS components
☐ Document rationale for license selection
☐ Obtain OSRB and legal approval

7. MONITORING AND ENFORCEMENT

7.1 OSS Scanning

All software builds shall include automated OSS scanning:

☐ Integrated into CI/CD pipeline
☐ Scans performed on every build
☐ Alerts generated for policy violations
☐ Reports generated for SBOM maintenance

Approved Scanning Tools:

7.2 Compliance Audits

Periodic compliance audits shall be conducted:

☐ Annual comprehensive audit of all products
☐ Quarterly spot-checks of selected projects
☐ Audit prior to major releases
☐ Audit upon acquisition of third-party software

Audit Checklist:

☐ All OSS components identified and documented
☐ All licenses identified with SPDX identifiers
☐ Attribution requirements met
☐ Source code obligations satisfied
☐ SBOM accurate and complete
☐ No prohibited licenses in use
☐ All Category B/C usage properly approved

7.3 Vulnerability Management

For OSS security vulnerabilities:

☐ Subscribe to vulnerability notifications for all approved OSS
☐ Assess impact within 24 hours of notification
☐ Critical vulnerabilities remediated within 7 days
☐ High vulnerabilities remediated within 30 days
☐ Track remediation in security dashboard

7.4 Non-Compliance Remediation

Upon discovery of compliance violations:

☐ Immediately notify OSRB and Legal
☐ Assess scope and impact of violation
☐ Develop remediation plan
☐ Implement remediation within approved timeline
☐ Document lessons learned
☐ Update processes to prevent recurrence

8. TRAINING AND AWARENESS

8.1 Required Training

All personnel covered by this policy shall complete:

☐ Initial OSS compliance training within 30 days of hire
☐ Annual refresher training
☐ Role-specific training (for developers, legal, security)

8.2 Training Content

Training shall cover:

☐ Overview of open source licensing
☐ Organization's OSS policy and procedures
☐ How to identify and document OSS
☐ Approval process and tools
☐ Compliance requirements by license type
☐ Security considerations
☐ Contribution guidelines

9. RECORD KEEPING

9.1 Required Records

The following records shall be maintained:

☐ OSS inventory/registry
☐ Approval records and correspondence
☐ SBOM for each product/version
☐ Attribution files
☐ Source code archives (for disclosure requirements)
☐ Audit reports
☐ Training completion records
☐ Signed CLAs

9.2 Retention Period

Records shall be retained for:

☐ Active products: Duration of product lifecycle plus 5 years
☐ Discontinued products: 5 years from end-of-life
☐ Source code (for disclosure): As required by license (typically 3+ years)

10. POLICY EXCEPTIONS

10.1 Exception Process

Exceptions to this policy require:

☐ Written request with business justification
☐ Risk assessment
☐ Compensating controls identified
☐ OSRB approval
☐ Legal approval for high-risk exceptions
☐ Executive approval for Category D exceptions

10.2 Exception Documentation

All exceptions shall document:

11. POLICY REVIEW AND UPDATES

This policy shall be reviewed and updated:

☐ Annually, at minimum
☐ Upon significant changes to OSS licensing landscape
☐ Upon changes to regulatory requirements
☐ Following significant compliance incidents

12. RELATED DOCUMENTS AND RESOURCES

APPENDIX A: LICENSE QUICK REFERENCE

Permissive Licenses Summary

Copyleft Licenses Summary

APPENDIX B: SBOM EXAMPLE (SPDX FORMAT)

SPDXVersion: SPDX-3.0
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: [Product Name] SBOM
DocumentNamespace: https://[organization].com/spdxdocs/[product]/[version]
Creator: Tool: [Scanning Tool]
Creator: Organization: [Organization Name]
Created: [Date]

PackageName: [Component Name]
SPDXID: SPDXRef-Package-[Component]
PackageVersion: [Version]
PackageSupplier: Organization: [Supplier]
PackageDownloadLocation: [URL]
FilesAnalyzed: false
PackageLicenseConcluded: [SPDX License ID]
PackageLicenseDeclared: [SPDX License ID]
PackageCopyrightText: [Copyright Text]
ExternalRef: SECURITY cpe23Type [CPE]
ExternalRef: PACKAGE-MANAGER purl [Package URL]

POLICY ACKNOWLEDGMENT

I acknowledge that I have read and understand the Open Source Software Compliance Policy. I agree to comply with all requirements set forth in this policy.

Employee Name: _________________________________

Employee Signature: _____________________________

Department: ____________________________________

Date: _________________________________________

NOTICE: This policy template is provided for informational purposes only. Organizations should customize this policy based on their specific business needs, risk tolerance, and legal requirements. Consult with legal counsel before implementing this policy.