Codeberg draws a line against vibe-coded open source

Codeberg has drawn one of the clearest lines yet between open source as a licensing model and free software as a human collaboration practice.

On July 23, the Codeberg e.V. association published the results of two member votes about large language models. The first is straightforward: Codeberg says its forge and associated services do not use, and will not use, project or user data to train generative AI systems such as LLMs. The second is the one that will keep maintainers arguing. Codeberg is changing its Terms of Use to prohibit what it calls "vibe-coded projects", meaning projects mostly created or maintained with heavy LLM use rather than human stewardship.

This is not GitHub-scale platform policy. Codeberg is smaller, community-run, and rooted in the Forgejo/FLOSS world. That is exactly why the move matters for Open Source Radar. Big platforms usually talk about AI as a productivity layer. Codeberg is asking a different question: should an independent forge spend donated infrastructure, moderator time and community trust on repositories that look open by license but are mostly machine output?

The answer Codeberg chose is not universal. It may not even be easy to enforce. But it is a real governance decision, not a blog-post mood. Other projects and forges will now have to decide whether they want neutral hosting rules, disclosure rules, human-review rules, resource limits, or a stronger cultural position against LLM-generated work.

What Codeberg actually voted on

Codeberg says the votes happened among active members of Codeberg e.V. after discussion at the association's annual assembly and a 14-day asynchronous voting period. Both proposals passed.

The first motion promises that Codeberg will not use hosted project or user data for training generative AI or LLM tools. That part fits a pattern many communities already understand: users do not want their repositories, issues, comments and private work treated as raw material for a model vendor unless they clearly consent.

The second motion was more divisive. Codeberg says it passed with 358 agreements, 144 disagreements and 14 abstentions, with turnout around 50% of active members. The change adds a rule to the Terms of Use saying users must not share projects that mostly consist of code written by generative AI tools, including services such as Claude and OpenAI Codex. The commit text links the concern to unclear copyright status and the lack of safeguards against harmful code.

The blog post uses the phrase "vibe-coded projects", but the policy is not framed as a ban on every AI-assisted keystroke. Codeberg says projects with an active community, a significant pre-LLM history, or occasional accepted LLM-generated contributions are unlikely to be affected if the project is not built around heavy LLM use. It also says the moderation team will not start with a mass deletion list or spend large resources automatically scanning repositories.

That nuance matters. The strongest version of the policy is not "no developer may ever use autocomplete." It is closer to: Codeberg does not want to host repository dumps where an AI agent or heavily LLM-driven workflow creates lots of code, artifacts, CI runs and release files without a real human community maintaining them.

Why an open-source forge cares about machine-generated code

The easy critique is that open source should care about the license, the code and whether the project works. If a tool helped write it, why should a forge care?

Codeberg's answer has three parts.

First, infrastructure is not free. The post points to crawler pressure from companies trying to ingest code for LLM training. Codeberg is happy with ordinary git clone, but says crawlers hit issue filters, history views and file pages in ways that create expensive database queries. The association has also written before about storage limits, abuse and the cost of serving user-generated content from a donation-funded service.

Second, machine-generated projects can externalize maintenance costs. Codeberg describes repositories with heavy activity, CI/CD, release binaries and broad platform support but almost no user community. A solo developer can now produce a project shape that looks like a large community effort: many files, many builds, many releases. If nobody is going to review, maintain or use it, the cost lands on the forge and its volunteers.

Third, trust is part of the commons. Maintainers already deal with low-effort LLM-generated contributions that take time to review. Codeberg also points to license laundering concerns, where copyleft code may be absorbed into model output without carrying reciprocal obligations forward. Even when no one has bad intent, the result is more suspicion. Contributors worry that careful bug reports will be dismissed as AI slop. Maintainers worry that polished patches hide unread code.

That is the cultural core of the decision. Codeberg is not only a Git server. It sees itself as a place where people collaborate on free software. If the work becomes mostly machine output, Codeberg argues, the social premise changes.

Why critics are uncomfortable

The objections are serious too.

"Vibe-coded" is not a clean technical category. A project can use AI for scaffolding, documentation, tests, translation, refactoring, code review or full agentic implementation. Somewhere along that line Codeberg wants to say: this is no longer the kind of project we host. But the boundary will be judged by humans after the fact, often from messy evidence.

That creates enforcement risk. Selective moderation may be practical, but it can also feel arbitrary. A disliked maintainer may be accused of AI use. A low-quality project may be treated as a policy violation even when the real issue is simply bad code. A good project written with heavy AI help may become suspect, while a hand-written mess passes because it looks traditional.

There is also a political tension. Open source historically lowered the barrier to publishing code. The community judged projects by license, transparency, buildability, maintainability and whether anyone cared enough to improve them. A rule about the toolchain used by the author feels to some critics like moral gatekeeping.

