Freie Software ungleich Open Source? Betrachtung von Lizenzen anhand von Beispielen und Vergleichen

Inhaltsverzeichnis

1. Einleitung und Motivation
1.1. Motivation
1.2. Der Plot

2. OSS und freie Software
2.1. Freie Software- eine Definition
2.2. Open Source- eine Definition nach OSI

3. Lizenzen im Vergleich
3.1. Plot
3.2. GPL, BSD, LGPL und Co
3.3. Die Lizenzen im Einzelnen
3.4. Zusammenfassung

4. Ausgewählte Aspekte des Plots
4.1. Die Doppellizensierung
4.2. Verdienstmöglichkeiten mit OSS
4.3. Haftungsaspekte
4.4. Missbrauch der GPL
4.5. Softwarepatente

5. Fazit

Literatur

A. Glossar

B. Thesenpapier
B.1. Zusammenfassung des Themas
B.2. Thesen zum Thema

C. Apache Lizenz

D. PHP Lizenz

E. GNU General Public Lizenz (GPL)

1. Einleitung und Motivation

1.1. Motivation

Open Source ist wegen der steigenden Verbreitung mehr und mehr auch für grosse Un- ternehmen interessant geworden. Grosse Konzerne wie IBM, Sun und Börsenhypes wie Netscape setzen zunehmend auf Open Source Software. Doch mit der zunehmenden Verbreitung werden auch rechtliche Probleme sichtbar. Diese Seminararbeit soll anhand einer fiktiven Firma mit einem fiktiven Kunden einen Plot aufzeigen, der verschiedenste Aspekte der Onlinediskussion erneut aufgreift und die Thesen hinterfragt.

Der im folgenden Abschnitt vorgestellte Plot wird weiterhin mit ergänzenden Fragen erweitert und anhand von praktischen Fragestellungen zu dem imaginären Produkt dann die rechtlichen Aspekte dazu vertieft dargestellt.

1.2. Der Plot

Die Firma ProjecTronik benötigt für ihre ausgedehnte Projektarbeit eine Lösung zur Verwaltung der einzelnen Projekte. Da die allgemeine Konjukturlage und das IT-Budget keine grossen Sprünge zulassen, wendet sich der Leiter der IT-Beschaffung Herr Nieswurz an den freien Berater Peter Schmitz¹.

Nieswurz: “Lieber Herr Schmitz, wie sie sicher wissen, benötigen wir in unserem Unternehmen eine neue Projektmanagementsoftware. Da wir ungern neue Software im grossen Umfang auf jedem PC im Unternehmen einführen wollen und nicht teure und neue Lizenzen erwerben möchten, wäre eine webbasierte, günstige Software für uns die erste Wahl. Haben sie da aus ihrer Erfahrung aus etwas vorzuschlagen?“

Schmitz: “Hmm. Sie wollen also in ihrem Intranet eine Software einsetzen, die auch einem Server laufen soll und über den Internetbrowser eines jeden Mitarbeiters aufgerufen werden soll. Die entsprechende Infrastrutur haben sie wie ich weiss ja bereits, ich hätte da tatsächlich etwas, was ich ihnen vorschlagen könnte. Das wäre die Software BSDProject. Sie ist eine LAMP Lösung und ist Open Source, d.h. ihre Kosten für Lizenzen sind gleich null.“

Nieswurz: “Hmm. Das klingt sehr interessant. Allerdings habe ich eine Frage: Was ist Open Source?“ Nach diesem Gespräch ist sich Herr Schmitz sicher, das noch einiges an Beratungstätigkeit auf ihn warten wird...

2. Was ist Open Source oder freie Software

Nicht nur Herr Nieswurz hat so einige Probleme, Open Source Software und freie Software auseinanderzuhalten. Allzuoft wird die Begriff “frei“ so aufgefasst, dass es sich um kostenlose Software handelt. Richard Stallman² meinte mit seiner Idee jedoch etwas anderes, was in der folgenden Definition der Freiheit ausgedrückt ist.

