(Intellectual) Property Rights, Transaktionskosten und Governance-Strukturen in Open Source Software Projekten

Inhaltsverzeichnis

  Abkürzungsverzeichnis  IV

Abbildungsverzeichnis .............................................................................................................. V

Tabellenverzeichnis................................................................................................................... V

1.  Einleitung  1

1.1.  Motivation und Zielsetzung  1

1.2.  Aufbau der Arbeit  2

2.  Das Gut Software  2

2.1.  Ökonomische Eigenschaften von Software  4

2.1.1.  Software als Netzwerkgut  4

2.1.2.  Software als Informationsgut  5

2.1.3.  Software als komplexes Gut  6

2.1.4.  Software als digitales Gut  7

2.1.5.  Software als Gut ohne Rivalität im Konsum  8

2.2.  Open Source Software  9

2.2.1.  Motive der beteiligten Entwickler  9

2.2.2.  OSS- vs CSS- Lizenzen  10

2.2.2.1.  Offene OSS-Lizenzen  12

2.2.2.2.  Virale OSS-Lizenzen  12

2.2.2.3.  CSS-Lizenzen  13

2.2.2.4.  Resümee zu den Lizenzmodellen  13

2.3.  (Intellectual) Property Rights und Softwareproduktion  14

3.  Governance von Open Source Software Projekten  17

3.1.  OSS-Governance und Projektlebenszyklus  21

3.1.1.  Die Einführungsphase  22

3.1.2.  Die Wachstumsphase  23

3.1.3.  Die Reifephase  24

3.1.4.  Die Rückgangsphase (mit oder ohne Wiederaufleben)  25

3.1.5.  Erkenntnisse aus der Lebenszyklusbetrachtung  25

3.1.6.  Einführung von Governance-Instrumenten in OSS-Projekten - eine  

  Gradwanderung  27

3.2.  OSS-Governance und Institutionenökonomik  28

3.2.1.  OSS-Governance und Transaktionskosten  31

  II  

3.2.2.  Institutionelle Arrangements zur OSS-Governance  33

3.2.2.1.  Prinzip der Offenheit  34

3.2.2.2.  Interne Governance  39

3.2.2.2.1.  Modularität in Programmarchitektur und Projektorganisation  41

3.2.2.2.2.  Hierarchie nach Leistung  44

3.2.2.2.3.  Passive Kontrollrechte  46

3.2.2.2.4.  Standardisierte Kommunikationsmechanismen  47

3.2.2.2.5.  Standardisierte Koordinationsmechanismen  49

3.2.2.2.6.  Instrumente zur Sicherung intrinsischer und Förderung extrinsischer  

  Motive  50

3.2.2.3.  Externe Governance  51

3.2.3.  Zusammenfassung zur Governance von OSS-Projekten  54

4.  Institutionenökonomische Erkenntnisse  55

5.  Fazit und Ausblick  59

  Literaturverzeichnis  VI

  III  

Abkürzungsverzeichnis

AGB Allgemeine Geschäftsbedingungen

BSD Berkley Software Distribution

bzw. beziehungsweise

CSS Closed Source Software

CVS Concurrent Versions System

ECIS European Committee for Interoperable Systems

et al. et alii

etc. et cetera

FSF Free Software Foundation

FTP File Transfer Protocol

GPL General Public License

i.e. id est

IPR Intellectual Property Rights

IRC Internet Relay Chat

KDE K Desktop Environment

LGPL Lesser General Public License

MIT Massachusetts Institute of Technology

NIÖ Neue Institutionenökonomik

OSD Open Source Definition

OSI Open Source Inititiative

OSS Open Source Software

PR Property Rights

S. Seite

u.a. unter anderem

US PTO United States Patent and Trademark Office

usw. und so weiter

vgl. vergleiche

z.B. zum Beispiel

IV

Abbildungsverzeichnis

  Abbildung 1 - Top-10-Verteilung der verwendeten Lizenzen für OSS registriert bei  

  SourceForge net (Stand: 25 01 2008)  11

  Abbildung 2 - Trade-off zwischen Wohlfahrtsverlusten durch externe Effekte und  

  Transaktionskosten  15

  Abbildung 3 - Lebenszykluskonzept  22

  Abbildung 4 - OSS und CSS im Trade-off zwischen Wohlfahrtsverlusten durch externe  

  Effekte und Transaktionskosten  57

