Exemptions sound relatively simple until you try to make them fair.

If Maven Central remains free for community open source projects, the obvious approach is to identify those projects and exempt them from publishing limits. Look at the licence, confirm that the source repository is public, perhaps check how widely the project is used, and make a decision.

In practice, none of those signals gives us a complete answer.

A licence, a public repository, download volume, and publisher identity all provide useful context. None of them, on its own, defines community open source.

This is where a straightforward principle becomes a difficult operational question.

In my first post about our work to make Central sustainable, I wrote about the space between open source code and community open source, and why seemingly similar components can have very different relationships with the infrastructure that distributes them.

The exemption process brings that nuance into focus. It requires us to make decisions about real projects, real publishing patterns, and organisations whose use of Central rarely fits neatly into a single category.

Why Exemptions Exist

Publishing limits use practical signals such as artifact size, publishing frequency, and sustained volume. Those signals help identify activity that looks different from the ordinary release cycle of most open source projects. But that is not conclusive.

A genuine community project may publish unusually large artifacts, release frequently because it maintains many modules, or generate several related components from a single release process.

That is why an exemption route is necessary. Thresholds help us identify where we need to look more closely, but they cannot replace judgement.

The alternative would be a completely mechanical system in which every project crossing a limit was treated in exactly the same way. That might be simpler to administer, but it would also treat unlike things as if they were the same.

The exemption process is intended to avoid that.

A Licence Is Important, but It Is Not the Whole Answer

Open source licences establish important rights to inspect, use, modify, and redistribute software. A project applying an appropriate open source licence is therefore an important part of any exemption review.

It is not, however, a complete definition of community open source.

The project may still exist primarily to support the adoption and operation of a commercial platform.

That does not make an SDK less open source in the licensing sense. It does mean that an open source licence, on its own, cannot tell us whether the commons is primarily supporting an independent community project or acting as part of a commercial distribution model.

The same issue appears inside larger publishing portfolios. An organisation may maintain genuinely community-oriented libraries alongside generated clients, service integrations, commercial agents, internal-adjacent components, or artifacts that are technically public but exist mainly to support its own platform.

All of them may carry the same licence. They may even sit beneath the same namespace.

Operationally, they are not necessarily the same.

Public Source Is Evidence, Not a Verdict

Repository visibility presents a similar challenge.

A public repository is a useful signal. It allows us to see the source, understand the release process, review documentation, and look at how the project is maintained. It may also show whether contributions, issues, and discussions take place in the open.

But repositories exist in many forms.

A repository can therefore help us understand a project, but its visibility cannot settle the question by itself.

There is also a danger in assuming that a particular style of repository activity represents the only legitimate form of community. Some mature open source projects have a small maintainer group, relatively little issue traffic, or governance distributed across a foundation, mailing list, standards body, or collection of related repositories.

We should not mistake a lack of visible social activity for a lack of community value.

Downloads Do Not Tell Us Who Is Being Served

Download volume is tempting because it appears objective — a project with millions of downloads may look like an important community dependency.

In many cases, it is. But high usage does not automatically mean community usage. Those downloads may also belong to a required SDK, a component embedded in a commercial platform, automated scanners repeatedly resolving the same dependency tree, or build systems operating without effective caching.

Low usage is no more conclusive. A specialised library may serve a small but legitimate community. A foundational component may release infrequently or be pulled transitively in ways that make its direct download figures difficult to interpret.

Download data is valuable operationally, particularly when understanding the load placed on Central. It is much less reliable as a definition of what a project is for.

Corporate Ownership Is Not a Disqualifier

The identity of the publisher creates another easy but misleading shortcut.

Large companies publish and maintain a substantial amount of important open source software. Some projects are company-led but independently useful, openly governed, widely contributed to, and relied upon far beyond the company's own products. Treating anything associated with a commercial organisation as automatically non-community would be both unfair and damaging.

