Open-Source License Review Checklist

1. Purpose

The Open-Source License Review Checklist provides a structured process for identifying, reviewing, approving, monitoring, and documenting the licensing requirements of open-source software used by the organization.

The checklist helps determine whether an open-source component:

Has a valid and identifiable license
Can be used for the intended purpose
Has applicable attribution or notice requirements
Creates source-code disclosure or distribution obligations
Can be included in a commercial product
Creates customer or contractual restrictions
Has security or dependency risks
Requires legal or compliance review
Is appropriately documented
Can continue to be used under the organization’s approved risk position

Core Principle

Identify → Verify → Understand License → Assess Obligations → Assess Security → Approve → Record → Monitor → Review

2. When to Use

Perform an open-source license review when:

A new open-source component is introduced
A dependency is materially upgraded
A new application is developed
An open-source package is added to production
A customer-facing product includes open-source software
An open-source component is redistributed
A license changes
A dependency is acquired by another organization
A new project uses an existing open-source component
A customer contract introduces additional requirements
A security or legal concern is identified

The depth of review should be proportionate to the component’s use, license, distribution model, security risk, and business impact.

3. Review Information

Field	Details
Review ID
Component Name
Version
Application/Product
Repository
Package Manager
Review Date
Reviewer
Technical Owner
Business Owner
Legal/Compliance Reviewer
Review Status
Risk Rating

Review Status

☐ Approved
☐ Approved with Conditions
☐ Further Review Required
☐ Remediation Required
☐ Not Approved
☐ Retire/Replace

4. Component Identification

Record the exact component being reviewed.

Field	Details
Component Name
Version
Package Name
Package Ecosystem
Repository URL
Source Repository
Distribution Source
Maintainer/Organization
Release Date
Application Using Component
Direct Dependency	☐ Yes ☐ No
Transitive Dependency	☐ Yes ☐ No

Examples of ecosystems include:

npm
PyPI
Maven
NuGet
RubyGems
Go modules
Cargo
Composer
Docker/container registries
OS package repositories

5. Source Verification

Verify that the component and source are correctly identified.

☐ Official project/repository identified
☐ Package name verified
☐ Version verified
☐ Source repository verified
☐ Package source verified
☐ Maintainer identified
☐ Release version verified
☐ Repository activity reviewed where relevant
☐ Component authenticity considered
☐ Known package impersonation/typosquatting risk considered

Evidence

6. License Identification

Identify the license that applies to the exact version being used.

☐ License file located
☐ License identified
☐ License version identified
☐ SPDX identifier identified where available
☐ Copyright notice identified
☐ Multiple licenses identified where applicable
☐ License information matches package metadata
☐ License information matches repository
☐ License ambiguity identified

License

License Name: __________________________

License Version: ________________________

SPDX Identifier: _________________________

Evidence Location: ______________________

7. License Source Verification

Do not rely solely on a third-party website or package summary when the original license can be reviewed.

Verify using appropriate sources such as:

☐ Upstream repository
☐ Official project documentation
☐ Package metadata
☐ LICENSE/COPYING file
☐ Release documentation
☐ Maintainer statement
☐ Organization-approved license database

Verification Result

☐ Verified
☐ Partially Verified
☐ Unable to Verify

Notes

8. License Type Classification

Classify the license for review purposes.

☐ Permissive
☐ Weak Copyleft
☐ Strong Copyleft
☐ Network/Service Copyleft
☐ Public Domain/Equivalent
☐ Source-available
☐ Custom License
☐ Dual License
☐ Multiple Licenses
☐ Unknown

Important

The label alone should not determine approval. The actual license terms and the organization’s intended use must be reviewed.

9. Intended Use

Document exactly how the component will be used.

☐ Internal development
☐ Internal tool
☐ SaaS backend
☐ SaaS frontend
☐ Customer-facing application
☐ Embedded software
☐ Mobile application
☐ Desktop application
☐ Commercial product
☐ Internal infrastructure
☐ Development-only dependency
☐ Test-only dependency
☐ Build dependency
☐ Runtime dependency
☐ Distributed to customers
☐ Distributed to suppliers/partners

Intended Use Description

10. Distribution Assessment

Determine whether the organization distributes the component or a product containing it.

