Codeberg verbietet KI-generierten Code und untersagt KI-Training mit Nutzerdaten

Codeberg hat sich entschieden, gegen den Strom zu schwimmen. Während GitHub, GitLab und diverse andere Plattformen ihre Nutzer mit KI-Assistenten zum Schreiben, Reviewen und Refactoren von Code überschütten, hat die Community rund um die gemeinnützige Codeberg e.V. am 22. Juli 2026 zwei Abstimmungen durchgezogen, die in eine ganz andere Richtung zeigen. Erstens: Projekte, die überwiegend aus KI-generiertem Code bestehen, werden nicht mehr gehostet. Zweitens: Codeberg selbst verpflichtet sich, keine KI-Modelle mit dem auf der Plattform liegenden Code oder mit Nutzerdaten zu trainieren. Zwei Beschlüsse, ein klares Signal – und ziemlich viel Diskussionsstoff für alle, die sich mit KI-Training, Datenschutz und der Zukunft von Open-Source-Hosting beschäftigen.

Codeberg ist für alle, die den Namen bisher nur am Rande kennen, eine gemeinnützige, community-getragene Alternative zu GitHub. Betrieben wird die Plattform vom Berliner Verein Codeberg e.V., technisch läuft sie auf Forgejo, einer Open-Source-Softwareforge, die aus einem Fork von Gitea entstanden ist. Wer sich näher für die technische Basis interessiert, findet in der offiziellen Forgejo-Dokumentation die entsprechenden Details zur Softwarearchitektur, auf der Codeberg aufsetzt. Wer sich für die Frage interessiert, wie automatisierte Prüfmechanismen mit KI-generiertem Code in der Supply Chain umgehen, findet ergänzende Einordnung im Beitrag zu KI-Code-Security und Supply-Chain-Risiken.

Codeberg und die Abstimmung vom 22. Juli 2026

Laut Berichterstattung von OMG! Ubuntu stimmten die Mitglieder von Codeberg e.V. am 22. Juli 2026 mit 358 zu 144 Stimmen bei 14 Enthaltungen dafür, die Terms of Use so zu ändern, dass Projekte, die überwiegend aus Code bestehen, der von generativen KI-Tools geschrieben wurde, künftig nicht mehr gehostet werden dürfen. Die Wahlbeteiligung lag den Berichten zufolge bei rund 50 Prozent der stimmberechtigten Mitglieder – für eine Vereinsabstimmung ein durchaus solider Wert, der zeigt, dass das Thema innerhalb der Community nicht nebenbei entschieden wurde.

Wichtig für die Einordnung: Es handelt sich um eine Änderung der Terms of Use, also der Nutzungsbedingungen der Plattform, nicht um eine Änderung geltenden Gesetzesrechts. Codeberg e.V. kann als Betreiber seiner eigenen Infrastruktur festlegen, welche Inhalte gehostet werden und welche nicht – das ist Plattformpolicy, kein neuer rechtlicher Standard, der außerhalb von Codeberg Wirkung entfalten würde. Wer diesen Unterschied im Kopf behält, versteht auch besser, warum die Regelung zwar für alle Projekte auf Codeberg bindend ist, aber keine Blaupause für die gesamte Open-Source-Welt darstellt.

Was die neue Terms-of-Use-Regel konkret verbietet

Die neue Formulierung in den Terms of Use untersagt laut den vorliegenden Berichten Projekte, die überwiegend aus Code bestehen, der von generativen KI-Tools geschrieben wurde. Das ist eine bewusst gewählte Schwelle: Es geht nicht darum, jede Codezeile zu verbannen, die irgendwann mal von einem Autocomplete-Vorschlag stammt. Es geht um Projekte, bei denen der KI-generierte Anteil den überwiegenden Teil der Codebasis ausmacht – umgangssprachlich oft als „vibe-coded“ bezeichnet, also Code, der im Wesentlichen durch Prompten statt durch händisches Schreiben entstanden ist.

The Register hat in seiner Berichterstattung genau diesen Punkt hervorgehoben: Die Policy unterscheidet zwischen KI-schweren Projekten, die überwiegend maschinengeneriert sind, und gewöhnlichen Projekten, die lediglich einzelne KI-unterstützte Beiträge enthalten. Diese Differenzierung ist entscheidend, denn sie verhindert, dass die Regel de facto jedes Projekt trifft, in dem irgendein Contributor mal einen KI-Assistenten zur Hilfe genommen hat. Wer gelegentlich Copilot oder ein anderes Tool zur Unterstützung nutzt, fällt nach dieser Lesart nicht automatisch unter das Verbot. Wer aber ganze Repositories im Wesentlichen von einer KI schreiben lässt und lediglich noch kosmetische Anpassungen vornimmt, schon.