Tabellenverzeichnis

Tabelle 1  - Güterarten nach Ausschließbarkeit und Rivalität: eigene Darstellung  8

Tabelle 2  - Softwarelizenzen und Übertragung von (I)PR  13

Tabelle 3  - Organisations- und Koordinationsformen  18

Tabelle 4  - charakteristische Eigenschaften der Projektphasen  26

  V  

1. Einleitung

1.1. Motivation und Zielsetzung

Die zunehmende Etablierung von Open Source Software (OSS) 1 im Softwaremarkt hat dazu

geführt, dass nicht nur das private und öffentliche, sondern auch das wissenschaftliche Inte- resse an OSS-Projekten zugenommen hat. Neben dem Betriebssystem Linux stellen zuneh- mend auch viele weitere OSS-Anwendungen, wie z.B. der Webbrowser Mozilla/Firefox oder der Apache Webserver ernstzunehmende Konkurrenz für ihre Mitstreiter aus dem Bereich der Closed Source Software (CSS) dar. Diese Entwicklung zeigt, dass sich mit OSS-Projekten eine alternative Organisationsform zur Erstellung komplexer Software herausgebildet hat. Der Erfolg von OSS-Projekten hängt dabei stark davon ab, inwieweit die Communities in der La- ge sind, ihre Zusammenarbeit effizient zu koordinieren.

“Open Source Software can sometimes defeat proprietary software. However this is far from being always true. It relies on the efficiency of its organization. […] In what extent then are open source software communities able to organize them- selves, to self-organize […]?” (Dalle/Jullien, 2002, S. 14)

Die Motive der OSS-Entwickler wurden in zahlreichen Studien bereits ausgiebig untersucht und diskutiert. Verhaltensweisen von Individuen ergeben sich jedoch aus dem Zusammen- spiel von Motiven mit den durch Institutionen bestimmten Anreizstrukturen. Entsprechend erscheint eine Untersuchung der institutionellen Arrangements von OSS-Projekten sinnvoll. Ziel dieser Arbeit ist es daher, sich anzuschauen welche institutionellen Arrangements zur Governance von OSS-Projekten eingesetzt werden. Aus institutionenökonomischer Sicht ist es vor allem interessant, die Effizienz verschiedener institutioneller Arrangements ökono- misch zu bewerten. In diesem Zusammenhang spezialisiert sich der vorliegende Beitrag auf die Frage, inwieweit die zwei verschiedenen Governance-Strukturen (CSS-Unternehmen vs. OSS-Projekt) effiziente Lösungen des Teamproduktionsproblems darstellen.

1 Es wird hier der Begriff Open Source Software (OSS) als Kennzeichnung aller Free-/Open Source Software Projekte benutzt, da sich diese Umschreibung für die zwei Richtungen „Open Source Software“ und „Free Soft-

ware“ in der einschlägigen Literatur durchzusetzen scheint.

1

Die Arbeit wendet also Aspekte der Neuen Institutionenökonomik, speziell der (Intellectual-) Propery-Rights-Theorie und Transaktionskostentheorie, auf die Governance der Softwarepro- duktion an.

1.2. Aufbau der Arbeit

Wenn man ökonomische Aspekte von CSS und OSS betrachten möchte, ist es sinnvoll, sich zunächst das Gut Software etwas genauer anzuschauen. Zu diesem Zweck wird in dem fol- genden Kapitel 2 auf ökonomische Eigenschaften und Lizenzmodelle von Software eingegan- gen. Das anschließende Kapitel 3 beschäftigt sich ausführlich mit der Governance von OSS- Projekten, bevor in Kapitel 4 die institutionenökonmischen Erkenntnisse diskutiert werden. Mit einem Fazit und kurzem Ausblick auf zukünftig interessante Forschungsfelder, bildet Kapitel 5 den Abschluss der Arbeit.

2. Das Gut Software