2.1. Freie Software- eine Definition

Stallman meinte den Begriff freie Software nicht im Sinne von “Freibier“, sondern im Sinne der folgenden vier Freiheiten, die einem Nutzer freie Software bieten soll:

0. Freiheit Die Freiheit, das Programm für jeden Zweck einsetzen zu dürfen.
1. Freiheit Die Freiheit, untersuchen zu dürfen, wie ein Programm funktioniert und es den eigenen Bedürfnissen anzupassen.
2. Freiheit Die Freiheit, Kopien für andere machen zu dürfen.
3. Freiheit Die Freiheit,das Programm verbessern zu dürfen und diese Verbesserungen zum allgemeinen Wohl zugänglich zu machen.

Freie Software bedeutet nicht, dass die Software kostenlos ist. Diese Freiheiten werden in der Open Source Software Szene im allgemeinen mit dem Begriff freie Software verknüpft. Der Begriff der Open Source Software hingegen ist noch weitergehender. Open Source bedeutet nicht nur freie Quellen; es gibt durchaus Software, deren Quellen offen liegen, aber nicht freie Software im obigen Sinne ist. Die OSI (Open Software Initiative)³ hat 1997 nach den obigen Richtlinien eine Definition quelloffener Software geschaffen, die i.A. als verbindlich angesehen ist und zumindest in den USA als Warenzeichen eingetragen ist. Jede Software, die nicht den Ansprüchen der OSI genügt, darf nicht als Open Source bezeichnet oder beworben werden. Diese zehn Punkte werden im folgenden Abschnitt erläutert.

2.2. Open Source- eine Definition nach OSI

Die Debian Free Software Guidelines⁴ legen mit ihren zehn Punkten einen verbindlichen Katalog fest, der Open Source Software in Sinne des Verständnisses der OSI definiert.

1.Freie Weitergabe Eine Lizenz, die der OSI Definition entsprechen soll, darf nicht die Weitergabe der Software einschränken. Dies gilt vor allem für die Bündelung mit anderer Software zu einer Compilation und der anschliessenden entgeltlichen oder auch unentgeltlichen Weitergabe.
2. Quellcode Das Programm muss den Quellcode beinhalten. Dem Nutzer muss es er- laubt sein, sowohl den Quellcode als auch das compilierte Programm weitergegeben zu dürfen, der Quellcode darf in keiner Form eingeschränkt sein und etwa lediglich aus Zwischencode bestehen.
3. Abgeleitete Software Die Lizenz muss Veränderungen an der Software zulassen und sicherstellen, dass diese Veränderungen unter denselben Lizenzbestimmungen wei- tervertrieben werden dürfen.
4. Unversehrtheit des Quellcodes des Autors Die Lizenz darf die Weitergabe des ver- änderten Quellcodes nur unter der Bedingung einschränken, wenn sie vorsieht den Code mit Patch Files weiterzugeben, die das Programm bei der Compilierung ver- ändern. Die Lizenz muss die Weitergabe dieser Software ausdrücklich erlauben, kann jedoch verlangen, dass die neue Software einen anderen Namen oder eine andere Versionsnummer tragen muss.
5. Keine Diskriminierung von Personen oder Gruppen Die Lizenz darf niemanden be- nachteiligen. Jeder Nutzer hat dieselben Rechte unter der Lizenz
6. Keine Einschränkung bzgl. des Einsatzfeldes Die Lizenz darf den Einsatz der Soft- ware in bestimmten Feldern nicht einschränken oder verbieten.
7. Weitergabe der Lizenz Die Rechte an dem Programm müssen auf alle Personen übergehen, die die Software erhalten, ohne dass diese zusätzlich eine Lizenz erwer- ben müssen.
8. Die Lizenz darf nicht auf ein bestimmtes Produktpaket beschränkt sein Die Re- chte an dem Programm dürfen sich nicht unterscheiden, egal ob ein Programm als Stand-alone oder in einem Softwarepaket vertrieben wird.
9. Nicht Weitergabe von Software mit anderer Software einschränken Die Lizenz darf z.B. nicht verlangen, dass Software, die quelloffen ist, auf einem Datenträger nur mit Software weitergegeben werden darf, die auch quelloffen ist. Man kann auf einem Datenträger durchaus Open Source und proprietäre Software vertreiben.
10. Beispiellizenzen Lizenzen, die diesen Bedingungen genügen , sind z.B. die GNU Public License⁵, die Berkley Software Distribution License oder die Artistic Licen- se⁶

