Offene Konkurrenz

Inhaltsverzeichnis

Namhafte IT-Hersteller investieren Unsummen in Open-Source-Software (OSS), zahlreiche Behörden und Verwaltungen sinnieren über ihren Einsatz - kein Zweifel, das Schmuddel-Image der einstigen „Hackersoftware“ gehört der Vergangenheit an. Dazu beigetragen hat neben der Qualität der Software und den konzeptionellen Vorteilen des Entwicklungsmodells die 1998 gegründete Open Source Initiative, die nicht nur diese Vorzüge nach „draußen“ kommunizierte, sondern überdies eine in neun Regeln festgehaltene Definition von Open-Source-Software lieferte.

Der Begriff „Open Source“ weist bereits auf das wesentliche Merkmal von OSS hin: den ohne Einschränkung zur Verfügung stehenden „öffentlichen“ Quellcode. Aber auch freie Software muss sich an juristische Spielregeln halten, die für den Laien nicht immer leicht zu durchschauen sind. Das OSS-Konzept wirft viele rechtliche Fragen auf, die die juristische Fachwelt zum Teil mit ungewohnter Heftigkeit diskutiert.

Open-Source-Software wird entweder direkt im Quellcode verbreitet oder aber in kompilierter Form, wobei der Quellcode in diesem Fall zusätzlich zur Verfügung stehen muss. Allen OSS-Lizenzen ist gemeinsam, dass dem Lizenznehmer nicht nur die unbeschränkte Weiterverbreitung der Software, sondern ebenso deren Änderung und Weiterentwicklung ausdrücklich gestattet ist. Juristisch gesehen geht es hier um die Bearbeitung, Verbreitung und Vervielfältigung von Computerprogrammen.

Erfolgreiches Geschäftsmodell

Ein Ausschluss bestimmter Personen oder Personengruppen von der Nutzung oder eine Beschränkung der Nutzung auf bestimmte Einsatzbereiche wäre mit dem OSS-Konzept nicht vereinbar, ebensowenig die Erhebung von Lizenzgebühren. Jedoch setzt das OSS-Konzept keineswegs voraus, dass die Software kostenlos verbreitet wird. Ein gängiges und ausgesprochen erfolgreiches Geschäftsmodell besteht zum Beispiel darin, OSS wie das Betriebssystem GNU/Linux zusammen mit Handbüchern, Installationsroutinen und Supportleistungen zu vertreiben - zwar gegen Entgelt, nicht aber gegen Zahlung von Lizenzgebühren.

Juristen streiten in letzter Zeit heftig über die Rechtssicherheit bei der Verwendung von OS-Produkten. In mehreren Beiträgen und Gutachten beschäftigen sich die Autoren vor allem mit der so genannten GNU General Public License (GPL), die der „Vater der freien Software“, Richard Stallman, im Jahre 1989 zusammen mit Eben Moglen entwickelte. Die GPL ist die bekannteste und am häufigsten verwendete OSS-Lizenz. Als so genannte Copyleft-Lizenz sieht sie vor, dass sämtliche Weiterentwicklungen der Software wiederum unter denselben Lizenzbedingungen freizugegeben sind. Auf diese Weise soll verhindert werden, dass Programme, die ursprünglich der OSS-Lizenz unterliegen, nach Vornahme von Änderungen nur gegen Zahlung einer Lizenzgebühr erhältlich sind. Wer Verpflichtungen aus der GPL missachtet, verliert gemäß Ziffer 4 GPL sämtliche durch die Lizenz eingeräumten Rechte.

Häufig erwirbt der Nutzer die Software jedoch nicht direkt vom Urheber, sondern von Distributoren. In diesem Fall stellt sich die Frage, mit wem der Erwerber überhaupt die GPL-Lizenzvereinbarung schließt. Etwa mit dem Distributor als dem so genannten Softwaregeber? Die Frage beantwortet Ziffer 6 Satz 1 GPL: Danach schließt der Benutzer den GPL-Lizenzvertrag mit dem oder den Urhebern der Software uxnd nicht mit dem jeweiligen Softwaregeber. Der Distributor ist zwar derjenige, der die Software verkauft, im Hinblick auf die Lizenz fungiert er jedoch nur als „Bote“ des Urhebers.