Der Begriff Software bezeichnet allgemein alle nicht physischen Funktionsbestandteile eines Computers, also neben Computerprogrammen auch die von den Programmen verarbeiteten Daten (vgl. Küchlin/Weber, 2005, S. 15f.). In Abgrenzung zu den Daten wird Software je- doch auch häufig mit dem Begriff Programm gleichgesetzt und als „Liste von Anweisungen zur Verarbeitung von Daten“ (Gröhn, 1999, S. 4) definiert. Der vorliegende Beitrag sieht die letztgenannte Abgrenzung als sinnvoll an und folgt daher dieser Begriffserklärung. Der Produktionsvorgang von Software bedingt, dass Programme prinzipiell in zwei verschie- denen Formen vorliegen. Entwickelt wird Software indem Programmierer logisch strukturier- te Befehle und Anweisungen in einer so genannten Programmiersprache schreiben. Ergebnis dieses Programmiervorganges ist Software in Form des so genannten Quellcodes. Dieser Quellcode - oft auch als Programmcode, Quelltext oder Source Code bezeichnet - stellt die für den Menschen lesbare Form von Software dar. Vorrausetzung zum Verständnis des Quelltex- tes ist die Kenntnis der jeweiligen Programmiersprache. Um das Programm für den Rechner ausführbar zu machen, muss der Quellcode durch einen so genannten Kompiliervorgang in eine maschinenlesbare Form umgewandelt werden. Als Ergebnis dieses Umwandlungsvor- ganges liegt die Software dann auch in Gestalt des Binärcodes vor. Im semantischen Sinne ist dieser Binärcode vom Menschen nicht lesbar. Rückschlüsse vom Binärcode auf das zugrunde liegende Programmierprinzip sind nicht oder nur sehr schwer möglich (vgl. Kooths et al., 2003, S. 16ff.; Hansen/Neumann, 2001, S. 155f.; von Engelhardt, 2006, S.1).

2

Daher wird im vorliegenden Beitrag unterstellt, dass die Funktion und die einzelnen Pro- grammierschritte nur anhand des Quellcodes nachvollzogen werden können.

Ausgehend von den zwei Formen in denen Programme vorliegen, wird in der Regel zwischen zwei Arten der Bereitstellung von Software unterschieden, die auf verschiedenen eigentums- bzw. verwertungsrechtlichen Kriterien und/oder Produktionsweisen basieren. Man spricht in diesem Zusammenhang von proprietärer (Closed Source) und offener (Open Source) Soft- ware. In der Literatur kursieren noch weitere Bezeichnungen und Unterteilungen, wie z.B. nichtkommerzielle Open Source Software, Free-/Shareware, kommerzielle Open Source Software und kommerzielle/proprietäre Software (vgl. Berlecon Research, 2002, S. 11). Da die Unterscheidung hauptsächlich anhand der Offenlegung des Quellcodes erfolgt, wird die stark stilisierte und typisierte Trennung zwischen Closed Source Software und Open Source Software für diese Arbeit als sinnvoll erachtet. Im Folgenden wird für Closed Source Soft- ware die Abkürzung CSS, und für Open Source Software die Abkürzung OSS, verwendet.

• OSS ist grundlegend durch eine Offenlegung des Quellcodes und damit auch der

zugrunde liegenden programmiertechnischen Leistung gekennzeichnet. Das OSS- Modell erlaubt es Software zu benutzen, zu kopieren, zu verändern und in veränderter oder unveränderter Form weiterzugeben (vgl. ausführlich die Open Source Definition der Open Source Initiative, 2006). Kommerzielle Verwertung von OSS erfolgt über so genannte OSS-Distributionen. Eine OSS-Distribution ist ein aufeinander abge- stimmtes Paket von mehreren OSS-Programmen. Dieses spezifische Paket wird in der Regel durch Supportleistungen, Handbücher und kleinere Hilfsprogramme ergänzt. Die verschiedenen kommerziellen OSS-Distributionen haben oft gemeinsame Schnittmengen bezüglich der beinhalteten OSS. Trotz dieser Konkurrenzsituation beteiligen sich, die im Wettbewerb stehenden, OSS-Distributoren oft mit eigenen Entwicklungsbeiträgen an denselben OSS-Projekten. Vergleichbar mit Forschungs- kooperationen wird so eine Art „cost-sharing“ betrieben (vgl. Pasche/von Engelhardt, 2006, S. 105; von Engelhardt, 2006, S. 14).

• Bei CSS hingegen wird der vom Menschen lesbare Quellcode nicht offengelegt, d.h.

die Software wird ausschließlich in der maschinenlesbaren Form des Binärcodes ver- trieben. Durch diese Konstruktion wird eine gewisse Ausschließbarkeit von der Nut- zung erreicht. Das Ausschlussprinzip wird in der Regel durch eine Kombination aus

