Open Source in IT-Projekten

Open Source Software ist auch im kommerziellen Umfeld weit verbreitet. Den damit einhergehenden Risiken muss in IT-Verträgen adäquat begegnet werden.

Open Source Software (oft abgekürzt als „OSS“) ist aus der heutigen IT-Landschaft kaum mehr wegzudenken. Von Webframeworks über Audio-Formate bis hin zu Bibliotheken für maschinelles Lernen: Für viele technische Herausforderungen lassen sich Open-Source-Lösungen finden. 

Begriffsbestimmung: Open Source vs. Closed Source

„Source„ bezieht sich dabei auf den Sourcecode eines Programms, also den Programmcode, der in einer für Menschen lesbaren Programmiersprache geschrieben ist und erst nach Übersetzung in maschinenlesbaren Code mittels eines sog. „Compilers“ dann auf einem Computer ausgeführt werden kann. Dabei ist die Frage, wann Software als „Open Source“ gilt, nicht immer einfach zu beantworten. Eine allgemeingültige oder gesetzliche Definition des Begriffs existiert nicht. Stattdessen verwenden verschiedene Organisationen und Interessensgruppen unterschiedliche und in Details teils voneinander abweichende Definitionen.

Diesen Definitionen ist in der Regel aber jedenfalls gemein, dass unter OSS solche Software zu verstehen ist, deren Sourcecode für jedermann verfügbar ist und unter einer Lizenz steht, die dem Verwender das Recht zur Nutzung, Veränderung und Weitergabe der Software unter den jeweiligen Lizenzbedingungen einräumt. Teil der „Open Source“ Definition kann auch die Verpflichtung sein, selbst den Sourcecode offenlegen zu müssen, wenn der Verwender der OSS am Sourcecode Modifikationen vornimmt oder diesen in eine andere Software einbettet.

Das Gegenstück zur OSS (also Software, die vom jeweiligen Entwickler nur unter restriktiven Nutzungsrechten vertrieben wird und deren Sourcecode der Entwickler regelmäßig geheim hält) wird in Abgrenzung zur „Open Source“ üblicherweise als „Closed Source“ oder auch „Proprietäre Software“ bezeichnet. Statt des Sourcecodes stellt der Entwickler von proprietärer Software regelmäßig nur das bereits in maschinenlesbaren Code übersetzte und ausführbare Programm selbst zur Verfügung. Aus diesem kann der Sourcecode nicht ohne weiteres abgeleitet werden und die Vornahme von Änderungen an der Software ist für den Verwender ist dadurch bereits aus technischen Gründen nur schwer möglich.

Open Source bietet Chancen und Risiken gleichermaßen

In den allermeisten Fällen wird OSS von ihren Entwicklern kostenlos angeboten. Das heißt aber nicht automatisch, dass eine Nutzung von OSS beliebig und ohne Vorgaben zur Nutzung möglich ist. Bei der Entscheidung, ob OSS in einem Projekt zum Einsatz kommen soll, muss beachtet werden, dass „Open Source“ nicht „rechtsfrei“ bedeutet. Die Nutzung der OSS wird von deren Entwicklern nämlich nur unter der Bedingung gestattet, dass die Bestimmungen der entsprechenden Lizenz, unter der die Software veröffentlicht wurde, eingehalten werden. Es kommt also ein rechtsverbindlicher Nutzungsvertrag zwischen den Entwicklern (als Lizenzgeber) und den Verwendern (als Lizenznehmer) zustande. Dieser Lizenzvertrag hat dann die Bedingungen der jeweiligen OSS-Lizenz zum Inhalt.

Viele OSS-Lizenzen (und damit auch viele Nutzungsverträge zwischen Entwicklern und Verwendern) enthalten umfangreiche Pflichten für den Verwender, der die OSS verwendet, modifiziert oder in eigene Software integriert. Ein Verstoß gegen diese Pflichten kann erhebliche rechtliche und wirtschaftliche Folgen haben. Diese reichen vom Unterlassungsanspruch bis hin zur Pflicht zur Offenlegung des eigenen vollständigen Quellcodes der Software, in die die OSS implementiert wurde. Diese können gegebenenfalls auch gerichtlich durchgesetzt werden.

Die Vorteile, die sich aus dem Rückgriff auf OSS für ein Projekt ergeben, liegen auf der Hand: Für viele Problemstellungen gibt es bestehende und optimierte Lösungen, die sofort verfügbar sind und damit die Entwicklungszeit für das Projekt erheblich verkürzen können. Für die Verwendung von OSS-Komponenten fallen in aller Regel keine unmittelbaren Lizenzkosten an, was die Projektkosten im Vergleich zur Lizenzierung kommerzieller Software klein hält. Zudem steht hinter OSS oft eine große Entwickler-Community, die erhebliches Knowhow in die Entwicklung der OSS einbringt. Dies führt einerseits oft zu qualitativ hochwertiger Software und erlaubt andererseits kurze Updatezyklen, die insbesondere eine schnelle Reaktion beim Bekanntwerden von Schwachstellen oder neuen Anforderungen an die Software ermöglichen.

