Git-Logs als rechtliche Beweismittel: Was Entwickler wissen müssen

Die Auseinandersetzung zwischen Orca Security und Wiz hat 2024 eine klare Botschaft an die Tech-Branche gesendet: Entwicklungsverläufe in Git sind längst keine bloßen Protokolldateien mehr, sondern potenziell gerichtsverwertbare Beweismittel. Die Klägerin forderte nicht weniger als die vollständige Historie des Versionskontrollsystems des Gegners – inklusive aller Kommentare, Notizen und Code-Änderungen. Das Gericht erkannte die Relevanz dieser Daten an, beschränkte jedoch die Anfrage auf zwei konkrete Funktionen. Diese Entscheidung markiert einen Wendepunkt: Git-Repositories sind heute Beweisketten für geistiges Eigentum.

Eine kryptografische Beweiskette entsteht

Jeder Git-Commit enthält fünf essenzielle Metadaten: Den Code-Änderungstext, den Namen und die E-Mail-Adresse des Autors, den Zeitpunkt der Erstellung, den Namen und die E-Mail des Committers sowie den Zeitpunkt der finalen Übernahme. Diese Informationen werden mit einem kryptografischen Hash – aktuell SHA-1 oder SHA-256 – versehen, der wiederum vom Hash des Eltern-Commits abhängt. Selbst eine minimale Änderung in einer früheren Version würde alle nachfolgenden Hashes ungültig machen. Diese Struktur entspricht einem Merkle-DAG, demselben Prinzip, das auch Blockchains fälschungssicher macht.

Git generiert dabei drei verschiedene Zeitstempel: Der AuthorDate markiert den Moment der ursprünglichen Code-Erstellung, der CommitterDate den Zeitpunkt der finalen Übernahme in das Repository. Der dritte Zeitstempel stammt vom Hosting-Anbieter wie GitHub oder GitLab und dokumentiert den Empfangszeitpunkt auf dem Server. Während die ersten beiden Zeitstempel vom Entwickler beeinflusst werden können, ist der dritte extern verifiziert und daher besonders wertvoll für rechtliche Zwecke.

Ein zentrales Merkmal von Git ist die dezentrale Natur des Systems. Jede Kopie eines Repositories enthält die vollständige Historie – auf den Maschinen der Entwickler, in CI-Pipelines, in Backups oder bei externen Dienstleistern. Forensiker bezeichnen dies als „Beweismittel-Proliferation“. Selbst wenn ein Angreifer oder ein versehentliches Löschen eine Kopie manipuliert, bleiben 49 unveränderte Repliken als Referenz bestehen. Nach Regel 902(14) der US-amerikanischen Bundesbeweisordnung gelten digital verifizierte Daten als selbstauthentifizierend. Die Hash-Validierung eines Git-Commits erfüllt diese Anforderung und macht die Historie gerichtsverwertbar.

Wie Git-Historien vor Gericht eingesetzt werden – und welche Fallstricke es gibt

Der Fall Orca v. Wiz demonstrierte, dass Gerichte Git-Logs als relevante Beweismittel anerkennen, jedoch nicht jede Anfrage pauschal zulassen. Statt einer vollständigen Offenlegung aller Commits beschränkte das Gericht die Herausgabe auf zwei spezifische Funktionen. Diese Präzision unterstreicht einen wichtigen Punkt: Eine strukturierte, sauber attribuierte Git-Historie ist vor Gericht wertvoller als ein ungeordnetes Monorepo-Dump. Entwickler sollten daher darauf achten, dass jeder Commit klar zuordenbar ist und sinnvolle Commit-Nachrichten enthält.

Ein Gegenbeispiel liefert der Fall Krause v. Titleserv: Ein unabhängiger Auftragnehmer entwickelte über zehn Jahre hinweg 35 Programme für ein Unternehmen – ohne je eine schriftliche IP-Übertragung zu vereinbaren. Als die Zusammenarbeit endete, fehlte beiden Parteien eine klare Dokumentation, wer welchen Code verfasst hatte. Der Auftragnehmer nahm sein Notizbuch mit, das die einzige Kopie des Quellcodes enthielt, während das Unternehmen nur die lauffähigen Executables besaß. Der Second Circuit benötigte Jahre, um die Urheberschaft zu klären – ein Prozess, der mit einer sauberen Git-Historie in wenigen Stunden hätte abgeschlossen werden können.

Ähnlich desaströs endete der Fall SCO v. IBM. SCO konnte vor Gericht keine konkreten Code-Zeilen vorlegen, die IBM angeblich kopiert hatte. Der Richter bezeichnete dies als „erstaunlich“ und verwies darauf, dass eine detaillierte Versionierung mit klaren Urheberangaben die Beweisführung erheblich erleichtert hätte. Ohne solche Nachweise blieb SCOs Klage ohne substanzielle Grundlage.

Ein aktueller Fall mit potenziell weitreichenden Konsequenzen ist Doe v. GitHub, eine Sammelklage gegen Copilot. Die Kläger argumentieren, GitHub habe Urheberangaben aus Trainingsdaten entfernt, was gegen den Digital Millennium Copyright Act (DMCA) verstößt. Paragraf 1202(b) schützt „Copyright-Management-Informationen“, zu denen auch der Name eines Autors in einem Git-Commit gehört. Die Löschung dieser Metadaten könnte eine rechtliche Verletzung darstellen. Der Fall ist noch nicht entschieden, doch er zeigt, wie kritisch die korrekte Handhabung von Attributionsdaten sein kann.