3

technischem und juristischem Kopierschutz umgesetzt. Im CSS-Modell wird also nur die Funktion des Softwareproduktes und nicht das zugrunde liegende Wissen ver- kauft. Das Recht zur Nutzung der Software wird in der Regel über den Kauf einer proprietären Lizenz erworben (vgl. Pasche/von Engelhardt, 2004, S. 8; von Engel- hardt, 2006, S. 2).

2.1. Ökonomische Eigenschaften von Software

Das Gut Software weist eine Reihe von ökonomisch relevanten Eigenschaften auf (vgl. aus- führlich von Engelhardt, 2006; Mundhenke, 2005). An dieser Stelle soll nur auf die, für die vorliegende Arbeit relevanten Eigenschaften näher eingegangen werden.

2.1.1. Software als Netzwerkgut

Software wird als Netzwerkgut bezeichnet (vgl. Pasche/von Engelhardt, 2006, S. 102), da es bei Verwendung desselben Programms durch verschiedene Personen zu so genannten Netz- werkeffekten bzw. Netzwerkexternalitäten kommt, die sich aus Vorteilen des Erfahrungs- und Datenaustausches ergeben. Netzwerkgüter sind also dadurch charakterisiert, dass der Nutzen für jeden einzelnen Konsumenten steigt, je mehr Leute das Produkt nutzen (vgl. Katz/Shapiro, 1985, S. 424). Anders ausgedrückt kann man sagen, dass sich der Nutzen eines Netzwerkgu- tes aus der Summe von Basis- oder Stand-Alone-Nutzen und Netzwerknutzen (vgl. Blank- art/Knieps, 1992, S. 79) ergibt. Es gibt Netzwerkgüter die einen Basisnutzen von Null haben,

beispielsweise ein Telefon oder eine Faxgerät 2 . Bei Software die lediglich zur Kommunikati-

on dient kann der Basisnutzen ebenfalls Null sein (z.B. Instant-Messaging-Programme), in der Regel kann man bei Software jedoch von einem positiven Basisnutzen ausgehen (z.B. Office- Anwendungen).

Diese direkten Netzwerkeffekte ergeben sich unmittelbar aus der Netzwerk-Eigenschaft von Software, d.h. dadurch, dass der Nutzen für jeden einzelnen Anwender mit der Verbreitung des Gutes steigt. Sie beruhen im Wesentlichen auf Vorteilen im Zusammenhang mit dem ver- einfachten Austausch von Daten (vgl. von Engelhardt, 2006, S. 3f.).

Darüber hinaus treten indirekte Netzwerkeffekte auf, die sich überwiegend aus dem Angebot an Komplementärprodukten und möglichem Wissensaustausch ergeben. Die Bedeutung von Komplementärprodukten lässt sich am Beispiel eines Betriebssystems gut verdeutlichen. So ist der potentielle Nutzen eines Betriebssystems umso größer, je mehr kompatible Anwen-

2 Von einer möglichen Kopierfunktion des Faxgerätes wird an dieser Stelle abgesehen.

4

dungssoftware zur Verfügung steht bzw. zu erwarten ist. Positive externe Effekte des Wis- sensaustausches äußern sich dadurch, dass mit der Nutzeranzahl einer Software auch die Wahrscheinlichkeit steigt, relativ leicht jemanden zu finden, mit dem man sich über Probleme und Lösungsansätze austauschen kann (vgl. von Engelhardt, 2006, S. 5).

In Märkten mit (indirekten) Netzwerkeffekten ist Standardisierung aufgrund der Relevanz von Kompatibilität in der Regel wohlfahrtsmaximierend. Jedoch findet der Markt nicht immer zu Standardisierung, oder anders ausgedrückt, die optimale Netzwerkgröße wird nicht in allen Fällen erreicht (vgl. Pasche/von Engelhardt, 2004, S. 4).

Zudem kann es aufgrund von nachfrageseitigen Pfadabhängigkeiten und Lock-In-Effekten dazu kommen, dass sich ein möglicherweise inferiorer Standard durchsetzt (vgl. Gröhn, 1999, S. 39ff.). Im CSS-Modell können Dateiformate und Schnittstellen als proprietäre Standards verstanden werden, was dazu führt, dass Standardisierung gleichzeitig auch eine Monopolisie- rung des Marktes zugunsten des führenden Softwareanbieters impliziert (vgl. Pasche/von En- gelhardt, 2004, S. 5). Offene Standards könnten helfen, die monopolisierte Marktmacht ein- zelner Anbieter zu verhindern, indem Wechselkosten gesenkt, und somit Wahlmöglichkeiten der Konsumenten erhöht werden (vgl. Kuhlmann, 2004, S. 245f.).

