Software & Quellcode
Ähnlicher Quellcode ist zunächst ein technischer Vergleichsbefund. Er kann eine Hypothese über gemeinsame Herkunft, Übernahme oder Ableitung stützen, beweist diese aber nicht automatisch. Für eine belastbare Untersuchung müssen konkrete Softwarestände, Vergleichsmethode, Granularität, Schwellenwerte, alternative Erklärungen, Versionshistorie und Aussagegrenzen gemeinsam betrachtet werden.
Kurzantwort
Eine technische Untersuchung von Codeübernahme sollte nicht mit einer einzelnen Prozentzahl zur Ähnlichkeit enden. Ein belastbarer Befund beschreibt, welche Codeeinheiten verglichen wurden, welche Normalisierungen erfolgten, mit welcher Methode und welchen Parametern Treffer entstanden und welche alternativen Ursachen für diese Treffer bestehen.
Besonders aussagekräftig wird ein Vergleich, wenn Inhaltsähnlichkeit mit Versionshistorie, zeitlicher Reihenfolge, unabhängigen Drittquellen, charakteristischen Besonderheiten und Gegenbelegen zusammengeführt wird.
1. Prüfgegenstand und Vergleichsgrundlage
Vor jedem Ähnlichkeitsvergleich muss feststehen, welche Softwarestände tatsächlich untersucht werden. Zwei Projektordner mit ähnlichen Namen sind noch keine reproduzierbare Vergleichsgrundlage.
Vergleichsstände müssen eindeutig festgelegt werden
Geeignete Bezugspunkte können konkrete Git-Commits, archivierte Quellcodebestände, ausgelieferte Versionen oder nachvollziehbar rekonstruierte Arbeitsstände sein. Für beide Seiten des Vergleichs sollten Herkunft, Zeitpunkt, Hashwerte und gegebenenfalls lokale Änderungen dokumentiert werden.
Wie Repository, Commit, Branch, Working Tree und Build voneinander abzugrenzen sind, erläutert der Beitrag Quellcode als Untersuchungsgegenstand .
Die Granularität bestimmt, was überhaupt verglichen wird
Ein Vergleich kann auf Dateiebene, Klassenebene, Funktions- oder Methodenebene oder auf kleineren Codeblöcken erfolgen. Unterschiedliche Granularitäten beantworten unterschiedliche Fragen und können zu unterschiedlichen Treffermengen führen.
Deshalb gehört die Vergleichseinheit ebenso zur Dokumentation wie die Auswahl- und Ausschlussregeln für Dateien, generierten Code, Bibliotheken, Tests oder Build-Artefakte.
2. Ähnlichkeit ist kein Herkunftsbeweis
Zwei Codefragmente können technisch ähnlich sein, ohne dass eines aus dem anderen übernommen wurde. Umgekehrt kann eine tatsächliche Übernahme durch Umbenennung, Umstrukturierung oder weitere Änderungen schwerer erkennbar werden.
Standardcode, Frameworks und gemeinsame Quellen können Ähnlichkeit erklären
Boilerplate, API-Vorgaben, Framework-Konventionen, automatisch erzeugter Code, verbreitete Beispiele, Open-Source-Komponenten oder dieselbe externe Vorlage können ähnliche Strukturen erzeugen.
Ein Treffer gewinnt daher nicht allein dadurch an Beweiskraft, dass zwei Fragmente viele identische Tokens besitzen. Zu prüfen ist auch, wie ungewöhnlich die übereinstimmenden Merkmale im jeweiligen technischen Kontext sind.
Auch unabhängige Entstehung ist eine Gegenhypothese
Bei kleinen, naheliegenden oder stark vorgegebenen Lösungen kann unabhängige Parallelentwicklung eine plausible Erklärung sein. Je stärker dagegen eine komplexe Kombination ungewöhnlicher Bezeichner, Kontrollflüsse, Kommentare, Fehler oder eigenwilliger Strukturen übereinstimmt, desto wichtiger wird eine vertiefte Prüfung.
Eine Codeähnlichkeitsanalyse kann Ähnlichkeit, strukturelle Beziehungen und technische Indizien für gemeinsame Herkunft untersuchen. Sie stellt nicht automatisch rechtliche Urheberschaft, eine Urheberrechtsverletzung, Vorsatz oder eine bestimmte Person als ursprünglichen Autor fest.
3. Clone-Typen und Vergleichsmethoden
Forschung zu Code-Clones unterscheidet verschiedene Formen von identischem, verändertem und strukturell oder semantisch ähnlichem Quellcode. Welche davon erkannt werden, hängt von Methode, Normalisierung und Parametern ab.
Clone-Typen beschreiben unterschiedliche Änderungsgrade
Eine verbreitete Taxonomie unterscheidet Type-1-Clones mit im Wesentlichen identischem Code, Type-2-Clones mit systematischen Änderungen beispielsweise an Bezeichnern, Type-3-Clones mit zusätzlichen, entfernten oder veränderten Anweisungen und Type-4-Clones, deren Ähnlichkeit stärker auf Verhalten oder Semantik beruht.
Diese Kategorien sind kein Beweismaß. Sie helfen vielmehr dabei, festzulegen, welche Art von Ähnlichkeit ein Verfahren überhaupt erfassen soll.
| Methode | Typischer Fokus | Stärke | Wichtige Grenze |
|---|---|---|---|
| Text-/Zeilenvergleich | Wörtliche oder nahezu wörtliche Übereinstimmung | Einfach nachvollziehbar | Empfindlich gegenüber Formatierung, Umbenennung und Umstrukturierung |
| Tokenvergleich | Lexikalische Struktur | Kann Formatierungsunterschiede teilweise abstrahieren | Ergebnis hängt von Tokenisierung, Normalisierung und Schwelle ab |
| Syntax-/Baumvergleich | Strukturelle Ähnlichkeit des Programmcodes | Kann syntaktische Beziehungen jenseits reinen Textvergleichs erfassen | Parser, Sprache und Baumrepräsentation beeinflussen den Befund |
| Semantisch orientierte Verfahren | Verhalten oder tiefere Programmbeziehungen | Kann stärker veränderte Implementierungen adressieren | Höherer Aufwand; keine universelle Erkennung funktional ähnlichen Codes |
Schwellenwerte und Normalisierung sind Teil der Methode
Ein Ergebnis wie „80 Prozent ähnlich“ besitzt ohne Methodenkontext nur geringe Aussagekraft. Unterschiedliche Werkzeuge können andere Einheiten, Ähnlichkeitsmaße, Mindestgrößen, Tokenisierungen und Schwellenwerte verwenden.
Warum ist ein Ähnlichkeitsprozentsatz nicht ohne Weiteres zwischen Werkzeugen vergleichbar?
Ein Prozentwert kann sich beispielsweise auf Textzeilen, Tokens, Mengenüberdeckung, Baumstrukturen oder werkzeugspezifische Maße beziehen. Schon eine andere Mindestgröße für Codeblöcke kann verändern, welche Kandidaten überhaupt in die Berechnung gelangen.
Deshalb müssen Messdefinition, Werkzeugversion, Parameter und Vorverarbeitung gemeinsam mit dem Ergebnis dokumentiert werden.
4. Treffer bewerten und Gegenbelege suchen
Clone-Detection erzeugt zunächst Kandidaten. Für eine sachverständige Untersuchung müssen relevante Treffer anschließend fachlich eingeordnet werden.
Normalisierung darf den Befund nicht künstlich erzeugen
Das Entfernen von Kommentaren, Vereinheitlichen von Formatierung oder Normalisieren von Bezeichnern kann sinnvoll sein, um oberflächliche Unterschiede auszublenden. Gleichzeitig kann aggressive Normalisierung charakteristische Unterschiede beseitigen.
Eine reproduzierbare Untersuchung sollte deshalb dokumentieren, welche Information vor dem Vergleich entfernt, vereinheitlicht oder transformiert wurde.
Charakteristische Übereinstimmungen müssen im Kontext bewertet werden
Besonders relevant können Kombinationen sein, die technisch nicht selbstverständlich wirken: ungewöhnliche Kontrollflüsse, identische seltene Fehler, dieselben atypischen Konstanten, eigenwillige Kommentare, ungewöhnliche Datenstrukturen oder übereinstimmende historische Zwischenstände.
Auch solche Merkmale sind nicht isoliert zu bewerten. Eine öffentlich verfügbare Drittquelle kann beispielsweise erklären, warum dieselbe ungewöhnliche Struktur in mehreren Projekten vorkommt.
| Evidenzbaustein | Kann stützen | Beweist allein nicht |
|---|---|---|
| Große identische Codeblöcke | Starke inhaltliche Übereinstimmung | Richtung oder Ursache der Übernahme |
| Near-Miss-Clones | Beziehung trotz Umbenennung oder lokaler Änderungen | Gemeinsame Herkunft |
| Seltene gemeinsame Besonderheiten | Höhere Spezifität eines Ähnlichkeitsbefunds | Urheberschaft einer bestimmten Person |
| Git-Historie | Existenz bestimmter Inhalte in dokumentierten Revisionen | Vollständige Entstehungsgeschichte oder rechtliche Autorenschaft |
| Frühere Drittquelle | Alternative Herkunftserklärung für gemeinsame Fragmente | Automatisch, wer die Quelle tatsächlich nutzte |
Ist ein Ähnlichkeitsbefund technisch belastbar?
- Sind beide Vergleichsstände eindeutig identifiziert und gesichert?
- Ist festgelegt, welche Dateien und Codeeinheiten einbezogen oder ausgeschlossen wurden?
- Sind Werkzeug, Version, Parameter, Schwellenwerte und Normalisierung dokumentiert?
- Wurden Treffer nach Typ, Größe, Lage und Charakteristik untersucht?
- Wurden Frameworkcode, Bibliotheken, generierter Code und öffentliche Drittquellen geprüft?
- Wurden plausible Gegenhypothesen und Gegenbelege aktiv gesucht?
- Wurde der Inhaltsvergleich mit zeitlicher beziehungsweise historischer Evidenz abgeglichen?
- Sind Befund, Interpretation, Bewertung und Aussagegrenze getrennt dokumentiert?
5. Provenienz und zeitlicher Kontext
Ein Inhaltsvergleich beantwortet zunächst die Frage, wie ähnlich zwei technische Artefakte sind. Für eine Herkunftshypothese ist zusätzlich relevant, wann welche Version nachweisbar vorlag und welche Beziehungen zwischen den Beständen dokumentiert sind.
Zeitliche Reihenfolge kann Hypothesen stützen oder schwächen
Ist ein charakteristisches Fragment in einem nachvollziehbaren früheren Stand eines Projekts vorhanden und erscheint es erst später in einem anderen Bestand, ist dies eine andere Evidenzlage als bei zwei undatierten ZIP-Archiven.
Zeitstempel allein reichen jedoch nicht. Git-Metadaten, exportierte Dateien, Dateisystemzeiten und Build-Zeitpunkte besitzen jeweils eigene Aussagegrenzen. Der Beitrag Git-Historie und Software-Provenienz technisch untersuchen behandelt diese Trennung ausführlich.
Eine belastbare Analyse sollte deshalb Inhaltsähnlichkeit und Provenienz nicht vermischen, sondern als unterschiedliche Evidenzebenen dokumentieren und erst in der fachlichen Synthese zusammenführen.
6. Sachverständige Synthese und Aussagegrenzen
Die Schlussfolgerung sollte stärker sein als eine bloße Trefferliste, aber nicht weiter reichen als die tatsächlich geprüfte Evidenz.
Eine geeignete Struktur lautet: technischer Befund → mögliche Interpretation → Prüfung konkurrierender Erklärungen → fachliche Bewertung → ausdrückliche Aussagegrenze.
Reproduzierbare Dokumentation gehört zum Ergebnis
Für wesentliche Befunde sollten Vergleichsstände, Hashwerte, Werkzeuge, Werkzeugversionen, Parameter, Ausschlussregeln, Trefferkennungen und relevante Ergebnisartefakte nachvollziehbar festgehalten werden.
Ein fachkundiger Dritter sollte erkennen können, aus welcher Untersuchungsgrundlage ein konkreter Treffer entstanden ist und welche Bearbeitungsschritte zwischen Ausgangsartefakt und Bewertung lagen.
Konstruiertes Beispiel
Zwei Java-Projekte enthalten eine jeweils etwa 70 Zeilen lange Methode mit weitgehend identischem Kontrollfluss. Variablennamen wurden verändert, mehrere Log-Ausgaben fehlen und einzelne Bedingungen wurden umgestellt.
Ein tokenbasierter Vergleich und ein struktureller Vergleich markieren die Methoden als starke Ähnlichkeitskandidaten. Zusätzlich findet sich in beiden Methoden dieselbe ungewöhnliche Konstante und derselbe atypische Randfall.
Der technische Befund lautet zunächst: Zwischen den beiden Methoden bestehen umfangreiche lexikalische und strukturelle Übereinstimmungen.
Anschließend werden Gegenhypothesen geprüft. Die fragliche Struktur findet sich nicht im eingesetzten Framework und nicht in einer identifizierten öffentlichen Drittquelle. Eine Repository-Historie zeigt außerdem, dass ein vergleichbarer Stand in Projekt A zeitlich früher dokumentiert ist als in Projekt B.
Diese Kombination kann die Hypothese einer technischen Ableitung stärker stützen als der reine Ähnlichkeitswert. Sie beweist dennoch nicht allein, welche Person den Code geschaffen hat, auf welchem rechtlichen Weg eine mögliche Übernahme erfolgte oder ob eine Rechtsverletzung vorliegt.
Das Beispiel ist vollständig konstruiert und stellt kein reales Mandat und keine gerichtliche Beauftragung dar.
Quellen und fachliche Grundlage
- Wissenschaftliche Übersichtsarbeit Chanchal K. Roy, James R. Cordy und Rainer Koschke: Comparison and evaluation of code clone detection techniques and tools: A qualitative approach . Science of Computer Programming, 74(7), 2009, 470–495. Taxonomie von Clone-Typen, Methodenfamilien und verfahrensabhängigen Erkennungsgrenzen. Geprüft am 17.10.2026.
- Wissenschaftliche Facharbeit Chanchal K. Roy und James R. Cordy: NICAD: Accurate Detection of Near-Miss Intentional Clones Using Flexible Pretty-Printing and Code Normalization . ICPC 2008. Parsergestützter Near-Miss-Vergleich mit Normalisierung. Geprüft am 17.10.2026.
- Wissenschaftliche Facharbeit Lingxiao Jiang, Ghassan Misherghi, Zhendong Su und Stéphane Glondu: DECKARD: Scalable and Accurate Tree-Based Detection of Code Clones . ICSE 2007, 96–105. Baum- beziehungsweise strukturorientierter Codevergleich. Geprüft am 17.10.2026.
- Wissenschaftliche Facharbeit Hitesh Sajnani, Vaibhav Saini, Jeffrey Svajlenko, Chanchal K. Roy und Cristina V. Lopes: SourcererCC: Scaling Code Clone Detection to Big Code . ICSE 2016, 1157–1168. Tokenbasierte Clone-Erkennung für große Codebestände. Geprüft am 17.10.2026.
- Technische Primärquelle Git-Projekt: gitrevisions und git-cat-file . Technische Bezugspunkte für Revisionen und Git-Objekte. Geprüft am 17.10.2026.
- Eigene veröffentlichte Methodik Quellen und Methodik . Trennung von Fragestellung, Untersuchungsgegenstand, Untersuchungsgrundlage, Referenzmaßstab, Methode, Befund, Interpretation, Bewertung und Aussagegrenze.
- Eigene veröffentlichte Vertiefung Git-Historie und Software-Provenienz technisch untersuchen . Technische Provenienz und Inhaltsähnlichkeit werden dort als unterschiedliche Evidenzebenen abgegrenzt.
- Eigene fachliche Einordnung Die konkrete Kombination aus Clone-Detection, manueller Trefferprüfung, Drittquellenrecherche, Versionshistorie, Gegenhypothesen und technischer Synthese richtet sich nach Fragestellung, Programmiersprache, Vergleichsumfang und verfügbarer Untersuchungsgrundlage.
Weiterführende Beiträge
Zur Rekonstruktion zeitlicher und technischer Herkunftsbezüge siehe Git-Historie und Software-Provenienz technisch untersuchen .
Wie der konkrete Quellcodestand für eine reproduzierbare Untersuchung bestimmt werden kann, erläutert Quellcode als Untersuchungsgegenstand: Repository, Commit, Branch und Build .
Welche Unterlagen vor einer Softwareuntersuchung typischerweise benötigt werden, beschreibt Welche Unterlagen benötigt ein IT-Sachverständiger bei Streit über Individualsoftware? .
Der gemeinsame Quellen- und Dokumentationsstandard ist unter Quellen und Methodik beschrieben.
Muss geklärt werden, ob Quellcode technisch übernommen oder abgeleitet wurde?
Ich untersuche konkrete Softwarestände, Ähnlichkeitsbefunde, Versionshistorie, Drittquellen und alternative Erklärungen. Technischer Befund, Interpretation und Aussagegrenzen werden nachvollziehbar voneinander getrennt.
Software-Gutachten ansehen