Doch wer ist der Urheber? An der Entwicklung von OSS ist meist eine nicht zu überschauende Zahl an Programmierern beteiligt. Wenn Rechtsschutz in Deutschland gelten soll, richtet sich die Beantwortung dieser Frage nach deutschem Recht. Die GPL ist somit nach deutschem Urheberrecht zu qualifizieren: Erfolgt die Entwicklung nach einem gemeinsamen Plan oder einer gemeinsamen Idee und die einzelnen Beiträge nicht gesondert verwertbar, so sind alle beteiligten Programmierer Miturheber. Ein Beispiel dafür sind so genannte Experimental Releases, die unter Mitwirkung anderer Programmierer zu einer Stable Release weiterentwickelt werden. Entwickeln verschiedene Personen Softwaremodule oder -funktionen, die eigenständig lauffähig sind, so kann daraus ein so genanntes verbundenes Werk entstehen. In diesem Fall bleibt der jeweilige Entwickler Urheber des von ihm entwickelten Moduls. Für OSS typischer ist allerdings die dezentrale, sukzessive Entwicklung. Hierdurch entsteht ein neues Urheberrecht, das sich nur auf die Bearbeitung der Software bezieht. Die Bearbeitung und ihre Verwertung dürfen jedoch nur mit Zustimmung des Urhebers der ursprünglichen Software erfolgen. Dieser kann die Nutzungsrechte an der bearbeiteten Software allerdings nur zusammen mit den anderen an der Entwicklung Beteiligten vergeben.

Ahndung von Verstößen

Erfährt ein einzelner Urheber, dass jemand gegen die Lizenzbestimmungen verstoßen hat, kann er denjenigen - ob Nutzer oder Miturheber - auf Unterlassung der Lizenzverletzung verklagen. Das kann er selbst dann tun, wenn er die Namen der anderen Miturheber nicht kennt. Denn seine Rechte wären kaum durchsetzbar, wenn er verpflichtet wäre, alle Miturheber ausfindig zu machen.

Vertreibt man Software über das Internet, sollte man generell beim oder noch besser vor dem Download einen Link auf die Lizenzbedingungen mit entsprechendem Hinweis setzen. Denn der Nutzer muss die Lizenzbedingungen ohne große Mühen einsehen können. Andernfalls werden sie - da es sich rechtlich um allgemeine Geschäftsbedingungen (AGB) handelt - nicht Vertragsbestandteil. Das hätte jedoch bei OSS zur Folge, dass der Nutzer weniger Rechte hätte als im Falle der Wirksamkeit der AGB: Er dürfte die Software zumindest nicht verändern oder verbreiten. Deshalb nimmt man unter bestimmten Voraussetzungen an, dass die Regelungen der GPL auch noch nachträglich in einen Vertrag einbezogen werden können. Ist beispielsweise die Lizenz der Software als Datei beigefügt und dem Nutzer die Kenntnisnahme somit möglich sowie zumutbar, wird eine Veränderung oder Verbreitung der Software durch den Nutzer als nachträgliche Zustimmung zur GPL gedeutet. Ziffer 5 der GPL, gemäß der die Veränderung oder Verbreitung der Software das Einverständnis mit den Lizenzbedingungen impliziert, stützt diese - dennoch umstrittene - Interpretation.

Ebenfalls umstritten ist die Frage, ob die GPL angesichts der Tatsache, dass die Lizenzbedingungen nur auf Englisch zur Verfügung stehen, überhaupt wirksam in den Vertrag einbezogen werden können, falls der Download nicht von einer englischsprachigen Website erfolgt. Einige Juristen verneinen das, weil man nicht generell damit rechnen könne, dass deutsche Nutzer der englischen Rechtssprache mächtig seien. Für die Wirksamkeit der GPL-Lizenzbedingungen spricht jedoch, dass der Nutzer, der die durch die Lizenz gewährten Nutzungsrechte in Anspruch nehmen will, sich auf ihre Bedingungen einlassen muss.