☐ No distribution
☐ Internal distribution
☐ Customer distribution
☐ Binary distribution
☐ Source-code distribution
☐ Container distribution
☐ SDK/library distribution
☐ Mobile application distribution
☐ On-premise software distribution
☐ SaaS/service delivery

Distribution Model

This assessment is important because some license obligations depend on how software is distributed, modified, combined, or provided as a service.

11. Modification Assessment

Determine whether the organization modifies the component.

☐ No modifications
☐ Configuration only
☐ Minor modifications
☐ Source-code modifications
☐ Significant modifications
☐ Forked project

If Modified

Record:

What was changed?
Why was it changed?
Is the modified version distributed?
Does the license impose obligations concerning modifications?
Are required notices or source-code obligations understood?

Evidence

12. License Obligation Assessment

Assess applicable obligations.

Obligation	Applicable?	Requirement	Action	Evidence
Copyright notice	☐ Yes ☐ No
License notice	☐ Yes ☐ No
Attribution	☐ Yes ☐ No
NOTICE file	☐ Yes ☐ No
Source availability	☐ Yes ☐ No
Source-code disclosure	☐ Yes ☐ No
Modification notice	☐ Yes ☐ No
Redistribution terms	☐ Yes ☐ No
Patent provisions	☐ Yes ☐ No
Trademark restrictions	☐ Yes ☐ No
Documentation requirement	☐ Yes ☐ No
Additional terms	☐ Yes ☐ No

13. Attribution and Notice Requirements

Determine whether the organization must provide notices.

☐ Copyright notice required
☐ License text required
☐ Attribution required
☐ NOTICE file required
☐ Third-party notices required
☐ Documentation update required
☐ Product UI notice required
☐ Distribution package notice required

Implementation Location

Examples:

Product documentation
Third-party notices page
About screen
License file
Distribution package
Customer documentation

14. Source-Code Obligations

Where applicable, determine whether the license creates source-code-related obligations.

☐ No source-code obligation identified
☐ Source code must be provided
☐ Corresponding source requirement identified
☐ Modified source requirement identified
☐ License information must accompany distribution
☐ Written offer or equivalent mechanism required
☐ Obligation depends on distribution model
☐ Legal review required

Assessment

Do not assume that all open-source licenses require source-code disclosure. The obligation depends on the specific license and use/distribution model.

15. Copyleft Assessment

If the component uses a copyleft or similar license:

☐ License identified
☐ Use model documented
☐ Linking/integration model assessed
☐ Modification assessed
☐ Distribution assessed
☐ Combined work assessed
☐ Customer distribution assessed
☐ SaaS/service model assessed where relevant
☐ Source-code obligations assessed
☐ Legal review completed where required

Assessment

16. Commercial Use

Determine whether commercial use is permitted.

☐ Commercial use permitted
☐ Commercial use restricted
☐ Commercial use subject to conditions
☐ Commercial use unclear
☐ Legal review required

Business Impact

17. Customer Contract Impact

Determine whether use of the component could affect customer commitments.

☐ No customer impact
☐ Customer contract reviewed
☐ Customer distribution involved
☐ Customer-specific license requirement
☐ Source-code commitment possible
☐ Security requirement affected
☐ Procurement requirement affected
☐ Legal review required

Customer Impact Assessment

18. SaaS Assessment

For SaaS applications, assess whether the component is:

☐ Used only internally
☐ Used in backend
☐ Used in frontend
☐ Included in container image
☐ Distributed to customers
☐ Exposed through an API
☐ Modified
☐ Used as part of a hosted service

SaaS License Assessment

Do not assume that “we do not distribute software because we are SaaS” automatically eliminates all license obligations. The actual license and service model must be considered.

19. Dependency Assessment

Identify dependencies associated with the component.

☐ Direct dependencies identified
☐ Transitive dependencies identified where practical
☐ Dependency tree available
☐ License information available
☐ Conflicting licenses identified
☐ Unknown licenses identified

Dependency Evidence

20. License Compatibility

Where multiple open-source components are combined, assess potential license compatibility.

Component	License	Combined With	Compatibility Concern	Resolution

Review

☐ No compatibility issue identified
☐ Compatibility requires assessment
☐ Potential conflict identified
☐ Legal review required
☐ Remediation required

21. Security Review

License approval does not mean security approval.

Assess:

☐ Known vulnerabilities checked
☐ Security advisories reviewed
☐ Supported version confirmed
☐ Maintainer activity considered
☐ Security update process understood
☐ Dependency scanning performed
☐ Malicious package risk considered
☐ Package integrity considered
☐ Criticality assessed

Security Findings

22. Maintenance and Support

Assess the health of the project.

☐ Actively maintained
☐ Security updates available
☐ Recent releases
☐ Active maintainers
☐ Community support
☐ Security reporting mechanism
☐ Project appears inactive
☐ Project archived
☐ Support concerns identified

Maintenance Assessment

An inactive project may create security and operational risk even where its license is acceptable.

23. Software Supply Chain Assessment

Where relevant:

☐ Source repository verified
☐ Package origin verified
☐ Dependency provenance considered
☐ Package integrity verified
☐ Release integrity considered
☐ Lock files used
☐ Dependency versions controlled
☐ Package manager controls implemented
☐ SBOM available
☐ Dependency monitoring enabled

24. License Evidence

Collect appropriate evidence.

☐ LICENSE file
☐ Copyright notice
☐ Package metadata
☐ Repository record
☐ Version information
☐ SBOM
☐ Dependency report
☐ License scan
☐ Product notice
☐ Legal review
☐ Approval record

Evidence Location

Do not retain unnecessary copies of sensitive information as license evidence.

25. License Scanning

Where automated tooling is available:

☐ License scanning performed
☐ Tool identified
☐ Scan date recorded
☐ Component version identified
☐ License detected
☐ Unknown licenses identified
☐ Conflicts identified
☐ Results reviewed by responsible person

Tool

Tool: __________________

Scan Date: __________________

Report: __________________

26. Manual Review

Automated scanners should not automatically be treated as the final legal determination.

Where necessary:

☐ License text manually reviewed
☐ Intended use reviewed
☐ Distribution model reviewed
☐ Modifications reviewed
☐ Contractual impact reviewed
☐ Security impact reviewed
☐ Legal/compliance review completed

Manual Review Result

27. Approval Criteria

Before approval, confirm:

☐ Component identified
☐ Version identified
☐ License verified
☐ Intended use documented
☐ Distribution model understood
☐ Modification status understood
☐ Obligations identified
☐ Attribution requirements identified
☐ Source-code obligations assessed
☐ Compatibility assessed where required
☐ Customer impact assessed
☐ Security review completed
☐ Evidence retained
☐ Owner assigned

28. Review Decision

Decision

☐ Approved
☐ Approved with Conditions
☐ Further Information Required
☐ Legal Review Required
☐ Remediation Required
☐ Replace Component
☐ Not Approved

Conditions

Restrictions

29. Risk Assessment

Risk	Likelihood	Impact	Risk Rating	Treatment
License uncertainty
License conflict
Source-code obligation
Customer impact
Security vulnerability
Unsupported component
Supply-chain risk

30. Exception Management

If the organization uses a component despite an identified license concern:

Exception ID	Component	Issue	Business Reason	Risk	Compensating Control	Approver	Expiry

Exceptions should be:

Documented
Risk assessed
Approved
Time limited where practical
Periodically reviewed

31. Review Triggers

Repeat the license review when:

☐ Component version changes
☐ License changes
☐ Project changes license
☐ Component is forked
☐ Component is modified
☐ Distribution model changes
☐ Product becomes commercial
☐ Customer requirements change
☐ Component becomes critical
☐ New dependency introduced
☐ Major dependency changes
☐ Security vulnerability identified
☐ Project ownership changes
☐ Component becomes unsupported
☐ Legal concern identified

Trigger Principle

Change → Reassess License → Reassess Security → Update Register → Approve

32. Open-Source Register Update

After completing the review:

☐ Open-Source Software Register updated
☐ Software License Register updated
☐ SBOM updated where applicable
☐ License obligations recorded
☐ Owner recorded
☐ Approval recorded
☐ Evidence linked
☐ Review date established

33. AWS SaaS Startup Example

A SaaS startup is developing a customer-facing application hosted on AWS.

The engineering team wants to introduce an open-source framework.

Component

Component: Application Framework
Version: 5.x
Application: Production SaaS
Use: Backend application
Source: Official project repository
Distribution: Hosted SaaS
Modification: Minor internal modifications

Review

License: Verified from the project’s official license information.

Intended Use: Commercial SaaS.

Distribution: Customer receives the service rather than the underlying framework directly.

