GitHub gehört Microsoft. Zeit für einen Ausweg.

GitHub ist kein neutraler Ort, an dem zufällig viel Software entsteht, sondern seit 2018 vollständig ein Microsoft-Produkt, mit allen Konsequenzen, die das mit sich bringt. Wer Code dort hostet, entwickelt oder auch nur benutzt, ohne es zu wissen, weil die eigene Vereinssoftware zufällig darüber gepflegt wird, arbeitet mit der Infrastruktur eines der größten US-Konzerne der Welt. Das lässt sich ändern, und es sollte geändert werden. Aber bevor es um den Ausweg geht, lohnt sich ein Blick darauf, warum es überhaupt einen braucht.

Der Cloud Act kennt keine Landesgrenzen

Am 11. Juni 2018 kündigte Microsoft an, GitHub für 7,5 Milliarden US-Dollar in Aktien zu übernehmen. Am 26. Oktober 2018 war der Deal abgeschlossen. Seitdem ist GitHub keine eigenständige Firma mehr, sondern eine Konzerntochter, und als solche unterliegt sie dem US Cloud Act. Das ist ein amerikanisches Gesetz, das US-Behörden erlaubt, von US-Unternehmen gespeicherte Daten anzufordern, unabhängig davon, wo auf der Welt die Server physisch stehen. Stell es dir wie einen Hausdurchsuchungsbefehl vor, der an der Konzerngrenze endet: Solange die Firma amerikanisch ist, ist es egal, in welchem Land der Aktenschrank steht.

Ich will hier ehrlich sein, weil Übertreibung der eigenen Sache mehr schadet als nützt: Einen öffentlich dokumentierten Fall, in dem GitHub per Cloud Act tatsächlich Repository-Daten an US-Behörden herausgeben musste, gibt es nicht. Die rechtliche Möglichkeit ist strukturell gegeben, weil GitHub eine US-Firma und Microsoft-Tochter ist, aber sie ist bislang ein theoretisches Risiko, kein belegter Präzedenzfall.

Was dagegen sehr wohl belegt ist: Im Juli 2019 sperrte GitHub unter Berufung auf US-Exportkontrollrecht Konten von Nutzer*innen aus Iran, Syrien und der Krim. Private Repositories, kostenpflichtige Funktionen und der Marketplace waren betroffen, öffentliche Repositories blieben zugänglich. Bis heute gilt laut GitHubs eigener Richtlinie: Konten mit Bezug zur Krim, zu Donetsk oder Luhansk sind auf Lesezugriff beschränkt, Nordkorea ist komplett gesperrt. Hier hört das Hypothetische auf: Eine amerikanische Firma setzt US-Außenpolitik gegenüber ihren Nutzer*innen durch, unabhängig davon, was die betroffenen Menschen mit Politik zu tun haben.

Copilot trainiert mit Code, den andere geschrieben haben

Die eigentliche Bruchstelle zwischen GitHub und der Open-Source-Community kam nicht durch den Cloud Act, sondern durch Copilot. GitHubs KI-Assistent schlägt beim Programmieren automatisch Code vor, trainiert auf gewaltigen Mengen öffentlich verfügbaren Quellcodes, darunter jede Menge unter Open-Source-Lizenzen veröffentlichter Projekte. Am 3. November 2022 wurde deshalb die Sammelklage „Doe v. GitHub” eingereicht, gegen GitHub, Microsoft und OpenAI gemeinsam. Der Vorwurf: fremder, urheberrechtlich geschützter Code sei ohne Zustimmung der Urheber*innen zum Training verwendet worden. Ein Gericht wies große Teile der Klage später ab, unter anderem den Vorwurf identischer Code-Kopien. Übrig blieben Ansprüche wegen Verletzung von Open-Source-Lizenzbedingungen, im Oktober 2024 ging der Fall in Berufung, im Januar 2026 lief die Beweisaufnahme noch. Ein Urteil steht aus.

