Yesterday, Codeberg merged a new rule into its Terms of Use:
- You must not share projects that mostly consist of code written by "generative AI"-tools (including services such as Claude, OpenAI Codex). Such projects having an unclear copyright status (see requirements § 2 (1) 1 and § 2 (1) 3) and furthermore have little safeguards to ensure that they do not include harmful code (c.f. § 2 (1) 5).
The punishment isn't abstract: the content gets removed and the user gets a warning. Further violations can get the account suspended. When the violation isn't obvious the presidium decides by simple majority.
I don't like vibe coding. I've written about this before: you cannot automate something you don't understand. Giving an LLM control of a codebase you can't read is a good way to end up with an application you can't maintain or, even worse, one that quietly does something dangerous. I understand why a Free Software forge doesn't want to become the place where people dump thousands of those projects.
What Codeberg wrote covers far more than that though. It covers any project that "mostly" consists of code written by a generative AI tool, reviewed or otherwise. There is no exception for a developer that understands the code, tests it, and takes responsibility for it. There isn't even an explanation of what mostly means.
I. The IRC client I wouldn't have built
We're at a dearth of modern IRC clients. There just aren't that many of them left. That's why I started Cascade Chat, which I wrote about when I first started working on it.
Frankly, I wouldn't have built or maintained it without AI. That doesn't make it slop. I decide what the program should do, how it should work, and how the project is run. AI does a lot of the grunt work that used to eat my time.
The policy doesn't have a way to care about any of that. If most of the code was written by an agent then the project is unwelcome. Free Software is short on more than just modern IRC clients and Codeberg's policy would turn away those projects because AI made their maintenance practical.
II. Mostly what?
Lines of code would be the obvious measurement, but it's also a pretty bad one. A generated migration might be a few thousand boring lines while the human-written part of the application contains nearly all of its behavior. Maybe commits are the measurement? Agents can make one large commit or a hundred small ones. Tokens don't tell you anything useful either. None of these account for a person rewriting generated code until very little of the original output remains.
Autocomplete is another fun problem. The policy names Claude and OpenAI Codex as examples, but it doesn't limit itself to agents. If an engineer uses generative autocomplete all day and accepts most of it one line at a time, a lot of their repository may be generated by even the most literal reading of the rule. That's not what most people mean when they complain about vibe coding, but it is what the Terms of Use say.
People asked about this in the pull request. At that point the proposal had already been sent out for a membership vote and substantial changes were off the table. When people continued to ask how existing projects would be handled, what counted as "written by," and who would enforce the rule, Codeberg closed the discussion and said those details would arrive in a blog post. That post hasn't been published as of this writing.
One of the authors did answer the ambiguity question on Mastodon. Their position is that precise moderation rules are easy to game, so at some point you have to trust the moderators. That's true of moderation in general. You can't turn harassment into a flow chart and expect a decent outcome every time.
I'm having trouble carrying that logic over to code authorship. Harassment leaves conduct to evaluate. A repository usually doesn't contain a record of every autocomplete suggestion, agent session, prompt, and manual edit that produced it. The moderator isn't being asked to interpret behavior with some amount of discretion; they're being asked to reconstruct a process that happened on somebody else's computer.
III. Detecting AI code
Let's say somebody reports one of my repositories for violating this rule. How does the presidium decide whether I wrote it?
They could run the code through a detector. A 2024 empirical study tested existing AI-code detectors and found that they performed poorly and didn't generalize well enough for practical use. The researchers built a better one that reported an average F1 score of 82.55. F1 balances two ways a detector can fail: saying code belongs to a class when it doesn't, and missing code that does. In this paper the authors calculated a score for both human and AI code and averaged them. A perfect score would be 100. An F1 of 82.55 does not mean 82.55 percent of its decisions were correct, and it doesn't mean the detector is 82.55 percent certain about any particular repository.
It is also the flattering number. The model was trained and tested on different splits from the same dataset. When the authors trained it on one dataset and tested it against code from another language or domain, the average F1 fell to about 42–45. A forge doesn't get to choose repositories that look like its training set. That's the number I care about if somebody's account is on the line.
Mixed authorship is worse. One system in the 2026 SemEval machine-generated code challenge managed a macro F1 of 0.49 when classifying human, AI, hybrid, and adversarial code. Macro F1 gives each label equal weight, so the common human label can't carry the result. On the same hundred-point scale that's 49. It was a different, four-way test, but it still isn't proof I would delete a repository over.
They could look for tells in the repository instead. LLMs like certain comments, naming patterns, and overly defensive code structures. They also change quickly and follow the patterns already in the repository. If I tell an agent to write code in my style it will do a passable job, especially after it has a hundred thousand lines of examples. A person can also write repetitive code, overdo comments, or make twenty commits in an hour. We've all worked with that person and some of us have been that person.
GitHub's own explanation says small amounts of generated code can't be detected with real confidence. GitHub can find exact matches against public code, which is useful, but a match doesn't tell you whether a person copied it directly or an LLM acted as the middleman. It also doesn't help when the output is novel.
So who gets caught? Probably the developer who mentions AI in a README or talks about it publicly. The rule doesn't require disclosure or agent logs. Honest developers hand moderators the best evidence against themselves.
I don't think this is really about copyright, or copyleft, either. If it were, the amount of generative AI in a project would not matter. If you believe AI neatly produces stolen material then no amount of it should be acceptable. One generated function would still be stolen. The word “mostly” makes no sense under that theory.
Transformer training is its own copyright fight. In Bartz v. Anthropic, the court found that using the plaintiffs' books to train a model was fair use. It separately found that downloading books from pirate libraries and keeping them in a permanent library was not fair use on the record before it. The fact that Anthropic ingested copyrighted material did not end the analysis.
We don't call every book written by somebody who has read books stolen. We look at what they produced. Whether a transformer deserves the same treatment is unresolved. Codeberg's “mostly” threshold avoids that question rather than answering it.
Codeberg already requires users to have the right to share what they upload. It can enforce that rule when code actually infringes somebody else's work. People were capable of copying code before LLMs came along.
Security has the same provenance problem. I have seen LLMs write some real whack-ass code, but I've also seen plenty of it written by hand. If the code is harmful then Codeberg has an existing rule for harmful code. I don't see what is gained by guessing which tool typed it first.
IV. Codeberg's values
The policy makes much more sense to me as a statement about Codeberg than it does as a solution to copyright or security problems.
The membership voted pretty decisively for it. There were 1,085 eligible voters and 517 ballots cast: 358 agreed, 144 disagreed, and 14 abstained. Codeberg is a member-run nonprofit and this wasn't handed down by an executive or venture capitalist. An active member made a proposal and the other active members voted on it. Whatever problems I have with the policy, its origin isn't one of them.
The Mastodon discussion is much more direct about the motivation. The author said the vote showed that Codeberg's organization and members share values. In another reply they described generative AI tools as inherently incompatible with the community's values. Later they argued that a schism is necessary, comparing this split to the one between corporate open source and copyleft.
I think this is what Codeberg actually voted for. Its active members want an AI-averse forge. They don't want their volunteer labor going toward projects built using tools they see as exploitative and incompatible with Free Software. Maybe that's a win for the people who see programming as a kind of artisanal craft and want a place organized around it.
I would rather Codeberg put that in the Terms of Use: projects built mostly with generative AI are unwelcome because those tools conflict with the community's values. Codeberg is allowed to make that choice.
The actual rule points to unclear copyright and harmful code. The Mastodon discussion talks about shared values and a necessary schism. When somebody reports a repository, moderators will decide whether it belongs and reach for the copyright and security language afterward. It comes off as dishonest.
I'm not convinced it's a win for Codeberg as a broadly useful alternative to GitHub. Cascade is the kind of project I would expect a Free Software forge to want. Under this policy the project is potentially outside the boundary Codeberg just drew anyway. It has nothing to do with the quality of the work.
V. There were other options
There was a less expansive option sitting in Codeberg's own history. In 2023 somebody proposed an AI disclosure rule that would have required users to name the tool and the affected files. The proposal deliberately tried not to capture traditional code completion. It was never merged, but at least it would have created some of the provenance the current rule assumes moderators can divine later. One person in that discussion even warned that removing content without a clear rule would make Codeberg look unreliable.
The Linux kernel has taken a different approach. Its
AI policy allows AI-assisted contributions
but requires a human to review the code, verify the licensing, sign the Developer Certificate of
Origin, and take responsibility for what they submit. It also asks for an Assisted-by tag. Linus
Torvalds made the broader position explicit in July 2026:
“Linux is not one of those anti-AI projects.”
He called AI a useful tool and said the kernel would continue to make decisions on technical merit.
Codeberg didn't have to copy the kernel. It could have required disclosure, left contribution rules to project maintainers, and used its existing rules when code was harmful or infringing. None of that requires guessing who typed most of a repository.
Instead Codeberg chose a rule it can't reliably enforce. That is worse than simply saying AI-heavy projects aren't welcome.