LINUXMAKER, OpenSource, Tutorials

Open-Source-Software und die GPL

Freiheiten, die Ihr Geld wert sind!

Open-Source-Software (OSS) wächst schon lange über das Betriebssystem Linux hinaus und setzt sich in immer mehr Bereichen durch. Oft werden dabei aber die Rechte und Pflichten vergessen, die mit dem Prädikat Open Source verbunden sind. Dieser Artikel soll den Werdegang von OSS nachzeichnen und – damit unzertrennlich verbunden – die Entwicklung und Auswirkung der GNU General Public License (GPL) beschreiben.
Freie Software ist keine Erfindung einiger weniger Gurus und Hacker, sondern Software galt bereits in den Anfängen der Computerisierung in den sechziger Jahren als frei. Damals war es selbstverständlich, dass ein Zweiter oder eine Dritte einen vorhandenen Algorithmus nicht erneut entwickeln musste. Entwickler haben den betreffenden Quellcode ohne Auflagen weitergegeben. Unfrei wurde die Software durch Leute und Firmen wie Bill Gates oder insbesondere AT&T in Amerika. Sie hatten erkannt, dass sich eine geistige Idee – in unserem Fall die Software – kostengünstig vermehren und teuer verbreiten ließ.

Probleme machte das Urheberrecht, etwa beim UNIX System V, das von AT&T entwickelt wurde. Ursprünglich entstand das System UNIX Anfang der Siebziger in den Universitäten. Nachdem die Hardware bei den Computerherstellern lag, entwickelten diese bald ihre eigenen Unixe. So auch die Firma AT&T, die im Jahr 1983 ihr UNIX System V als proprietäre Software auf den Markt brachte und die Nutzung derselben unter Lizenz stellte. Noch im selben Jahr widersetzten sich einige Entwickler diesem Trend, unter ihnen Richard Stallmann, der sich auf das Prinzip aus den Sechzigern berief: „Free as in freedom, not as in free beer“, sprach er und entwarf eine Definition des Begriffs „Freie Software“, nach der auch heute noch Open Source Software (OSS) von anderer Software unterschieden wird. Die besonderen Rechte umfassen:

  1. die Freiheit, das Programm zu jedem Zweck auszuführen
  2. die Freiheit, das Programm zu studieren und zu verändern
  3. die Freiheit, das Programm zu kopieren
  4. die Freiheit, das Programm zu verbessern und zu verbreiten, um damit einen Nutzen für die Gemeinschaft zu erzeugen