In vielen Entwicklerteams ist eine solche Nachfrage längst Routine: Ein Pull Request landet im Review, jemand fragt, ob bestimmte Passagen von einem KI-Assistenten stammen, und die Antwort entscheidet mit darüber, wie gründlich die manuelle Prüfung ausfällt. Genau diese Alltagssituation greift die neue Codeberg-Regel auf und macht daraus ein verbindliches Kriterium für die gesamte Hosting-Berechtigung eines Projekts, statt sie dem Ermessen einzelner Maintainer zu überlassen.

KI-Training mit Plattformdaten ist künftig ausgeschlossen

Die zweite Abstimmung ist für das Thema Datenschutz mindestens genauso relevant wie die erste für das Thema Code-Qualität. Laut OMG! Ubuntu wurde ein zweiter Antrag angenommen, der Codeberg dazu verpflichtet, keine KI-Modelle mit gehostetem Code oder Nutzerdaten zu trainieren. Damit schließt sich die Plattform selbst aus dem Kreis der Anbieter aus, die Nutzerinhalte als Trainingsmaterial für eigene oder fremde KI-Modelle verwenden – ein Weg, den andere große Plattformen zumindest in Teilen gegangen sind oder zumindest offengehalten haben.

Für Entwicklerinnen und Entwickler, die aus Datenschutzgründen skeptisch gegenüber der Nutzung ihrer Repositories als KI-Trainingsdaten sind, ist das ein handfestes Versprechen. Es bedeutet: Wer Code auf Codeberg hostet, muss nicht damit rechnen, dass dieser Code oder die damit verknüpften Metadaten irgendwann in einem Trainingsdatensatz für ein Sprachmodell landen, ohne dass er dem aktiv zugestimmt hat. Das betrifft nicht nur den eigentlichen Quellcode, sondern auch Nutzerdaten im weiteren Sinn – also etwa Interaktionsmuster, Issue-Diskussionen oder Kommentare, die auf der Plattform entstehen.

Die Kombination beider Beschlüsse ist interessant, weil sie zwei unterschiedliche Sorgen gleichzeitig adressiert. Die eine Sorge betrifft die Qualität und rechtliche Sauberkeit von Code, der auf Codeberg gehostet wird. Die andere betrifft die Frage, was mit den Daten passiert, die durch das Hosten überhaupt erst entstehen. Beide Sorgen sind in der Open-Source-Community seit Jahren präsent, aber erst mit generativer KI haben sie eine neue Dringlichkeit bekommen.

Copyright-Fragen als Treiber der Entscheidung

Ein zentrales Motiv hinter dem Verbot von überwiegend KI-generiertem Code liegt laut Sekundärberichterstattung im Urheberrecht. Ein Bericht von genztech.blog verknüpft das Verbot explizit mit Sorgen um den rechtlichen Status von KI-generiertem Code. Die Grundproblematik ist bekannt, aber nicht trivial: Wenn ein KI-Modell Code generiert, der aus Trainingsdaten mit unklarer Lizenzlage stammt, ist es oft schwer zu beurteilen, wem die Rechte an diesem Code tatsächlich zustehen und ob eine Weiterverbreitung unter einer offenen Lizenz überhaupt rechtlich sauber möglich ist.

Für eine Plattform, die sich explizit als Heimat für freie und offene Software versteht, ist das kein Nebenschauplatz. Freie Lizenzen wie die GPL oder die MIT-Lizenz basieren auf der Annahme, dass die ursprünglichen Autoren ihre Rechte an einem Werk kennen und bewusst unter bestimmten Bedingungen weitergeben. Bei Code, dessen Entstehung durch ein KI-Modell und dessen zugrunde liegende, oft nicht vollständig dokumentierte Trainingsdaten vermittelt wurde, wird diese Kette brüchig. Genau hier setzt die Sorge an, die offenbar viele Codeberg-Mitglieder zur Abstimmung bewegt hat: Wer garantiert, dass ein von einer generativen KI erzeugter Codeblock nicht faktisch eine Kopie oder eine sehr enge Paraphrase von urheberrechtlich geschütztem Material aus den Trainingsdaten ist?

Diese Unsicherheit betrifft nicht nur Codeberg. Sie ist Teil einer größeren Debatte, die auch in Unternehmen mit Bezug zu Supply-Chain-Sicherheit und Code-Provenienz geführt wird – etwa dort, wo es um die Nachverfolgbarkeit von Abhängigkeiten und die Absicherung gegen unklare Rechteketten geht, wie es auch im Beitrag zu KI-gestütztem Code-Review als neuem GitHub-Standard beschrieben wird. Codeberg reagiert mit seiner Entscheidung auf ein Risiko, das viele andere Plattformen bislang eher stillschweigend in Kauf nehmen oder den einzelnen Projekten zur eigenen Klärung überlassen.