Wie zu sehen ist, gibt es zwar viele Kriterien; die Hauptkriterien für eine Open Source Lizenze sind jedoch die Lizenzgebührenfreiheit, die Offenlegung des Quelltextes und die Erlaubnis, das Programm zu vervielfältigen, zu verändern und die veränderten oder unveränderten Programme weiterzuverbreiten.

3. Lizenzen im Vergleich

3.1. Plot

Nun geht es weiter im Plot, Herr Nieswurz versteht zwar das Konzept, hat aber verständlicherweise noch weitere Fragen.

Nieswurz: “Gut, Herr Schmitz, jetzt habe ich den Unterschied zwischen Freeware und Open Source verstanden, allerdings bin ich doch noch etwas verwirrt. Was für eine Lizenz genau brauche ich denn nun und wo bekomme ich sie her? Gibt es das Einschränkungen? “

Schmitz: “Ja, das ist eine sehr interessante Frage. Das System, was ich Ihnen empfehle hat tatsächlich Komponenten, die unter verschiedenen Lizenzen stehen. Doch wenn man sich alles einmal genau anschaut, gibt es dort keine Probleme. Ich werde es ihnen mal kurz erklären. Das System besteht aus verschiedenen Komponenten. Das Betriebssystem des Servers wird Linux sein, darauf werden wir einen sogenannten Webserver installieren, ähnlich einem Server im Internet für Homepages. Ich würde hierfür den Apache Webserver empfehlen. Der Apache bekommt dann als sogenanntes Modul den PHP Interpreter, der die Scriptsprache PHP, die in Webseiten eingebettet werden kann, interpretiert und an den Webserver ausliefert. Die Ausgabe kann dann auf einem x-beliebigen Rechner mit Browser erfolgen. Dadurch haben sie dann überall im Unternehmen Zugriff auf die Daten. Als Datenbank würde ich die MYSQL Datenbank empfehlen, sie ist extrem einfach mit PHP anzusprechen, schnell und vor allem kostenlos. Entwickler für diese Techniken bekommen sie heutzutage zuhauf auf dem Arbeitsmarkt. MYSQL wird unter der GPL veröffentlicht, Apache und PHP haben jeweils eigene Lizenzen, die aber auch den OSI Bedingungen genügen, Linux ist in verschiedenen Distributionen erhältlich, die aber alle unter GPL stehen. “

Nieswurz: “Hmm. Wo ist denn der Unterschied zwischen den Lizenzen? Warum gibt es soviele?“

3.2. GPL, BSD, LGPL und Co

Wie Herr Nieswurz erkannt hat, gibt es diverse Lizenzen⁷. Dort durchzublicken ist nicht immer so ganz einfach. Es wird vor allem zwischen zwei grossen Arten von Lizenzen unterschieden: der Gruppe mit einem Copyleft-Effekt und der Gruppe ohne Copyleft- Effekt⁸.

Das Copyleft als Begriff kommt als Verballhornung daher, das von der FSF das Copy- right abgelehnt wird. Demjeniegen, der die Software lizensiert hat, werden zusätzliche Privilegien eingeräumt. Dies wird von der Copyleftfraktion abgelehnt, die daher den Begriff geprägt hat. Es geht daher um die Frage, ob Weiterentwicklungen und sonsti- ge Änderungen an einem Programm ebenfalls wieder freigegeben werden müssen, in dem man die neuen modifizierte Software unter dieselbe Lizenz stellen muss wie die ursprüngliche Software. Die Copyright Fraktion vertritt hingegen die Meinung, dass ein Programmierer auch die Freiheit haben muss, Modifikationen eines Programmes pro- prietär zu verwenden, d.h. Lizenzgebühren zu verlangen und den Quelltext verdeckt zu halten.