Security: Current supported version; dependency scanning enabled.

Attribution: Requirements assessed and documented.

Source-Code Obligations: Assessed based on the applicable license and actual use.

Customer Impact: No unsupported contractual commitment identified.

Decision: Approved, subject to maintaining the approved version and monitoring license/security changes.

Evidence

Repository reference
License file
Version
License scan
Dependency record
SBOM
Security scan
Review record
Approval

34. Startup-Friendly Review Model

For a startup, every developer does not need to perform a lengthy legal assessment for every package.

Use a risk-based model.

Low-Risk Component

Basic review:

Component
Version
License
Intended use
Security status
Register entry

Medium-Risk Component

Add:

Distribution assessment
Modification assessment
License obligations
Dependency review
Security review
Evidence

High-Risk Component

Add:

Detailed license analysis
Compatibility assessment
Customer impact
Source-code obligations
Commercial-use assessment
SBOM
Legal/compliance review
Formal approval

Examples of higher-risk situations include:

Copyleft software
Customer-distributed software
Modified open-source software
Core product components
Components with unclear licensing
Custom licenses
Multiple conflicting licenses

35. Common Mistakes

Avoid:

Assuming “open source” means “no restrictions.”
Checking only the package name without checking the exact version.
Relying entirely on automated license scanners.
Ignoring transitive dependencies.
Ignoring license compatibility.
Ignoring customer distribution.
Ignoring modifications.
Ignoring AI-generated or AI-assisted code dependencies.
Treating license compliance as security compliance.
Using abandoned software without assessing security risk.
Failing to preserve license evidence.
Failing to update reviews after dependency changes.
Treating every license as if it creates the same obligations.

36. Relationship With Other ISMS Documents

Document	Relationship
Open-Source Software Register	Records approved components
Software License Register	Records broader software licensing
Intellectual Property Register	Records IP ownership
Open-Source Software Policy	Defines organizational requirements
Software License Compliance Procedure	Defines license management
SBOM	Provides component-level inventory
Vulnerability Management Procedure	Manages security vulnerabilities
Secure Development Policy	Controls software development
Change Management Procedure	Controls dependency changes
Supplier Security Assessment	Assesses external software providers
Customer Contract Security Review	Identifies customer-specific obligations
Risk Register	Tracks significant risks

37. ISO/IEC 27001 Connection

Open-source license management can support the organization’s risk-based management of:

Intellectual property
Software assets
Secure development
Technology supply chain
Vulnerability management
Change management
Supplier relationships
Information protection
Legal and contractual requirements

The Open-Source License Review Checklist is not itself a universally mandatory ISO/IEC 27001 document.

The organization should determine the appropriate process based on:

Information-security risk
Software development practices
Licensing requirements
Customer commitments
Contractual requirements
Legal requirements
Product distribution model
Technology supply-chain risk

Relevant controls should be addressed through the organization’s risk assessment and applicable Statement of Applicability.

38. Audit Evidence

Examples of evidence include:

Completed review checklist
Open-Source Software Register
Software License Register
LICENSE file
Repository reference
Package metadata
SBOM
Dependency report
License scan
Manual license review
Compatibility assessment
Security scan
Vulnerability assessment
Customer impact assessment
Legal review
Approval record
Exception record
Corrective action record
Updated product notices
Updated third-party notices

39. Final Audit Trail

For every significant open-source component, the organization should be able to demonstrate:

What component are we using?
Which exact version are we using?
Where did it come from?
What license applies to that version?
Have we verified the license?
How are we using the component?
Are we modifying it?
Are we distributing it?
What obligations apply?
Are attribution or notice requirements applicable?
Are source-code obligations applicable?
Are there compatibility concerns?
What security risks exist?
Who approved its use?
What evidence supports the decision?
When should the review be repeated?

40. Final Principle

Identify the Component → Verify the Exact Version → Verify the License → Understand the Intended Use → Assess Distribution & Modification → Identify Obligations → Assess Compatibility → Assess Security → Approve → Record → Monitor → Reassess

Open-source review should not be treated as a one-time checkbox. A component can change through new versions, license changes, ownership changes, new dependencies, security vulnerabilities, product distribution changes, or customer requirements.

The objective is to maintain a defensible connection between the software component, its license, its actual use, its obligations, its security risk, and the organization’s approval decision.