Wenn jemand Software unter Verwendung von GPL-Programmcode entwickelt, muss er das fertige Produkt wieder der GPL unterstellen. Das soll die freie Verfügbarkeit von Derivaten der OSS sicherstellen. In diesem Bereich bestehen jedoch einige Abgrenzungsschwierigkeiten, wann überhaupt ein solches Derivat vorliegt und nicht nur eine komplementäre Software. Laut GPL ist das der Fall, wenn das Programm oder ein Teil davon im Arbeitsergebnis enthalten sind. Qualitative oder quantitative Anforderungen sind nicht definiert. So wird etwa nicht verlangt, dass das Derivat „wesentliche Züge“ des Originalwerks übernimmt, wie das bei „Bearbeitungen“ im Sinne des deutschen Urheberrechts der Fall ist.

Was die Nutzung von OSS durch Endanwender betrifft, diskutiert man, inwieweit Arbeitsergebnisse, die mit freien Programmen erstellt wurden, ebenfalls der GPL zu unterstellen sind. Da die GPL nicht verlangt, dass es sich bei den Arbeitsergebnissen um Programme handeln muss, ist diese Frage zum Beispiel für Präsentationen relevant. Denn Präsentationsprogramme enthalten häufig eine Funktion, die es ermöglicht, eine mit der Software erstellte Präsentation auch auf einem Rechner ohne diese Software laufen zu lassen. Zu diesem Zweck muss man die Präsentation mit einer ausführbaren Umgebung verknüpfen. Diese ist vom Präsentationsprogramm generiert und enthält daher einen Teil von ihm. Würde eine solche Präsentation nun der GPL unterliegen, so wäre das gerade bei geheimhaltungsbedürftigen Inhalten fatal. Viele sind daher der Ansicht, dass Werke, die zwar auf einem Programm basieren, nicht aber seine Werkkategorie teilen, nicht unter die GPL fallen. Bei einer anderen Auslegung wäre diese Klausel der GPL als „überraschend“ anzusehen und könnte mangels Vereinbarkeit mit den gesetzlichen Regelungen zu allgemeinen Geschäftsbedingungen nicht wirksam in den Vertrag einbezogen werden.

Kompiliert = kompliziert?

Schwierig ist diese Fragestellung auch bei Compilern, die unter der GPL stehen. Ist ein Programm, das unter Zuhilfenahme eines solchen Compilers in den Objektcode übersetzt wurde, ebenfalls der GPL zu unterstellen? Die Antwort lautet hier: Es kommt darauf an. Die Leistung des Compilers besteht nur in einer mechanischen Umwandlung. Im Objektcode finden sich im Regelfall keine urheberrechtlich schutzfähigen Programmteile des Compilers wieder. Das kompilierte Programm ist somit nach allgemeiner Auffassung nicht der GPL zu unterstellen. Wenn der Compiler jedoch Teile seines eigenen Quellcodes in den Objektcode überträgt, gilt für das erzeugte Programm in jedem Fall die GPL. Aus diesem Grund legte man beim Open-Source-Parser-Generator Bison abweichend von der GPL fest, dass die Ergebnisse des Programms auch in Closed Software verwendet werden dürfen. Eine Übertragung des eigenen Quellcodes wie bei Bison erfolgt allerdings ausgesprochen selten. Für Editoren gelten die gleichen Grundsätze wie für Compiler.

Bedeutend komplexer stellt sich die Verwendung von Libraries unter der GPL dar. Zahlreiche Programme etwa greifen bei ihrer Ausführung auf Standardroutinen des Betriebssystems zu, die sich in den Programmbibliotheken befinden. Für diese hat die Entwicklergemeinde die weniger restriktive „Lesser GPL“ konzipiert. Ihr ist etwa die GNU C Library unterstellt. Sie soll den gemeinsamen Vertrieb des Betriebssystems mit proprietären Anwendungsprogrammen ermöglichen, die auf die klassischen Bibliotheken des Betriebssystems zugreifen müssen.