Wie The Register die Entscheidung einordnet

The Register hat die Entscheidung unter dem Aspekt betrachtet, dass Codeberg e.V. hier als Berlin-basierte gemeinnützige Organisation handelt, die den Dienst überwacht und trägt. Diese Organisationsform ist ein wichtiger Kontextfaktor: Codeberg ist kein börsennotiertes Unternehmen mit Investoren im Nacken, sondern ein Verein, dessen Mitglieder direkt über die Grundregeln der Plattform abstimmen können. Genau diese Struktur hat die beiden Beschlüsse überhaupt erst möglich gemacht – bei einem klassischen SaaS-Anbieter hätten Nutzer schlicht keine vergleichbare demokratische Stimme über die Terms of Use.

The Register betont zudem den bereits erwähnten Unterschied zwischen KI-schweren Projekten und Projekten mit punktueller KI-Unterstützung. Diese Differenzierung dürfte in der Praxis zum eigentlichen Streitpunkt werden. Denn „überwiegend KI-generiert“ ist keine Kategorie, die sich mit einem einfachen automatisierten Check zweifelsfrei feststellen lässt. Es wird Grenzfälle geben: Projekte, bei denen ein Kern von Hand geschrieben wurde und drumherum viel Boilerplate-Code von einer KI stammt. Projekte, bei denen unklar ist, wie viel Prompting-Anteil tatsächlich in welchem Commit steckt. Codeberg wird also früher oder später Kriterien oder zumindest Fallpraxis entwickeln müssen, wie diese Schwelle in strittigen Fällen angewendet wird.

Vergleichbare Abwägungen kennt man bereits aus dem Alltag automatisierter Review-Tools, die heute schon versuchen, Muster typischer KI-Generierung in eingereichtem Code zu erkennen, etwa im Kontext von agentischer Code-Review durch DevOps-Agenten. Solche Systeme liefern Hinweise, aber keine hundertprozentige Gewissheit – ein Grund mehr, warum Codeberg absehbar auf eine Mischung aus Selbstauskunft und Einzelfallprüfung setzen dürfte.

Datenschutz als zweite Säule der Entscheidung

Während die Debatte um KI-generierten Code stark um Urheberrecht und Codequalität kreist, ist die zweite Abstimmung klar im Bereich Datenschutz verortet. Die Zusage, keine KI-Modelle mit gehostetem Code oder Nutzerdaten zu trainieren, ist im Kern eine Selbstverpflichtung gegen eine Praxis, die in der Branche zwar diskutiert, aber längst nicht überall ausgeschlossen wird. Große Plattformen haben in der Vergangenheit unterschiedliche Wege gewählt, wie sie mit Trainingsdaten aus Nutzerinhalten umgehen – von Opt-out-Mechanismen bis zu Klauseln, die eine Nutzung grundsätzlich erlauben, sofern Nutzer nicht aktiv widersprechen.

Codeberg geht mit dem zweiten Beschluss den entgegengesetzten Weg: eine grundsätzliche Nicht-Nutzung, unabhängig davon, ob einzelne Nutzer dem zugestimmt hätten oder nicht. Das ist eine klare, leicht verständliche Position, die sich gut kommunizieren lässt, aber auch bedeutet, dass Codeberg selbst auf mögliche Erträge oder strategische Vorteile verzichtet, die aus der Verwendung der eigenen Plattformdaten für KI-Training entstehen könnten. Für eine gemeinnützige Organisation, deren Selbstverständnis stark auf Vertrauen und Community-Kontrolle beruht, ist das eine konsequente Entscheidung – wirtschaftlich mag sie für andere Anbieter mit kommerziellen Interessen schwerer zu treffen sein.

Aus Sicht des Datenschutzes ist relevant, dass hier nicht nur der Quellcode selbst, sondern auch Nutzerdaten im weiteren Sinn erfasst werden. Das lässt Raum für eine breite Auslegung, die über reinen Code hinausgeht und etwa auch Metadaten, Aktivitätsmuster oder Kommunikation auf der Plattform einschließen könnte. Wie eng oder weit Codeberg diese Zusage in der Praxis auslegt, wird sich zeigen müssen, wenn die Regel im Alltag angewendet wird.

Was das für Entwicklerinnen und Entwickler bedeutet

Für Projektbetreiber auf Codeberg heißt das zunächst: Wer ein Projekt pflegt, das überwiegend von generativer KI geschrieben wurde, sollte sich auf Nachfragen oder im Extremfall auf eine Entfernung von der Plattform einstellen. Wer KI-Tools punktuell als Unterstützung nutzt, etwa für Boilerplate, Testgerüste oder Dokumentationsvorschläge, dürfte von der Regel nach aktuellem Stand der Berichterstattung nicht betroffen sein, solange der überwiegende Teil der Codebasis weiterhin von Menschen stammt.