Folgende Grafik zeigt die am meisten verbreiteten Lizenzen auf Basis der Open Source Software Projekte auf dem SourceForge Servern⁹:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Verteilung Open Source Software Projekte bei SourceForge

Hieran erkennt man sehr schön, dass die beiden grossen Copyleft Lizenzen, die GPL und die LGPL einen sehr grossen Anteil an den gesamten Open Source Software Lizenzen haben, die BSD-artigen Lizenzen ohne Copylefteffekt haben allerdings auch noch einen signifikanten Anteil.

3.3. Die Lizenzen im Einzelnen

Die folgenden kurzen Erläuterungen fassen die grössten Lizenzen zusammen. Die GPL (GNU Public License):

Wie die vorhergehende Grafik zeigt, ist die GPL¹⁰ die meistverbreitete Lizenz, was vor allem historische und ideologische Gründe hat. Richard Stallman rief die Ursprünge der GPL schon in den Achtziger Jahren ins Leben, und durch die OSI wird die GPL auch heute noch weiter verbreitet. Die GPL hat neben den Ansprüchen der OSI auch die in Kapitel 2.2 beschriebenen wesentlichen Klauseln:

- Jedes aus einem GPL Programm hervorgehende Programm muss auch unter GPL lizensiert werden (“work based on program“).
- Der gesamte Quellcode des Programmes muss mitgeliefert werden.
- Beim Programmstart sollte ein Hinweis auf die GPL erfolgen Die Haftung für entstehende Schäden wird soweit möglich ausgeschlossen.
- Der Lizenzgeber kann die Lizenz auf bestimmte Länder einschränken, z.B. aus patentrechtlichen Gründen.

Damit wird eine Überprüfbarkeit sichergestellt, und dass GPL Software immer freie Software bleibt. Durch die “work based on program“ Klausel gibt es allerdings das Pro- blem, dass Bibliotheken unter GPL bei der Verwendung dazu führen, dass das gesamte Programm ebenfalls unter GPL lizensiert werden muss. Jedoch stimmt es nicht, dass jede Software, die mit GPL Software zusammen verwendet wird, auch unter der GPL lizensiert werden muss. Auch bei der Weitergabe von GPL Software auf Datenträgern muss die andere Software nicht GPL lizensiert sein. Die blosse Anpassung von GPL Soft- ware führt nicht zu der Pflicht, diese auch veröffentlichen zu müssen. Die Kombination von GPL Software mit anderer Software und die anschliessende Weiterverbreitung als ein Werk führt dazu, dass das gesamte Softwarepaket unter der GPL lizensiert werden muss.

Die LPGL (GNU Lesser General Public License)¹¹:

Durch die Einschränkung der GPL bei der Verwendung von Bibliotheken stehen Ent- wickler oft vor dem Probleme, dass durch Verwendung elementarer GPL Bibliotheken in ihren Programmen die Entwicklung proprietärer Software nahezu unmöglich wird. Die- ses Problem erkannten sogar die hartgesottensten GPL Verfechter und riefen die Library General Public License ins Leben, die später zur Lesser General Public License unbe- nannt wurde. Im Gegensatz zur GPL erlaubt die LGPL die statische und dynamische Verlinkung einer Bibliothek mit einem Programm, ohne dass gleich das gesamte Programm unter der GPL stehen muss. Veränderungen an der Bibliothek selber unterliegen jedoch der GPL. Die BSD (Berkley Software Distribution).¹²:

Die Lizenzbedingungen der BSD Lizenz haben ein ganz andere Tradition als die GPL Lizenzen, sind aber ähnlich alt. Es gibt mehrere Hauptbedingungen für eine Lizenz nach BSD:

