Policy clarification: are AGPL projects rejected categorically, or is there a path forward?

[hermanekt]

Summary

internal/licenses/check.go hard-rejects any project whose GitHub license key starts with gpl, agpl, or npl. We maintain an AGPL-3.0 MCP server (initMAX/zabbix-mcp-server, 232 Zabbix API tools, admin portal, PDF reporting) that we would like to contribute to the registry, and we want to clarify the policy before either investing in the submission work or considering relicensing.

Context

The relevant code:

https://github.com/docker/mcp-registry/blob/main/internal/licenses/check.go#L31-L36

func IsValid(license *github.License) bool {
    if license != nil && (strings.HasPrefix(license.GetKey(), "gpl") || strings.HasPrefix(license.GetKey(), "agpl") || strings.HasPrefix(license.GetKey(), "npl")) {
        return false
    }
    return true
}

CONTRIBUTING.md frames this softer:

Make sure that the license of your MCP Server allows people to consume it. (MIT or Apache 2 are great, GPL is not).

The code is the source of truth, so as written today AGPL projects cannot be submitted at all. We respect the policy and are not asking for it to be changed lightly, but we would like to understand the reasoning and whether any path exists for projects in our position.

Questions

1. Is the current policy a hard "no" for AGPL specifically, or is it primarily aimed at GPL with AGPL grouped in by inheritance? AGPL-3.0 has stronger network copyleft than GPL-3.0, but in many practical respects (consumption by users, container distribution) it behaves identically. We want to make sure the policy is intentional for AGPL and not collateral.

2. Is there any exception or whitelist mechanism today (or planned) for projects that demonstrate active maintenance, security review, and a permissive contribution model? Some examples: case-by-case approval, separate community/ namespace, opt-in flag in server.yaml that puts an AGPL warning on the catalog entry.

3. Is the policy driven by Docker Inc.'s legal posture (concerns about distributing AGPL code in the mcp/* Docker Hub namespace and the resulting AGPL §13 obligations on Docker), or by end-user consumption concerns (downstream users worrying about copyleft contamination of their own code)? The right workaround is very different depending on which it is.

4. Would a fresh permissively-licensed reimplementation be the only viable path? We see grafana/mcp-grafana is Apache-2.0 even though Grafana itself is AGPL, and from inspecting its source it is a from-scratch Go reimplementation rather than a wrapper around any AGPL Grafana code. If that is the expected pattern for AGPL projects that want to be in the registry, it would be useful to document this explicitly in CONTRIBUTING.md so others do not have to discover it the same way we did.

What we are not asking

We are not asking for a "wrapper" loophole where an Apache-licensed thin shim pip installs an AGPL package at build time. That would technically pass the automated check (which only looks at the wrapper repo's license) but is essentially license laundering and would expose Docker Inc. to the same AGPL §13 distribution obligations. We have no interest in that path and would not propose it.

Why this matters to us

Concrete decision we are trying to make: invest engineering time in either (a) a fresh permissively-licensed reimplementation of zabbix-mcp-server, (b) relicensing the existing project, or (c) skipping the Docker MCP Registry and focusing on other distribution channels. The right answer depends entirely on whether AGPL has any path forward here.

Thanks for clarifying. Happy to provide more context on our project or help update the documentation once we know where things stand.

[shivasurya]

I had the same question. However, Looks like this project is dead and if you see no PRs are being merged.

[hermanekt]

The repo is active - PRs were merged as recently as yesterday (automated pin updates for grafana, apify, testkube, etc.). 30 open PRs at the moment. The license policy question is more of a legal/governance topic though, so I'd expect it takes longer to get a response from the Docker team than a typical code review.

[shivasurya]

Those are just bump to the base image automated PR otherwise no active merged on new MCP servers :(

#2099