Beispiele für Pflichten unter OSS-Nutzungsverträgen

Wie oben erläutert erfolgt die Nutzung von OSS nicht „im rechtsfreien Raum“, sondern auf der Grundlage eines Nutzungsvertrags. Der Inhalt dieses Nutzungsvertrags und die sich daraus ergebenden Pflichten des Lizenznehmers richten sich nach der Lizenz, unter der die OSS zur Verfügung gestellt wird. Aufgrund der Vielzahl an verwendeten OSS-Lizenzen, die teils auch in modifizierter Form zur Anwendung kommen können, kann kein abschließender und allgemeingültiger Katalog von Pflichten aufgestellt werden, der den Verwender jeglicher OSS trifft. Welche Pflichten den Verwender konkret treffen, ist im Einzelfall vor Einsatz der OSS gründlich zu prüfen.

Die meisten OSS-Lizenzen verpflichten aber jedenfalls dazu, bei Weiterverbreitung der OSS (sei es als alleinstehende und gegebenenfalls modifizierte Software oder integriert in ein größeres Softwareprodukt) den Lizenztext mitzuliefern, bestehende Urheberhinweise im Quellcode zu erhalten, und den Sourcecode zugänglich zu machen.

Besonders die Pflicht zur Zugänglichmachung des Sourcecodes ist für Unternehmen riskant, da die Reichweite dieser Pflicht oft größer ist, als die Verwender sich klarmachen: Bei sogenannten „Copyleft“-Lizenzen wie beispielsweise der GPL droht die „Infektion“ proprietären Sourcecodes: Wird OSS in proprietäre Software integriert, kann eine Copyleft-Lizenz regeln, dass auch der eigentlich proprietäre Teil denselben Offenlegungspflichten unterfällt und damit faktisch von der OSS-Lizenz „infiziert“ wird. Das bedeutet, dass durch den Einsatz eines einzigen OSS-Codebausteins in einer umfangreichen Software, die ansonsten vollständig aus selbst entwickeltem Code besteht, gegebenenfalls der gesamte Sourcecode dieser Software offengelegt und Dritten unentgeltlich zugänglich gemacht werden müsste. Ein solches Szenario ist für jedes Unternehmen problematisch. Für Software-Startups, deren Unternehmenswert oft allein in der entwickelten Software liegt, ist eine solche „Infektion“ aber besonders kritisch, da diese im Zweifelsfall die Möglichkeiten zur Vermarktung des einzigen Produkts des Unternehmens erheblich erschwert und den Unternehmenswert massiv mindert.

Ein weiterer Aspekt, der insbesondere bei der Entwicklung von Firmware für Elektrogeräte relevant ist, wird unter dem Stichwort „Tivoization“ diskutiert. Dabei geht es um die Möglichkeit, vom Kunden veränderte Versionen der ursprünglich auf dem Gerät installierten OSS-Komponenten auch auf diesem Gerät auszuführen. Dies betrifft klassische Gerätekategorien wie Multimediageräte, aber potentiell auch kritische Komponenten wie Motorsteuergeräte, ABS-Systeme oder Herzschrittmacher. Während dieser Aspekt früher oft nicht ausdrücklich geregelt war, beinhalten neuere Lizenzbedingungen teilweise ausdrücklich die Pflicht, dies zu ermöglichen. 

Der Umgang mit OSS im Projekt

In vielen Projekten wird der OSS-Einsatz vertraglich komplett ausgeschlossen. Entwickler werden in diesem Fall vertraglich verpflichtet, keine OSS-Komponenten zu verwenden, sodass dem Auftraggeber an dem Arbeitsergebnis exklusive und unbeschränkte Rechte eingeräumt werden können. Dieser Ansatz sorgt für klare und unkomplizierte IP-rechtliche Verhältnisse, sodass von vornherein feststeht, dass jegliche Nutzung der in dem Projekt entwickelten Software zulässig ist und der Auftraggeber in keiner Weise eingeschränkt wird. Dafür bezahlen Unternehmen jedoch mit der Notwendigkeit, eigene Lösungen selbst für Standardprobleme zu entwickeln, was einen nicht zu vernachlässigenden zeitlichen und finanziellen Aufwand bedeutet.