Für die Software Freedom Conservancy war das schon 2022 Grund genug zu handeln, lange bevor das Gerichtsverfahren überhaupt begann. Unter der Überschrift „Give Up GitHub” kündigte die Organisation am 30. Juni 2022 an, jede eigene Nutzung von GitHub zu beenden, und half ihren Mitgliedsprojekten beim Umzug. Anfang 2026 folgte Gentoo Linux, eines der bekannteren Linux-Projekte überhaupt. Die Begründung im eigenen Jahresrückblick war unmissverständlich: wiederholte Versuche, Copilot-Nutzung für die eigenen Repositories zu erzwingen. Am 16. Februar 2026 ging die offizielle Gentoo-Präsenz bei Codeberg live, die Migration läuft seither schrittweise.

Und dann kam der nächste Schritt, der die Sache endgültig persönlich macht. Ab dem 24. April 2026 verwendet GitHub Interaktionsdaten von Copilot standardmäßig für KI-Training, für Nutzer*innen der kostenlosen und der günstigeren Bezahlstufen. Eingaben, Ausgaben, Code-Kontext, alles fließt ein, sofern niemand aktiv widerspricht. Wer nichts tut, hat automatisch zugestimmt. Nur Business- und Enterprise-Kund*innen sind ausgenommen, wer zahlt, wird verschont, wer die kostenlose Stufe nutzt, liefert Trainingsmaterial.

Warum das auch dich betrifft, wenn du nie eine Zeile Code geschrieben hast

Vielleicht denkst du jetzt, das sei ein Problem für Programmierer*innen, nicht für dich. Das stimmt nicht. Ein Repository ist im Grunde ein digitaler Aktenordner für Quellcode, in dem jede Änderung nachvollziehbar gespeichert wird, wer sie gemacht hat und wann. Genau in solchen Ordnern liegt die Software, die du längst täglich benutzt, ohne es zu merken: der Passwort-Manager, das Vereinsverwaltungstool, das Blog-System, mit dem dein Verein oder dein kleines Unternehmen arbeitet. Diese Software wird irgendwo entwickelt und verteilt, und für einen erschreckend großen Teil davon heißt der Ort GitHub.

Wenn ein IT-Dienstleister für deinen Verein oder dein Unternehmen Software entwickeln lässt, lohnt sich deshalb eine einzige, unbequeme Frage: Wo landet der Code eigentlich? Liegt er bei GitHub, unterliegt er derselben strukturellen Cloud-Act-Bindung, derselben Möglichkeit zur Kontosperrung nach US-Exportrecht, derselben Trainingsdatenpolitik, egal ob dein Verein das je bemerkt. Wer im Zweifel Kontrolle über die Werkzeuge deines Vereins oder Unternehmens hat, entscheidet sich genau an dieser Stelle, nicht erst, wenn etwas passiert.

Codeberg: gemeinnützig, europäisch, ohne Konzern im Rücken

Die naheliegende Alternative heißt Codeberg. Codeberg ist kein Unternehmen, sondern ein 2018 gegründeter, gemeinnütziger eingetragener Verein nach deutschem Recht mit Serverstandort Berlin, finanziert ausschließlich über Spenden und Mitgliedsbeiträge. Es gibt kein Bezahlmodell für Nutzer*innen, es gibt keinen Konzern, der Trainingsdaten sammelt, es gibt keine Aktionär*innen, denen Wachstum geschuldet wäre. Stand November 2025 zählte Codeberg über 200.000 registrierte Nutzer*innen und mehr als 300.000 Repositories, mit 1.208 Vereinsmitgliedern, von denen 786 stimmberechtigt sind. Eine Plattform, die tatsächlich denen gehört, die sie nutzen, kein Marketingversprechen, sondern Vereinsstruktur.

Technisch läuft Codeberg auf Forgejo, und die Entstehungsgeschichte von Forgejo ist selbst schon eine Warnung davor, wie schnell aus einem offenen Projekt ein kommerzielles wird. Forgejo ist ein Fork von Gitea, entstanden im Oktober 2022, nachdem bekannt wurde, dass der Gitea-Lead-Maintainer Marken, Domains und Betrieb still an eine gewinnorientierte GmbH übertragen hatte. Ein offener Brief von Gitea-Mitwirkenden mit der Forderung nach echter Community-Kontrolle wurde abgelehnt. Anfang 2024 folgte der vollständige, unabhängige Hard Fork, seither wird Forgejo unter dem Dach des gemeinnützigen Codeberg e.V. weiterentwickelt. Wer glaubt, Kommerzialisierung passiere nur bei den großen Namen wie GitHub, sollte sich diese Geschichte merken.

