A License Is a Permission, Not a Quality Label

On 16 October 2026, GitHub's changelog announced that open source license compliance is generally available for GitHub Enterprise Cloud customers, including data-resident GHEC, on repositories with GitHub Code Security enabled. GitHub says the feature "expands on the capabilities of the dependency review action by introducing an enterprise-wide license policy". Repositories are targeted with a ruleset that uses a new Require license compliance results before merging condition, and pull requests that add or change dependencies are checked against the policy.

When a new or changed dependency has a license the policy does not allow, the pull request is annotated. GitHub says those annotations "must be addressed by removing or replacing the dependency, amending the license policy, or creating package exceptions". A new predefined role, Enterprise Open-Source License Manager, is for the people who review and approve those requests. GitHub also lists a new API endpoint for checking whether a package complies with the policy, which it says "enables coding agents to avoid recommending or incorporating packages which violate an organization's license usage policy".

None of that is free, and none of it is aimed at someone with a home server. The interesting part for self-hosters is the shift underneath: a dependency's license has become something a machine checks before a merge. You can run your own version of that check on a single box, for free, this afternoon.

Why you should check open source licenses before you ship

A license tells you what you are allowed to do with someone else's code. It says nothing about whether the code is good, maintained or safe. A license is a permission, not a quality label.

Most licenses fall into a few families. In plain terms:

Permissive (MIT, Apache-2.0, BSD). Use, change and ship the code, even inside closed software. Keep the copyright and license notice.
Copyleft (GPL, LGPL). If you distribute the software, including a modified version, the people who receive it are entitled to the source under the same terms. The LGPL is a lighter variant written for libraries.
Network copyleft (AGPL). The same idea, but letting people use your modified version over a network also counts. More on this below.
Source-available (Business Source License, SSPL, many "open weights" model licenses). You can read the source or download the weights, but the license attaches conditions, often about commercial use or competing services.

"Open source" has a published definition, maintained by the Open Source Initiative, and a license either meets it or does not. "Source available" is a different and weaker claim: you can see the code, but you may not be free to use it the way you planned. I made the same argument about AI models in why "open weights" is not "open source", and about devices in why "open" has to be defined, not assumed.

The AGPL network clause, the one that actually bites self-hosters

The GNU Affero General Public License version 3 adds a section the ordinary GPL does not have. Section 13, "Remote Network Interaction", says that if you modify the program, your modified version:

"must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version"

It applies to modified versions that other people use over a network. That is what the license text says. It is a license condition, not a legal opinion, and this article is not legal advice. If a client contract depends on the answer, ask a lawyer.

Here is how that looks on a real box. Nextcloud (nextcloud/server) is licensed AGPL-3.0, and so is Grafana (grafana/grafana). If you run an unmodified Nextcloud for yourself, section 13 has nothing to ask of you, because you did not modify it.

Now change the shape. You fork the same code, patch a few files to suit a client, and offer it as a hosted service to their staff or to paying customers. Those people interact with your modified version over a network, so offering them the Corresponding Source of your version is now a license condition you have to meet.

Jitsi Meet (jitsi/jitsi-meet) sits on the other side of the line. It is Apache-2.0, a permissive license with no network clause. I run both Nextcloud and Jitsi Meet on my own hardware, and they can sit on the same server: two containers, one compose file, and two very different sets of obligations once you start changing code and handing the service to other people.

How to check licenses in your own project this afternoon

You do not need an enterprise plan to get a license inventory. Each ecosystem has a free tool that reports the licenses of what you have installed. I am not claiming any of them is complete or accurate, and the commands below only show the basic shape, so check each project's documentation for current options.

Python: pip-licenses dumps the license list of the packages installed in an environment. Run it inside your app's virtual environment.
JavaScript and Node: license-checker walks an npm dependency tree and reports the licenses it finds.
Rust: cargo-deny has a licenses check for a Cargo project, next to its advisory checks. You list the licenses you allow in its config file, and the check fails on anything else.
Containers, repositories and any stack: Syft generates a Software Bill of Materials (SBOM) and records the licenses it detects alongside each package. Trivy can scan for package licenses as well as vulnerabilities.
Whole codebases: ScanCode Toolkit, from aboutcode-org, detects licenses across a codebase. The OSS Review Toolkit (ORT) describes itself as "a suite of tools to automate software compliance checks".
No install at all: GitHub's dependency review action is available for public repositories on GitHub.com, and for organization-owned repositories on GitHub Team with GitHub Code Security enabled. GitHub's documentation says it "provides information on license, dependents, and age of dependencies".

pip-licenses
npx license-checker
cargo deny check licenses
syft <image> -o spdx-json
trivy image --scanners license <image>

The tool is the easy part. The habit is what makes it useful:

Generate the list. Save the output next to the code, for the exact version you are about to deploy.
Check it against a written policy. Keep three short lists in a text file: licenses you allow, licenses you reject for this project, and licenses you accept case by case after reading them. I put AGPL and anything source-available in that third list.
Record the decision. When you accept something case by case, write down the package, the version, the license, the date and the reason. Next year you will not remember.

Be clear about what these tools cannot see. They read package metadata and license files. They do not know how your code uses a dependency, whether you modified it, or whether you offer it to other people over a network, which is exactly what section 13 turns on. They cannot tell you whether your use is lawful. A scan reflects the day you ran it, not the license change a transitive dependency made last Tuesday. I wrote about the same blind spot for security in bugs no scanner can see.

The license can change between two pulls

The people who own a project can change the license of future versions, and well-known projects have.

HashiCorp announced on 10 August 2023 that it "adopts Business Source License". Redis had earlier added license options that are not open source, and then Redis said on 1 May 2025 that Redis is "now available under the AGPLv3 open source license". After that history, the GitHub license metadata for redis/redis no longer reports a standard SPDX license. The same is true of hashicorp/terraform. A machine reading either repository today cannot give you a one-word answer.

A dependency's license can change between two docker compose pull runs, and nothing in your terminal will warn you. That is why the policy belongs in a file you version, next to your compose file, instead of in someone's memory.

Pin versions. Use a specific image tag or digest instead of latest, so a license change arrives when you choose to upgrade, not by surprise.
Read the license of anything you plan to offer as a service. Do it before a client depends on it, and again at each major upgrade.
Keep the note. Record which licenses you accepted, for which versions, and why.

GitHub's changelog says policy changes in its enterprise feature now emit audit log events. Take away the console and the shape is one you can build yourself: a written policy, a check before merge, and a record of every exception.

Start with one list

You do not need to become a license expert. Pick one project, generate its license list, write a ten-line policy file and commit it. The next time a license question comes up, you will have a written answer instead of a guess.

If you would rather have someone set up dependency scanning, patching and the record-keeping habit on your own servers, that is the kind of work I do for clients. The details are on the services page. Fiverr: hiteshsaini459 · Upwork: hiteshsaini25