Praktisch bedeutet das für viele Teams: Es lohnt sich, den eigenen KI-Anteil im Code ehrlich einzuschätzen. Wer heute schon stark auf KI-Coding-Agenten setzt, kennt das Thema vermutlich bereits aus Diskussionen um Code-Reviews und Qualitätssicherung – etwa wenn es darum geht, wie viel Vertrauen man automatisiert generiertem Code ohne gründliche menschliche Prüfung entgegenbringen sollte. Codeberg macht aus dieser ohnehin geführten Debatte nun eine Plattformregel mit konkreten Konsequenzen für die Hosting-Berechtigung.

Für Nutzer, die primär aus Datenschutzgründen zu Codeberg wechseln oder dort bleiben, ist die zweite Abstimmung die eigentlich relevante Nachricht. Sie bekommen eine klare, mitgliedschaftlich legitimierte Zusage, dass ihre Beiträge nicht zum Trainingsmaterial für KI-Modelle werden – weder für Modelle von Codeberg selbst noch, so lässt sich die Formulierung lesen, für Dritte, denen Codeberg entsprechende Daten zur Verfügung stellen könnte.

Codeberg im größeren Kontext von KI-Regulierung und Plattformpolitik

Wichtig ist die saubere Trennung zwischen Plattformpolicy und geltendem Recht. Die beiden Codeberg-Beschlüsse ändern keine Gesetzeslage, sie ändern die Terms of Use einer einzelnen, wenn auch prominenten Plattform. Wer nach einer regulatorischen Einordnung sucht, sollte diese Entscheidung nicht mit einer gesetzlichen Vorgabe zum Umgang mit KI-Training oder KI-generiertem Code verwechseln. Es ist eine unternehmens- beziehungsweise vereinsinterne Selbstregulierung, die aus einer demokratischen Abstimmung der Mitglieder entstanden ist.

Für andere Plattformen und Foundations, die ähnliche Diskussionen führen, könnte Codeberg damit zu einem Referenzpunkt werden – nicht weil die Entscheidung automatisch übertragbar wäre, sondern weil sie zeigt, dass eine klare, mitgliedschaftlich abgestimmte Position zu diesen Fragen praktisch umsetzbar ist, ohne dass die Plattform dadurch handlungsunfähig würde. Ob andere Anbieter diesem Beispiel folgen, hängt stark von ihrer jeweiligen Governance-Struktur ab. Bei kommerziellen Plattformen mit Investoren dürfte eine vergleichbare Selbstverpflichtung deutlich schwerer durchzusetzen sein als bei einem Verein, dessen Mitglieder direkt mitbestimmen können.

Offene Fragen zur praktischen Umsetzung

Trotz der klaren Abstimmungsergebnisse bleiben praktische Fragen, die sich erst im Alltag der Plattform klären werden. Wie genau wird festgestellt, ob ein Projekt „überwiegend“ aus KI-generiertem Code besteht? Reicht eine Selbstauskunft der Projektbetreiber, oder wird Codeberg technische Prüfmechanismen einsetzen? Und wie geht die Plattform mit Grenzfällen um, bei denen KI-Unterstützung im Verlauf eines Projekts schrittweise zugenommen hat, ohne dass es einen klaren Zeitpunkt für einen Statuswechsel von „überwiegend menschlich“ zu „überwiegend KI-generiert“ gibt?

Auch bei der zweiten Abstimmung, dem Verzicht auf KI-Training mit Plattformdaten, bleibt abzuklären, wie Codeberg diese Zusage technisch und organisatorisch absichert. Eine Selbstverpflichtung ist nur so glaubwürdig wie ihre praktische Umsetzung – etwa durch entsprechende vertragliche Regelungen mit Dienstleistern, technische Zugriffsbeschränkungen oder Transparenzberichte, die zeigen, dass die Zusage eingehalten wird. Die vorliegende Berichterstattung liefert dazu noch keine Details, was angesichts des frischen Datums der Abstimmung wenig überraschend ist.

Was an dieser Geschichte über den konkreten Fall hinaus interessant bleibt, ist die Blaupause, die Codeberg hier liefert: eine Community, die sich aktiv und mit klarer Mehrheit gegen bestimmte Praktiken im Umgang mit generativer KI positioniert, statt die Entwicklung passiv über sich ergehen zu lassen. Für eine Branche, die sich gerade zwischen KI-Euphorie und wachsender Skepsis neu sortiert, ist das ein Beispiel, das man im Blick behalten sollte, unabhängig davon, ob man die konkreten inhaltlichen Entscheidungen teilt oder nicht.