Is GitHub license compliance in public preview now

Is GitHub license compliance in public preview now

Yes. GitHub says open source license compliance is in public preview, subject to change, and available for GitHub Enterprise Cloud customers with GitHub Advanced Security Code Security licenses. GitHub also documents it as a feature for enforcing dependency license policy at enterprise scope.

The part people get wrong is the name. GitHub is not talking about generic repository license metadata, and it is not talking about a check you turn on for every public repo by default. The preview feature is about open source license compliance for dependencies, with rulesets, policy checks, and closure requests for exceptions.

GitHub’s docs describe the feature as an enterprise policy layer. You define which licenses are allowed, GitHub evaluates pull requests that add or change dependencies, and noncompliant changes stay blocked until the violation is resolved or an exception is approved. That makes the feature useful for supply-chain governance, not just for showing a license badge.

Public preview is not the same as general availability. GitHub’s release-cycle docs say public preview features are documented and ready for broader distribution, but they do not have SLAs or technical support obligations. GitHub’s pre-release terms also say preview software may change or be discontinued without notice.

That matters operationally. If you plan to rely on the feature in a release gate, treat the policy as part of your review process and keep a fallback path for dependency approval. A preview feature can help you enforce standards, but it is still a moving target, so teams usually test it on a small set of repositories before they make it mandatory everywhere.

The inconvenient part is scope. GitHub documents that organizations need GitHub Code Security, and the feature is tied to enterprise accounts and rulesets. If your setup does not include those pieces, the preview status does not matter much because you cannot use the feature in the first place.

A practical way to verify access is to open one repository with dependency manifests, enable the relevant ruleset condition, and run a pull request that changes a dependency. If GitHub flags a noncompliant package, you have the feature. If the option is missing, the issue is usually licensing or organization scope, not preview status.

If you are comparing it with other preview features, GitHub keeps preview language consistent across the product. In the same docs set, GitHub explains that preview features can be public or private, and that public preview is meant for broader use but still carries less operational commitment than GA. That is the normal state of a feature that you can adopt before it is final.

If you are trying to decide whether to roll it into a compliance workflow, start with one repository, one policy, and one reviewer group. That is enough to learn whether the exception flow fits your approval process. DevConnect keeps a separate view of this kind of platform work at https://devconnectplatform.com, but the GitHub docs are the source you should use for the feature itself.

What GitHub says the feature does

GitHub says open source license compliance lets enterprises define which licenses are allowed for dependencies, then enforce that policy through rulesets. When a pull request changes package manifests, GitHub checks direct and transitive dependencies and compares the detected licenses to the policy. Violations block the merge until they are resolved or approved.

GitHub also says the feature adds an enterprise role for policy managers. That role is meant for people who review closure requests and manage exceptions. For teams with legal or platform governance steps, that is the piece that turns the preview feature from a report into an approval workflow.

What public preview means here

Public preview means the feature is documented and available for broader use, but not locked as final. GitHub’s own release-cycle docs say public preview features do not have SLAs or technical support obligations, and GitHub’s pre-release terms say the software may change, stop, or never reach a commercial version.

That is the inconvenient part for teams who want to standardize on it. A preview can be production useful, but it is still a preview, so you should not assume its behavior, scope, or admin flow will stay identical. If your compliance process depends on a specific interface or approval route, check it again before you make policy commitments around it.

What to check before you depend on it

First, confirm your enterprise has GitHub Code Security enabled, because GitHub limits the feature to organizations owned by a GitHub Enterprise account with that capability. Second, confirm your rulesets target the repositories where dependency changes are reviewed. Third, test one real dependency change so you can see the blocking and exception flow end to end.

If you only check whether the label says public preview, you miss the real question, which is whether your enterprise can actually enforce policy with it. The docs make clear that the feature is for enterprise policy control, not a standalone badge or repository setting. That distinction is where most setup mistakes happen.

FAQ

Is it available to everyone on GitHub No. GitHub documents it for organizations owned by an enterprise account with GitHub Code Security enabled, not as a universal repository feature.

Does public preview mean it is stable No. GitHub says public preview features are documented and broadly available, but they do not carry SLAs or technical support obligations, and pre-release terms allow change or discontinuation.

Does this replace repository license files No. GitHub’s license compliance feature is about policy enforcement for dependency licenses. Repository licensing information is a separate GitHub concept.

Can I use it to block noncompliant dependencies before merge Yes. GitHub says the feature evaluates pull requests and blocks noncompliant dependencies until the violation is resolved or approved through the exception flow.