Gerade in neueren und inhaltlich weniger sensiblen Projekten wird oft ein differenzierter Ansatz verfolgt: Erlaubt ist dann regelmäßig die Nutzung von OSS mit „permissiven“ Lizenzen (beispielsweise BSD, MIT oder Apache 2.0), also Lizenzen, die keine erheblichen Pflichten für den Verwender der OSS und insbesondere keinen Copyleft-Effekt in Bezug auf proprietären Sourcecode des Nutzers vorsehen. Hierdurch wird die Nutzung von OSS-Komponenten und in der Folge eine schnellere und günstigere Entwicklung bei gleichzeitig begrenzten Offenlegungspflichten ermöglicht. Allerdings verlangt dieser Ansatz ein erhöhtes Augenmerk auf effektives Lizenzmanagement. Zudem besteht (anders als wenn von vornherein feststeht, dass generell keine OSS verwendet werden darf) eine größere Gefahr unbeabsichtigter Verwendung von OSS, die in Wahrheit unter einer Copyleft-Lizenz steht, wenn fälschlich angenommen wird, dass diese OSS unter einer permissiven Lizenz steht.

Unter Umständen entscheiden sich Auftraggeber aber auch ganz bewusst für den Einsatz von OSS und die Entwicklung des beauftragten Softwareprodukts unter einer Open-Source-Lizenz. Die Gründe hierfür können vielfältig sein: Womöglich ist beabsichtigt, eine Community aufzubauen, auf deren Ressourcen dann künftig für die Weiterentwicklung des Produkts zurückgegriffen werden kann, was die Weiterentwicklung erheblich vergünstigt und beschleunigt. Ein Interesse daran, das eigene Produkt unter einer OSS-Lizenz zu verbreiten, haben aber auch Anbieter, die versuchen ihre Software als Standard zu etablieren (oder im Gegenteil, den teuren Standard eines Mitbewerbers durch ein attraktives Alternativangebot zu verdrängen), da die Nutzung ihres OSS-Angebots für ihre Kunden aus den oben ausgeführten Gründen als vorteilhaft wahrgenommen wird. Durch die niedrige wirtschaftliche Hürde für Dritte, kann zudem ein Anreiz gesetzt werden, ein Drittanbieter-Ökosystem um das entwickelte Produkt aufzubauen. Als Kehrseite müssen Anbieter freilich den Verlust exklusiver Verwertungsrechte sowie erhebliche Herausforderungen bei der Monetarisierung ihrer Software in Kauf nehmen.

Entscheidend bei Nutzung von „Open Source“ ist die vertragliche Regelung

Wie auch immer der Auftraggeber sich zu den Chancen und Risiken positioniert: Sobald er Entwicklungsleistungen im Rahmen von IT-Projekten aus der Hand gibt, sollten die damit im Zusammenhang stehenden Aspekte in dem entsprechenden Projekt- bzw. Entwicklungsvertrag detailliert geregelt werden.

Generell sollte ein solcher Vertrag eine klare Definition dessen enthalten, was unter „Open Source“ im Einzelfall zu verstehen ist, wenn dieser Begriff verwendet wird. In Anbetracht der breiten Palette an OSS-Lizenzen, unter denen Software lizenziert werden kann, ist hier Präzision gefragt. Besonders relevant ist dieser Punkt, wenn der Auftraggeber OSS nicht generell ausschließen möchte, sondern unter bestimmten Voraussetzungen erlauben oder sogar fördern möchte. Sinnvoll ist dazu insbesondere die Formulierung einer „White-List“, also einer abschließenden Aufzählung von Lizenzarten, die der Auftraggeber als unkritisch befunden hat. Der Auftragnehmer darf dann nur solche OSS verwenden, die unter einer in der White-List enthaltenen Lizenzen steht. Alternativ kann auch abstrakt beschrieben werden, unter welchen Rahmenbedingungen der Auftragnehmer die Entwicklung später nutzen und vertreiben möchte. Der Auftragnehmer kann dann dazu verpflichtet werden (idealerweise in Form einer Garantie), dass das Endprodukt unter Wahrung aller Lizenzbedingungen der in der Software eingesetzten Komponenten wie gewünscht genutzt bzw. vertrieben werden kann.

Sofern der Einsatz von OSS nicht generell verboten wird, sollte der Auftragnehmer dazu verpflichtet werden, verwendete OSS inkl. Lizenz und Version zu dokumentieren und diese Dokumentation stets aktuell zu halten. Nur so kann der Auftraggeber sicherstellen, dass er selbst ein ordnungsgemäßes Lizenzmanagement betreiben kann, das erforderlich ist, um die im Unternehmen bestehenden Lizenzvereinbarungen im Blick zu halten und die daraus erwachsenden Verpflichtungen einhalten zu können.