Ein Pull Request, den es sowohl bei GitHub als auch bei Codeberg gibt, ist im Grunde ein Änderungsvorschlag: Jemand schlägt eine Verbesserung am Code vor, andere prüfen sie gegen, bevor sie übernommen wird, ungefähr wie ein redigierter Textentwurf, der erst nach Freigabe in die Endfassung übernommen wird. Dieses Kernstück der Zusammenarbeit funktioniert bei Codeberg genauso gut wie bei GitHub. Es gibt keinen funktionalen Nachteil beim eigentlichen Code-Hosting.

Wo Codeberg noch an Grenzen stößt

Ehrlichkeit gehört zu einer glaubwürdigen Empfehlung dazu, und deshalb verschweige ich nicht, wo Codeberg aktuell schwächelt: bei CI/CD. Continuous Integration und Continuous Deployment, kurz CI/CD, ist im Grunde ein automatisiertes Fließband für Software: Bei jeder Änderung wird der Code automatisch getestet, gebaut und im besten Fall gleich auf einem Server ausgeliefert, ohne dass jemand jeden Schritt von Hand anstoßen muss. Bei GitHub heißt diese Funktion GitHub Actions, bei GitLab GitLab CI/CD, bei Codeberg läuft sie über eine externe Lösung namens Woodpecker CI.

Und genau hier zeigt sich der Ressourcenunterschied zwischen einem spendenfinanzierten Verein und einem milliardenschweren Konzern. Der Zugang zu Woodpecker CI bei Codeberg ist kein Self-Service, sondern erfordert ein manuelles Freischaltverfahren über ein Issue, das laut Codeberg-eigener Dokumentation von Freiwilligen „innerhalb weniger Stunden” geprüft wird. Unterstützt wird ausschließlich Linux/amd64 als Build-Ziel, und die Rechteverwaltung beschränkt sich auf eine einfache Unterscheidung zwischen Admin und normalem Nutzerkonto, was differenzierte Teamberechtigungen erschwert. Für ein einfaches privates Repository, bei dem es vor allem um Code-Hosting, Issues und Pull Requests geht, spielt das keine Rolle. Für ein Projekt, das bei jedem Codeupdate automatisch auf einem Server ausgerollt werden soll, ist das eine spürbare Hürde.

Selbst gehostetes GitLab schließt die Lücke, verlangt aber Verantwortung

Genau an dieser Stelle kommt selbst gehostetes GitLab Community Edition ins Spiel. GitLab CE steht unter MIT-Lizenz, ist kostenlos, und Community sowie Enterprise Edition teilen sich denselben Code: Ohne kostenpflichtigen Lizenzschlüssel laufen beide im identischen Kernfunktionsumfang. Das Herzstück ist Auto DevOps: GitLab erkennt automatisch, in welcher Programmiersprache ein Projekt geschrieben ist, und richtet eine einsatzbereite Pipeline für Build, Test, Sicherheitsanalyse und Deployment ein, ganz ohne von Hand geschriebene Konfigurationsdatei. Ein sogenannter GitLab Runner verbindet sich mit der eigenen Instanz und führt jeden Arbeitsschritt isoliert aus, üblicherweise in einem eigenen Container. Für Projekte, bei denen jede Codeänderung automatisch auf einem Server landen soll, wie es beispielsweise bei chrislo.de selbst der Fall ist, ist das genau die Lücke, die Codeberg aktuell noch offenlässt.

Der Preis dafür ist Eigenverantwortung, und die ist nicht klein. GitLabs eigene Dokumentation nennt für eine Single-Node-Installation einen Richtwert von 8 vCPU und 16 GB RAM, minimal 8 GB in ressourcenknappen Umgebungen, dazu mindestens 40 GB Speicher für die Anwendung selbst, zusätzlich zum Platz für Repositories und Datenbank. Das ist kein Projekt, das mal eben auf einem Raspberry Pi im Schrank läuft. Und Ressourcen sind nur die halbe Miete. Im April 2026 behob GitLab in einem Patch-Release elf bis zwölf Sicherheitslücken in Community und Enterprise Edition, darunter eine mit dem Schweregrad 8,5 von 10, die es niedrigprivilegierten, authentifizierten Angreifer*innen erlaubte, Zugriffskontrollen über einen WebSocket-Endpunkt zu umgehen. GitLab.com, der von GitLab selbst gehostete Dienst, war sofort geschützt. Wer selbst hostet, blieb verwundbar, bis die Aktualisierung manuell eingespielt wurde. Wer sich für Self-Hosting entscheidet, übernimmt genau diese Pflicht selbst, bei jedem einzelnen Patch-Release wieder: Bleibt die Aktualisierung liegen, bleibt auch die Lücke mit dem Schweregrad 8,5 offen, erreichbar für jeden, der danach sucht.