Ebenfalls 1983 startete Stallmann sein GNU-Projekt mit dem Ziel der Entwicklung eines freien Betriebssystems. Dabei ist GNU ein rekursives Akronym („GNU's not Unix“), das sowohl auf die Ähnlichkeit mit UNIX als auch auf die Abgrenzung zu unfreien UNIX-Systemen hinweist. 1985 folgte als weiterer Meilenstein die Gründung der Free Software Foundation (FSF), der Wächterin der späteren GPL. Zusammen mit Jerry Cohen veröffentlichte Stallmann im Januar 1989 die Version 1 der GPL, der wohl bekanntesten Lizenz für Freie Software.

Die nachstehende Grafik visualisiert auf beeindruckende Art und Weise das Konzept von Freier Software.

Einmal GPL, immer GPL

Die GPL verlangt keine Nutzungsgebühren, schränkt keine Rechte ein und erlaubt explizit die Weiterverbreitung. Allerdings geschieht dies unter einer Bedingung: Hat sich ein Entwickler für die Publikation unter der GPL entschlossen, ist das endgültig auch für Folgeversionen. Ein Programm unter der GPL kann also nicht mehr proprietär werden. GPL und damit OSS entsprechen somit einem Virus, der sich stets selbständig fortpflanzt und verbreitet. In Bezug auf die gebotenen Freiheiten kann man ihn „Virus of Freedom“ (Freiheitsvirus) nennen. OSS geht davon aus, dass jeder geistiges Eigentum frei nutzen kann und weitergeben darf. Damit brachte die GPL Probleme für proprietäre Software, die auf die beliebten freien Libraries zugreifen wollte. Eigens für diesen Zweck wurde 1991 die „Library General Public License“ (LGPL), auch bekannt unter dem Namen „Lesser GPL“, geschaffen. Aufgrund der LGPL konnte das auf die Bibliothek zugreifende Programm einem anderen Lizenzmodell unterliegen, womit OSS und GPL kompatibel zu unfreien Systemen wurden.

Der Terminus „Open Source“

Bisher ist von Freier Software die Rede gewesen, das Schlagwort jedoch ist Open-Source-Software. Und Schlagwort ist die richtige Bezeichnung, denn der Terminus „Open Source“ erzielt einen größeren Marketing-Effekt. Bereits 1998 diskutierten viele Entwickler Freier Software heftig darüber, ob diese „Free Software“ genannt werden sollte. Im deutschen Raum assoziiert man mit dem Begriff „Freie Software“ das, was gemäß der Definition der FSF damit ausgedrückt werden soll. Im Englischen jedoch bedeutet der Begriff „free“ zwei Dinge: frei und kostenlos. Aber kostenlos ist OSS keineswegs. Schon beim freien Download entstehen Kosten, selbst wenn sie bei einer DSL-Flatrate niedrig ausfallen. Hinter der Software stecken meist freiwillige Arbeit von Entwicklern oder auch Projekte von Auftraggebern, die durchaus kommerzielle Interessen verfolgen können.

Man konnte und wollte sich nicht auf „Free Software“ einigen. Um also Freie Software als geschäftstüchtig und weniger mit Ideologien beladen zu vermarkten, entwarf Christine Peterson vom Foresight Institute den Begriff „Open Source“, denn „open“ impliziert im Englischen das, was wir in Deutschland unter „frei“ verstehen. Hinzu kam, dass der Begriff Bezug auf die Freilegung des Quellcodes nimmt und eine leichtere Vermarktung ermöglichte. Denn offensichtlich haben Menschen ein Vorurteil gegenüber „kostenlos“ - nach dem Motto: Etwas, das nichts kostet, kann qualitativ nicht gut sein. Das sahen Eric S. Raymond, Bruce Perens und Tim O'Reilly ebenso. Und so wurde schließlich Open Source auch zum Namensgeber der von Raymond, Perens und O'Reilly ins Leben gerufenen Open Source Initiative (OSI).

Unterschiede zwischen OSS und proprietärer Software

OSS unterscheidet sich in ganz wesentlichen Punkten von proprietärer Software, nicht nur in puncto freie Verfügbarkeit als Programm und Sourcecode. Auch die Auswahl an unterschiedlichen Lizenzmodellen und der Insolvenzschutz bieten Vorteile gegenüber kommerzieller Software. Die Sicherheit ist höher und die Entwicklungskosten sind niedriger.

Bei kommerzieller Software läuft der Kunde stets Gefahr, dass ein Hersteller in Konkurs gehen kann und ein Programm nicht mehr weiterentwickelt beziehungsweise unterstützt wird. OSS kennt dieses Problem nicht. Verschwindet der Entwickler einer OSS, können andere das Projekt aufnehmen und weiterentwickeln. So geschehen 1998 bei Netscape, das aufgrund der Dominanz von Microsoft auf dem Browser-Markt den Quellcode zum Netscape Navigator freigab. Das Projekt Netscape lebt heute als Mozilla-Projekt weiter und erfreut sich als Firefox-Browser großer Beliebtheit.

Die Entwicklungskosten trägt nicht eine Firma oder ein Entwickler, sondern sie verteilen sich weltweit auf einige Hunderte in den entsprechenden Projekten. Sie entwickeln aus Spaß am Programmieren in ihrer Freizeit oder gehören OSS-Projekten an, die von einer Firma mit dem Auftrag für Spezialsoftware angestoßen wurden und anschließend unter der GPL weiterentwickelt werden. Auch die Firmen profitieren davon, denn auf diese Weise erhalten sie mehr Leistung zurück. Die Software wird durch Aufträge um Module erweitert und in der Bedienung verbessert.

Ein weiterer wichtiger Aspekt von OSS ist die „prozessorientierte Softwareentwicklung“, bei der Kunden an der Produktion beteiligt sind. Sie steuern wesentlich die späteren Funktionen und die Bedienbarkeit des Programms. Eine kommerzielle Softwareschmiede hingegen schaut zunächst, was sie gewinnbringend verkaufen kann und entwickelt danach die Software. Sicherheit mit OSS wird durch das hohe Qualitätsniveau der großen Entwickler- und Tester-Netzwerke erzielt sowie durch das hohe Sicherheitsniveau der Peer-Reviews. So werden Gefahrenquellen in der Regel relativ schnell aufgedeckt und zeitnah von Spezialisten behoben. Prinzipiell wird bei den OSS-Lizenzen zwischen zwei Modellen unterschieden: Non-Copyleft-Lizenzen und Copyleft-Lizenzen.

Non-Copyleft-Lizenzen

Non-Copyleft-Lizenzen sind stark an die BSD License (Berkeley Software Distribution) angelehnt. Sie sind weniger konsequent in Bezug auf ihre Sublizenzierung als Copyleft-Lizenzen. Unter sie gestellte Software lässt sich leichter in proprietäre Software integrieren. Ein Beispiel ist die „X11/XFree License“, die keine Angaben über eine Sublizenzierung macht und sie somit implizit zulässt. Daraus resultiert, dass von dem X Window System sowohl OSS- als auch proprietäre Versionen existieren.

Weiterentwicklungen können unter einer anderen Open-Source-Lizenz erfolgen, sogar der proprietäre Vertrieb ist möglich. So kann Software unter einer Non-Copyleft-Lizenz durchaus unfrei werden. Meistens geht es hier um Haftungsausschlüsse und Urhebervermerke, es bestehen jedoch keine Verpflichtungen wie bei der GPL. Die wichtigsten Vertreter von Non-Copyleft-Lizenzen sind neben den BSD-Lizenzen die „Apache Software License“ und die „OpenLDAP Public License“.

Copyleft-Lizenzen

„Copyleft“ war eine Anspielung Richard Stallmanns auf das Copyright. Bearbeitet ein Urheber erlaubterweise das durch ein Copyright geschützte Werk eines anderen, dann erhält er nach geltender Rechtssprechung ein Mitspracherecht, darüber zu entscheiden, wie die Bearbeitung verwendet werden darf.

Wenn das ursprüngliche Werk bis dahin noch für jedermann frei kopierbar, verteilbar und veränderbar war, dann übertragen sich aber diese Freiheiten nicht automatisch auf die Bearbeitung. Dieses Prinzip versuchen Copyleft-Lizenzen umzukehren. Da hier auch der ursprüngliche Autor ein Mitspracherecht an der Bearbeitung hat, erlaubt er nur dann die Weitergabe der Bearbeitungen, wenn sie zu den gleichen umfangreichen Rechten an jedermann lizenziert werden. Kurz gesagt soll das Copyleft-Verfahren verhindern, dass Freie Software zum Ausgangsmaterial knapper proprietärer Software wird.

GNU General Public License ist eine Copyleft-Lizenz

Die GNU General Public License (GPL) baut auf dem beschriebenen Copyleft-Verfahren auf. Daneben sind in ihr eine ganze Reihe Rechte und Verpflichtungen enthalten, die übersichtlich beschrieben und dokumentiert sind [1]. Allerdings umfasst die Dokumentation der GPL ein ganzes Buch, sodass hier nur die wesentlichen Punkte genannt werden:

Interessant ist das Thema Haftung bei GPL-Software. Grundsätzlich haftet der Urheber von freier Software ebenso wie der Urheber proprietärer Software. Somit kann ein Entwickler durchaus an seinem Heimatort für Schäden, die durch den Einsatz seiner Software entstanden sind, verklagt werden. De facto ist das selbst bei proprietärer Software in den letzten 20 Jahren nie passiert. Vielleicht hat das mit der Erwartungshaltung der Nutzer zu tun, dass Software prinzipiell fehlerbehaftet sei und kein Kunde Fehlerfreiheit erwartet. Ohnehin wäre eine Haftungsklage bei der Vielzahl von Entwicklern eines Programms kaum möglich, da sie über den Globus verteilt in unterschiedlichen Staaten zu Hause sind. Man müsste zuerst den Verantwortlichen für den fehlerhaften Codeschnipsel finden, um ihn dann im entsprechenden Land nach dort gültigem Recht zu verklagen. Praktisch ist das nicht umsetzbar und somit das Thema Haftung bei GPL-Software für Urheber kein relevantes Problem. Ganz anders, wenn sich der Lizenznehmer nicht an die Regeln der GPL hält.

Rechtliche Konsequenzen in zwei Fällen

1999 musste Professor Victor Yodaiken auf sein Echtzeitbetriebssystem RTLinux (US-Patent 5.995.745) aufgrund des Drucks der FSF ein Open-Source-artiges Nutzungsrecht an dem Patent einräumen (Open Patent RTLinux Patent License Version 2). Sinngemäß darf das Patent mit dieser Lizenz nur von solchen Programmen verwendet werden, die auch der GPL unterliegen, nicht jedoch von anderweitig lizenzierter OSS [2]. Yodaiken hatte den Kernel unter Debian GNU Linux verwendet, um ihn mit einem Echtzeit-Interrupt-Handling zu erweitern. Allerdings unterlag der Linux-Kernel der GPL und daraus folgte, dass die gesamte Entwicklung der GPL unterliegt. Der „Virus of Freedom“ hatte gegriffen. Yodaiken hatte versucht, die Patent-Lizenz zu verwenden, um restriktive Bedingungen auf ein unter der GPL stehendes Betriebssystem anzuwenden. Das OSS-Prinzip geht streckenweise sogar so weit, dass Software, die mit GPL-Werkzeugen entwickelt oder kompiliert wurde (z. B. mit gcc), bereits zu OSS wird.

Im zweiten spektakulären Fall entschied am 19. Mai 2004 das Landgericht München I als weltweit erstes Gericht für die rechtliche Wirksamkeit einer Open-Source-Lizenz, in diesem Fall der GPL. Dem Verfahren ging eine einstweilige Verfügung des Berliner Softwareentwicklers Harald Welte gegen einen Router-Hersteller voraus. Harald Welte ist Vorsitzender des Netfilter Core Teams, von dem das Programm „netfilter/iptables“ [3] entwickelt wird, das zum Sicherheitssystem des Linux-Kernels gehört. Auf den Websites der Entwickler steht das Programm zum freien Download mit dem ausdrücklichen Hinweis auf Freie Software und die GNU/GPL bereit. Die beklagte Firma bot ihre Firmensoftware, die inzwischen das GPL-Programm „netfilter/iptables“ enthielt, ebenfalls zum Download an. Allerdings fehlte der Hinweis, dass Teile der Software unter der GPL-Lizenz stehen. Ebenso wenig wurde eine Kopie des Quellcodes der Allgemeinheit zugänglich gemacht.

Nach erfolglosen Abmahnungen des Klägers zeigte das gerichtliche Vorgehen gegen den Router-Hersteller Erfolg, indem das LG München I einen Unterlassungsanspruch aus §§97, 69a, 8 Abs.2, 15 UrhG gewährte und entschied, dass die Handlungen der beklagten Firma gegen die Inhalte der GPL-Lizenz verstießen. Das Gericht war der Auffassung, dass in der Einräumung von Nutzungsrechten durch die GPL keineswegs ein Verzicht auf das Urheberrecht und die urheberrechtlichen Rechtspositionen gesehen werden kann. Stattdessen nutzen die Lizenzgeber die Möglichkeiten im Urheberrecht, die Verbreitung und Weiterentwicklung von Software sicherzustellen und zu realisieren. Im Prinzip entspricht die GPL nach Ansicht der Richter dem Konstrukt von Allgemeinen Geschäftsbedingungen. Sie unterliegen damit der Kontrolle der §§ 305 ff BGB. Mit dem Urteil wurde erstmals ein rechtlicher Beweis erbracht, dass die GPL deutschem Recht entspricht. Das Gerichtsurteil ist im Internet veröffentlicht [4].

Fazit

OSS-Anbieter müssen in jedem Fall die verwendete Lizenz mit angeben. Damit es nicht zu urheberrechtlichen Ansprüchen der Miturheber von OSS kommt, sollte der oder die Betreffende ihre Vertriebskette an der GPL ausrichten. Dabei muss sichergestellt sein, dass bei der Weitergabe des Sourcecodes die teilweise unterschiedlichen Lizenzpflichten erfüllt sind. Hier tritt wieder der „Virus of Freedom“ hervor: Einmal GPL, immer GPL.

Dass der Gedanke und die Idee der GNU GPL immer mehr Früchte tragen, zeigen zahlreiche andere freie Lizenzen, die an die jeweiligen Anforderungen angepasst das Lizenzspektrum erweitern. Als Beispiele seien die GNU Free Documentation License (GFDL) oder die Creative-Commons-Lizenzen genannt. Inzwischen ist das Angebot an verschiedenen Lizenzen so groß, dass es schwierig wird, nicht den Überblick zu verlieren oder sich nicht in rechtlichen Details zu verheddern. Gerade im Hinblick darauf, dass OSS auf immer breiterer Basis in kommerziellen Lösungen Anwendung findet, sollten Entwickler und Anbieter darauf achten, nicht gegen die grundlegenden Lizenzrechte zu verstoßen.