Updated Oct 16

Share this article

Related News

GitHub puts shared Copilot Automations under repository ownership

Oct 29, 2026

GitHub puts shared Copilot Automations under repository ownership

Shared Copilot Automations use repository access, owner billing and Copilot attribution. The October 28 rollout leaves teams with a workflow-maintenance decision.

GitHubCopilotDeveloper tools

Linear adds Slack and GitHub triggers, shared templates and reasoning settings to Loops

Oct 26, 2026

Linear adds Slack and GitHub triggers, shared templates and reasoning settings to Loops

Linear’s October 22 release lets Slack and GitHub events start Loops, adds workspace templates and exposes reasoning settings. The notice leaves plan access, full event filters and connection permissions unspecified.

LinearAI agentsSlack

LiteLLM 1.107.0 compromise puts AI gateway credentials at risk

Oct 21, 2026

LiteLLM 1.107.0 compromise puts AI gateway credentials at risk

Security researchers found credential-stealing startup files in LiteLLM 1.107.0 wheels and affected container images. Teams need to inspect the exact deployed artifact, isolate exposed environments and rebuild from trusted material rather than assuming a clean source tag or package removal has repaired a running system.

LiteLLMAI gatewaysupply chain security

GitHub’s license compliance can now block dependency merges — start in Evaluate mode — Source: GitHub / official license-compliance product imageSource image

Supply Chain Security

GitHub’s license compliance can now block dependency merges — start in Evaluate mode

By OpenTools TeamOctober 16, 2026

GitHub’s enterprise license controls are generally available. Active rulesets can block pull requests, while Evaluate mode lets teams measure policy impact before enforcement.

The general release is limited to Enterprise Cloud repositories with Code Security

GitHub made open source license compliance generally available on October 16, 2026. The feature applies to GitHub Enterprise Cloud, including data-resident Enterprise Cloud, but a repository needs GitHub Code Security enabled before policy can be enforced.

That scope matters. This is not a new universal block on open source packages, and GitHub is not declaring any particular license acceptable for every company. An enterprise defines its own allow policy, then targets repositories through rulesets. The control evaluates new or changed dependencies in pull requests, including transitive dependencies detected in the dependency graph.

The useful change is timing: a license-policy conflict can now enter the same review path as the code change that introduced it. Teams no longer need to discover every issue later from an inventory export, but the quality of the result still depends on the enterprise policy and the dependency metadata GitHub can see.

Active mode blocks merges; Evaluate mode exposes the impact first

GitHub’s license-compliance documentation distinguishes two rollout states. An Active ruleset using Requires license compliance results before merging blocks a pull request until a violation is resolved. An Evaluate ruleset runs the check and annotates the pull request without making the license result a merge gate.

Evaluate mode is the safer first deployment for a large portfolio. It reveals which manifests, package ecosystems and transitive dependencies would trigger the proposed policy, while developers can still merge. The result is evidence for adjusting policy, fixing missing metadata and identifying teams that will need an exception workflow.

There is one interaction to test: GitHub says a branch-protection rule that requires comment resolution can make annotations actionable even when the license rule itself is only evaluating. A staging repository should therefore test the complete ruleset and branch-protection combination, not assume that the word Evaluate guarantees zero merge friction.

A failed check has three resolution paths with different governance costs

When a dependency violates policy, the developer can remove or replace the package, the enterprise can amend the policy, or an authorized reviewer can approve a package or license exception. GitHub added an Enterprise Open-Source License Manager role for the people or teams responsible for those closure requests. Pending requests appear in enterprise security views and can generate email notifications.

Those paths are not interchangeable. Replacing a dependency changes engineering work. Amending the enterprise policy changes the baseline for every targeted repository. An exception preserves the baseline but creates a local decision that needs an owner and rationale. Teams should record which path resolved each alert rather than treating every green check as the same outcome.

A practical rollout needs a service-level target for exception review and a fallback when the assigned reviewers are unavailable. Without that operating path, Active mode can convert a legal-policy signal into an unpredictable delivery queue.

Audit events and policy APIs make the control usable outside the pull request UI

The general release adds audit-log events for license-policy changes and API endpoints to download, update or replace the enterprise policy. GitHub also added an API that checks whether packages comply with policy, which it says can help coding agents avoid recommending or adding packages that an organization would reject. The dependency graph REST reference remains the broader API entry point for dependency changes, submissions and software bills of materials.

The agent use case is preventive: query policy before proposing a dependency, then show the result to the developer. It should not silently turn a policy response into legal advice or invent an exception. API callers also need to pin the API version, authenticate with the minimum permission, retain the policy revision that produced the answer and fail visibly when the policy service is unavailable.

Audit events solve a different problem. They can feed a system of record when policy changes, but an event stream does not by itself explain why a license was allowed or who accepted the downstream risk. Pair the event with the human decision record and the affected repository scope.

A bounded rollout separates policy quality from enforcement reliability

Start with a representative repository set in Evaluate mode. Include more than one package ecosystem, repositories with and without generated lockfiles, and at least one project whose dependency graph contains transitive packages. Measure unsupported or unknown licenses, false policy conflicts, review time and the number of requested exceptions before enabling a merge gate.

Then promote by repository class rather than all at once. GitHub documents a pattern that uses repository custom properties to distinguish inactive, evaluate and active groups, with enterprise policy as a common baseline and repository-specific exceptions layered on top. Preserve an emergency bypass process with named authority and audit evidence.

The release gives enterprises a native enforcement path, not proof that their license policy is legally complete. The operational win comes from testing the policy, staffing the exception queue and making both human and agent decisions traceable. Follow further GitHub platform changes on the GitHub organization page.

Image: GitHub’s official license-compliance interface showing a non-compliant dependency and its resolution timeline; cropped and resized without generative alteration or artificial upscaling.

Sources

1.github.blog (github.blog)
2.docs.github.com (docs.github.com)
3.docs.github.com (docs.github.com)

Tags

GitHubopen source licensessupply chain securitydependency governancecoding agents