- Gegenüber den Programmierern können Haftungsansprüche geltend gemacht wer- den.
- Das Programm darf auch als ausführbare Datei ohne Quellcode überlassen werden.
- Sollte es in ausführbarer Form weitergegeben werden, so muss die Lizenz als Datei in einer speziellen Form dem Programm beigefügt werden, d.h. ggf. auf dem Datenträger enthalten sein.
- Bei Weiterentwicklungen darf der Name des Herstellers/der Autoren nicht ohne Erlaubnis für Werbezwecke eingesetzt werden.¹³

Die BSD Lizenz ohne ihren Copyleft Effekt ermöglicht es, Software aus dem Open Source Bereich als proprietäre Software weiterzuentwickeln und somit letztendlich auch an dieser Software direkt zu verdienen. Der Quelltext bleibt verborgen und man legt keine Geschäftsgeheimnisse offen.

3.4. Zusammenfassung

Software unter GPL...

- ermöglicht keine Verbindung mit proprietärer Software,
- eigene Veränderungen müssen frei sein,
- die Software darf nicht unter anderen Bedingungen veröffentlicht werden,
- enthält keinerlei besondere Rechte für den Lizenzinhaber. Software unter LGPL...
- ermöglicht die indirekte Verbindung in proprietärer Software (statisches oder dynamisches Linking),
- eigene Veränderungen müssen frei sein,
- die Software darf nicht unter anderen Bedingungen veröffentlicht werden,
- enthält keinerlei besondere Rechte für den Lizenzinhaber. Software unter BSD...
- ermöglicht die direkte Überführung in proprietäre Software,
- eigene Veränderungen müssen nicht frei sein,
- die Software darf nicht unter anderen Bedingungen veröffentlicht werden,
- enthält keinerlei besondere Rechte für den Lizenzinhaber.

Wie man letztendlich sieht, unterscheiden sich die Lizenzen vor allem am Effekt ihres Copylefts. Ihre Open Source Herkunft kann man stets klar erkennen.

Nieswurz: “Dann sagen sie mir doch mal, was bei BSDProject an Lizenzen benutzt wird.“

Schmitz: “Das kommen verschiedene Lizenzen zusammen, die im gesam- ten allerdings unkritisch sind wegen einiger Gründe, die ich ihnen nennen werde. Das Betriebssystem für den Server ist wie bereits erwähnt Linux, daher fällt es auf jeden Fall unter die GPL. Allerdings ist die Software an sich betriebssystemunabhängig, deswegen könnten sie auch einen eventuell vorhanden Windows Server weiter benutzen. Ausserdem wird das gesamte System nicht mit dem Betriebssystem beworben und angeboten, daher muss bei der Bündelung auch nicht die restliche Software in ihrer Gesamtheit unter der GPL lizensiert werden. Der Apache Webserver wird unter der Apache License herausgegeben, diese ist eine BSD-artige Lizenzen, daher könnten sie sogar selber die Software weiterentwickeln und verkaufen. Dies gilt ebenso für PHP. Einzig die MYSQL Datenbank steht unter der GPL Lizenz Und unter einer kommerziellen Lizenz, es wurde also eine Doppelizensierung angewendet. Für den nichtkommerziellen Einsatz und die nichtkommerzielle Verbreitung ist die Datenbank kostenlos, wenn sie jedoch ihr Produkt mit den DB verkaufen wollen, eine Haftungsgarantie von dem Hersteller wünschen oder einfach nur die Entwicklergemeinde unterstützen wollen, dann müssen und sollten sie eine Lizenz erwerben. Da wir nun also das System ohne GPL haben wenn wir die DB lizensieren, können sie sogar das System weiterentwickeln und an andere Nutzer verkaufen, da die BSD Lizenzen ihnen dies erlauben.“

Nieswurz: “Klingt ja höchst interessant. Aber ihre Erläuterungen haben wieder einige Fragen aufgeworfen. Aber erstmal der Reihe nach: Was ist denn eine Doppellizensierung?“