Typische Fehler: Wie Entwickler ihre eigenen Beweise vernichten

Der wohl häufigste Fehler ist das Squash-Merging. Ein Pull Request mit 15 einzelnen Commits wird dabei zu einem einzigen Commit zusammengefasst. Bis Dezember 2019 wurde dieser Squash-Commit standardmäßig demjenigen Entwickler zugeordnet, der den Merge-Button drückte – die ursprünglichen Autoren verschwanden aus der Historie. Selbst mit modernen Co-Author-Trailern geht die granulare Zeitachse verloren. Fünfzehn Datenpunkte werden auf einen reduziert, was die Beweiskraft erheblich schwächt.

Ein weiteres Problem stellt das Rebasing dar. Durch das Neuordnen von Commits oder das Ändern der Historie werden die kryptografischen Hashes ungültig. Ein git push --force überschreibt die Remote-Historie – und damit die einzige unveränderte Kopie. Die Beweiskette ist gebrochen, und das Gericht könnte argumentieren, dass die Historie manipuliert wurde. Eine Studie analysierte 111 Millionen Repositories und fand 1,22 Millionen mit veränderter Historie – in den meisten Fällen aus trivialen Gründen wie nachträglichen Lizenzanpassungen oder der Entfernung versehentlich committeter Passwörter. Aus rechtlicher Sicht untergräbt jede solche Manipulation die Glaubwürdigkeit der gesamten Historie.

Ein oft unterschätzter Risikofaktor sind geteilte Commit-Accounts. Teams nutzen häufig generische E-Mail-Adressen wie deploy@firma.de oder Bot-Konten für CI/CD-Pipelines. Eine Untersuchung von über zwei Milliarden Commits identifizierte über 23 Millionen verschiedene Autor-Identitäten – mit erheblichen Problemen bei der Zuordnung zu realen Personen. Wenn Commits einem geteilten Konto zugeordnet sind, ist die Urheberschaft nicht mehr nachweisbar. Dies ist besonders kritisch in Streitfällen, in denen einzelne Entwickler ihre Beiträge belegen müssen.

Ein weiterer kritischer Moment ist das Verlassen eines Unternehmens. Viele Entwickler verlieren nach ihrem Austritt den Zugriff auf die Repositories. Wird das Repository später gelöscht, migriert oder das Unternehmen aufgelöst, geht die gesamte Provenienz verloren. GitHub bietet zwar eine 90-tägige Frist zur Wiederherstellung gelöschter Repositories, doch danach ist die Historie unwiederbringlich verloren. Jahre der Arbeit hinterlassen keine digitale Spur mehr.

Drei Mythen über Urheberrecht in der Softwareentwicklung

Der erste Mythos lautet: Wer für Code bezahlt, besitzt ihn. Das stimmt nicht. Nach § 201 des US-Urheberrechtsgesetzes (17 U.S.C. § 201) gilt der Urheber als Eigentümer, es sei denn, es gibt eine explizite schriftliche Vereinbarung über eine „Work-for-Hire“-Regelung. Für Freelancer ist diese Ausnahme jedoch kaum anwendbar, da Softwareentwicklung nicht zu den neun gesetzlich definierten Kategorien gehört. Eine Analyse des CCB Journals kommt zu dem Schluss, dass die „Work-for-Hire“-Doktrin „in Softwareverträgen fast nie funktioniert“.

Der zweite Mythos betrifft die implizite Übertragung von Rechten. Viele Entwickler gehen davon aus, dass ein mündliches Einverständnis oder eine E-Mail ausreicht, um die Urheberrechte zu übertragen. Doch nach US-Recht sind solche Vereinbarungen ohne schriftliche Fixierung nichtig. Selbst wenn ein Unternehmen die Rechte an einem Projekt beansprucht, bleibt der ursprüngliche Entwickler rechtlich geschützt – es sei denn, es gibt eine klare, notariell beglaubigte Abtretung.

Der dritte Mythos ist die Annahme, dass Open-Source-Lizenzen automatisch die Rechte klären. Viele Entwickler nutzen Code unter MIT-, Apache- oder GPL-Lizenzen, ohne zu prüfen, ob die ursprünglichen Urheberrechte korrekt attribuiert sind. Doch selbst bei Open-Source-Projekten bleibt die individuelle Urheberschaft bestehen. Wer Code in ein proprietäres Projekt integriert, ohne die Lizenzbedingungen zu beachten, riskiert rechtliche Konflikte – besonders wenn die Git-Historie die Herkunft nicht mehr nachverfolgbar macht.

Mit diesen Erkenntnissen wird klar: Git ist nicht nur ein Werkzeug für die Softwareentwicklung, sondern auch eine digitale Beweiskette für geistiges Eigentum. Die Art und Weise, wie Teams ihre Historie pflegen, entscheidet darüber, ob diese Kette vor Gericht Bestand hat – oder ob jahrelange Arbeit in einem Rechtsstreit wertlos wird. Entwickler sollten daher proaktiv Maßnahmen ergreifen: klare Commit-Nachrichten, Vermeidung von Squash-Merges in kritischen Branches, regelmäßige Backups der Historie und die Dokumentation von Urheberrechtsübertragungen. Nur so lässt sich die digitale Spur sichern – bevor ein Gericht sie einfordert.