2.1.2. Software als Informationsgut

Jede Software stellt ein logisches Konstrukt aus geschriebenen Algorithmen und Anweisun- gen (vgl. von Engelhardt, 2006, S. 7) dar, welches die Funktion der Software bestimmt. Algo- rithmen und Handlungsanweisungen werden - in Abgrenzung zum Begriff des Wissens - der Kategorie Informationen zugeordnet (vgl. Dosi, 1996, S. 84). Damit gehört Software zur Gruppe der Informationsgüter. Beim wirtschaftlichen Handel mit Informationsgütern tritt das so genannte Informationsparadoxon auf. Nach Arrow (1971) liegt das Problem beim Handel von Informationen darin, dass

“[…] its value for the purchaser is not known until he has the information, but then he has in effect acquired it without costs”. (Arrow, 1971, S. 148)

Dieses Problem wird als Paradoxon bezeichnet, da die Transaktionspartner bei der Aushand- lung des Wertes einer Information in die paradoxe Situation geraten, dass der Anbieter die Information offenbaren muss, um mit dem Interessenten einen Kaufvertrag abschließen zu können. Mit der Offenlegung der Information entfällt für den Nachfrager jedoch der Grund

5

die Information zu kaufen, da er die Information bereits hat (vgl. Picot/Reichwald, 1991, S. 259f.).

Informationen werden daher in der Regel vor dem Kauf nicht oder nur unzureichend offenge- legt. Somit stellt der Kauf von Informationen immer eine Entscheidung unter Unsicherheit dar. Das Informationsparadoxon kann als Erklärung herangezogen werden, warum CSS ledig- lich in Form des Binärcodes vertrieben wird. Wäre der Quellcode offengelegt, würde kein oder nur ein sehr geringer Anreiz bestehen einen Preis für die Software zu bezahlen. Da bei

OSS genau das der Fall ist, existiert für OSS an sich auch kein Markt, sondern nur für

komplementäre Güter und Dienstleistungen. Die Kombination aus OSS und komplementären Leistungen ist daher Grundlage der meisten kommerziellen OSS-Distributionen (vgl. von En- gelhardt, 2006, S. 7f.).

Die vorangegangen Ausführungen haben deutlich gemacht, dass Software die Eigenschaften eines Informationsgutes aufweist. Dennoch existiert bei Software ein entscheidender Unter- schied zu anderen Informationsgütern. Dieser liegt darin, dass ein durchschnittlicher Soft- warekonsument nicht an der zugrunde liegenden Information - im Sinne von Algorithmen - interessiert ist, sondern ausschließlich an der daraus resultierenden Funktion (vgl. von Engel- hardt, 2007, S. 8). Beispielsweise ist für den Großteil der Nutzer von Programmen zur Wie- dergabe von Audio- oder Videodateien nur von Bedeutung, dass die Software den Film oder den Musiktitel abspielt. Die zugrunde liegenden Algorithmen, welche die Funktion dieser Software ermöglichen, sind für den durchschnittlichen Programmanwender jedoch uninteres- sant.

Das erklärt, warum Software im Vergleich zu anderen Informationsgütern für den Konsumen- ten auch dann einen Nutzen stiftet, wenn die Information nach dem Kauf nicht offengelegt wird (vgl. von Engelhardt, 2006, S. 9).

2.1.3. Software als komplexes Gut

Von einigen Trivialfällen abgesehen, wie beispielsweise einem simplen Texteditor, sind die meisten Softwareanwendungen sehr komplex aufgebaut. Das Gesamtsystem besteht aus Wenn-Dann-Abfolgen, logischen Schleifen, Entweder-Oder-Schaltungen etc. Aufgrund der Komplexität wird es als unmöglich erachtet, eine völlig fehlerfreie Software zu programmie- ren (vgl. von Engelhardt, 2006, S. 14).

Dieser komplexe, fehleranfällige Aufbau von Software hat zur Folge, dass ein erheblicher Anteil der Arbeitsleistung in der Fehlersuche und Fehlerbeseitigung liegt. Da viele Fehler erst während der Benutzung der Software bekannt werden, ist eine kontinuierliche Wartung und