Equally, being published by an individual, a small company, or a loosely organised group does not automatically make a project community open source. Central can be used as commercial delivery infrastructure by organisations of any size. Corporate identity should not become a proxy for intent.

The relevant question is not simply who employs the maintainers or owns the namespace. It is how the project relates to the wider ecosystem, who it is designed to serve, and what role Central plays in its distribution.

Organisations Rarely Fit Into One Category

This may be the most important lesson from the exemption conversations so far. An organisation is rarely entirely "community open source" or entirely "commercial publishing." It may be both.

In one conversation with a publisher, the initial challenge was identifying which projects in a broad publishing portfolio were genuinely community open source. Elsewhere, the question was how to distinguish community publishing from the use of Central as part of a commercial infrastructure model.

These are not edge cases. They are a predictable result of how modern software organisations work. This means the correct unit of review may not always be the company or even the namespace.

An organisation-wide exemption could be too broad. Reviewing every individual artifact could create unnecessary complexity. The meaningful boundary may be a project, a family of related components, or a clearly defined part of a publishing portfolio.

Finding that boundary is part of the work.

What Does "Community" Mean Operationally?

There is unlikely to be a single test that answers this question in every case. Instead, an exemption review needs to build a picture from several kinds of evidence.

An exemption review may consider if:

• The project solves a general ecosystem problem or primarily supports a commercial service.

• Meaningful community participation exists.

• Publishing patterns reflect the project itself or avoidable automation.

• Central serves as the project's natural public home or as part of a commercial delivery pipeline.

None of these questions should become a purity test.

Community open source does not require the absence of commercial involvement, a particular governance template, a minimum number of external contributors, or to be operated without paid maintainers. Commercial support and community benefit frequently coexist.

Why the Process Can Feel Like Bureaucracy

From the publisher's perspective, requests for additional information may feel unnecessary.

The source is public. The licence is open source. The artifacts are useful. Why should anything more be required?

Automatic exemption based only on those facts would place independent community libraries, commercial service SDKs, generated product clients, and infrastructure-driven publishing beneath the same umbrella.

At the other extreme, denying exemptions based on company ownership, publishing volume, or unusual artifacts would penalise legitimate projects for having corporate backing or complex release models.

Neither approach would be fair. The review exists because the visible signals point in different directions. Asking questions is an attempt to make a decision based on what is actually being published rather than relying on assumptions.

That process needs to be proportionate. Publishers should not have to produce a philosophical defence of every project, and community maintainers should not be burdened with repeated requests for information that is already clear.

Fairness Requires More Than a Checkbox

Simple rules are attractive because they promise certainty:

• A licence-only rule is clear but too broad.

• A download-based rule is measurable but misleading.

• A company-based rule is simple but unfair.

• A volume-only rule is operationally useful but incomplete.

Once we accept that none of these is sufficient, some form of contextual review becomes unavoidable. That means acknowledging the limits of the available signals and making the reasoning behind decisions as clear as possible.

The exemption process is not bureaucracy for its own sake. It allows us to preserve a free path for community open source without extending that exemption automatically to every form of commercial or infrastructure-scale publishing that can technically be described as open source.

Keeping the Promise

Maven Central remains free for community open source.

Keeping that promise requires more than checking a licence or confirming if a source repository is public. It requires understanding how projects are maintained, who they serve, and why Central is part of their distribution model.

That work is harder than applying a label. It also gives us a better chance of being fair.

Community projects with legitimate but unusual publishing patterns should not be treated as commercial infrastructure users simply because they cross a numerical threshold. At the same time, organisations using Central as a significant part of a commercial delivery model should not receive an unlimited infrastructure subsidy simply because the components they distribute are source-visible.

The space between those two cases is where the exemption process operates.

It will continue to require judgement, conversation, and refinement. That is not a sign that the principle is wrong. It is a consequence of applying a sensible principle to an ecosystem that is more varied than any single definition can capture.

Open source is nuanced. Community is contextual. Fair stewardship depends on recognising both.