Nota:
Open source license compliance is in versión preliminar pública and subject to change.
Overview
Open source license compliance helps you track dependency licenses and enforce policy for the open source software in your supply chain. You can use license compliance to reduce legal and operational risk, catching nonconforming dependencies before changes are merged.
How license policy works
You can define an enterprise policy that controls which licenses your dependencies are allowed to use.
You can specify licenses from either a built-in list or, if a license is not listed, by manually adding a SPDX license identifier.
Your policy is enforced by rulesets that can be defined at the enterprise, organization, and repository scope. You can also add package or license exceptions when an Enterprise Open Source License Manager approves requests.
License evaluation uses dependency data from your repositories, including transitive dependencies detected in the dependency graph.
How pull request enforcement works
Open source license compliance is enforced through branch rulesets. When a pull request changes package manifests, GitHub compares dependency changes between the base and pull request branches, evaluates detected licenses against policy, and reports violations.
If there is a ruleset in Active mode which uses the "Requires license compliance results before merging" condition, pull requests that introduce noncompliant dependencies are blocked until violations are resolved. An Evaluate mode ruleset with that condition will run license checks and annotate the pull request, but not block merges.
Additionally, a branch protection rule that requires comment resolution before merging will track annotations from license checks, so even alerts generated by Evaluate rulesets will be subject to the protection.
Where results appear
If a dependency's license isn't in your policy, findings will appear in pull request annotations. The annotations do not automatically generate an exception request, because the developer could decide to modify their code to avoid the noncompliant dependency. If they do want to use the dependency, GitHub will prompt the developer for more information, then send the closure request to the Enterprise Open Source License Managers, who have permission to modify the policy.
For Enterprise Open Source License Managers, pending exception requests are available in enterprise security views and sent as email notifications.
Scope and governance model
You can create policy at enterprise scope for a common baseline, then layer repository-specific exceptions where needed.
For large enterprises, a common pattern is:
- Define broad policy centrally
- Assign the Enterprise Open Source License Manager role to policy reviewers
- Use a repository custom property to classify repositories as inactive, evaluate, or active
- Use rulesets that target the custom property values to control enforcement mode by repository
Developers with write access can view the effective policy and exceptions for a repository from the repository's license policy settings page.
Next steps
To get started, see Configuring open source license policies.
For more information about rulesets, see Acerca de los conjuntos de reglas.