Theo on Codeberg’s AI Code Restriction and the Future of Open Source

I recently donated thousands of dollars to Codeberg and encouraged people to use it as an alternative to GitHub. Now its members have voted for a restriction on projects made mostly with generative AI, and I am frustrated. I support independent open-source infrastructure; that is exactly why this decision matters to me.

Codeberg is a community-run home for open-source projects. I had expected a refuge from the problems of a large commercial platform, but I worry that this rule excludes people based on how their software was made, rather than whether their projects and contributions are useful.

Before discussing it, please do not harass the volunteers or members involved. They are people donating their time to a service I have benefited from. Disagreeing with a policy is not an excuse to attack its authors.

I start with a community discussion calling for a ban on AI-generated material. That post is a participant's proposal, not itself the adopted platform policy. It nevertheless shows the strength of the sentiment behind the debate and how quickly a concern about low-quality contributions can turn into a much broader prohibition.

The question is not whether every AI-generated change is good. It is whether the presence of AI makes a project unworthy of hosting. I think tools can help people write and review code, and judging the output and the maintainers' behavior is a better starting point than judging the tool alone.

Codeberg is a membership organization with volunteers, limited capacity and its own governance. I appreciate that its discussions and votes happen in public. Transparency does not require me to agree with the result, and the fact that a community voted for a rule does not make the consequences irrelevant.

I am bothered by the assumption that AI-assisted work cannot be real open-source work. A project can have responsible human maintainers and meaningful collaboration even when a substantial amount of its code was produced with an assistant. Conversely, a human-written project can be poorly maintained.

Some of the comments around this debate are especially discouraging to people who have tried to support Codeberg. I do not think disagreement about AI justifies dismissing those people or assuming that every developer using these tools is acting in bad faith.

The official announcement describes two member decisions: a commitment not to use hosted content to train language models, and a proposed terms change concerning projects consisting mostly of generative-AI-written code. Those are separate questions: protecting hosted material from training is not the same as deciding which projects may be hosted.

The vote on the hosting restriction passed 358 to 144. I disagree with the outcome, but those numbers are a vote by participating members, not a poll of all open-source developers. My own audience poll is also self-selected and cannot settle what the broader community thinks.

The proposed wording concerns projects that mostly consist of code written by generative AI. It is not a blanket ban on every use of AI. Codeberg's accompanying explanation says enforcement will be developed, and its early examples distinguish established community-maintained projects from some heavily automated or resource-intensive uses. See [Codeberg's announcement](https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html).

I think AI can also improve software: it can help examine unfamiliar code, identify problems and give more people access to development. Those benefits are possibilities, not proof that generated code is secure or that a project can skip review. The policy question is how to handle the bad outcomes without excluding the good ones.

The volunteers describe problems that I take seriously. Automated crawlers can put pressure on the service, and a wave of superficial machine-written issues or patches can force maintainers to spend time reviewing material that its submitter did not understand. An open-source maintainer is not obligated to accept that work.

Codeberg also describes very large AI-related repositories and inactive projects consuming storage and continuous-integration capacity. A service funded by donations and volunteer work cannot assume unlimited infrastructure. Hosting a repository includes ongoing costs that a contributor may never see.

I agree that Codeberg should be able to stop abusive scraping, limit resource consumption and reject floods of low-effort submissions. I would prefer rules aimed at those concrete behaviors and costs. A category defined by the proportion of AI-written code risks catching useful projects along with the problematic ones.

Access to computing is uneven. I worry that a rule framed around who wrote each line can make participation harder for people who lack the time, experience or resources to develop in the traditional way. The better question is whether a project has a human willing to understand and maintain it.

The announcement also raises the environmental costs of AI infrastructure. I question how those costs are being compared with other uses of computing and whether a hosting ban is the right response. That discussion needs measurements rather than treating either unlimited AI growth or zero impact as a given.

I suggest that data-center cooling largely reuses water and that its impact is often overstated. That is too broad: cooling systems differ, and evaporative systems consume water. The [US Department of Energy](https://www.energy.gov/cmei/femp/cooling-water-efficiency-opportunities-federal-data-centers) describes evaporation losses; the [IEA](https://www.iea.org/reports/energy-and-ai/executive-summary) estimates all data centers used about 1.5% of global electricity in 2024, with local effects varying. That figure is not AI alone.

I would rather see investment in cleaner energy and more efficient infrastructure than an assumption that one class of software tools must be excluded. Environmental tradeoffs are real, but the way to reduce them should be connected to actual energy and water use.

I bring up Germany's energy choices as an example of how difficult those tradeoffs can be. My criticism of those choices is an opinion; it does not by itself establish the emissions or water impact of a particular Codeberg project or model.

Another concern in the announcement is that software produced by agents can appear without a genuine community around it. I think a project can begin with AI assistance and still become a place where people collaborate. Its history, human stewardship and actual interactions matter more than a simple label.

Trust is a real issue. Maintainers need to know that a contributor has understood a change and will take responsibility for it. If someone produces a large patch in seconds but leaves the maintainer to discover the problems, the apparent productivity gain has merely transferred the work.

I sympathize with maintainers overwhelmed by low-effort submissions. Projects can state their contribution requirements, close inadequate reports and insist that authors test and explain their patches. Those boundaries protect maintainers without requiring the platform to decide that every heavily AI-assisted project has no value.

The discussion also raises licensing concerns: generated output may resemble existing work, and people worry about obligations and provenance. Those questions deserve attention, but asserting that every AI-assisted project is automatically a license violation would go beyond what this discussion establishes.

Enforcement raises another practical problem: how can a host reliably determine what proportion of a codebase was written by a model? I worry about false accusations, arbitrary decisions and maintainers feeling they must prove a negative. A policy's implementation matters as much as its stated intention.

Codeberg frames its position around free software, collaboration and care for a shared resource. I share the desire for a healthy community, but I reach a different conclusion about the tool. Open collaboration can include human responsibility for code produced with assistance.

The blog's preliminary, informal guidance matters. It says existing community-maintained projects, including projects that have occasionally accepted generated contributions, are generally less likely to be affected. Lightweight side projects are discouraged but likely to be tolerated; this is guidance rather than a promise about every case.

The examples of uses that may no longer be welcome include projects substantially produced by autonomous agents, repeated LLM use and projects making excessive demands on resources, as well as contributions that violate a project's own rules. These examples are not equivalent to an immediate automatic ban on every project in a category.

Even with those qualifications, I find the direction disappointing. Developers who care about open-source alternatives should be able to debate a platform's choices, and the people who keep it running should be able to set limits on what their service can sustain.

I return to what open source means: sharing code so others can inspect, change and build on it. In my view, excluding projects because of their development tools makes that community narrower. A host's terms and the rights granted by an individual open-source license are distinct things, even when both affect where a project can live.

The debate over AI and open-source contributions will not be settled by one vote. Maintainers are entitled to require meaningful, reviewable contributions; contributors should also be able to use tools responsibly. The difficult part is writing and enforcing rules that preserve both.

For now, I remain disappointed in Codeberg's decision and consider alternatives, including running Forgejo independently. I still value the people who provide open infrastructure, and I hope the discussion stays focused on the policy and its consequences.