Ratgeber · Recht & Datenschutz
Urheberrecht an Source-Code und Binary: Was § 69a UrhG wirklich schützt
Quellcode geniesst urheberrechtlichen Schutz nach einem Sonder-Regime, das von normalen Werken abweicht. Wir klären, was geschützt ist, was nicht, und welche Verpflichtungen Open-Source-Lizenzen wie MIT, GPL und Apache mit sich bringen.
Software ist seit den 1980er Jahren urheberrechtlich geschützt, und zwar nach einem besonderen Regime, das vom normalen Urheberrechts-Recht abweicht. Wer einen Quellcode schreibt, eine Anwendung kompiliert oder eine Bibliothek verteilt, sollte die wichtigsten Regeln kennen. Wir gehen die Grundlagen durch und beleuchten den Sonderfall der reinen Binärdarstellung von Texten, wie sie binaerkonverter.de produziert.
§ 69a UrhG: Der Schutz für Computerprogramme
Im deutschen Urheberrechtsgesetz steht der Schutz für Computerprogramme in den §§ 69a bis 69g UrhG. Diese Vorschriften wurden 1993 in Umsetzung der EU-Computerprogramm-Richtlinie (91/250/EWG, später ersetzt durch 2009/24/EG) eingeführt und schützen Software als eigene Werkkategorie neben Sprachwerken, Musik und Bildkunst.
Die wichtigste Regelung steht in § 69a Abs. 3 UrhG: Computerprogramme sind geschützt, wenn sie individuelle Werke in dem Sinne darstellen, dass sie das Ergebnis der eigenen geistigen Schöpfung ihres Urhebers sind. Andere Kriterien dürfen nach dem ausdrücklichen Wortlaut nicht angewendet werden. Das heisst: Anders als bei normalen Werken (Romane, Gemälde, Musik) wird hier keine ästhetische Wertung vorgenommen. Es wird nur gefragt: Hatte der Programmierer eine Wahl zwischen verschiedenen Lösungsmöglichkeiten, und hat er sich für eine bestimmte entschieden?
Diese sogenannte kleine Münze-Doktrin senkt die Schöpfungshöhen-Schwelle deutlich gegenüber normalen Werken. Praktisch bedeutet das: Fast jeder produktive Quellcode ab einer gewissen Grösse ist geschützt. Trivialste Code-Schnipsel ohne erkennbare Gestaltungswahl (etwa Standard-Getter und -Setter, klassische Hello-World-Beispiele oder rein algorithmische Boilerplate) erreichen die Schwelle nicht. Für alles ernsthaft Funktionale können Sie vom Schutz ausgehen.
§ 69a Abs. 2 UrhG stellt klar: Der Schutz umfasst Ausdrucksformen eines Computerprogramms aller Art. Das schliesst Source-Code (in Hochsprachen wie C, Java, Python), Object-Code, Bytecode (Java .class, .NET-IL), Maschinencode und Container-Images ein. Auch das vorbereitende Entwurfsmaterial ist erfasst.
Was § 69a NICHT schützt
Hier kommt die wichtige Abgrenzung. § 69a Abs. 2 UrhG schützt das Programm als Ausdrucksform, aber nicht die zugrundeliegenden Ideen und Grundsätze. Algorithmen als solche sind nicht urheberrechtlich geschützt. Wenn jemand den Quicksort-Algorithmus oder den Fisher-Yates-Shuffle in einem Buch beschreibt, kann ein anderer Programmierer diesen Algorithmus in einer eigenen Implementierung verwenden, ohne das Urheberrecht zu verletzen.
Geschützt ist nur die konkrete Code-Form. Wer also die Quicksort-Implementierung aus Donald Knuths Buch wortwörtlich abschreibt, verletzt das Urheberrecht. Wer den gleichen Algorithmus in einer eigenständigen Implementierung neu schreibt, ist auf der sicheren Seite, auch wenn der Algorithmus identisch ist.
Diese Trennung von Idee und Ausdrucksform ist fundamental für die Software-Entwicklung. Sie erlaubt es, dass Konkurrenten die gleichen Probleme lösen können, ohne jedes Mal das Rad neu erfinden zu müssen. Patentschutz auf Software ist in Europa zwar eingeschränkt, aber nicht völlig ausgeschlossen, was eine separate Rechtsfrage ist.
Die reine Binärdarstellung eines Texts
Hier kommen wir zur speziellen Frage, die binaerkonverter.de aufwirft. Wenn das Tool den Text “Hallo” in die Bit-Sequenz 01001000 01100001 01101100 01101100 01101111 umwandelt, ist diese Bit-Sequenz dann ein eigenes urheberrechtlich geschütztes Werk?
Die Antwort ist klar Nein. Die Konvertierung eines Texts in seine Binärdarstellung ist ein deterministischer mechanischer Vorgang. Es gibt keine schöpferische Wahlfreiheit. Wenn Sie “Hallo” in UTF-8 codieren, ergibt sich zwingend die genannte Byte-Sequenz, weil das Encoding fest definiert ist (RFC 3629). Eine andere Sequenz wäre kein UTF-8 mehr. Damit fehlt die Voraussetzung der eigenen geistigen Schöpfung, die § 69a Abs. 3 UrhG verlangt.
Geschützt sein kann hingegen der ursprüngliche Text. Wenn dieser Text die normale Schöpfungshöhe nach § 2 UrhG erreicht (also etwa ein Roman, ein wissenschaftlicher Aufsatz, ein längerer Werbetext mit eigener Gestaltung), ist er als Sprachwerk geschützt. Die Binärdarstellung ist dann eine technische Repräsentation dieses geschützten Werks, vergleichbar mit einer Fotokopie oder einer digitalen Datei.
<path class="arrow" d="M 340 70 L 200 110"/>
<path class="arrow" d="M 380 70 L 380 110"/>
<path class="arrow" d="M 420 70 L 560 110"/>
<rect class="box" x="100" y="110" width="200" height="50" rx="8"/>
<text class="label" x="200" y="140">Source-Code</text>
<rect class="box" x="280" y="110" width="200" height="50" rx="8"/>
<text class="label" x="380" y="140">Algorithmus an sich</text>
<rect class="box" x="460" y="110" width="200" height="50" rx="8"/>
<text class="label" x="560" y="140">Binärdarstellung eines Texts</text>
<path class="arrow" d="M 200 160 L 200 200"/>
<path class="arrow" d="M 380 160 L 380 200"/>
<path class="arrow" d="M 560 160 L 560 200"/>
<rect class="boxYes" x="100" y="200" width="200" height="50" rx="8"/>
<text class="label" x="200" y="220">JA: § 69a UrhG</text>
<text class="small" x="200" y="238">Schöpfungshöhe niedrig</text>
<rect class="boxNo" x="280" y="200" width="200" height="50" rx="8"/>
<text class="label" x="380" y="220">NEIN: keine Form</text>
<text class="small" x="380" y="238">nur Idee, nicht Ausdruck</text>
<rect class="boxNo" x="460" y="200" width="200" height="50" rx="8"/>
<text class="label" x="560" y="220">NEIN: deterministisch</text>
<text class="small" x="560" y="238">keine Schöpfung</text>Open-Source-Lizenzen und ihre Verpflichtungen
Wer Software anderer Urheber verwendet, braucht eine Lizenz. Bei kommerzieller Software ist das ein vertraglicher Lizenzvertrag. Bei Open-Source-Software ist es eine standardisierte Open-Source-Lizenz, die der Urheber zusammen mit dem Code veröffentlicht hat. Die drei wichtigsten Familien:
Erstens: permissive Lizenzen wie MIT, BSD, Apache 2.0. Diese erlauben fast jede Nutzung, einschliesslich kommerzieller, modifizierter und proprietärer Weiterverteilung. Sie verlangen typischerweise nur, dass der Copyright-Hinweis und die Lizenz-Klausel in den verteilten Source-Files und Binaries erhalten bleiben. Die Apache 2.0 verlangt zusätzlich eine NOTICE-Datei mit Beiträger-Hinweisen und enthält eine explizite Patentklausel, die Patentstreitigkeiten regelt.
Zweitens: Copyleft-Lizenzen wie die GPL (in den Versionen 2 und 3) und die AGPL. Diese verlangen, dass jede modifizierte oder erweiterte Version des Programms ebenfalls unter der gleichen Lizenz veröffentlicht werden muss, wenn sie weiterverteilt wird. GPL-Code in proprietärer Software einzubauen und das Produkt zu vertreiben, verletzt die GPL. Die AGPL (Affero GPL) geht noch einen Schritt weiter: Sie greift auch dann, wenn die Software nur als Netzwerk-Dienst angeboten wird, ohne dass Code weitergegeben wird.
Drittens: weak Copyleft-Lizenzen wie die LGPL und MPL. Diese erlauben die Verwendung in proprietärer Software, solange das Open-Source-Modul als separate, austauschbare Bibliothek vorliegt. Modifikationen am Open-Source-Modul selbst müssen unter der gleichen Lizenz veröffentlicht werden, die proprietäre Software, die nur damit linkt, bleibt aber proprietär.
Eine Verletzung dieser Lizenzbedingungen ist gleichzeitig eine Urheberrechtsverletzung, weil die Lizenz ja gerade die Voraussetzung für die erlaubte Nutzung war. Bekanntester Fall in Deutschland: Welte gegen Skype 2008, in dem Skype eine GPL-Verletzung am Linux-Kernel begangen hatte und sich nach gerichtlicher Auseinandersetzung zur Konformität verpflichten musste.
Was die Engine hinter binaerkonverter.de schützt
Die Konvertierungs-Engine, die binaerkonverter.de antreibt, ist als Source-Code in JavaScript und TypeScript verfasst. Sie nutzt die Web-Standard-APIs TextEncoder und TextDecoder, ergänzt um eigene Logik für die ASCII-Pfad-Validierung, die Bit-Gruppierung (8 oder 16 Bit) und die Trennzeichen-Optionen (Leerzeichen, Komma, Zeilenumbruch, keine Trennung).
Diese Engine erreicht klar die Schöpfungshöhe nach § 69a Abs. 3 UrhG, weil bei jedem Entwicklungsschritt mehrere Implementierungsmöglichkeiten zur Wahl standen. Die Wahl der konkreten Architektur, der Fehlerbehandlung mit fatal-Mode, der Persistenz im localStorage: alles sind gestalterische Entscheidungen, die den Code als individuelles Werk qualifizieren.
Die AKARA Solutions GmbH ist als Arbeitgeberin des Hauptentwicklers nach § 69b UrhG ausschliesslich zur Ausübung aller vermögensrechtlichen Befugnisse berechtigt, sofern nichts anderes vereinbart ist. Der Code wird derzeit nicht als Open-Source veröffentlicht, eine zukünftige Veröffentlichung unter MIT- oder Apache-Lizenz ist nicht ausgeschlossen.
Die vom Tool produzierten Binärsequenzen (etwa wenn ein Nutzer “Hallo” in 01001000 01100001 01101100 01101100 01101111 umwandelt) sind hingegen nicht urheberrechtlich geschützt, weil es sich um deterministische Konvertierungen ohne Schöpfungselement handelt. Die Nutzer können die Output-Sequenzen frei verwenden, kopieren und weitergeben. Das gilt auch für eigene Binär-Eingaben, die das Tool zurück in Text konvertiert.
Praxis-Tipps für Software-Entwicklungs-Teams
Aus meiner Praxis als Geschäftsführer eines Software-Unternehmens kann ich die folgenden Empfehlungen aussprechen.
Erstens: Lizenz-Audit der eingesetzten Open-Source-Komponenten. Jedes ernsthafte Entwicklungsprojekt nutzt Dutzende bis Hunderte Open-Source-Dependencies. Tools wie OWASP Dependency-Check, FOSSA oder die in GitHub eingebaute Dependency-Liste machen die Lizenzen sichtbar. GPL-lizenzierte Komponenten in proprietären Produkten sind ein häufiger Verstoss, der bei einer Übernahme oder einer Investorenprüfung auffliegt und teure Sanierungen erfordert.
Zweitens: Klare Arbeitsverträge mit Mitarbeitern und Auftragnehmern. § 69b UrhG regelt zwar die Vermutung, dass Arbeitgeber an dienstlich geschaffener Software vermögensrechtlich berechtigt sind. Bei freien Mitarbeitern und externen Dienstleistern gilt das aber nicht automatisch. Hier muss vertraglich eine Übertragung der Nutzungsrechte vereinbart werden, am besten ausdrücklich und schriftlich.
Drittens: Bei eigener Open-Source-Veröffentlichung eine bewusste Lizenz-Wahl. Wer den eigenen Code unter Apache 2.0 stellt, signalisiert kommerzielle Offenheit, hat aber die Patent-Klausel als zusätzlichen Schutz. MIT ist die liberalste Wahl mit minimalen Verpflichtungen. GPL setzt aktiv auf Copyleft und ist für Plattform-Komponenten geeignet, die nicht in proprietäre Software einsickern sollen.
Viertens: Dokumentation von Lizenz-Entscheidungen. Jede Lizenz-Wahl sollte mit einer kurzen Begründung dokumentiert werden, am besten im Repository selbst (etwa in einer LICENSE-Datei und einem README-Abschnitt zu Beiträger-Bedingungen). Das hilft späteren Maintainern und macht Audits einfacher.
Was hängenbleibt
Computerprogramme sind nach § 69a UrhG urheberrechtlich geschützt, mit niedrigerer Schöpfungshöhen-Schwelle als normale Werke. Der Schutz umfasst Source-Code, Bytecode und Maschinencode gleichermassen. Algorithmen als blosse Ideen sind nicht geschützt, nur ihre konkrete Code-Implementierung. Die reine Binärdarstellung eines Texts ist mangels Schöpfungselement nicht geschützt, geschützt sein kann nur der ursprüngliche Text. Open-Source-Lizenzen wie MIT, GPL und Apache stellen unterschiedliche Anforderungen an Weiterverteilung und Modifikation. Wer Software anderer Urheber nutzt, sollte die Lizenzbedingungen genau prüfen, weil Verstösse zivilrechtliche und strafrechtliche Konsequenzen haben können.
FAQ
Häufige Fragen
Ist jeder Quellcode automatisch urheberrechtlich geschützt?
Im Grundsatz ja, sofern eine gewisse Mindestkomplexität vorliegt. § 69a Abs. 3 UrhG schützt Computerprogramme, wenn sie individuelle Werke in dem Sinne darstellen, dass sie das Ergebnis der eigenen geistigen Schöpfung ihres Urhebers sind. Die Schöpfungshöhen-Schwelle ist nach der Rechtsprechung des EuGH (Rechtssache C-393/09 BSA, 2010) und des BGH (I ZR 124/11, 2013) bewusst niedrig gehalten: Es reicht aus, dass der Programmierer eine Wahl zwischen verschiedenen technisch möglichen Lösungen hatte und sich für eine bestimmte entschieden hat. Komplett triviale Code-Schnipsel von wenigen Zeilen ohne erkennbare gestalterische Wahl erreichen diese Schwelle nicht. Beispiele aus der Praxis sind etwa Standard-Getter-Setter-Methoden oder klassische Hello-World-Beispiele. Für jeden ernsthaften produktiven Quellcode kann man hingegen vom Schutz ausgehen.
Schützt § 69a UrhG nur den Source-Code oder auch das Compilat?
Beides. Der Gesetzgeber hat in § 69a Abs. 2 UrhG ausdrücklich klargestellt, dass der Schutz Ausdrucksformen eines Computerprogramms aller Art umfasst. Das schliesst sowohl den Quellcode (in Sprachen wie C, Java, Python, JavaScript) als auch die ausführbare Binärform (Maschinencode, Bytecode, Container-Images) ein. Beide sind als Übersetzungen oder Bearbeitungen derselben geistigen Schöpfung anzusehen. Das bedeutet konkret: Wer ohne Lizenz eine kompilierte Anwendung verteilt, verletzt das gleiche Urheberrecht wie wer den unkompilierten Source-Code verbreitet. Ebenso geschützt sind Zwischenstufen wie Bytecode (Java .class-Dateien, .NET-IL, WebAssembly .wasm), die nicht direkt menschenlesbar sind, aber funktional dem Source-Code entsprechen.
Ist die reine Binärdarstellung eines Texts wie 01001000 für Hallo urheberrechtlich geschützt?
Nein. Die Konvertierung eines Texts in seine Binärdarstellung ist ein deterministischer mechanischer Vorgang ohne schöpferische Leistung. Wenn Sie den Text Hallo in UTF-8 codieren, ergibt sich zwangsläufig die Byte-Sequenz 48 61 6C 6C 6F, in Binär 01001000 01100001 01101100 01101100 01101111. Es gibt keine Wahlfreiheit, keine gestalterische Entscheidung, keine eigene geistige Schöpfung. Damit fehlt die Voraussetzung für urheberrechtlichen Schutz. Geschützt ist hingegen der ursprüngliche Text (sofern er die normale Schöpfungshöhe erreicht, also etwa ein Roman, ein wissenschaftlicher Aufsatz oder ein längerer Werbetext). Die Binärdarstellung ist dann nur eine technische Repräsentation des geschützten Werks. Konkret: Wer einen Roman Buchstabe für Buchstabe in Binärcode umwandelt, verletzt das Urheberrecht am Roman, nicht ein eigenes Urheberrecht am Binärcode.
Was unterscheidet die MIT-, GPL- und Apache-Lizenz konkret?
Die drei Lizenzen unterscheiden sich vor allem in der Copyleft-Komponente und in den Patent-Klauseln. Die MIT-Lizenz ist permissiv: Sie erlaubt fast jede Nutzung (kommerziell, modifiziert, geschlossen) und verlangt nur den Copyright-Hinweis und die Lizenz-Klausel im Source und in den Binaries. Keine Patentklausel. Die Apache-Lizenz 2.0 ist ähnlich permissiv wie MIT, fügt aber eine explizite Patentlizenz hinzu und verlangt eine NOTICE-Datei mit Beiträger-Hinweisen. Sie ist die Wahl für viele große Open-Source-Projekte (Apache HTTP Server, Hadoop, Kafka). Die GPL (GNU General Public License) ist copyleft: Wer GPL-Code in seinem Produkt verwendet und das Produkt weiterverteilt, muss seinen kompletten Source-Code ebenfalls unter GPL veröffentlichen. Das ist die strikte Variante, die Linux-Kernel und viele GNU-Tools nutzen. Wer GPL-Code in proprietärer Software einsetzt, verletzt die Lizenz und damit das Urheberrecht des GPL-Autors.
Welche Konsequenzen drohen bei einer Urheberrechtsverletzung an Software?
Mehrstufig. Erstens zivilrechtlich: Der Rechteinhaber kann nach §§ 97 ff. UrhG Unterlassung, Schadensersatz und Auskunft verlangen. Schadensersatz kann nach der Lizenzanalogie berechnet werden, also was eine ordnungsgemässe Lizenzierung gekostet hätte, oder nach dem konkret entstandenen Schaden. Bei vorsätzlichen oder grob fahrlässigen Verletzungen ist ein Aufschlag möglich. Zweitens strafrechtlich: § 106 UrhG sieht für die unerlaubte Verwertung urheberrechtlich geschützter Werke Freiheitsstrafe bis zu drei Jahren oder Geldstrafe vor, bei gewerbsmässigem Handeln sogar bis zu fünf Jahren. In der Praxis kommen Strafverfahren selten vor, weil die Beweisführung aufwändig ist. Drittens reputationell: Insbesondere bei GPL-Verletzungen gibt es spezialisierte Akteure wie das gpl-violations.org-Projekt und die Software Freedom Conservancy, die Verletzungen öffentlich machen und gerichtlich verfolgen. Bekanntester Fall in Deutschland war Welte vs Skype 2008, wo Skype die GPL des Linux-Kernels verletzte und sich nach gerichtlicher Auseinandersetzung zur Konformität verpflichtete.
Quellen
Worauf dieser Ratgeber sich stützt
Verwandte Ratgeber