Was ich selbst mache

Ich praktiziere das, was ich hier empfehle, und zwar nicht als Lippenbekenntnis. chrislo.de liegt als privates Repository bei Codeberg, kein GitHub, nirgends. FediSuite und APBoard Next Generation, zwei meiner eigenen Open-Source-Projekte, liegen teils ebenfalls bei Codeberg, teils in meinem eigenen, selbst gehosteten GitLab, je nachdem, ob automatisiertes Deployment gebraucht wird oder nicht. Für den Blog, den du gerade liest, reicht Codeberg vollkommen, weil das Deployment über einen eigenen, separaten Prozess läuft. Für Projekte, bei denen jede Änderung direkt live gehen soll, nutze ich mein eigenes GitLab, weil Auto DevOps mir genau die automatisierte Pipeline gibt, die Codeberg aktuell nicht hat. Zwei Werkzeuge, zwei Zwecke, keine Ausrede.

Was das für dich bedeutet

Wenn du oder dein Verein Software entwickeln lässt, ohne komplexe automatisierte Deployment-Anforderungen, ist die Antwort einfach: Codeberg, und zwar sofort. Es kostet nichts, es unterliegt keinem US-Recht, es gehört einem gemeinnützigen Verein, und für Code-Hosting, Issues und Pull Requests fehlt funktional nichts gegenüber GitHub. Es gibt keinen vernünftigen Grund mehr, neue Projekte bei einer Microsoft-Tochter anzulegen, deren Copilot mit fremdem Code trainiert und deren Eigentümer dem Cloud Act unterliegt.

Erst wenn automatisiertes Deployment eine echte Anforderung ist, wenn also jede Codeänderung ohne manuellen Zwischenschritt auf einem Server landen soll, wird es komplizierter. Dann kommst du aktuell an selbst gehostetem GitLab kaum vorbei, weil Codebergs Woodpecker CI mit dem manuellen Freischaltverfahren und der eingeschränkten Rechteverwaltung diese Anforderung schlicht nicht in der Ausbaustufe abdeckt, die ein eigener GitLab-Server hat. Dann kombinierst du Codeberg für Code-Hosting mit einem eigenen GitLab-Runner für das Deployment, oder du hostest gleich vollständig selbst. Beides bleibt in europäischer, nicht konzerngebundener Hand. Nur eben mit dem Unterschied, dass Self-Hosting Verantwortung bedeutet, die du entweder selbst trägst oder an jemanden abgibst, der sie ernst nimmt.

Was du niemals mehr tun solltest: einfach GitHub nehmen, weil es der Standard ist, ohne die Frage überhaupt zu stellen. Genau diese Gedankenlosigkeit ist es, die einen US-Konzern mit fragwürdiger KI-Trainingspolitik und laufendem Rechtsstreit zum unangefochtenen Standard gemacht hat.

Wenn du bei deinem eigenen Projekt oder in deinem Verein nicht mehr wissen willst, ob dein Code gerade Trainingsmaterial für Copilot ist, sondern es einfach anders machen willst: Ich begleite Migrationen von GitHub zu Codeberg genauso wie den Aufbau eines eigenen, selbst gehosteten GitLab mit Auto DevOps, inklusive Server-Härtung und einer Update-Routine, die dafür sorgt, dass Sicherheitslücken wie die vom April 2026 nicht wochenlang offenstehen.

Reden wir über deinen Code.

Schreib mir eine E-Mail: Kurz beschreiben, was du vorhast oder was dich beschäftigt. Ich melde mich in der Regel innerhalb eines Werktages. hallo@chrislo.de

Kein Kontaktformular, keine Pflichtfelder, keine Datenspur. Einfach schreiben.