This article explains how to block a merge when a dependency uses a non-compliant open-source license. After reading it, you can turn on the license gate and Block merge when the gate fails under repository Settings → Security, select License compliance on the AngusSecurity policy, and see where to fill Allowed licenses and Denied licenses.
The security overview of repository xlliu/e2e-license-gate currently says “License gate did not pass. Merge rejected”. The Licenses page has two open findings. The high one, GPL-3.0-only, is Strong copyleft: when you distribute the software, the related code has to be published under the same license. The low one, MIT, is Permissive: it mainly requires you to keep the copyright notice.
A gate is a rule that refuses the merge when its condition is met.
Sign in to AngusGit, then open repository xlliu/e2e-license-gate. Open your own repository from the repository list after you sign in. Security scanning is available on Team, Enterprise, and Cloud Service. Community has no Security menu. Turn scanning on before you start: a system admin opens Management → Security settings. The page title is AngusSecurity integration. Config enabled is On, and Platform reachable is OK. If it is not provisioned yet, click Provision. When the page asks for angus.git.external-security.enabled=true, set the environment variable ANGUS_GIT_EXTERNAL_SECURITY_ENABLED to true and restart AngusGit. A repository admin then opens that repository’s Settings → Security, turns on Auto security scanning for this repo and License compliance, and saves. The success message is “Security settings saved”. When you compare the screens in this article, read the settings already saved on the repository. You do not need to click Save, Scan now, or Run now.
1. How “incompatible” is decided
The license gate in AngusGit repository settings has three choices. Block when incompatible and Also block when undetermined can block a merge. Disabled does not block on licenses.
After you select License compliance on the AngusSecurity policy, Allowed licenses, Denied licenses, and Distribution appear. The order is:
- Denied licenses: a dependency license on the denied list is non-compliant.
- Allowed licenses: when the allowed list is not empty, every license outside it is non-compliant.
- Distribution: when the first two do not match, the decision follows how the software is delivered. The form says: “GPL is compatible for internal use and SaaS, and incompatible when you distribute a binary or a container image. AGPL is incompatible except for internal use.”
When distribution is left empty, the check uses Distribute a binary. Under that default, strong copyleft (GPL) counts as incompatible, and a permissive license (for example MIT) counts as compatible. Undetermined means the scan did not recognize a license. With Also block when undetermined, that kind of dependency blocks the merge too.
2. Open license compliance before the lists appear
Scans that AngusGit sends use the AngusSecurity policy [System] GIT Inbound by default. The policy detail id is 378599664200187905.
![Policy [System] GIT Inbound: Fail on is High, and the capabilities are Code security, Secret scanning, and Dependency / artifact vulns](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fwmmk0ebazc3ld7qcy6nw.png)
The detail page shows:
- Title
[System] GIT Inbound, badge Enabled, descriptionAuto-created for GIT inbound scans. - Fail on is High. The note says “Fails on high or critical findings”.
- Capabilities are Code security, Secret scanning, and Dependency / artifact vulns. License compliance is not among them.
- The summary on the right: default is No. Created 2026/08/03 12:02:29.
On the edit page, License compliance is a checkbox. Its note is “Dependency license compliance”. Until it is selected, Allowed licenses, Denied licenses, and Distribution stay hidden. This policy does not have License compliance selected. After you select it, the lists and distribution appear. The ids in the form are placeholder examples. They are not values this policy has saved.
- Open the policy
In the AngusSecurity sidebar, open Policy. The list says: “Configure scan gate policies and default thresholds.” Open [System] GIT Inbound and click Edit policy.
- Select License compliance
Under Capabilities, select License compliance. Before you save, confirm the company allows license conclusions to be written into this shared policy.
- Choose distribution
Distribution appears only after that checkbox is on: Internal use only, SaaS, Distribute a binary, and Distribute a container image. When the product is delivered as an installer or a container image, choose one of the last two. Leave it unset and the check uses binary distribution.
- Fill the lists when you need them
Allowed licenses and Denied licenses take SPDX ids, separated by commas. The form placeholders are MIT, Apache-2.0, BSD-3-Clause and AGPL-3.0, SSPL-1.0. The same license cannot be on both lists. Once the allowed list is not empty, every license outside it is non-compliant.
- Save
After you save, the change applies to later checks. A status check already written on a pull request is not recalculated on its own.
A license the built-in catalog does not include can be added on the Custom licenses tab of the Policy page. The id is an SPDX id or LicenseRef-*. When the built-in catalog already recognizes GPL, you do not need to open that tab first.
3. Turn the check and the gate on in AngusGit
The repository’s own switches are under Settings → Security, at ?tab=settings§ion=security. The form on xlliu/e2e-license-gate is:
The switches visible in the screenshot:
- Code security, Secret scanning, and License compliance are on. Dependency and artifact vulnerabilities and Code quality are off.
- Block merge when the gate fails is on.
- Vulnerability gate is High. License gate is Block when incompatible.
The capability marks at the top of the detail page light up only Secret scanning and License compliance, while the Code security switch on the settings page is on. The two places read different fields. Compare the page as it is. You do not need to save immediately to make the two displays match.
The note on License compliance is: “Identify dependency licenses. The merge gate uses this only when it is turned on.” If a license gate is set and this check is off, the page says: “The license gate is on but License compliance is not checked. With Block merge on, PRs cannot merge because there is no license result.”
If you set the license gate and leave Block merge when the gate fails off, the result is recorded and the merge is not blocked. When the license gate is Disabled, the lists on the policy are used only to show risk.
4. What this repository shows now
The security page is https://git.anguskit.com/security/repos/xlliu/e2e-license-gate. The overview score is 95. Critical, high, medium, low, info, secrets, and quality are all 0. License risk is 1. The default branch shows main@d3ebc5a.
The red line is “Gate advice: Fail”. The line under it is “License gate did not pass. Merge rejected”. When open findings are already there, read those findings first. You do not need to click Scan now right away.
On the Licenses tab, disposition Open, there are 2 findings:
| Level | Title | Category | Location |
|---|---|---|---|
| High | GPL-3.0-only in e2e-with-gpl |
Strong copyleft |
package.json, component e2e-with-gpl@1.0.0
|
| Low | MIT in e2e-with-gpl |
Permissive | LICENSE |
The high finding’s branch is e2e-git07 @591d671. Disposition is Open. The description is Declared by project manifest. In the drawer you can click View in code or Open in Security. Leave the disposition Open when you are only reading the conclusion.
The license categories on the page also include Public domain, Weak copyleft, Network copyleft, Proprietary, Unrecognized, and Forbidden. This GPL finding shows Strong copyleft.
The status check on a pull request uses the latest scan of that commit. There are three wordings:
- The license did not pass: “License gate did not pass”.
- The vulnerability gate and the license gate are both on and both passed: “Vulnerability gate and license gate both passed for commit {8 chars}”. Merged #1 and #2 on this repository use this sentence.
{8 chars}is the first 8 characters of the commit id. - Only the vulnerability gate was recorded: “Vulnerability gate passed for commit {8 chars}”.
On the same commit d3ebc5a, an earlier push scan had a failed license gate. A later manual scan marked the license check skipped, and the gate recorded the latest scan as passed. That is why the row on #4 does not say “License gate did not pass”. The overview still says the merge is rejected, because the open GPL finding is still there and the license gate in the repository settings is still on. A check row on a pull request that is already merged is not recalculated when settings change later. To recalculate under a new threshold, scan the branch again.
After a merge is blocked, the usual fix is to switch to a dependency with a suitable license. If legal confirms it can be used, the person who manages the policy puts it on Allowed licenses, or changes Distribution, then you push a new commit. A list change affects later checks only.
5. The mistakes that are easiest to make
| What you see | Cause | What to do |
|---|---|---|
| “License gate is enabled, but this check did not include license compliance” | The license gate is on, and License compliance is off | Turn on License compliance under Settings → Security, then push once |
| Almost every pull request says “License gate did not pass” | The allowed list is not empty, and common licenses were left off it | Complete the allowed list, or use the denied list instead |
| A GPL dependency was added and was not blocked | Distribution is Internal use only or SaaS. Under those two, strong copyleft counts as compatible by default | Choose distribution for the way you actually deliver, or add that GPL id to Denied licenses |
| The policy detail does not show the allowed list | License compliance is not selected, so the lists do not appear | Edit the policy and select License compliance. Before you select it, confirm this policy is shared by the repositories |
| You changed a list, and a merged pull request’s conclusion stayed the same | The new rule applies to later checks. Status checks use the latest scan | Push a new commit, or scan the source branch again |
| The overview says the merge is rejected, and the pull request is Success | The open finding is still there, and the latest scan of that commit marked the license check skipped | Read the push scan and the manual scan of the same commit in scan history. Do not read only the one row on the pull request |
Common questions
Do the license gate and the vulnerability gate have to be configured separately?
They are judged separately. Both sit under Merge gate, and Block merge when the gate fails decides whether they block. After block-merge is on, the vulnerability gate always takes part. Its threshold has no Disabled. This repository’s vulnerability threshold is High, and the counts from critical through low are all 0. If you mainly want to govern licenses, set the vulnerability threshold to Critical.
How is this different from code traceability?
The license check reads the license a dependency declares. Code traceability checks whether this code looks like code in another repository. They are separate jobs.
Can each repository have a different list?
Allowed licenses, Denied licenses, and Distribution live on the AngusSecurity policy. When scans that AngusGit sends share [System] GIT Inbound, the lists are the same for repositories that use that policy. Each repository can turn License compliance on, choose Block when incompatible or Also block when undetermined, and decide whether to block the merge. This repository turned the license gate on itself. The system policy’s capability set does not include license compliance yet.
Summary
Repository settings on xlliu/e2e-license-gate already have License compliance on, the license gate set to Block when incompatible, and Block merge when the gate fails on. The open GPL-3.0-only finding is strong copyleft. When distribution is empty, the check uses binary distribution, and this license counts as incompatible. The overview therefore says “License gate did not pass. Merge rejected”.
Policy [System] GIT Inbound currently has capabilities Code security, Secret scanning, and Dependency / artifact vulns, and Fail on is high. Allowed licenses and Denied licenses appear only after License compliance is selected. This policy has not selected it, and it has not saved any lists. The status check on merged #4 is “Vulnerability gate passed for commit d3ebc5ab”, because it uses the later scan that skipped the license check.
Security scanning is available on Team, Enterprise, and Cloud Service. Community does not have this gate.
Conclusion: With License compliance, Block when incompatible, and Block merge when the gate fails all on in repository settings, a non-compliant license is recorded on the security overview and the overview advises refusing the merge. Allowed licenses and distribution live on the AngusSecurity policy. Select License compliance before you fill them. After you save, they apply only to later scans.
Top comments (0)