4. Ausgewählte Aspekte des Plots

4.1. Die Doppellizensierung

Das Verfahren, eine Open Source Software unter eine Open Source Lizenz und zusätzlich noch unter einer proprietären Lizenz herauszubringen, wird als Doppellizensierung be- zeichnet. Wie die vorherigen Abschnitte gezeigt haben, ist es mitunter nicht sehr einfach, zu sehen, welche Komponenten in ein proprietäres Programm überführt werden dürfen oder wie GPL-Komponenten mit proprietärer Software kombiniert werden können. Um diese Probleme zu umgehen, wird eine Software einfach unter zwei oder mehr Lizenzen veröffentlicht. Dies ist rein rechtlich gesehen überhaupt kein Problem. Beispiel für Soft- ware unter einer Doppellizenz sind die Datenbank MYSQL, die Grafikbibliotheken Qt von Trolltech und das Officepaket Star Office/ OpenOffice von Sun. Die Doppellizenz ermöglicht es hier, die Software einzusetzen, wenn sie interessant für das Projekt ist und man verhindern möchte, dass am Ende das gesamte Projekt unter GPL Lizenz gestellt werden muss. Es gibt also die Möglichkeit proprietäre und freie Software gleichzeitig zu produzieren.

Einschränkend muss man sagen: wenn man eine Software einmal unter GPL gestellt hat, dann bleibt sie auch unter GPL, da man die einmal eingeräumten Nutzungsrechte nicht kündigen kann. Die GPL enthält jedoch nicht die Verpflichtung zum Verzicht auf urhe- berrechtliche Befugnisse, sie räumt lediglich einfache Nutzungsrechte für jedermann ein, was der Autor nicht daran hindert, das Programm noch anderweitig zu nutzen. Einziges Problem ist hier, dass eventuelle Verbesserungen aus dem GPL Zweig an dem Programm nicht durch den Autor übernommen werden dürfen. Hier gibt es zwar einige Lizenzen, die solche Dinge fordern, z.B. Die SCSL¹⁴ von Sun, eine so geänderte Lizenz entspricht jedoch nicht dem Geist der OSI, da sie dem Lizenzgeber Sonderrechte einräumt.

Nieswurz: “Die MYSQL Datenbank hat also ein solche Doppellizenz. Das bedeutet, wenn wir das Programm weiterentwickeln und es anbieten wollen, müssen wir hierfür eine Lizenz erwerben. Stimmt das?“ Schmitz: “Ja das stimmt. Es gibt jedoch wie schon erwähnt bei den BSD Lizen- zen Einschränkungen. Das System darf z.B. nicht “ProjecTronik Apache Pro- jektmanagementsoftware“ nennen. Allerdings erlaubt es die BSD Lizenz eben, die Software in eine proprietäre Software zu überführen. Auch das eigentliche Programm, das Skript der Software in PHP und HTML, ist unter der BSD Lizenz erschienen.“

4.2. Verdienstmöglichkeiten mit OSS

Wie erwähnt kann man zwar BSD-lizensierte Software in proprietäre Software überführen, bei GPL Software ist jedoch keine Verdienst mit der Software selber möglich.

[...]

¹ Anm.: in Glossar sind alle kursiv gedruckten EDV-Begriffe erklärt

² siehe [Sta82]

³ siehe http://www.opensource.org/

⁴ siehe [Ron03]

⁵ enthalten im Anhang

⁶ eine der Lizenzen unter der die Skriptsprache Perl lizensiert ist

⁷ siehe [Ifr03]

⁸ siehe auch [Jae00]

⁹ siehe [Ber03]

¹⁰ deutscher Version unter http://www.gnu.de/gpl-ger.html

¹¹ verfügbar unter http://www.gnu.org/copyleft/lesser.html

¹² siehe http://www.opensource.org/bsd-license.php ¹³ siehe z.B. Apache/PHP Lizenz im Anhang

¹⁴ siehe http://wwws.sun.com/software/jini/licensing/licenses.html