Das Open-Source-Modell ist so beliebt, dass man es mittlerweile auch auf andere Bereiche überträgt: So entwickelte das Institut für Rechtsfragen der freien und Open-Source-Software IFROSS kürzlich eine Open-Content-Lizenz, eine Lizenz für freie Inhalte. Diese überträgt das Lizenzmodell der OSS auf andere Werkgattungen wie insbesondere Datenbanken, Texte, Bilder et cetera. Die juristischen Probleme, die bei der Nutzung der bislang bekannten OSS-Lizenzen auftreten, hat man bei der Entwicklung der neuen Lizenz nach eigenen Aussagen - soweit möglich - ausgeräumt. Die Anhänger des Open-Source-Modells werden sich darüber freuen. Mit Sorge hingegen betrachtet die Entwicklergemeinde die Bestrebungen, in der europäischen Gemeinschaft Softwarepatente regulär und nicht wie derzeit in Ausnahmefällen zuzulassen. Im September stimmt das EU-Parlament in Brüssel über den umstrittenen EU-Richtlinienentwurf ab, der bei seiner Umsetzung für Entwickler und Unternehmen weitreichende Konsequenzen hätte (siehe „Softwarepatente in Europa“).

Mehr Infos

Softwarepatente in Europa

Einige Jahre dauert das Tauziehen um die Einführung der bislang nur in Ausnahmefällen erlaubten Softwarepatente in Europa per EU-Richtlinie schon an. Patentgegner befürchten eine Innovationsverhinderung und die Benachteiligung speziell kleiner Unternehmen und Selbstständiger.

Vor allem das Patentieren von abstrakt formulierten Algorithmen könnte dazu führen, dass OSS-Entwickler weitgehend in ihrer Freiheit hinsichtlich der Entwicklung neuer Programme eingeschränkt werden. Außerdem besteht beim Patentschutz, der ein technisches Verfahren oder Erzeugnis betrifft und unabhängig von der konkreten Umsetzung des jeweiligen Codes besteht, in hohem Maße die Gefahr einer unbewussten Verletzungshandlung. Diese Gefahr droht besonders freien Programmierern, die in der Regel nicht die Möglichkeit haben, regelmäßig teure Patentrecherchen anstellen zu lassen oder gegebenenfalls Patentlizenzen zu erwerben.

Die Abstimmung des EU-Parlaments über eine „Richtlinie des Europäischen Parlaments und des Rates über die Patentierbarkeit computerimplementierter Erfindungen“ am 30. September dieses Jahres wird daher besonders in der Open-Source-Gemeinde mit Spannung erwartet.

Fazit

Um die in jüngster Zeit viel beschworene „Rechtsunsicherheit“ im Zusammenhang mit Open-Source-Software zu vermeiden, helfen einige einfache Regeln: Eine Lizenzgebühr darf nicht erhoben werden. Die kostenpflichtige Verbreitung ist aber insoweit gestattet, als es sich dabei etwa um ein Entgelt für die Datenträger handelt, auf denen sich die Software befindet. Auch für Dienst- oder Unterstützungsleistungen (Handbücher, Supportmaterialien et cetera) kann man Geld verlangen. Wer mit OSS Eigenentwicklungen erstellt, muss diese - etwa nach der GPL - ebenfalls wieder frei zugänglich machen. Andernfalls verliert er seine Rechte aus der GPL, was zu einer Unterlassungsklage gegen ihn führen kann. Dies gilt aber in der Regel nicht bei kompilierten Programmen und nicht für mit OSS erstellte Präsentationen. Bei Softwarebibliotheken ist eine allgemein gültige Einschätzung nicht möglich. Es kommt hier immer auf die Umstände des Einzelfalls an. Etwa darauf, ob die Libraries der GPL oder der Lesser GPL unterstellt sind und ob die darauf basierenden Programme statisch oder dynamisch gelinkt werden.

Tobias Haar und Gabriele Keck
sind Rechtsanwälte in der Communications, Media and Technology Group von Clifford Chance Pünder. (ur)