6

Pflege von Nöten (vgl. Franck/Jungwirth, 2002, S. 125). Laut Raymond (2000, S. 4) machen die Kosten für Wartung und Pflege bei CSS rund 75% der gesamten Produktionskosten aus. Software stellt somit ein Gut dar, das in einem nicht-endgültigen Zustand ausgeliefert, und anschließend laufend durch komplementäre Updates und Patches verbessert wird (vgl. von Engelhardt, 2006, S. 15).

Aufgrund dieser Komplexität und Fehlerhaftigkeit von Software, kann es vor allem für Be- nutzer sehr hilfreich sein, wenn die Möglichkeit einer schnellen und einfachen Kontaktauf- nahme zum verantwortlichen Programmierer gegeben ist. Ein modularer Programmaufbau in Verbindung mit entsprechender Modularität in der Organisation (vgl. Langlois, 2002, S. 26ff.) kann in diesem Zusammenhang eine wichtige Vorraussetzung sein.

2.1.4. Software als digitales Gut

Laut Quah (2003, S. 29) weist Software die Eigenschaften eines digitalen Gutes auf. Ein wichtiges Merkmal digitaler Güter ist die Möglichkeit zur Rekombination.

”Digital goods are recombinant. By this I mean they are cumulative and emergent new digital goods that arise from merging antecedents have features absent from the original, parent digital goods.“ (Quah, 2003, S. 19)

Rekombinierbarkeit bedeutet also, dass bereits geschriebene Programmelemente in andere, neue Software integriert werden können. Ein einfaches Beispiel bietet die kontinuierliche Weiterentwicklung von Software. Eine neue Programmversion ist in der Regel eine Rekom- bination aus altem und neuem Quellcode. Darüber hinaus können aber auch Quellcode- Komponenten aus verschiedenen Programmen kombiniert, und mit neuem Quellcode ergänzt werden, um ein neues Programm zu entwickeln.

Zu diesem Zweck existieren ganze Bibliotheken aus Programmelementen (vgl. Gröhn, 1999, S. 5), die ein solches komponentenbasiertes Softwareengineering erleichtern. Bei der Soft- wareproduktion kann also auf Verbundvorteile zurückgegriffen werden. Das heißt, verschie- dene Software kann auf denselben Quellcode-Bausteine basieren, ohne dass es zu einer Riva- lität in der Nutzung der Quellcode-Komponenten kommt (vgl. Pasche/von Engelhardt, 2004, S. 6; von Engelhardt, 2006, S. 11f.).

7

2.1.5. Software als Gut ohne Rivalität im Konsum

Tabelle 1 zeigt eine Einteilung ökonomischer Güter nach den Kriterien Rivalität im Konsum und Ausschließbarkeit vom Konsum.

Tabelle 1 - Güterarten nach Ausschließbarkeit und Rivalität: eigene Darstellung

Eine einmal erstellte Software kann aufgrund ihrer digitalen Natur, ohne Qualitätsverluste zu Grenzkosten von nahezu Null, unendlich oft reproduziert werden (vgl. Shapiro/Varian, 1999, S. 3ff.).

Diese Eigenschaft macht einmal erstellte Software zu einem nicht-knappen Gut, d.h. es tritt keine Rivalität im Konsum auf. Dies lässt sich dadurch verdeutlichen, dass die Verwendung einer Software durch einen Benutzer nicht durch die Verwendung der gleichen Software (in Form einer Kopie) durch einen anderen Nutzer eingeschränkt wird (vgl. Pasche/von Engel- hardt, 2004, S. 6). Man kann sogar noch weiter gehen und sagen, dass Software wegen der angesprochenen direkten Netzwerkeffekte, eine Art Anti-Rivalität im Konsum aufweist und somit auch als anti-knappes Gut verstanden werden kann (vgl. Weber, 2004, S. 153ff.; von Engelhardt, 2007, S. 10). Der Wert eines Softwareproduktes für jeden Einzelnen steigt also mit der Anzahl der Nutzer, die diese Software ebenfalls benutzen (vgl. Liebowitz/Margolis, 1994, S. 139f.).

