Anwendung von Aspekten der Neuen Institutionenökonomik auf Open Source Software
Produktion, Verfügungsrechte und Transaktionskosten eine theoretische und empirische Untersuchung
©2003
Magisterarbeit
109 Seiten
Zusammenfassung
Inhaltsangabe:Zusammenfassung:
In der vorliegenden Arbeit wird eingangs die historische Entwicklung der Open Source Community dargelegt. Dieser Schritt wird der Anwendung des Property Right Ansatzes und des Transaktionskostenansatzes vorgeschoben, da im Lauf der Entwicklungsgeschichte wichtige Personen das institutionelle Umfeld von Open Source Software entscheidend geprägt haben. Es werden die drei Meilensteine UNIX, GNU und Linux betrachtet.
Im folgenden Kapitel wird der Property Right Ansatz auf das Lizenzmodell der Open Source Software angewendet. Es wird die Property Rights Struktur ausgewählter Lizenzen incl. ihrer Ausschlussmöglichkeiten von einzelnen Personen ausgearbeitet. Nach Betrachtung der Durchsetzungsfähigkeit der einzelnen Lizenzen wird untersucht, welche Anreizwirkungen die Lizenzen auf Konsumenten und Produzenten haben. Hier soll vor allem aufgezeigt werden, welche Anreize Entwickler haben, ihren Softwarecode unter einer Open Source Definition (OSD) kompatiblen Lizenz zu veröffentlichen. Abgeschlossen wird das Kapitel mit einen Exkurs in die Spieltheorie. Es soll spieltheoretisch analysiert werden, unter welchen Vorraussetzungen Individuen ihre Verfügungsrechte an ihrem geistigen Eigentum in Kooperationen einbringen.
Danach wird untersucht welche Transaktionskosten beim Tausch von Verfügungsrechten zur Erstellung von Open Source Software entstehen. Hierzu werden die Einzelphasen einer Transaktion betrachtet. Folgend wird geprüft, welche Einwirkung die Transaktionsatmosphäre in Form der Transaktionshäufigkeit, spezifische Investitionen, Opportunismus, Komplexität und beschränkter Rationalität auf die Transaktionskosten bei der Open Source Softwareerstellung hat. Auf Basis dieser Erkenntnisse wird begutachtet, ob die Transaktionskosten Auswirkungen auf die Projektgröße bzw. innerhalb von Projekten auf die Koordinationsformen haben.
Die Arbeit wird mit einer kurzen ergänzenden empirischen Analyse des Quellcodes ausgewählter Projekte abgeschlossen.
Inhaltsverzeichnis:Inhaltsverzeichnis:
EINLEITUNG3
1.FRAGESTELLUNG UND METHODE4
2.ÜBERBLICK6
3.HISTORISCHE ENTWICKLUNG7
3.1DIE UNIX-PHASE7
3.2GNU9
3.3LINUX10
3.4GRÜNDUNG DER OPEN SOURCE INITIATIVE12
3.5KERNPUNKTE DER OPEN SOURCE DEFINITION13
4.ANWENDUNG DES PROPERTY RIGHTS ANSATZ AUF DIE LIZENZEN VON OPEN SOURCE SOFTWARE15
4.1EIGENSCHAFTEN DIGITALER GÜTER15
4.2ARTEN VON OPEN SOURCE LIZENZEN17
4.2.1OFFENE LIZENZEN18
4.2.2VIRALE […]
In der vorliegenden Arbeit wird eingangs die historische Entwicklung der Open Source Community dargelegt. Dieser Schritt wird der Anwendung des Property Right Ansatzes und des Transaktionskostenansatzes vorgeschoben, da im Lauf der Entwicklungsgeschichte wichtige Personen das institutionelle Umfeld von Open Source Software entscheidend geprägt haben. Es werden die drei Meilensteine UNIX, GNU und Linux betrachtet.
Im folgenden Kapitel wird der Property Right Ansatz auf das Lizenzmodell der Open Source Software angewendet. Es wird die Property Rights Struktur ausgewählter Lizenzen incl. ihrer Ausschlussmöglichkeiten von einzelnen Personen ausgearbeitet. Nach Betrachtung der Durchsetzungsfähigkeit der einzelnen Lizenzen wird untersucht, welche Anreizwirkungen die Lizenzen auf Konsumenten und Produzenten haben. Hier soll vor allem aufgezeigt werden, welche Anreize Entwickler haben, ihren Softwarecode unter einer Open Source Definition (OSD) kompatiblen Lizenz zu veröffentlichen. Abgeschlossen wird das Kapitel mit einen Exkurs in die Spieltheorie. Es soll spieltheoretisch analysiert werden, unter welchen Vorraussetzungen Individuen ihre Verfügungsrechte an ihrem geistigen Eigentum in Kooperationen einbringen.
Danach wird untersucht welche Transaktionskosten beim Tausch von Verfügungsrechten zur Erstellung von Open Source Software entstehen. Hierzu werden die Einzelphasen einer Transaktion betrachtet. Folgend wird geprüft, welche Einwirkung die Transaktionsatmosphäre in Form der Transaktionshäufigkeit, spezifische Investitionen, Opportunismus, Komplexität und beschränkter Rationalität auf die Transaktionskosten bei der Open Source Softwareerstellung hat. Auf Basis dieser Erkenntnisse wird begutachtet, ob die Transaktionskosten Auswirkungen auf die Projektgröße bzw. innerhalb von Projekten auf die Koordinationsformen haben.
Die Arbeit wird mit einer kurzen ergänzenden empirischen Analyse des Quellcodes ausgewählter Projekte abgeschlossen.
Inhaltsverzeichnis:Inhaltsverzeichnis:
EINLEITUNG3
1.FRAGESTELLUNG UND METHODE4
2.ÜBERBLICK6
3.HISTORISCHE ENTWICKLUNG7
3.1DIE UNIX-PHASE7
3.2GNU9
3.3LINUX10
3.4GRÜNDUNG DER OPEN SOURCE INITIATIVE12
3.5KERNPUNKTE DER OPEN SOURCE DEFINITION13
4.ANWENDUNG DES PROPERTY RIGHTS ANSATZ AUF DIE LIZENZEN VON OPEN SOURCE SOFTWARE15
4.1EIGENSCHAFTEN DIGITALER GÜTER15
4.2ARTEN VON OPEN SOURCE LIZENZEN17
4.2.1OFFENE LIZENZEN18
4.2.2VIRALE […]
Leseprobe
Inhaltsverzeichnis
ID 8196
Böhnlein, Ingo: Anwendung von Aspekten der Neuen Institutionenökonomik auf Open
Source Software - Produktion, Verfügungsrechte und Transaktionskosten eine
theoretische und empirische Untersuchung
Hamburg: Diplomica GmbH, 2004
Zugl.: Johann Wolfgang Goethe-Universität Frankfurt am Main, Magisterarbeit, 2003
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2004
Printed in Germany
INHALTSVERZEICHNIS
EINLEITUNG ...3
1
FRAGESTELLUNG UND METHODE...4
2
ÜBERBLICK ...6
3
HISTORISCHE ENTWICKLUNG...7
3.1
D
IE
U
NIX
-P
HASE
...7
3.2
GNU...9
3.3
L
INUX
...10
3.4
G
RÜNDUNG DER
O
PEN
S
OURCE
I
NITIATIVE
...12
3.5
K
ERNPUNKTE DER
O
PEN
S
OURCE
D
EFINITION
...13
4
ANWENDUNG DES PROPERTY RIGHTS ANSATZ AUF DIE LIZENZEN VON
OPEN SOURCE SOFTWARE ...15
4.1
E
IGENSCHAFTEN DIGITALER
G
ÜTER
...15
4.2
A
RTEN VON
O
PEN
S
OURCE
L
IZENZEN
...17
4.2.1
O
FFENE
L
IZENZEN
...18
4.2.2
V
IRALE
L
IZENZEN
...20
4.2.3
F
IRMENLIZENZEN
...22
4.2.4
D
ER
S
ONDERFALL DER
D
OPPELLIZENZIERUNG
...24
4.3
S
EGMENTATION DER
S
OFTWAREARTEN AUFGRUND DER
P
ROPERTY
R
IGHTS
...25
4.3.1
K
OMMERZIELLE
S
OFTWARE
...25
4.3.2
S
HAREWARE
...26
4.3.3
F
REEWARE
...26
4.3.4
O
PEN
S
OURCE
S
OFTWARE
...27
4.4
A
USSCHLUSSMÖGLICHKEIT DER
O
PEN
S
OURCE
L
IZENZEN
...27
4.5
D
URCHSETZUNGSMÖGLICHKEITEN VON
O
PEN
S
OURCE
L
IZENZEN
...28
4.6
A
LLOKATIONSANREIZE DURCH DIE
L
IZENZEN
...31
4.6.1
A
LLOKATIONSANREIZE DER
O
PEN
S
OURCE
K
ONSUMENTEN
...32
4.6.2
A
LLOKATIONSANREIZE DER
O
PEN
S
OURCE
P
RODUZENTEN
...33
4.6.2.1
Monetäre Anreize...33
4.6.2.2
Reputation und Signalproduktion ...36
4.6.2.3
Bedarf...38
4.6.2.4
Reziprozität ...39
4.6.2.5
Offener Quellcode ...41
4.7
D
IE
B
EDEUTUNG DER
L
IZENZEN
E
XKURS IN DIE
S
PIELTHEORIE
...41
4.8
Z
USAMMENFASSUNG DES
K
APITELS DER
P
ROPERTY
R
IGHTS BEI DER
O
PEN
S
OURCE
S
OFTWARE
P
RODUKTION
...44
1
5
ANWENDUNG DES TRANSAKTIONSKOSTENANSATZ AUF DIE ERSTELLUNG
VON OPEN SOURCE SOFTWARE ...45
5.1
T
RANSAKTIONSPHASEN BEI DER
E
RSTELLUNG VON
O
PEN
S
OURCE
S
OFTWARE
...48
5.1.1
A
NBAHNUNGSKOSTEN
...49
5.1.1.1
Anbahnungskosten bei Kleinstprojekten und Neugründungen ...49
5.1.1.2
Anbahnungskosten bei Großprojekten...52
5.1.2
V
EREINBARUNGSKOSTEN
...53
5.1.3
K
ONTROLLKOSTEN
...54
5.1.3.1
Qualitätskontrolle...55
5.1.3.2
Kontrolle des Werte- und Normensystems...56
5.1.4
A
NPASSUNGSKOSTEN
...57
5.1.4.1
Technikbedingte Anpassungskosten...57
5.1.4.2
Mitarbeiterbedingte Anpassungskosten ...58
5.2
E
INFLUSSFAKTOREN DER
T
RANSAKTIONSKOSTEN
...58
5.2.1
T
RANSAKTIONSHÄUFIGKEIT
...59
5.2.2
S
PEZIFISCHE
I
NVESTITIONEN
...60
5.2.3
S
PEZIFITÄTSVERHÄLTNIS DER
T
RANSAKTIONSBETEILIGTEN
...63
5.2.4
O
PPORTUNISTISCHES
V
ERHALTEN
...64
5.2.5
B
ESCHRÄNKTE
R
ATIONALITÄT UND
K
OMPLEXITÄT
...67
5.3
W
AHL DER OPTIMALEN
O
RGANISATIONSGRÖßE
...69
5.3.1
I
NTERNE
O
RGANISATION
...69
5.3.2
E
XTERNE
O
RGANISATION
...71
5.3.3
H
YBRIDE
O
RGANISATIONSFORM
...73
5.4
D
IE PROJEKTINTERNE
K
OORDINATION
...75
5.4.1
V
ERTIKALE
K
OOPERATION
...75
5.4.2
H
ORIZONTALE
K
OOPERATION
...78
5.4.3
W
ETTBEWERB
...79
5.5
Z
USAMMENFASSUNG DES
K
APITELS DER
T
RANSAKTIONSKOSTEN BEI DER
O
PEN
S
OURCE
S
OFTWARE
P
RODUKTION
...80
6
EMPIRISCHE ÜBERPRÜFUNG ...81
6.1
F
RAGESTELLUNG
...82
6.2
M
ETHODE
...82
6.2.1
CVSA
NAL
Y ...84
6.2.2
P
RE
-T
EST
...84
6.2.3
B
ERECHNUNGSABLAUF
...85
6.3
E
RGEBNISSE
...85
6.3.1
F
REE
BSD ...87
6.3.2
KDE...89
6.4
Z
USAMMENFASSUNG DER EMPIRISCHEN
E
RGEBNISSE
...93
7
SCHLUSSBETRACHTUNG ...94
8
LITERATURVERZEICHNIS...96
2
Einleitung
Open Source Software ist in jüngster Zeit ein viel diskutiertes Phänomen. Internationa-
le Firmen wie IBM, HP oder Sun Microsystems investieren jährlich Milliarden US $ in
die Entwicklung dieser Software (heise_news vom 31.01.2001; heise_news vom
23.01.2003; heise_news vom 07.02.2002),. Die deutsche Bundesregierung erstellt Leit-
fäden für klein- und mittelständische Unternehmen zum Umstieg von kommerzieller
Software auf Open Source Software (heise_news vom 10.07.2003). Die Stadtverwal-
tung der deutschen IT-Hochburg München stattet 14000 Rechner mit Open Source
Software aus, und kündigt ihre Kooperation mit Microsoft auf (heise_news vom
20.05.2003).
Das Phänomen Open Source Software rückt gleichzeitig einen ,,neuartigen" Produkti-
onsstil der Softwareerstellung ins Licht der Aufmerksamkeit obwohl diese Produkti-
onsmethode im Grunde schon seit mehr als 30 Jahren besteht. So hat der erste Teil
der sogenannten ,,Halloween Documents, ein internes Arbeitspapier der Firma Micro-
soft belegt (Hall_doc, 98), dass auch Microsoft von der Open Source Community ler-
nen kann. In diesem Dokument werden die Produktionsvorteile dargelegt, die sich
durch eine Abkehr von der streng hierarchischen koordinierten Produktionsmethode
ergeben. Microsoft hat sich auch ein Beispiel an der besonderen Lizenzpolitik der O-
pen Source Community genommen und im Jahre 2001 die ,,Shared Source-Initiative"
gestartet. Es soll Großabnehmern Einblick in den sonst streng gehüteten Quellcode
der microsofteigenen Programme gestattet werden (heise_news vom 18.05.2001).
Die vorliegenden Arbeit versucht daher Einblicke in die Struktur und Funktionsweise
von Open Source Projekten unter Anwendung von Aspekten der ,,Neuen Institutione-
nökonomie" zu geben.
3
1 Fragestellung und Methode
Die Betrachtung der historischen Entwicklung von Open Source Software, die im fol-
genden dargelegt wird, zeigt auf, dass die Produktion von Open Source Software stark
durch Institutionen gelenkt ist. Zum einen sind die jeweiligen Open Source Projekte als
Institutionen zu betrachten, die das individuelle Verhalten der Einzelentwickler in be-
stimmte Richtungen lenken, und auf diese Weise Ordnung, Sicherheit und Berechen-
barkeit beim Tausch der Codezeilen etablieren (Richter / Furubotn, 1996, S.7). Zum
anderen werden durch die jeweiligen Open Source Lizenzen rechtliche Institutionen
geschaffen, die Regeln und Normen etablieren und auch durchsetzen, die für die Pro-
duktion von Open Source Software notwendig sind.
Die freiwilligen Entwickler dieser Software kommen aus dem Umfeld der Hackerkultur
(Grassmuck, 2002, S.217 ff; Stallman, 1995, Stallman 1996; Himanen / Torvalds /
Castells, 2001, Seite vii f). In dieser Hackerkultur herrscht ein bestimmtes Werte- und
Normensystem welches Regeln und Gebräuche institutionalisiert, die neben den juris-
tisch rechtlichen Vorgaben einzuhalten sind (Osterloh, 2002, S.20 f).
Daher soll in dieser Arbeit der Versuch unternommen werden die Struktur und Funkti-
onsweise von Open Source Projekten näher zu betrachten, indem Aspekte der ,,Neuen
Institutionenökonomie" auf das Phänomen Open Source Software angewendet wer-
den.
Im folgenden wird der Property Rights Ansatz und der Transaktionskostenansatz der
Neuen Institutionenökonomik auf Open Source Software angewendet. Der Prinzipal
Agent Ansatz wird nicht berücksichtigt, da aus der Betrachtung der Entwicklungsge-
schichte hervorgehen wird, dass sowohl die Projektgründer, als auch die freiwilligen
Mitarbeiter grundsätzlich die gleiche Zielrichtung verfolgen. Die individuellen Beweg-
gründe sind jedoch vielfältig. Allen Beteiligten an der Open Source Produktion kann die
Absicht unterstellt werden, eine Leistungsfähige Software produzieren zu wollen. Es
ergeben sich für die Entwickler daher kaum Motive wissentlich relevante Informationen
zurückzuhalten. Des weiteren soll kein Vergleich von Open Source Software zu kom-
merzieller Software unternommen werden. Es werden zwar in einzelnen Punkten Ver-
weise auf kommerzielle Software gegeben, doch der zentrale Gegenstand der Unter-
suchung richtet sich auf Open Source Software.
Der Property Rights Ansatz wirft bezogen auf Open Source Software die Fragestellung
auf, welche Property Rights Strukturen in den Open Source Lizenzen manifestiert sind.
Es soll hinterfragt werden welche Verfügungsrechte die Entwickler an dem von ihnen
bereitgestellten Softwarecode institutionell zugesichert bekommen, bzw. welche Verfü-
gungsrechte von den Originalautoren auf andere an der Produktion unbeteiligte Perso-
4
nen übergehen. Des weiteren ist im Rahmens des Property Right Ansatzes zu erörtern,
welche Produktionsanreizmechanismen die Lizenzen durch die institutionelle Zuwei-
sung von Verfügungsrechten schaffen.
Der Transaktionskostenansatz wird herangezogen, da zu hinterfragen ist, welche Res-
sourcen erforderlich sind, um eine Organisation, also eine Institution einschließlich der
daran beteiligten Personen (North, 1990), zu schaffen, aufrecht zu erhalten, bzw. zu
betreiben. Dies folgt der Annahme, dass der Austausch von Verfügungsrechten in
Form von Arbeitsleistung bei einem Open Source Projekt bestimmte Kosten aufwirft,
die als Transaktionskosten bezeichnet werden. In diesem Zusammenhang stellt sich
die Frage an welchen Punkten des Property Rights-Tauschs in einem Open Source
Projekt Transaktionskosten entstehen, bzw. welche Sachverhalte Einflüsse auf die
Transaktionskosten haben. Es wird außerdem untersucht, ob die Organisationsgröße
Einfluss auf die Transaktionskosten hat, bzw. ob innerhalb von Organisationen be-
stimmte Koordinationsformen mit spezifischen Koordinationsmechanismen transakti-
onskostensenkend sind.
Die ,,Neue Institutionenökonomie" erscheint als geeignete Methode, da sie zum einen
den methodologischen Individualismus zu Grunde legt, der besagt, dass Gruppen nicht
als Kollektive anzusehen sind, sondern diese sozialen Phänomen durch das Zusam-
menwirken von individuellen Handlungen entstehen (Richter / Furubotn, 1999, S.3).
,,The Linux operating System were actually developed not by enterprises or govern-
ments but were created primarily by some enthusiastic individuals who just started to
realize their ideas with other like-minded individuals working in a free rhythm" (Hima-
nen / Torvalds / Castells, 2001, S. viii). Zum anderen stellt die "Neue Institutionenöko-
nomie" die Institution in den Mittelpunkt der Analyse. ,,Institutionen lassen sich definie-
ren als die Menge von Funktionsregeln, die man braucht, um festzustellen, wer für Ent-
scheidungen in einem bestimmten Bereich in Frage kommt, welche Handlungen statt-
haft oder eingeschränkt sind, welche Aggregationsregeln verwendet werden, welche
Verfahren eingehalten werden müssen, welche Information geliefert oder nicht geliefert
werden muss, und welche Entgelte den einzelnen entsprechend ihren Handlungen
zugebilligt werden" (Ostrom, 1999, S. 51).
5
2 Überblick
Im folgenden Kapitel 3 wird die historische Entwicklung der Open Source Community
dargelegt. Dieser Schritt wird der Anwendung des Property Right Ansatzes und des
Transaktionskostenansatzes vorgeschoben, da im Lauf der Entwicklungsgeschichte
wichtige Personen das institutionelle Umfeld von Open Source Software entscheidend
geprägt haben. Es werden die drei Meilensteine UNIX, GNU und Linux betrachtet.
Im Anschluss wird in Kapitel 4 der Property Right Ansatz auf das Lizenzmodell der O-
pen Source Software angewendet. Es wird die Property Rights Struktur ausgewählter
Lizenzen incl. ihrer Ausschlussmöglichkeiten von einzelnen Personen ausgearbeitet.
Nach Betrachtung der Durchsetzungsfähigkeit der einzelnen Lizenzen wird untersucht,
welche Anreizwirkungen die Lizenzen auf Konsumenten und Produzenten haben. Hier
soll vor allem aufgezeigt werden, welche Anreize Entwickler haben, ihren Softwareco-
de unter einer Open Source Definition (OSD) kompatiblen Lizenz zu veröffentlichen.
Abgeschlossen wird das Kapitel 4 mit einen Exkurs in die Spieltheorie. Es soll spielthe-
oretisch analysiert werden, unter welchen Vorraussetzungen Individuen ihre Verfü-
gungsrechte an ihrem geistigen Eigentum in Kooperationen einbringen.
Das Kapitel 5 zeigt auf, welche Transaktionskosten beim Tausch von Verfügungsrech-
ten zur Erstellung von Open Source Software entstehen. Hierzu werden die Einzelpha-
sen einer Transaktion in Anlehnung an Picot (Picot / Reichwald / Wiegand, 2001,
S.339) betrachtet. Folgend wird geprüft, welche Einwirkung die Transaktionsatmosphä-
re in Form der Transaktionshäufigkeit, spezifische Investitionen, Opportunismus, Kom-
plexität und beschränkter Rationalität auf die Transaktionskosten bei der Open Source
Softwareerstellung hat. Auf Basis dieser Erkenntnisse wird begutachtet, ob die Trans-
aktionskosten Auswirkungen auf die Projektgröße bzw. innerhalb von Projekten auf die
Koordinationsformen haben.
Die Arbeit wird mit einer kurzen ergänzenden empirischen Analyse des Quellcodes
ausgewählter Projekte abgeschlossen.
6
3 Historische Entwicklung
Die Historische Entwicklung von Open Source Software gliedert sich in drei Phasen.
Jede dieser Phasen ist durch ein typisches Softwareprodukt und eine spezifische Pro-
duktionsmethode geprägt.
3.1 Die Unix-Phase
Ken Thompson und sein Kollege Denis Ritchie arbeiteten an den AT&T Bell Laborato-
ries. Beide Entwickler versuchen sich bis Februar 1969 an der Entwicklung des Be-
triebssystems Multics
1
. Multics ist ein Gemeinschaftsprojekt des Massachusetts Institu-
te of Technology (MIT) General Electric
2
(GE) und AT&T
3
. Ziel des Multics-Projekts ist
es, ein Timesharing
4
Betriebssystem für die GE 645
5
zu entwickeln. At&T zieht sich im
Februar 1969 aus dem Projekt zurück, da Zeitplan und Budget weit überschritten sind
(Grassmuck, 2002, S.211). Beide Entwickler versuchten sich an der Entwicklung eines
Timesharingsystems für kleinere Rechner. Im August 1969 schreibt Ken Thompson die
Grundversion von Unix
6
in seinem nur vier wöchigen Urlaub. Unix ist in der binärcode
nahen Sprache Assembler geschrieben (Moody, 2001, S.26 f). Unix zeichnete sich im
Systemdesign vor allem durch zwei Neuerungen im Vergleich zu bisher exsistierender
Software aus. Zum einen, dass alles eine Datei ist
7
und zum andern, dass jede Aufga-
be, die eine Software erfüllen soll, in einer Datei bzw. in einem Modul verankert ist.
Jedes Modul in einer Software soll nur einen Zweck erfüllen, diesen aber hervorra-
gend. Dieses neue Systemdesign bedeutet, dass ein Betriebsystem Stück für Stück
entwickelt werden kann. Es ist vorstellbar, dass eine einzige Person eine komplexe
Software wie ein Betriebssystem schreibt, wenn man ihr nur genügend Zeit gibt. Ferner
ist denkbar, dass Außenstehende durch eigene Beiträge die Software weiterentwickeln
können. Gerade diese Eigenschaft machen sich die Entwickler des Unix-ähnlichen
Betriebssystem Linux später zu Nutze (Moody, 2001, S.27). 1971 wird Unix in den
AT&T Bell Laboratories neu geschrieben, doch diesmal in der objektorientierten Pro-
grammiersprache C. Nun ist Unix nicht mehr an bestimmte Hardwareplattformen ge-
bunden, sondern kann auf verschiedenste Rechner portiert werden.
1
Multiplexed Information und Computing Service
2
General Electric produzierte unter anderem auch Großrechner
3
US-amerikanischer Telefondienstleistungsanbieter
4
Mehrere Benutzer nutzen abwechselnd den selben Rechner. Jeder Nutzer hat nur Zugriff auf
sein eigenes Dateisystem.
5
Großrechner von General Electric
6
Uniplexed Information and Computing Service; aus ,,UNICS" wird bald das Akronym ,,UNIX"
gebildet.
7
Selbst Laufwerke werden als Datei angesehen
7
AT&T darf Unix jedoch nicht kommerziell vermarkten, da AT&T schon 1956 vom De-
partment of Justice angewiesen wurden, sich nur auf den Bereich Telekommunikation
zu beschränken (verlorener Kartellrechtsprozess 19491956). Aus diesem Grund li-
zenziert AT&T das Betriebssystem zu einem nominellen Betrag (50 $) an US-
Universitäten. Kommerzielle Nutzer können sich auch eine Lizenz erkaufen, jedoch
müssen sie dafür astronomische Summen zahlen (100 000 $). Unix wird von AT&T nur
für firmeneigene Zwecke weiterentwickelt. Da AT&T keinen offiziellen Support, Bugfi-
xes
8
u.a. für Unix unternimmt, entwickelt sich ein reger Austausch an Neuentwicklun-
gen und Erweiterungen in Form von Patch-Dateien
9
im universitären Umfeld. Der Aus-
tausch der Programme (inkl. Quellcode) ist möglich, da fasst alle Universitäten Unix-
Lizenzen besitzen. Die Universität Berkeley fungiert als Koordinationsstelle und entwi-
ckelt einen eigenen Unixzweig (O´Reilly, 1999, S.16 f). Diese Koordinationsfunktion
wird von der ARPA
10
unterstützt (Grassmuck, 2002, S.214). Anwälte des Telekommu-
nikationsmonopolisten AT&T erarbeiten 1979 mit Vertretern der Universität Berkeley
die erste Lizenzvereinbarung (BSD-Lizenz)
11
über quelloffene Software. AT&T beab-
sichtigt damit, ihren firmeneigenen Code vom freien Code der Universitäten abzugren-
zen. Nutzer müssen also eine AT&T Unix-Lizenz von AT&T erwerben, und können mit
Hilfe des kostenfreien BSD-Codes Ergänzungen und Fehlerbehebungen in Form von
Patch-Dateien integrieren (Grassmuck, 2002, S.279 f). Die Universitäten entwickeln in
den folgenden Jahren Unix weiter, so dass immer mehr AT&T-Code durch freien uni-
versitären Code ersetzt wird. Die Firmen IBM, HP und DEC veröffentlichen 1982 ihre
eigenen Unix-Versionen, bestehend aus dem universitären Code und Eigenentwick-
lungen, die AT&T Code ersetzen. Diese Softwarepakete werden von den Firmen jetzt
kommerziell gegen Lizenzgebühren vermarktet (O´Reilly, 1999, S.16). Als Reaktion
darauf trennt sich der Konzern AT&T 1984 von 26 Firmen, und darf daher nun auch auf
dem somit neu entstandenen Softwaremarkt tätig werden. Die Unix-Versionen der
kommerziellen Anbieter zeichnen sich durch eigene Entwicklungsstränge aus, so dass
immer mehr inkompatible Verzweigungen der Code-Basis entstehen. Die verschieden
Versionen verlassen damit die gemeinsamen Standards und werden inkompatibel zu-
einander (Grassmuck, 2002, S.215). Im universitären Umfeld wird Unix weiterentwi-
ckelt bis 1991 das erste komplett freie Unix erhältlich ist. 1992 sieht die Universität
Berkeley keine technische Herausforderung mehr in der Unix-Entwicklung und stellt
daher das ,,Forschungsprojekt Unix" im selben Jahr ein. Aus dem Humankapitalpool
8
Fehlerkorrekturen
9
Patchdateien sind kleine Programmblöcke, die sich bei Ausführung in andere Software integ-
rieren. Patchdateien können zur Programmerweiterung oder Fehlerkorrektur benutzt werden.
10
Advanced Research Projects Agency; 1958 gegründetes Projekt innerhalb des US Verteidi-
gungsministeriums. Ziel war es, den Sputnik-Schock von 1957 mit der Erringung der (militär-)
technologischen Vorherrschaft zu bewältigen (Meretz, 2000, S.9).
11
Berkley Software Distribution
8
der Universität Berkeley entstehen drei Unix-Derivate mit jeweils unterschiedlichen
Schwerpunkten (FreeBSD, NetBSD, OpenBSD), gemein ist diesen Projekten die Ziel-
setzung ein Unix für Computer mit 386er Prozessoren
12
zu entwickeln (Hausen, 1999).
3.2 GNU
Richard Stallman initiiert 1984 das GNU-Projekt (Gnu is not Unix). Das GNU-Projekt
stellt für Stallman eine Gegenbewegung zur Kommerzialisierungswelle im Softwarebe-
reich dar. Zahlreiche Softwareentwickler lassen sich von Firmen anstellen, und entwi-
ckeln Softwarecode gegen Bezahlung. Die Bezahlung an sich ist für Stallman nichts
Verwerfliches, doch Stallman lehnt es strikt ab, dass diese Software nur noch ge-
schützt von Lizenzen in Form von maschinenlesbaren Binärcode gegen Bezahlung
weitergegeben wird. Stallman sieht darin das Ende der Hackerkultur
13
, die er am AI-
Lab
14
des MIT so sehr genoss (Grassmuck, 2002, S.217 ff). Steven Levi zitiert in sei-
nem Buch ,,Hackers" aus dem Jahr 1984 Stallman mit folgenden Worten: ,,Ich finde
nicht, dass Software Eigentum sein sollte...weil mit dieser Praxis die Menschlichkeit im
Ganzen sabotiert wird. Sie verhindert, dass die Menschen aus einem Programm den
maximalen Nutzen ziehen" (Levi, 1984). Stallman setzt sich zum Ziel ein Betriebssys-
tem zu entwickeln, das im Verwendungszweck seine Ansprüche von Software erfüllen
soll. Jedermann soll die Freiheit haben, das Programm für jeden beliebigen Zweck zu
nutzen. Es soll jedem gestattet sein, das Programm nach seinen Wünschen zu verän-
dern. Hierfür ist die Bereitstellung des Quellcodes eine zwingende Vorraussetzung.
Ferner soll jede Person die Freiheit haben, das Programm in Originalzustand oder in
abgeänderter Version weiterzuverteilen (Stallman, 1985, Stallman, 1996). Um sein
ehrgeiziges Vorhaben zu realisieren, muss sich Stallman die programmiertechnische
Infrastruktur bereitstellen. Er entwickelt hierzu GnuEmacs
15
und den Gnu C Compiler
16
.
Beide Programme unterstellt er einer Lizenz, die Stallmans Ansprüche an Software
auch rechtlich manifestieren soll, der General Public License (GPL)
17
. Als rechtlicher
12
368er Prozessoren waren zu dieser Zeit der Standardprozessor für PCs.
13
Der Begriff ,,Hacker" wird seit Mitte der 80er Jahre für Computerkriminelle verwendet. Hier ist
die ursprüngliche Begriffsbedeutung, die ihre Wurzeln in der Hackergemeinde des MIT hat ver-
wendet. ,,...people who ,,program enthusiastically" and who believe that ,,information-sharing is a
powerful positive good, and that is an ethical duty of hackers to share their expertise by writing
free software and facilitating access to information and to computing resources wherever possi-
ble", Himanen / Torvalds / Castells, 2001, Seite vii f).
14
Laboratory of Artificial Intelligence
15
Gnu Editing MACroS; Die Benutzer können Sammlungen an Befehlen (Makros) eingeben,
und erhalten unmittelbares Feedback über die Ausführbarkeit (Moody, 2001, S.29).
16
Ein Compiler übersetzt Quellcode in maschinenlesbaren Code, der zur Ausführung auf einem
Computer notwendig ist.
17
Stallman entwickelt die GPL zusammen mit dem Juraprofessor Eben Moglen.
9
Träger der GPL und Koordinationsstelle des GNU-Projekts fungiert die von Stallman
gegründete Free Software Foundation (FSF).
Stallman greift das Systemdesign von Unix auf, um sein Betriebssystem GNU zu ver-
wirklichen. Gerade der modulare Aufbau ermöglicht es einer Einzelperson, dieses Vor-
haben zu bewältigen. Ein Betriebssystem zeichnet sich durch eine sehr hohe Komple-
xität aus. Der modulare Aufbau ermöglicht somit, die Gesamtkomplexität auf viele klei-
ne Module zu verteilen. Stallmans selbstgesetztes Ziel ist also zu verwirklichen, indem
viele kleine Einzelmodule programmiert werden (Moody, 2001, S.34 f). Der Ansatz des
GNU-Projekt zeichnet sich dadurch aus, dass die Module von Einzelentwicklern pro-
grammiert werden. Kooperation von Entwicklern bei der Erstellung von Einzelmodulen
gibt es zu Beginn kaum, da der Bauplan des Betriebssystems eine Unmenge an ver-
schiedenen Funktionen vorsieht, die nach und nach mit entsprechendem Code gefüllt
werden müssen. Anfangs sieht sich Stallman als Einzelkämpfer später wird er von
anderen freiwilligen Programmierern unterstützt. Die Fehlersuche in GNU erweisen
sich als sehr schwer, da das Betriessystem GNU nicht ausgeführt werden kann. Das
zentrale Steuerungsprogramm, der Kernel, kann nicht fertig gestellt werden, da Stall-
man einen Mikrokernel
18
in GNU einbinden will. Der Mikrokernel ,,Hurd" des GNU-
Projekts ist bis dato noch nicht fertiggestellt.
3.3 Linux
Das Linux-Projekt wird 1991 von dem finnischen Studenten Linus Torvalds gestartet.
Ziel des Linux-Projektes ist es, ein freies unixähnliches Betriebssystem für 386er Pro-
zessoren zu entwickeln. Zwar exsistiert zu dieser Zeit mit Mimix ein unixähnliches Be-
triebssystem, das auf 386er Prozessoren läuft, doch ist Mimix nicht frei erhältlich. Tor-
valds beginnt einen Kernel zu programmieren. Dieser Kernel erhält den Namen Li-
nux
19
. Nachdem Torvalds im selben Jahr, und nach viel Einzelarbeit eine relativ stabile
Grundversion von Linux entwickelt hat, nutzt er die Mimix-Newgroup
20
, die zu diesem
Zeitpunkt etwa 40.000 Interessenten hat um sein Projekt vorzustellen. Am 25 August
1991 stellt er seinen Linux-Kernel in der Newsgroup vor, und bittet die Leser um Anre-
gungen. Prompt erhält er Resonanz und Angebote von Personen, die Linux als Beta-
18
Ein Mikrokernel sieht jede Softwareeinheit des Kernels als eigenständiges Anwendungspro-
gramm an.
19
Eine Kombination aus seinem Vornamen ,,Linus" und ,,Unix".
20
Eine Newsgroup ist eine internetgestützte Kommunikationsplattform. Die Beteiligten Perso-
nen bekommen alle Einträge und die dazugehörenden Antworten via e-mail zugesendet. Bsp.:
comp.os.linux; ,,comp" steht für eine offizielle Computer-Newsgroup; ,,os" für den Themenbe-
reich operation system; ,,mimix" bzw. ,,linux" identifizieren die einzelnen Newsgroups.
10
tester
21
ausprobieren möchten. Torvalds gibt am 5. Oktober 1991 die Linuxversion
0.02
22
zum download über den Server der Uni Helsinki frei. Von diesem Zeitpunkt an
nutzt eine immer größer werdende Anzahl an Entwicklern die Minix-Newsgroup zur
Weiterentwicklung von Linux (Torvalds, 2001, S.94 ff). Torvalds bekommt so viele
Nachfragen über Linux in die comp.os.minix Newsgroup gepostet, dass Linux im Spät-
sommer 1992 seine eigene comp.os.linux Newsgroup zugeteilt bekommt (Torvalds,
2001, S.126 ff). Die Nutzerschar von Linux wächst in dieser Zeit stetig. Torvalds sieht
die Nutzer als Mitentwickler an und übernimmt Erweiterungen und Verbesserungen in
den Linux-Kernel (Raymond, 1998). Ferner entwickelt sich eine Eigendynamik im Li-
nux-Projekt. Die weltweit verteilten Linux-Entwickler tauschen regelmäßig Änderungs-
vorschläge untereinander aus. Die besten Entwürfe werden Torvalds zugesandt mit der
Hoffnung in der Kernel aufgenommen zu werden.
Linux wächst so schnell, dass im März 1994 die Version 1.00 veröffentlicht wird.
Das rasante Wachstum von Linux hat auch Auswirkungen auf die Lizenzpolitik des
Projektes. Bei Projektgründung bindet Torvalds die Nutzer an folgende Vorraussetzun-
gen:
Dieser Kernel ist ©1991 Linus Torvalds, kann aber unter folgenden Voraussetzungen
zur Gänze oder teilweise weitervertrieben werden:
· Der volle Quellcode muss verfügbar (und frei) sein, wenn nicht durch die Vertei-
lung, dann wenigstens auf Verlangen.
· Die Copyrightvermerke müssen intakt sein. (Wenn ihr nur Teile davon verteilt,
müsst ihr möglicherweise Copyrights hinzufügen, da es nicht in allen Teilen ©
gibt.) Kleine Teilauszüge können ohne Rücksicht kopiert werden.
· Ihr dürft das System nicht gegen Gebühr vertreiben, nicht einmal gegen ,,Hand-
ling Kosten".
Die letzte Klausel bedeutet, dass die Nutzer keine Gebühr für die Weiterverteilung von
Linuxdisketten erheben dürfen
23
. Da das Internet Anfang der 90er Jahre noch nicht
sehr weit verbreitet war entstehen Nutzern, die anderen Linux-Interessierten den Zu-
gang zum Quellcode oder zur ausführbaren Version ermöglichen wollen, Kosten. Da-
her wird Linux nach 1991 der GPL unterstellt (Torvalds, 2001, S.103 ff).
21
Betatester sind Personen, die eine Software vor Veröffentlichung auf Funktionsfähigkeit tes-
ten. Der Begriff stammt ursprünglich aus der kommerziellen Softwareentwicklung. Im Zusam-
menhang mit Open Source Software wird er soweit gedehnt, das jeder Nutzer (auch die eines
offiziellen Release als Betatester angesehen werden.
22
Diese Version enthält etwa 10000 Zeilen Quellcode.
23
Der komplette Kernel ist 1991 komprimiert nur 72 KB groß
11
In den folgenden Jahren wird der Linux-Kernel mehr und mehr an schon exsistierende
Applikationen des GNU Projektes angepasst und weiterentwickelt. Der Linux-Kernel
stellt somit die fehlende Komponente des 1984 gegründeten GNU-Projektes von Ri-
chard Stallman dar. Anfangs wird das Betriebssystem GNU/Linux genannt. Später
setzt sich jedoch der Name Linux durch. Linux ist augenblicklich eines der stabilsten
Betriebssysteme, und wird wegen der Stabilität meist als Betriebssystem für Server
genutzt. Derzeitig hat der aktuelle Linux-Kernel die Version 2.4.20 mit mehr als 10 Mil-
lionen Zeilen Quellcode.
Der Erfolg von Linux hat zur Folge, dass auch kommerzielle Softwareunternehmen auf
diese Produktionsmethode Aufmerksam werden.
3.4 Gründung der Open Source Initiative
Als Netscape in Januar 1998, nach eingehender Beratung von Eric Raymond und
Frank Hecker, bekannt gibt, den Quellcode ihres Browsers zu veröffentlichen, sehen
Raymond, Perens u.a. die Möglichkeit der Unternehmenswelt die Überlegenheit des
,,horizontalen Basarentwicklungsstils"
24
nachzuweisen. Sie versuchen, den Unterneh-
men die pragmatischen und wirtschaftlichen Vorteile des offenen Entwicklungsmodells
zu verdeutlichen (Perens, 1999), da sie der Meinung sind, dass sich diese Entwick-
lungsmodell nur durch Kooperation mit der Industrie durchsetzen könne.
Um mit einer einheitlichen Definition von industriekonformer freier Software Fürspre-
cher in Unternehmen zu finden, gründen Eric Raymond, Todd Anderson, Christine Pe-
terson, John ,,maddog" Hall, Larry Augustine, Sam Ockman, Bruce Perens und Linus
Torvalds die Open Source Initiative (OSI) (OSI, 1998). Der Begriff ,,Open Source" wird
erst auf dem Gründungstreffen von Christine Peterson (Foresight Institute)
geschaffen
und soll den Charakter der Quelloffenheit der Software in den Vordergrund stellen. Der
Begriff ,,free" soll vermieden werden, da er sowohl Freiheit als auch kostenlos impli-
ziert. Sie erstellen eine Richtlinie für die Bewertung von Lizenzen freier Software auf
Basis der Debian Free Software Guidelines (DFSG, 1997), die Open Source Definition
(Perens, 1999). Alle Lizenzen, die mit der OSD konform sind, dürfen sich mit dem Gü-
tesiegel ,,Open Source Lizenz" schmücken. Rechtlich wird der Begriff ,,Open Source"
als Trademark durch die OSI (eingetragen auf Bruce Perens) geschützt. Ziel der OSI
ist es, Open Source Produkte für die Industrie interessant zu machen, da sich dieses
Softwaremodell nach Meinung der OSI-Gründer nur in Zusammenarbeit mit Wirtschaft
und Industrie durchsetzen könne. Nach Abschluss der Konferenz ist nicht klar, ob sich
24
Unter ,,horizontalem Basarentwicklungsstil" wird die hierarchiefreie, freiwillige Zusammenar-
beit von Einzelentwicklern verstanden.
12
der Begriff und die Definition von ,,Open Source" etablieren wird. Erst als die Vorreiter
Netscape, und O´Reilly
25
den Namen annehmen, folgen ihnen auch andere Firmen mit
der Anerkennung der neuentwickelten Produktbeschreibung (Perens, 1999).
3.5 Kernpunkte der Open Source Definition
1.Freie Weiterverbreitung
Die Lizenz darf niemanden im Verkauf oder in der Weitergabe der Software als
Teil einer aus verschiedenen Quellen zusammengesetzten Softwaredistribution
einschränken. Die Lizenz darf keinerlei Lizenzgebühren oder andersartige
Beiträge verlangen.
2.Quellcode
Das Programm muss den Quellcode beinhalten und sowohl die Verbreitung im
Quellcode als auch in kompilierter (binärer) Form gestatten. Wird ein Teil des
Produkts nicht mit Quellcode verbreitet, so muss auf die Möglichkeit, den Quell-
code gebührenfrei aus dem Internet downzuloaden, ausdrücklich hingewiesen
werden. Der Quellcode muss in einer Form zur Verfügung gestellt werden, in
der ein Programmierer ihn verändern kann. Absichtlich verwirrend geschriebe-
ner Quellcode ist nicht erlaubt. Ebenso sind Zwischenformen, wie die Ausgabe
eines Präprozessors oder eines Übersetzers, verboten.
3.Auf dem Programm basierende Werke
Die Lizenz muss die Veränderung des Programms, auf dem Programm basie-
rende Werke, sowie deren Verbreitung unter den gleichen Lizenzbedingungen
gestatten.
4.Die Unversehrtheit des Originalcodes
Die Lizenz darf die Verbreitung von modifizierten Quellcode nur dann ein-
schränken, wenn sie die Verbreitung von sogenannten ,,Patchdateien"
26
in Ver-
bindung mit dem Originalcode gestattet, damit das Programm vor der Benut-
zung verändert werden kann. Die Lizenz muss ausdrücklich die Verbreitung von
Software erlauben, die mit verändertem Quellcode erstellt wurde. Die Lizenz
25
Distributor von Softwarehandbüchern
26
Patchdateien sind kleine Programmblöcke, die sich bei Ausführung in andere Software integ-
rieren. Patchdateien können zur Programmerweiterungen oder Fehlerkorrektur benutzt werden.
13
darf allerdings von auf dem Programm basierenden Werken verlangen, einen
von der Originalsoftware verschiedenen Namen oder eine andere Versions-
nummer zu tragen.
5.Keine Diskriminierung von einzelnen Personen oder Gruppen
Die Lizenz darf keinerlei Personen oder Personengruppen diskriminieren.
6.Keine Einschränkung für bestimmte Anwendungsbereiche
Die Lizenz darf niemanden in der Benutzung des Programms in einem be-
stimmten Einsatzgebiet einschränken. Sie darf beispielsweise nicht die kom-
merzielle Nutzung oder die Verwendung in der Genforschung verbieten.
7.Verbreitung der Lizenz
Die zum Programm gehörigen Rechte müssen für jeden gelten, der das Pro-
gramm erhalten hat, ohne dass eine weitere Lizenz beachtet werden muss.
8.Die Lizenz darf nicht für ein bestimmtes Produkt gelten
Die zum Programm gehörigen Rechte dürfen nicht davon abhängen, dass das
Programm Teil einer bestimmten Softwaredistribution ist. Wird das Programm
außerhalb einer Distribution genutzt oder verbreitet, so gelten für den Benutzer
dieselben Rechte, die in der Originaldistribution gewährt werden.
9.Die Lizenz darf andere Software nicht beeinträchtigen
Die Lizenz darf keine andere Software einschränken, die zusammen mit der li-
zenzierten Software verbreitet wird. Die Lizenz darf beispielsweise nicht verlan-
gen, dass jegliche andere Software, die auf demselben Datenträger verbreitet
wird, Open Source Software sein muss.
14
4 Anwendung des Property Rights Ansatz auf die Lizenzen
von Open Source Software
Der Property Right Ansatz wird im Folgenden auf OSD-kompatible Lizenzen angewen-
det. Ziel dieser Analyse ist es, die ökonomischen Einflussfaktoren der Property Rights
auf die Erstellung von Open Source Software herauszuarbeiten. Zu Beginn werden die
besonderen Eigenschaften von Software als digitales Gut beschrieben. Im Anschluss
folgt eine Analyse der Open Source Definition incl. verschiedener Beispiellizenzen auf
Grundlage des Property Rights Ansatzes. Es wird im Anschluss eine Segmentation der
verschiedenen Softwarearten auf Basis der Property Rights Struktur durchgeführt.
Nach Klärung verschiedener Durchsetzungsmöglichkeiten der in den Lizenzen spezifi-
zierten Verfügungsrechten und deren Bedeutung für die Allokationsanreize, wird ein
spieltheoretischer Versuch unternommen, Kooperationsgewinne aufgrund der beson-
deren Lizenzeigenschaften nachzuweisen.
4.1 Eigenschaften digitaler Güter
Zu Beginn der Analyse sollen die Eigenschaften digitaler Güter aufgezeigt werden, da
sich bei digitalen Gütern Unterschiede zu festen materiellen Gütern ergeben.
Digitale Güter stellen sich als Teilmenge der Informationsgüter dar (Luxem, 2001,
S.20). "Essentially, anything that can be digitized - encoded as a stream of bits - is in-
formation." (Shapiro / Varian, 1999, S.4)
Als ein digitales Gut werden nicht abnutzbare Produkte und Dienstleistungen verstan-
den, die sich mit Hilfe von Informationssystemen entwickeln, vertreiben und anwenden
lassen. Diese Güter lassen sich in Form von Binärdateien digital übertragen, darstellen
und verbreiten (Choi / Stahl / Whinston, 1997, S.62f).
Beispiele für digitale Güter sind Dienstleistungen, die auf elektronischen Marktplätzen
gehandelt werden, digitale Radio und Fernsehprogramme, Software sowie Informati-
onsdienste die mit Hilfe von elektronischen Agenten die Informationsflut des Internet zu
bewältigen helfen.
15
Ein digitales Gut zeichnet sich durch folgende Eigenschaften aus (Stelzer, 2000, S.835
ff):
· Digitale Güter können sehr einfache Produkte (wie Aktienkurse), aber auch
komplexe Dienstleistungen, wie die elektronische Arbeitsvermittlung, sein. Hier
werden auf einem elektronischen Marktplatz Angebot und Nachfrage von Ar-
beitskraft zusammengeführt. Bei digitalen Gütern herrscht auch das sogenann-
te Informationsparadoxon. Hierunter wird grundsätzlich die ,,unrechtmäßige"
Aneignung fremder Property Rights Verstanden. Gerade bei Informationspro-
dukten stellt sich ein signaling-Problem, denn oftmals wird durch das signaling
schon so viel Information preis gegeben, dass der potentielle Nachfrager die In-
formation nicht mehr kaufen muss.
· Die klare Trennung zwischen Produkten und Dienstleistungen verschwimmt. So
werden bestimmte Dienstleistungen zunehmend durch digitale Produkte er-
setzt. Die Dienstleistung der Vermittlung von Urlaubsreisen (ursprünglich in
Reisebüros) wird zunehmend durch die Funktionalität komplexer Informations-
systeme substituiert (Bieberbach / Hermann, 1999, S. 19 ff).
· Digitale Güter kommen in unterschiedlichen Digitalisierungsgraden vor. So
kann eine Software mit einer Einführungsberatung gekoppelt vertrieben wer-
den. Es entsteht somit ein digitales Gut mit einem Dienstleistungsanteil. Ferner
kann eine Software auf einem physischen Medium, z.B. einer CDROM bzw.
DVD vertrieben werden. Die vollständige Digitalisierung ist erreicht, wenn die
entsprechende Software über das Internet zum download angeboten wird.
Die ökonomische Besonderheit von digitalen Gütern zeigt sich durch die Betrachtung
der Produktionskosten. Ein digitales Gut zeichnet sich durch hohe Differenz zwischen
Entwicklungskosten und Produktions- bzw. Absatzkosten aus. So werden von Arthur
(1996, S.100f) die Entwicklungskosten von Windows 3.1 mit 50 Millionen $ beziffert.
Die Produktion, Versand und Verpackung einer Einzelkopie verursachte lediglich noch
Kosten in Höhe von 3 $. Ist nun eine Software vollständig digitalisiert, und wird über
das Internet zum Download angeboten, incl. eines Abrechnungssystems wie z.B. das
Microsoft eigene .NET System, so tendieren die Reproduktionskosten gegen Null (Ba-
chem / Heesen / Pfennig, 1996, S.699 f). Die fixen Kosten der Produktion eines voll-
ständig digitalisierten Gutes sind also im Vergleich zu den variablen kosten sehr hoch.
Firmen, die ihr Kerngeschäft in der Softwareproduktion haben, müssen also versuchen,
eine entsprechende Anzahl an Kopien auf dem Markt zu verkaufen, die ihre Fixkosten
decken. Dies setzt gleichfalls voraus, dass diese Firmen Versuche unternehmen, wi-
16
derrechtliches kopieren ihrer Software einzuschränken. Dies geschieht in erster Linie
durch Lizenzen, die das Kopieren der Software untersagen. Im Gegensatz dazu erlau-
ben alle Open Source Lizenzen das kopieren der betreffenden Software. Daher werden
im folgenden Open Source Lizenzen genauer analysiert.
4.2 Arten von Open Source Lizenzen
In der OSD (OSD_DEF, 1998) kann man die vier Verfügungsrechte des römischen
Rechtes (usus, usus fructus, abusus und das Weitergaberecht) wiederfinden. Jeder-
mann ist die uneingeschränkte, sogar zwingend lizenzkostenfreie Nutzung (usus) der
Software gestattet (Abschnitt 1,5 und 6). Es ist egal, auf welche Weise der Nutzer zu
den Binärdateien des Programms gekommen ist. Er kann die Software über einen Drit-
ten, z.B. einem Distributor, gegen Bereitstellungskosten bezogen haben. Ferner kann
er die Software direkt vom Urheber erhalten, oder das Programm aus dem Internet
runtergeladen haben. Abschnitt 6 der OSD erlaubt ihm, mögliche Gewinne (usus fruc-
tus), die er aus der Nutzung der Open Source Software erzielt, für sich zu behalten.
Jedem Nutzer muss gestatten sein, ein Open Source Programm nach seinen Wün-
schen zu verändern (abusus). Der Zugang zum hierfür nötigen Quellcode ist in Ab-
schnitt 2 geregelt. Die Abschnitte 2 und 3 erlauben die Veränderung des Programms.
Ferner wird die Möglichkeit zur Weitergabe des Programms, also der drei bisher ge-
nannten Rechte (usus, usus fructus, abusus) durch die Abschnitte 1,2,3,und 4 festge-
legt.
Das Recht zur Weitergabe der Software spielt in allen OSD übereinstimmenden Li-
zenzen eine entscheidende Rolle, da zwar das Weitergaberecht ausdrücklich gewährt
wird, es jedoch an bestimmte lizenzspezifische Bedingungen geknüpft ist.
Verallgemeinernd kann man sagen, dass der Nutzer die Lizenzbedingungen erst bei
Weitergabe der Software akzeptieren muss. Gebrauchs-, Veränderungs-, und Ge-
winnmitnahmerecht sind ihm durch OSD kompatible Lizenzen ohne Einschränkungen
gestattet, das Weitergaberecht ist jedoch an gewisse Beschränkungen geknüpft.
Die Verfügungsrechte stellen damit Dominanzbeziehungen zwischen den ursprüngli-
chen Entwicklern und den Nutzern dar. Ein originärer Entwickler hat alle Verfügungs-
rechte an einer Software inne, und hat damit keine Dominanz über die Software an
17
sich, sondern kann andere Personen von der Nutzung an der Software ausschließen,
falls sie die Lizenzauflagen der Weitergabebedingungen nicht akzeptieren.
27
Um eine genauere Analyse der Property Rights in den einzelnen OSD konformen Li-
zenzen durchzuführen, müssen nun die einzelnen Lizenzen genauer betrachtet wer-
den. Es wird der in der Literatur häufig verwendeten Einteilung von offenen und viralen
Lizenzen gefolgt (Hawkins, 2001, S.6; Jaeger / Metzger, 2002, S.VIII f), und diese Li-
zenztypen anhand von Beispiellizenzen erklärt. Im Anschluss wird noch auf den Son-
derfall von Firmenlizenzen eingegangen, die den Firmen besondere Rechte einräu-
men.
4.2.1 Offene Lizenzen
Die älteste und gleichwohl eine der bekanntesten offenen Lizenzen ist die Berkeley
Software Distribution (BSD) License (BSD_LICENSE, 1998). Diese Lizenz gewährt
jedermann die vier Verfügungsrechte des alten römischen Rechts (usus, usus fructus,
abusus, Weitergabe). Jedermann darf die Software also nutzen (auch gewinnbrin-
gend), verändern, und mit oder ohne Änderungen weitergeben. Gibt eine Person die
Software an Dritte weiter, so ist sie jedoch verpflichtet (1-3 Pflicht) dem Programm ei-
nen von der Berkeley-Universität vordefinierten Lizenztext (Haftungsausschluss) beizu-
fügen. Dieser Haftungsausschluss entbindet den oder die ursprünglichen Entwickler
von jeglicher Haftung, falls durch den Gebrauch der Software Schäden oder Datenver-
luste für den Nutzer entstehen. Diese Art von Haftungsausschlüssen sind nicht nur in
allen Open Source Lizenzen zu finden, sondern auch proprietäre
28
Anbieter wie z.B.
Microsoft oder Novel übernehmen keine Haftung für Schäden, die durch Gebrauch
ihrer Softwareprodukte entstehen (Microsoft Windows NT Workstations 4.0, 1997).
Ferner müssen die Copyrightvermerke der Software beigefügt werden (1 u. 2 Pflicht).
Es muss also auch für spätere Nutzer nachvollziehbar sein, welche Entwickler an der
jeweiligen Software mitgearbeitet haben, und daher die Inhaber des Copyright sind.
Um die Persönlichkeitsrechte der Originalautoren zu wahren, darf bei abgeleiteten
Werken nicht ohne ausdrückliche Genehmigung der Originalautoren mit deren Namen
für das neu entstandene Produkt geworben werden (4 Pflicht).
Da im Lizenztext kein Hinweis darauf gegeben ist, dass vom Originalprogramm abge-
leitete Werke ebenfalls auch im Quelltext weiterverbreitet werden müssen, ergibt sich
27
,,In the rights of a person to a resource we include the probability that his decision about
demarcated uses of the resource will determine the use, in the sense that his decision domi-
nates that of any other person." (Alchian, 1979, S.237.)
28
Als proprietär wird Software verstanden, die nur in Form von Binärcode gegen Lizenzkosten
weitergegeben wird.
18
die Möglichkeit abgeleitete Werke oder einzelne Module in eine andere Software zu
integrieren. Diese Software darf nun unter einer anderen, frei wählbaren Lizenz ver-
breitet werden, solange der Haftungsausschluss und der Copyrightvermerk im Quell-
code, oder bei Binärdateien in der Dokumentation, vorhanden sind. Diese Freiheiten
der BSD-Lizenz hat auch Microsoft in verschiedenen Windows Versionen genutzt
(Grassmuck, 2002, S.306). Dort sind z.B. TCP/IP Module zu finden, die im Rahmen der
BSD entwickelt wurden.
Betrachtet man die Entwicklungsgeschichte der BSD-Lizenz, so ist es nicht verwunder-
lich, dass die Lizenz kaum Restriktionen für die Verwendung des Codes auferlegt. Die
BSD-Lizenz ist 1979 von Anwälten der Firma AT&T und Vertretern der Universität Ber-
keley entwickelt worden. Die BerkeleyUniversität fungiert damals als Koordinations-
stelle für die freie UNIX-Weiterentwicklung in den amerikanischen Universitäten. Durch
Lizenzbedingungen des von AT&T entwickelten Unix ist es den UNIX-Nutzern gestat-
tet, das AT&T Unix zu nutzen und auch zu verändern, jedoch darf es nicht weitergege-
ben werden. Da bis dato im universitären Bereich noch kein eigenständiges UNIX-
Derivat entwickelt ist, verteilt man die im universitären Umfeld getätigten UNIX-
Weiterentwicklungen als Patchdateien unter der BSD-Lizenz, die in Verbindung mit
dem AT&T Unix ein vollständiges, weiterentwickeltes Unix darstellen.
AT&T wird 1956 durch das Department of Justice angewiesen, auf die kommerzielle
Vermarktung von Software zu verzichten, um die Monopolstellung, die AT&T schon
durch den Telekommunikationsmarkt hat, nicht noch weiter auszubauen. Daher lizen-
ziert der Telefonmonopolist sein UNIX für einen nominellen Betrag (ca.50 $) an Univer-
sitäten. Da eigentlich alle Universitäten eine AT&T UNIX-Lizenz besitzen, kann UNIX in
den Universitäten in Form von Patchdateien immer weiterentwickelt werden. Nachdem
die letzte Codezeile AT&T- Code 1991 durch freien universitären BSD-Code ersetzt
wird, kann das BSD-UNIX als eigenständiges Betriebssystem jedermann zugänglich
gemacht werden (Grassmuck, 2002, S.279 ff).
Weil in den USA jedermann universitärer (staatlich geförderter) Code zugänglich ge-
macht werden soll (es sei denn es betrifft die nationale Sicherheit), muss die BSD-
Lizenz auch einen sehr liberalen Charakter haben. Die BSD-Lizenz ist zwar streng ge-
nommen nicht der ,,public domain" zuzuordnen, da Copyrightvermerke und Haftungs-
ausschlüsse verpflichtend sind. Durch die Möglichkeit modifizierten BSD-Code unter
einer beliebigen anderen Lizenz zu verbreiten hat sie jedoch den Charakter einer ,,pub-
lic domain" Software, obwohl die Software an die oben genannten Lizenzbedingungen
geknüpft ist.
29
29
Die Universitäten als Copyrightinhaber verzichten auf ihre Urheberschaft, so dass die Soft-
ware von jedermann in beliebiger Form genutzt werden kann. (Jaeger / Metztger, 2002, S.5)
19
4.2.2 Virale Lizenzen
Als Richard Stallman 1984 das GNU-Projekt (Gnu is Not Unix) gründet, reagiert er auf
den zunehmenden Trend Software nicht frei im Quellcode zu vertreiben, sondern diese
nur noch als kostenpflichtige Binärdateien gegen Lizenzkosten zu vermarkten. Als Ko-
ordinationsstelle für das GNU-Projekt gründet Stallman die ,,Free Software Foundation"
(Moody, 2001, S.25 ff). Das Wort ,,free" soll die Freiheit der Software in den Vorder-
grund stellen.
Die Software der Free Software Foundation soll jedem Nutzer folgende Freiheiten bie-
ten (Stallman, 1985 ; Stallman, 1996):
· You have the freedom to run the program, for any purpose.
· You have the freedom to modify the program to suit your needs (To make this
freedom effective in practice, you must have access to the source code, since
making changes in a program without having the source code is exceedingly
difficult).
· You have the freedom to redistribute copies, either gratis or for a fee.
· You have the freedom to distribute modified versions of the program, so that the
community can benefit from your improvements.
Um diese Ansprüche auch rechtlich zu manifestieren entwickelt er zusammen mit dem
Juraprofessor Eben Moglen die GPL (General Public License)
30
. Betrachtet man die
Verfügungsrechte, die dem einzelnen Nutzer durch die GPL (GPL_LICENSE, 1991)
gewährt werden, so wird deutlich, dass jedermann die Software in beliebiger Art und
Weise nutzen darf (auch gewinnbringend). Ferner darf die Software verändert und
auch weitergegeben werden. Genau diese vier Rechte stellen auch die Ansprüche
Stallmans an freie Software aus dem GNU-Manifest dar. Doch Stallmans Zielsetzun-
gen des GNU-Projekts gehen noch weiter, da er erreichen will, dass freie Software auf
lange Zeit (wenn möglich für immer) auch frei bleiben muss, und niemand die Möglich-
keit haben soll, freie Software in proprietäre Programme einzubinden. Dieses Ziel er-
30
Schon bei der Nummerierung der einzelnen Absätze ist Stallmans computerwissenschaftliche
Herkunft zu sehen. Die GPL sowie die oben genannten Anforderungen an freie Software aus
dem GNU-Manifest beginnen mit dem Absatz 0, da irgendjemand einmal herausgefunden hat,
dass es einfacher ist, die Nummerierung von Datenbanken mit 0 beginnen zu lassen, weil man
dann nicht so oft eine 1 abziehen muss. (Wayer, 2001, S.104)
20
reicht Stallman, indem er dem Nutzer durch die GPL auch Pflichten auferlegt, falls er
ein Programm oder einzelne Teile aus einem GPL lizensierten Programm weitergibt.
So heißt es in Abschnitt 2 der GPL, dass jeder Nutzer ein unter der GPL lizenziertes
Programm verändern und auch weitergeben darf. Dieses neu entstandene Programm
stellt aber ein auf dem Ursprungsprogramm basierendes Datenwerk dar. Genauer wird
dieser Sachverhalt in Abschnitt 2b der GPL spezifiziert, indem dem Nutzer auferlegt
wird, dass das neu entstandene Programm im Falle einer Weitergabe ebenfalls unter
der GPL lizenziert werden muss, wenn es ganz oder auch nur teilweise aus GPL Pro-
grammen abgeleitet ist
31
.
Dieser Abschnitt der GPL wird als größter ,,Hack" Stallmans bezeichnet, der auch sehr
bekannte Programme wie Emacs (Texteditor) oder den Gcc (Gnu C Compiler) ge-
schrieben hat. Durch die Verpflichtung auch abgeleitete Werke wiederum unter die
GPL zu stellen erreicht Stallman, dass GPL-Code nicht in proprietäre Programme in-
tegriert werden darf. Es sei denn das (ehemals) proprietäre Programm wird unter der
GPL lizenziert, und der Quellcode wird zugänglich gemacht. Die der GPL unterstellten
Werke werden also im Sinne des GNU-Manifests ,,geimpft", denn sobald auch nur eine
Zeile GPL-Code verwendet wird, muss das neu entstandene Werk ebenfalls unter der
GPL veröffentlicht werden.
Ferner werden bei Weitergabe eines abgeänderten Programms die in der GPL ge-
währten Verfügungsrechte aller Copyrightinhaber des Originalcodes auf den neuen
Nutzer übertragen (haben viele Entwickler an einem bestimmten Modul mitgearbeitet,
gibt es also viele Copyrightinhaber - die Verfügungsrechte des einzelnen Autors sind
also sehr verdünnt
32
). Hierdurch ist die GPL als ein Vertrag zu verstehen, der auch in
ferner Zukunft noch Gültigkeit hat, da ein Programm so lange durch das Copyright ge-
schützt ist, bis die copyrightrechtliche Schutzzeit des letzten überlebenden Originalau-
tors abgelaufen ist (Grassmuck, 2002, S.184). Durch die Weitergabe von abgeänder-
ten Programmen kann das Copyright also immer wieder erneuert werden und auf fol-
gende Generationen übertagen werden.
31
Verändert ein Nutzer ein GPL Programm und gibt dieses Programm nicht an Dritte weiter, so
ist er nicht gezwungen den abgeleiteten Quellcode unter der GPL zu veröffentlichen. Der
Zwang zur Veröffentlichung des Quellcode unter der GPL gilt also nur im Falle einer Weitergabe
der Software.
32
Sind an einem Open Source Projekt mehrere Entwickler beteiligt, so kann der einzelne Ent-
wickler nicht mehr alleine entscheiden wie er die Software verwenden will. Er hat zwar noch die
ausschließlichen Verfügungsrechte über seine Codezeilen inne, doch am neu entstandenen
Netzwerkprodukt hat er nur noch beschränktes Verfügungsrecht. Ihm werden an der gesamten
Software nur die Verfügungsrechte zu Teil, die jedem anderen Nutzer, der die OSD konforme
Lizenz akzeptiert, auch zustehen. Je mehr Entwickler sich also an einem Projekt beteiligen,
desto verdünnter werden die Verfügungsrechte jedes einzelnen Entwicklers an dem Netzwerk-
produkt.
21
Die GPL nutzt also den institutionellen rechtlichen Rahmen des Copyright, um die ihr
unterstellte Software im Sinne des GNU-Manifests zu schützen. Das in der Regel das
Nutzungsrecht beschränkende Copyright wird angewandt, um eine Art ,,Copyleft"
33
zu
erzeugen. Gleichzeitig gewährt die GPL allen Personen, die die Regelungen der GPL
akzeptieren, einen äußerst liberalen Umgang mit den Verfügungsrechten der
Originalautoren.
Es wird deutlich dass die Überschrift des von Stallman verfassten Textes ,,Why soft-
ware should not have owners" (Stallman, 1994) nicht ganz der Realität entspricht.
Denn auch freie Software hat Eigentümer, nämlich die Originalautoren, die ihre Nut-
zungsrechte aber großzügig und kostenlos an den Personenkreis weitergeben, der die
GPL akzeptiert.
Auf der anderen Seite werden die Beschränkungen der GPL von Vielen in Frage ge-
stellt. Diese kritisieren die GPL vor allem aufgrund des Abschnitts 2b. Sie sehen diesen
Abschnitt nicht als Impfung an, sondern argumentieren, dass die GPL einen viruellen
Charakter hat (Lee, 1999, S.34 ff; Hawkins, 2001, S.6 ff). Die GPL hat die Eigenschaft,
andere Software mit dem Virus GPL zu infizieren. Entwickler, die schon unter der GPL
existierende Programmteile nicht neu schreiben wollen, um Redundanzen zu vermei-
den, sind also gezwungen die von ihnen entwickelte Software unter die GPL zu stellen.
Die Entwickler sind durch die GPL in der Freiheit der Lizenzwahl beschränkt, da sie in
einem solchen Fall ja nur die GPL wählen können. Ferner haben viele Softwareprodu-
zenten Vorbehalte, GPL-Software auf ihren Rechnern laufen zu lassen, da die Mög-
lichkeit besteht, dass Mitarbeiter heimlich oder versehentlich GPL-Code in den Code
firmeneigener Software integrieren und dann die gesamten firmeneigenen
Nutzungsrechte dieser Software von der GPL assimiliert werden (MPL_FAQ, 1998).
Weiter wird kritisiert, dass die GPL aufgrund ihres viruellen Charakters mit allen
Lizenzen inkompatibel ist, außer mit sich selbst (Dalheimer, 1998).
4.2.3 Firmenlizenzen
Da erkannt wurde, dass der horizontale Basarentwicklungsstiel durchaus auch für Fir-
men interessant sein kann, entwickeln eine Vielzahl von Firmen in den letzten Jahren,
motiviert durch die Erfolge von GNU/Linux, Apache und anderen Open Source Projek-
33
,,copyleft (very simply stated) is the rule that when redistributing the program, you cannot add
restrictions to deny other people the central freedoms. This rule does not conflict with the cen-
tral freedoms; rather it protects them." (Stallman, 1996)
22
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2003
- ISBN (eBook)
- 9783832481964
- ISBN (Paperback)
- 9783838681962
- DOI
- 10.3239/9783832481964
- Dateigröße
- 981 KB
- Sprache
- Deutsch
- Institution / Hochschule
- Johann Wolfgang Goethe-Universität Frankfurt am Main – Gesellschaftswissenschaften, Arbeitslehre und politische Bildung
- Erscheinungsdatum
- 2004 (August)
- Note
- 1,3
- Schlagworte
- netzwerke koordinationsmechanismen property rights linux