The Hacker News thread around Codeberg's post showed that split clearly. Some commenters welcomed Codeberg as an explicitly anti-LLM home for projects that want that identity. Others argued that any user can apply to become an active member, so the vote was a legitimate association decision. Critics questioned the definition of "vibe-coded", the democratic reach of a member vote compared with the user base, and whether quality should be judged directly rather than inferred from AI use. The thread was active, with roughly 195 points and 128 comments through the Algolia mirror at research time.

LWN also picked up the story for the Linux and FLOSS audience, which is a useful signal. This is no longer only a Codeberg blog item. It is now part of the wider free-software argument about AI-generated code, open weights, platform scraping and what maintainers owe each other.

This is different from the open-source AI debate, but connected

At the same time, Hacker News was discussing a very different essay, "The arguments against open source AI are bad." That thread argues from the other direction: open models and open weights should not be restricted by large labs or safety gatekeepers who happen to benefit from closed access.

The two debates can look contradictory, but they are not the same question.

The open-source AI debate asks whether model weights, training recipes and AI capability should be controlled or shared. The Codeberg debate asks whether a volunteer FLOSS forge should host repositories mostly produced by those systems. You can believe in open AI research and still want stricter contribution rules for a specific project. You can dislike LLM-generated patches and still oppose giving a few frontier labs the power to define who may run models.

This distinction will matter. The phrase "open source AI" is already messy because open weights are not the same thing as source code, reproducible builds, documented data, training scripts and the right to modify the whole system. Codeberg's position adds another layer: even if a model or tool is open, the output may still be unwelcome in a community built around human review and long-term maintainability.

What maintainers should do now

The practical lesson is not that every project should copy Codeberg's rule. Many should not. A game jam, research prototype, AI tooling project or commercial open-core repository may have a different tolerance for generated code.

But every serious project should probably write down its policy. Silence is no longer enough.

A small project can start with a CONTRIBUTING.md section that says whether LLM-generated patches are allowed, whether contributors must disclose AI assistance, and whether maintainers may reject generated code that cannot be explained. The policy should focus on reviewable facts: tests, provenance, copyright risk, security, maintainability, dependency changes and whether the contributor understands the patch.

For projects that allow AI assistance, disclosure can be lightweight. "I used an LLM to draft tests" is different from "an agent generated the feature and I did not inspect it." Maintainers do not need a confession ritual. They need enough information to review the work honestly.

For projects that reject AI-generated contributions, the wording should be specific. Ban undisclosed generated patches if that is the problem. Ban code the contributor cannot explain. Ban agent-created drive-by changes. Require that contributors certify they have rights to submit the work. A blunt "no AI" slogan may feel good and fail when the first ambiguous patch arrives.

Forges have another layer to consider. They can enforce project-level policies, rate-limit crawlers, restrict storage and CI abuse, require clearer metadata for generated repositories, or create explicit zones for AI experiments. Codeberg chose a mission-driven line. Other platforms may choose resource-based rules instead.

Choosing a forge becomes a cultural decision

Developers already choose forges by features: pull-request workflow, federation, CI integration, issue tracking, account policy, exportability and federation support. AI policy now joins that list.

GitHub will likely remain the default for AI-assisted development because Copilot and agent workflows are built into its strategy. SourceHut may appeal to people who prefer email-first, minimal, human-readable workflows. Forgejo and Gitea instances can diverge by local policy. Codeberg is signaling that it wants to be a home for FLOSS projects that care about human collaboration and do not want their work folded into LLM training or drowned in generated repository noise.

That pluralism may be healthier than pretending one forge can satisfy everyone. Some projects want maximum reach and AI tooling. Some want a quiet place with stricter community norms. Some will sit in the middle: AI allowed, but only under human accountability.

The risk is factionalism. If every platform turns tool choice into identity, developers may spend more time arguing about how code was written than whether it is useful, secure and maintainable. The benefit is clarity. Communities can stop fighting the same battle in every pull request and say upfront what kind of collaboration they are trying to protect.

What to watch next

The next important signal is not the announcement. It is enforcement.

Will Codeberg publish a clearer moderation process? Will projects get warnings before removal? How will appeals work? What evidence will count as heavy LLM use? Will resource-heavy ghost projects be treated differently from active communities using AI tools? Will the Terms of Use language stay broad, or will examples become the real law in practice?

Also watch whether other FLOSS projects write their own AI contribution policies. The Helix editor discussion linked from community comments is one example of a maintainer-level conversation rather than a forge-level one. That may become the normal pattern: forges set hosting boundaries, while projects set contribution boundaries.

Codeberg's move will irritate people, including some who care deeply about free software. It may also make Codeberg more attractive to contributors who want a human-first space. Both outcomes can be true.

The open-source world is entering a cultural fork. One branch treats AI as another power tool for producing code. The other asks whether code without accountable human maintenance is really part of the commons. Codeberg has picked its branch. Now every maintainer has to decide how explicit their own policy should be.