Aufgrund der nicht vorhandenen Rivalität im Konsum kann es nicht zu dem für Allmendegü- ter bekannten Übernutzungsproblem kommen, welches auch als „Tragödie der Allmende“ (Hardin, 1968) bezeichnet wird.

Mit Bezug auf Tabelle 1 kann Software also nur ein öffentliches Gut oder ein Club-Gut sein, in Abhängigkeit davon ob Ausschließbarkeit gegeben ist oder nicht. Genau an diesem Punkt unterscheiden sich die beiden Modelle CSS und OSS. Im klassischen CSS-Produktionsmodell wird Software als Club-Gut bereitgestellt. Das Ausschlussprinzip wird im CSS-Modell durch proprietäre Lizenzen, d.h. durch exklusive (Intellectual) Property Rights (IPR) am Quellcode, sichergestellt (vgl. Pasche/von Engelhardt, 2004, S. 7). Man könnte also sagen, dass das in seiner Natur nicht-knappe Gut Software, im CSS-Modell durch eine Kombination aus techni- schem und rechtlichem Kopierschutz künstlich verknappt wird.

8

Im OSS-Modell hingegen wird darauf verzichtet. Durch OSS-Lizenzen, d.h. durch inklusive (Intellectual) Property Rights am Quellcode, wird das Ausschlussprinzip aufgehoben. OSS ist also durch Nichtrivalität im Konsum und Nicht-Ausschließbarkeit vom Konsum gekenn- zeichnet. Somit weißt OSS Eigenschaften eines öffentlichen Gutes auf (vgl. Pasche/von En- gelhardt, 2004, S. 6f.; Gehring, 2006a, S. 62f.).

Bei fehlender Ausschließbarkeit tritt bekanntermaßen das so genannte Trittbrettfahrerproblem auf. Trittbrettfahrerverhalten führt bei öffentlichen Gütern tendenziell zu Unterversorgung (vgl. Richter/Furubotn, 1999, S. 107f.). Im Fall von Software würde dies also bedeuten, dass Programmierer keinen oder einen nur sehr geringen Anreiz zur Produktion von Software ha- ben, wenn sie keine exklusiven (Intellectual) Property Rights an dem von ihnen entwickelten Quellcode erhalten. Die Beteiligung an OSS-Entwicklung stellt somit nach ökonomischer Theorie ein irrationales Verhalten dar, weshalb OSS oft auch als Phänomen bezeichnet wird.

2.2. Open Source Software

Mit der zuvor beschriebenen theoretischen Erkenntnis im Hinterkopf, ist es interessant sich das Phänomen OSS etwas genauer anzuschauen. Nachfolgend wird daher erst kurz auf die Motive der beteiligten Entwickler eingegangen, anschließend erfolgt eine Abgrenzung von CSS- und OSS-Lizenzen anhand der Übertragung von (Intellectual) Property Rights.

2.2.1. Motive der beteiligten Entwickler

Der Umstand, dass weltweit Millionen von Menschen bereit sind, freiwillig teilweise erhebli- chen Aufwand aufbringen, um Software zu entwickeln an der sie keine exklusiven Rechte erhalten, hat eine Reihe von Studien (vgl. z.B. Lakhani/Wolf, 2005; Lerner/Tirole, 2002; Franck et al., 2005) hervorgerufen, die sich mit den Motiven von OSS-Entwicklern auseinan- dersetzen. Lerner und Tirole (2002) - eine der meist zitierten Arbeiten in diesem Zusammen- hang - formulieren die oft diskutierte Frage wie folgt:

“Why should thousands of top-notch programmers contribute freely to the provi- sion of a public good?” (Lerner/Tirole, 2002, S. 198)

Die Untersuchungen zeigen, dass man die Motive der Beitragenden nicht verallgemeinern kann. Die individuellen Gründe für die Beteiligung an einem OSS-Projekt sind sehr unter- schiedlich und können sowohl intrinsischer als auch extrinsischer Natur sein. Beispiele häufig genannter Motiven reichen von ideologischer Einstellung (Anti-MS), Altruismus, Reziprozi-

9

tät, Spaß am Programmieren, Lerneffekten, Reputationserwerb für den CSS-Markt und Ei- genbedarf bis hin zu direkten monetären Anreizen (Vertrieb von komplementären Gütern und Dienstleistungen). Die Reihenfolge der aufgezählten Motive ist hier bewusst gewählt, da sie die tendenzielle Richtung von absolut intrinsischen zu absolut extrinsischen Motivationskal- külen widerspiegelt. Oben wurde angesprochen, dass die Beteiligung an OSS-Projekten aus Sicht der (I)PR-Theorie ein irrationales Verhalten darstellt (vgl. Abschnitt 2.1.4.). Betrachtet man die empirisch belegten Motivationskalküle kann man jedoch anmerken, dass die indivi- duellen Gründe zur Partizipation durchaus rationale Entscheidungen in Bezug auf Opportuni- tätskostenüberlegungen darstellen. Dies gilt sowohl für intrinsisch als auch extrinsisch ge- prägte Motive, was nachfolgend an zwei Beispielen verdeutlicht werden soll. Für einen Men- schen, der Programmieren als Spaß oder Hobby ansieht (intrinsische Motivation), stellt die Entscheidung sich in seiner Freizeit an einem OSS-Projekt zu beteiligen durchaus eine ratio- nale Entscheidung dar. Wenn sich die Verantwortlichen einer OSS-Distribution an der Ent- wicklung von OSS beteiligen, zu der sie komplementäre Produkte und Dienstleistungen an- bieten (extrinsische Motivation), handeln sie auch nicht irrational.

2.2.2. OSS- vs. CSS- Lizenzen

Seit der Etablierung der Open Source Definition (OSD) 3 durch die Open Source Initiative (OSI) im Jahr 1998, wurde eine breite Masse an Lizenzen 4 entwickelt, die die Bedingungen

der OSD erfüllen. Um einen Überblick über den Stellenwert der verschiedenen OSS-Lizenzen zu bekommen, hat sich der Autor der vorliegenden Arbeit angeschaut, von wievielen OSS- Projekten die einzelnen Lizenzen verwendet werden. Als Datenbasis für die Analyse diente die Internet-Plattform SourceForge.net. Nach eigenen Angaben stellt SourceForge.net die weltweit größte Plattform dar, auf der OSS-Projekte gelistet sind (vgl. http://sourceforge.net/). Für die Erstellung der Verteilungsübersicht wurden die gelisteten Projekte nach Lizenzen sor- tiert. Anschließend wurde die Anzahl der Projekte je Lizenz ins Verhältnis zur Gesamtanzahl der gelisteten Projekte gesetzt. Die Ergebnisse sind in Abbildung 1 graphisch dargestellt.

3 Die Kernpunkte der OSD können unter http://www.opensource.org/docs/osd eingesehen werden.

4 Unter http://www.opensource.org/licenses ist eine Auflistung der „Open Source Initiative Approved“ Lizenzen zu finden.

10

Abbildung 1 - Top-10-Verteilung der verwendeten Lizenzen für OSS registriert bei SourceForge.net

(Stand: 25.01.2008)

Die Verteilungsgraphik zeigt, dass die schon lange existierenden, GNU General Public Licen- se (GPL), Lesser General Public License (LGPL) und die Berkeley Software Distribution (BSD) License am häufigsten verwendet werden. Wie zu sehen ist, verwenden über 80% aller OSS-Projekte eine der drei Lizenzen.

De Laat hat im Jahr 2005 eine ähnliche Analyse vorgenommen und war dabei zu einem ver- gleichbaren Ergebnis gekommen. Er hatte zu diesem Zweck neben SourceForge.net noch Da-

ten von der Plattform Freshmeat.net 5 erhoben, die wiederum zu einem analogen Ergebnis ge-

führt hatten (vgl. de Laat, 2005, S. 1520f.). Aufgrund der starken Verbreitung werden die

GPL und die BSD nachfolgend als Standardbeispiele - zur Abgrenzung von CSS- und OSS-

Lizenzen anhand des (I)PR-Ansatzes - herangezogen.

Der (I)PR-Ansatz basiert auf den vier Verfügungsrechten des römischen Rechts. Die einzel- nen Rechte dabei sind: ein materielles oder immaterielles Gut zu benutzen (usus), sich den Ertrag aus der Nutzung anzueignen (usus fructus), die Form eines Gutes zu verändern (abu- sus) und die Weitergabe des Gutes an Dritte (alienation right) (vgl. Fischer, 1994, S. 316; Ce- zanne/Mayer, 1998, S. 1346).

5 Freshmeat.net gehört neben SourceForge.net zu den bekanntesten Indizees für OSS-Projekte.

11