Inhaltsverzeichnis

Abk  ürzungsverzeichnis  IV

Tabellenverzeichnis VI   

Abbildungsverzeichnis   VII

1  Einleitung  1

1.1  Hintergrund und Fragestellung der Arbeit  1

1.2  Aufbau der Arbeit  5

2  Geschichte der Open Source Bewegung  6

2.1  Die Anfänge der Softwareentwicklung  6

2.2  Die Entstehung von Unix  15

2.3  Software wird zur Ware  17

2.4  Das GNU-Projekt  19

2.5  GNU/Linux  21

2.6  Freie Software vs. Open Source  24

2.7  Zusammenfassung  25

3  Zu den rechtlichen Aspekten von Freier Software  27

3.1  Die Entstehung geistigen Eigentums  28

3.2  Lizenzarten  31

3.3  Zusammenfassung  40

4  Organisation von Open Source Projekten  43

4.1  Kathedralen vs. Basare  43

4.2  Der Anfang eines Projektes  45

4.3  Frühes Projektstadium  46

4.4  Reifes Stadium  50

4.5  Der benevolente Diktator  55

4.6  Zeitmanagement  57

4.7  Zusammenfassung  60

II

Inhaltsverzeichnis

5  Motivation von Open Source Programmierern  61

5.1  Wer sind F/OSS-Programmierer?  63

5.2  Motivationsarten  68

5.3  Auswertung vorliegender Umfragen  69

5.4  Rückschlüsse aus den Umfrageergebnissen  81

6  Open Source Ökonomik  83

6.1  Das Modell der Kochtopfökonomie  83

6.2  Signaling als ökonomischer Anreiz für eine Teilnahme an F/OSS  86

6.3  Spieltheoretische Betrachtung der Lizenzierungsproblematik  93

6.4  Strategische Lizenzierung zur Sicherung von Innovationen  95

7  Schluss und Ausblick  98

A  General Public License  101

B  BSD License  109

Literaturverzeichnis   111

Internetquellen   116

III

Abkürzungsverzeichnis

Abs. Absatz ARPA Advanced Research Projects Agency AT&T American Telephone & Telegraph BCG Boston Consulting Group BGH Bundesgerichtshof BSD Berkeley Software Distribution CMU Carnegie-Mellon University DEC Digital Equipment Corporation EGCC Experimental/Enhanced GNU Compiler System F/OS Free/Open Source F/OSS Free/Open Source Software FLOSS Free Libre Open Source Software FSF Free Software Foundation FTP File Transfer Protocol FUD Fear, Uncertainty, and Doubt GCC GNU Compiler Collection GFDL GNU Free Documentation License GIMP Graphic Image Manipulation Program GNU GNU is Not Unix GPL General Public License GTK Gimp Tool Kit IBM International Business Machines KDE K Desktop Environment LGPL Lesser General Public License MIT Massachusetts Institute of Technology

IV

MPL Mozilla Public License NCSA National Center for Supercomputing Applications NPL Netscape Public License OEM Original Equipment Manufacturer OS Open Source OSI Open Source Initiative P/GSS Proprietär/Gated Source Software PC Personal Computer PDP Programmed Data Processor RFC Request for Comments SAIL Stanford University’s Artificial Intelligence Laboratory TCP/IP Transmission Control Protcol / Internet Protocol UrhG Urheberrechtsgesetz WWW World Wide Web

V

Tabellenverzeichnis

3.1 Überblick Lizenzarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Status der Programmierer . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2 Mittleres Alter von F/OSS-Entwicklern . . . . . . . . . . . . . . . . . . . 64 5.3 Beschäftigungsstatus von F/OSS-Programmierern . . . . . . . . . . . . . . 65 5.4 Wöchentlicher Zeitaufwand von F/OSS-Programmierern . . . . . . . . . . 66 5.5 Arbeitsort von F/OSS-Entwicklern . . . . . . . . . . . . . . . . . . . . . . 67 5.6 Motivation von Programmierern bei Hars/Ou . . . . . . . . . . . . . . . . 70 5.7 Motivation von Programmierern bei Lakhani/Wolf . . . . . . . . . . . . . . 72 5.8 Motivation F/OSS-Entwickler FLOSS-EU und FLOSS-JP . . . . . . . . . 76 5.9 Motivation F/OSS-Entwickler FLOSS-US . . . . . . . . . . . . . . . . . . 77 5.10 Motivation eine Usenetgruppe zu lesen. . . . . . . . . . . . . . . . . . . . 79 5.11 Motivation Hilfestellung in Usenetgruppe zu leisten. . . . . . . . . . . . . 80

VI

Abbildungsverzeichnis   

2.1  Größe der komprimierten Kernelarchive in MByte  23

4.1  Erwartungen an einen Projektmaintainer  56

VII

1 Einleitung

1.1 Hintergrund und Fragestellung der Arbeit

Die Frage der Ressourcenallokation ist ein Problem, vor dem jedes ökonomische System steht und die für komplexe, marktbasierte Ökonomien mit Signalisierung über Preise ausreichend beantwortet werden kann. ¹ In den letzten Jahren hat sich aber in einem Bereich, der den modernsten Teil der heutigen industriellen Produktion, die Softwareindustrie, berührt, ein System der Kooperation etabliert, welches vollständig ohne Preissignale zu funktionieren scheint. Gleichzeitig erweckt dieses System den Anschein, sich außerhalb des Spannungsfeldes zwischen Markt und Staat zu bewegen. Gemeint ist hier die Open Source ² Bewegung, in welcher sich Programmierer vermittels internetbasierter Kommunikation organisieren, um Software herzustellen, was in der Freigabe der Software als öffentlichem Gut ³ resultiert. Der Ökonomischen Theorie ⁴ zufolge, müsste dieses Gut unter einem Trittbrettfahrerproblem und Mitnahmeeffekten leiden. Vorstellbar ist hier zum einen, dass es kaum Beitragende gibt; jeder nur Nutzer sein will und es somit auf längere Sicht einen Still-stand in der Entwicklung gibt. Zum anderen legt individuell rationales Verhalten nahe, dass sich Individuen oder Firmen besser stellen, indem sie das kollektive Gut nehmen, es privatisieren, dann mit geringerem Aufwand erweitern und verkaufen. Jedoch ist das System F/OSS seit etwa 20 Jahren stabil und stärker denn je, wie nachfolgend zu zeigen sein wird. Sonach ist eine Fragestellung dieser Arbeit: Durch welche ”Verfassung” ⁵ wird verhindert, dass die neue ”Wissensallmende” ⁶ das Trittbrettfahrerproblem umgeht und nicht aufs neue ”tragisch” ⁷ endet?

¹ Vgl. [Hayek].

² Freie Software und Open Source Software (→ F/OSS) werden in dieser Arbeit als synonyme Begriffe verwendet. Das Antonym bildet proprietäre/Gated Source Software, genauer dazu in Kapitel 2.

³ Niemand ist ausschließbar und es existiert keine Rivalität im Konsum.

⁴ Vgl. [Olson] u. [Ostrom].

⁵ Vgl. [Ostrom]

⁶ Vgl. [Grassmuck]

⁷ Vgl. [Hardin]

1

Weiterhin soll nachgewiesen werden, dass bei Nichtberücksichtigung der Entstehungsgeschichte und damit der Überzeugungen der Protagonisten, die letztendlich institutionell verankert wurden, eine Beurteilung der Motivation der Teilnehmer, die auf Reduktion von In-formationsasymmetrien in der Principal-Agent-Theorie beruht, ungenügend sein muss. ⁸ Des Weiteren soll dargelegt werden, dass die F/OSS-Bewegung in einem breiteren Kontext der ”Kulturkämpfe im digitalen Kapitalismus” ⁹ um eine neue Wissensordnung, ¹⁰ aber auch eine neue Form der Organisation von Arbeit ¹¹ zu sehen ist. Wodurch auch verdeutlicht werden soll, dass Rationalitätspostulate die sich an einem strikt materiellen ”homo oeconomicus” orientieren, in einem Umfeld, das sehr stark ideologisch geprägt ist, als unzureichend erweisen müssen. Der Nachweis wird nicht nur unter Verwendung von Elementen der Neuen Institutionenökonomik, der neoklassischen Theorie, sowie der Spieltheorie geführt. Überdies werden vor allem auch Rückgriffe auf soziologische und psychologische Theorien genommen, um dem Anspruch, ein möglichst umfassendes Bild der Erscheinung Freie / Open Source Software zu geben, gerecht werden zu können. Aufgrund dessen versteht sich diese Arbeit als interdisziplinär.

1.1.1 Was ist so ungewöhnlich an F/OSS?

Für den Einstieg in das Verständnis von der Neuartigkeit von Open - Source Software bietet sich ein Gleichnis an. ¹² Die Firma Coca - Cola ist bekannt für den Verkauf von Limonade. Der Verbraucher kann dieses Erfrischungsgetränk käuflich erwerben und dem Etikett die Zutaten entnehmen. Jedoch bieten ihm die Angaben auf dem Etikett nicht die Möglichkeit, das Getränk genau zu reproduzieren. Dazu fehlt ihm das Wissen um die genaue Zusammensetzung und ebenso das Wissen um geheime Zutaten. Wäre dies nicht so, könnte jeder ein Nachahmerprodukt auf den Markt bringen, welches identisch mit dem Original ist und der vordem existierende Wettbewerbsvorteil wäre dahin. Hierüber ist jedem zugänglich, wieso Coca - Cola alles daran setzen wird, das Rezept dieses Getränks geheim zu halten. Analog zu diesem Beispiel verhält es sich in der Welt der Software. Die Firma Microsoft verkauft unter anderem das Betriebssystem Windows. Der Käufer kann dieses in seiner binären Version benutzen - meist nur auf einem Rechner-, jedoch ist es ihm untersagt, dieses zu kopieren,

⁸ Vgl. hierzu [Akerlof], [Spence] und [North] S.35ff

⁹ Hier ist der Umgang mit Wissen allgemein gemeint. Vgl. [Glotz] und auch [Gorz]

¹⁰ Vgl. [Spinner]

¹¹ Vgl. [Himanen]

¹² Vgl. [Weber2004] S.3f

2

zu verändern oder gar seine eigene veränderte Version zu vertreiben. Damit dies nicht geschehen kann, wird von Microsoft ebenfalls das ”Rezept” für die Software geheimgehalten. Dies ist der Quellcode, also der Bauplan der Software.

Im Unterschied dazu wird bei Open Source Software der Bauplan mitgeliefert. Es wird sogar dazu aufgefordert, diesen zu verändern, zu verbessern; der Vertrieb von eigenen Versionen ist zulässig.

Das Argument zur Sicherung des ”Rezeptes” ist, dass der Inventor für seine Tat einen Anreiz - eine Gewinnaussicht - benötigt, der den Aufwand, die investierte Zeit und sein Wissen, rechtfertigt. Mittels Geheimhaltung, Patentierung, Copyright/Urheberschaft ¹³ lassen sichim Erfolgsfalle - Gewinne realisieren, welche die vorherigen Ausgaben wenigstens kompensieren sollen. Besteht keine Erwartung auf diesen Fall, so die gängige Theorie, existiert kein oder nur ein verminderter Anreiz dazu, die Kosten für eine neue Erfindung auf sich zu nehmen. Innovationen werden demzufolge nur realisiert, wenn es einen finanziellen Anreiz gibt. ¹⁴ Demgegenüber stehen die Programmierer in der Open Source Bewegung. ¹⁵ Diese geben nicht nur ihre Rezepte frei, sondern erlauben auch noch diese unter genau spezifizierten Bedingungen zu verändern und zu verkaufen.

Die Tatsache wäre ignorierbar, wenn Open Source Software heute nicht von jedem Internetnutzer direkt oder indirekt genutzt würde, denn sie stellt die Infrastruktur des Internet sicher. So beläuft sich der Marktanteil des Webserverprogrammes Apache inzwischen auf fast 70%. Folglich basieren 70% des WWW, dem bekanntesten Teil des Internets, auf einer Open Source Software. ¹⁶ Mehr als 50% der Mailserver im Internet werden mit Open Source Software wie Sendmail, Postfix oder Exim betrieben. ¹⁷ Nameserver, Computer die als Mittler zwischen den Internetadressen und deren Übersetzung in numerische IP Adressen fungieren, werden zu ca. 70% mit dem Programm BIND betrieben. ¹⁸ Der Webbrowser Mozilla Firefox - aus der Offenlegung des Netscape Quellcodes hervorgegangen - tritt als einziger ernsthafter Gegner für den Internet Explorer der Firma Microsoft an. Er hat diese sogar zu einer Vorverlegung des Veröffentlichungstermines der neuen Version veranlasst

¹³ Vgl. hierzu Kapitel 3.1.2.1 auf S. 29

¹⁴ In der klassischen Theorie wird mit Erfindung und Ansporn argumentiert. Vgl. [ Machlup] Kapitel IIB

¹⁵ Und nicht nur diese, da wohl schlecht behauptet werden kann, dass vor der Einführung von Geheimhaltungsprozeduren, den Instrumenten der Patentierung, des Copyrights bzw. der Urheberschaft, dass es zu dieser Zeit keine menschliche Entwicklung oder gar das völlige Fehlen von Innovationen gab.

¹⁶ Vgl. [Heise2005b].

¹⁷ Vgl. [Mailserver2000], [Mailserver2003], [Mailserver2004]

¹⁸ Vgl. [DNS-Serversurvey2004]

3

und besitzt momentan einen Marktanteil zwischen 5 und 10%. ¹⁹ Außerhalb des Bereiches reiner Internetsoftware tritt das Officepaket OpenOffice an, welches aus der Offenlegung des Quellcodes von SUN’s StarOffice entstanden ist. Es findet auf immer mehr Desktopsystemen Anwendung, nicht zuletzt durch die verstärkte Übernahme von freier Software in Stellen öffentlicher Verwaltung. 20

Zusätzlich fungiert das freie Betriebssystem Linux in immer mehr mobilen Geräten als Mittler zwischen Benutzeroberfläche und Hardware, so in den Mobiltelefonen von Samsung und Motorola, genauso wie in Geräten von Nokia. 21

F/OSS ist demnach nicht mehr aus der Welt der Software wegzudenken und hat sich einen Platz nicht nur im öffentlichen Bewusstsein erkämpft. Wenn mehr als 50% der strukturrelevanten Software für das Funktionieren des Internet auf F/OSS basieren und in dem Wissen, das die heutige Ökonomie ohne Internetkommunikation praktisch nicht mehr denkbar ist, lässt sich ausmalen, was ein plötzlicher Wegfall dieser Softwarebasis für Auswirkungen hätte.

Dies findet statt in einer Zeit, in welcher der Beginn der als solchen klassifizierten Wissensgesellschaft postuliert wird und in der Wissen die wichtigste Ressource zur Produktion darstellen soll. ²² Wissen ist in diesem Zusammenhang definiert als:

”... Sammlung in sich geordneter Aussagen über Fakten oder Ideen, die ein vernünftiges Urteil oder ein experimentelles Ergebnis zum Ausdruck bringen und anderen durch irgendein Kommunikationsmedium in systematischer Form übermittelt werden ...” 23

Dementsprechend kann Software in ihrer reinen Form des Quellcodes als Form von Wissen aufgefasst werden und muss somit, wenn wir der obigen Diktion folgen, als wichtige Ressource verstanden werden. Genau in dem Augenblick, in dem diese Ressource so wichtig zu werden scheint, verfolgen die Produzenten dieses Wissens eine Strategie der völligen Freigabe dieser Ressource, was auf den ersten Blick ökonomisch wenig rational erscheint. Daraus ergibt sich eine weitere Fragestellung dieser Arbeit: Inwiefern ist diese Handlung ökonomisch rational und welche Motive liegen dem Verhalten zu Grunde?

¹⁹ Vgl. [Heise2005c].

²⁰ Die Fälle Schwäbisch Hall und München sind die bekanntesten in Deutschland. Vgl. [ Bräuner], [Kharitoniouk/Stewin] u. [Sturm].

²¹ Vgl. [Heise2004a], [Heise2005f] und [Heise2005d]

²² Vgl. [Bell] S.32ff, [Spinner] S. 72ff, [Castells2001b] S.100f u. allgemein [Drucker]

²³ Vgl. [Bell] S. 180

4

Diese Arbeit liefert jedoch keinen Überblick zu den Geschäftsmodellen von F/OSS und auch nicht zu den Entwicklungen auf dem Softwaremarkt, beispielsweise das Quasi-Monopol von Microsoft im Desktopbereich betreffend. Diese Punkte können zwar nicht ganz ausgeblendet werden und tauchen in den nachfolgenden Betrachtungen am Rande auf, stellen jedoch keine der Hauptthemen dar. Des Weiteren kann hier nur eine ungenügende Sicht auf die makroökonomischen Implikationen, ausgelöst mit und durch F/OSS gegeben werden. Die Auswirkungen auf die gesamtgesellschaftliche Wohlfahrt sind nicht vollständig ausblendbar, allein kann dieser Punkt hier ebenfalls nur unzureichend berücksichtigt werden.

1.2 Aufbau der Arbeit

Das erste Kapitel widmet sich einer Skizzierung der Entstehung von F/OSS aus der Kultur der Hacker und der Akademie heraus. Besondere Berücksichtung finden dabei die institutionellen Rahmenbedingungen, wie die in dieser Zeit existierenden Monopole, sowie die technischen und rechtlichen Möglichkeiten, die in erheblichem Maße das Verhalten der damaligen - und nicht nur dieser - Protagonisten determinierten. Die Darstellung konzentriert sich vornehmlich auf den US-amerikanischen Raum, da von dort die wesentlichen Beiträge zur Entwicklung von F/OSS erfolgten. Im zweiten Kapitel werden die rechtlichen Institutionen, welche die F/OSS-Programmierer vorfanden, einer Analyse unterzogen. Darauf aufbauend wird ihr neues Verhältnis gegenüber geistigem Eigentum aus den Lizenzen heraus entwickelt. Das Bild von F/OSS soll folglich, ähnlich wie bei North ²⁴ , aus der Entstehungsgeschichte und den daraus resultierenden Institutionen entfaltet werden. Daran schließt sich die Schilderung des Entstehungsprozesses von F/OSS-Produkten anhand der Besonderheiten der Organisation an.

Diesem Kapitel folgt eine eingehendere Untersuchung der Motivationen von F/OSS-Entwicklern. Daran anschließend werden im letzten Kapitel die bis dahin erarbeiteten Erkenntnisse dazu benutzt, bisher vorliegende Arbeiten von Ökonomenseite - welche den Versuch unternahmen das F/OSS-Phänomenon mit ökonomischen Modellen zu erfassen - zu bewerten und eventuell existierenden Forschungsbedarf aufzuzeigen.

²⁴ Vgl. [North].

5

2 Geschichte der Open Source

Bewegung

2.1 Die Anfänge der Softwareentwicklung

Software ¹ etablierte sich erst in einem langwierigen Prozess als eigenständige Ware. Die in den Anfangszeiten der Computerindustrie übliche Praxis bestand darin, einen Computer zu verkaufen und zu diesem, neben Service für die Hardware, noch einen Grundstock an Software, gewissermaßen als Betriebsanleitung, mitzuliefern. ² Diese Verfahrensweise hielt sich bis zum Jahre 1969. Damals begann IBM, als der größte und dominierende Computerhersteller, ³ damit, Software und Hardware extra auszuliefern. ⁴ Was in der Firmengeschichte unter ”new marketing policy” firmiert, ist wohl eher auf das in diesem Jahr eingeleitete Kartellverfahren gegen IBM zurückzuführen, was auf eine Zerschlagung hinauszulaufen drohte. ⁵ Dieses ”unbundling” berührte jedoch nicht die bereits existierenden Programme und die zu dieser Zeit übliche Praxis des offen verfügbaren Quellcodes. Die recht überschaubare Anzahl von Computernutzern, die vornehmlich an Forschungseinrichtungen und Universitäten vorhanden waren, ließ eine Kultur entstehen, die auf freier Verfügbarkeit von Software und offenen Zugang zum Quellcode ⁶ basierte. Mit der Aufgabe der Praxis des Bundling seitens

¹ Unter Software werden alle nicht zur physischen Hardware gehörenden Bestandteile eines Computersystems verstanden, die zu dessen Funktion notwendig sind. Im weiteren Sinne zählen auch gedruckte Handbücher dazu.

² Vgl. [Grassmuck] S. 202.

³ 70% des damaligen Marktes wurden von IBM bedient. Ebenda S. 203.

⁴ Vgl. [IBM].

⁵ Vgl. [Grassmuck] S. 203.

⁶ Software kann in zwei Formen erscheinen, einmal als binäre ausführbare Programmversion, im so genannten Objektcode und zum anderen in der Form des Quelltextes, dem so genannten Sourcecode, der in gewissem Sinne eine Art Bauanleitung darstellt. An sich stellt er keine Funktionen zur Verfügung, ist also für den reinen Anwender nutzlos. Jedoch kann der versierte Nutzer diesen in eine ausführbare Version übersetzen lassen und zudem, mit genügend technischem Wissen, Erweiterungen vornehmen oder auch Fehler finden und bereinigen.

6

IBM wurde die Voraussetzung für Software als Ware und eine darauf aufbauende Softwareindustrie geschaffen. Firmen wie Microsoft, Oracle und SAP bekamen auf der Grundlage dieser Entscheidung heraus eine Basis zur Entwicklung ihres Geschäftsmodells. Diese Praxis gegenüber stand die bis zu diesem Zeitpunkt vorherrschende Programmierkultur, auf die im Folgenden eingegangen wird.

2.1.1 Die Kultur der Hacker

Bis in die 70er Jahre hinein dominierte an den Universitäten und Forschungseinrichtungen in den USA, wie dem Tech Model Railroad Club am MIT und den AT&T Bell Laboratories eine Kultur des freien Austausches von Wissen und der konstruktiven Kooperation. ⁷ Das sich die Kultur der Hacker ⁸ gerade auf diesen Prinzipien gründet ist kein Produkt des Zufalls. Förderlich dafür waren zum einen die akademischen Traditionen zum anderen die Restriktionen denen die Computernutzer in den Anfängen der Arbeit mit Computern unterlagen. Die Nutzung von Computern, die Ende der 50er Jahre und noch Anfang der 60er Jahre ganze Zimmer in Beschlag nahmen, war in den Anfängen abhängig vom Wohlwollen des Systemadministrators, denn nur dieser hatte direkten Zugang zu Computern und hatte die Rolle des Vermittlers zwischen Computer und Programmierer inne. Dies führte zu ständigen Spannungen zwischen Programmierern und Systemverwaltern den Zugang zu den Computerkapazitäten betreffend und resultierte in einem allgemeinen Misstrauen von Programmierern gegenüber Autoritäten. ⁹ Die technische Ursache für diesen Konflikt lag in der Konstruktion der Großrechner von IBM, die nur eine Stapelverarbeitung von Programmen zuließ und spätestens 1959 mit der Einführung des TX-0, einer Eigenentwicklung der Lincoln Laboratories am MIT, ¹⁰ und dessen Weiterentwicklung zum PDP-1 1961 ¹¹ unter den

⁷ Vgl. [Levy] u. [Raymond1999a] S. 20.

⁸ Der Begriff "Hacker"wurde in den 50er-Jahren im Tech Model Railroad Club am MIT geprägt und stand für eine Person, die etwas nicht unbedingt sinnvoll, obsessiv mit voller Leidenschaft tat. Vgl. [ Levy] S. 18f. Im ”Jargon File” einer Selbstbeschreibung von Begriffen der Hackerkultur steht der Begriff Hacker für eine Person, die einerseits obsessiv programmiert oder ein besonderes Interesse zeigt an der Erforschung der Möglichkeiten programmierbarer Systeme und der Erweiterung dieser. Andererseits wird von dem Begriff jegliche Person erfasst, die etwas mit Leidenschaft betreibt, erforscht versucht die Grenzen zu erweitern. Also durchaus ein Begriff der auch außerhalb von Softwareproduktion Sinn macht. Der Terminus Hacker wird hier im weiteren Verlauf in strenger Abgrenzung zum Ausdruck Cracker verwendet, der eine Person bezeichnet, die destruktiv ihr Computerwissen anwendet. Im allgemeinen Sprachgebrauch werden diese Begriffe inzwischen synonym verwendet, was jedoch von der Sache her falsch ist. Vgl. hierzu [ Jargon].

⁹ [Levy] S. 34

¹⁰ Ebenda S. 22.

¹¹ Vgl. [Raymond1999a] S. 20, die Vermarktung und Weiterentwicklung übernahm die Firma DEC.

7

Hackern als überholt galten. Diese Geräte gestatteten erstmals einen direkten und zudem interaktiven ¹² Zugang zu Computern. Nicht zuletzt deswegen genoss IBM in diesen Tagen unter den Hackern den Ruf eines bürokratischen, zentralistischen, schwerfälligen Riesens und wurde zum ersten Gegner der neuentstehenden Hackerkultur. ¹³ Später bekam AT&T die zweifelhafte Ehre als Gegner für Hacker zu dienen ¹⁴ und diese Rolle wird heute perfekt von Microsoft eingenommen. Diesen Unternehmen ist gleich, dass sie zu einer bestimmten Zeit ein Monopol ¹⁵ eingenommen haben und zudem noch als zentralistisch bzw. geschlossen gelten/galten, was für ”wahre Programmierer” ¹⁶ ablehnenswert ist. Die Erfahrungen mit Systemverwaltern und deren Notwendigkeit aus der Systemarchitektur heraus führten zur Formulierung folgenden Grundsatzes, der in die so genannte Hackerethik ¹⁷ mit einfloss:

”Mistrust Authority Promote Decentralization.” 18

Diese erwähnte Hackerethik stellt kein verbindliches Gesetzeswerk dar, ist niemals verkündet oder in einem Manifest niedergeschrieben worden, sondern enthält Konventionen ¹⁹ , denen stillschweigend zugestimmt werden konnte. ²⁰ Eine Form der Entscheidungsfindung, die sich bis heute erhalten hat und als ”Konsens-Demokratie” ²¹ bezeichnet werden kann. Im Kapitel 4 ab Seite 43 zur Organisation von Open Source Projekten wird noch einmal darauf zurückzukommen sein.

Computersysteme damaliger Herstellung wurden mit einer rudimentären Ausstattung an Software ausgeliefert, so dass Benutzer sich ihre Programme in der Regel selbst schreiben mussten und demzufolge zwangsläufig auch Programmierkenntnisse erwerben mussten. Die knapp bemessene Zeit ²² führte dazu, dass es einen regen Informationsaustausch zwischen den Programmierern gab. Grundsätzlich waren alle Teilnehmer daran interessiert, ihren eigentlichen Aufgabenstellungen nachzugehen und nicht jedes mal das Rad neu zu erfinden. 23

¹² Programme konnten eingegeben, gestartet und sofort korrigiert werden.

¹³ Ebenda S. 34.

¹⁴ Vgl. [Raymond1999a] S. 24.

¹⁵ IBM - Großrechner, AT&T - geschlossene Unixsysteme, Microsoft - Windows.

¹⁶ Vgl. [Raymond1999a]

¹⁷ Vgl. [Levy] S. 32ff.

¹⁸ Ebenda S. 34.

¹⁹ ”Dies sind Regeln, die nie bewusst formuliert wurden und die beizubehalten in jedermanns Interesse ist.” Vgl. Sugden zitiert nach [North] S. 49.

²⁰ Ebenda S. 32. Steven Levy extrahierte in seinem 1984 über die Hackerkultur geschriebenem Buch, diese Hackerethik in erster Linie aus dem Verhalten und den Aussagen der Protagonisten dieser Gruppe.

²¹ Vgl. [Merten].

²² Trotz der Fortschritte in Richtung interaktive Computernutzung, waren Computerplätze weiterhin rar und mussten zwischen den Interessenten geteilt werden.

²³ Vgl. [Levy] S. 33.

8

Aufgrund dessen konnten Quellcodes frei eingesehen werden, wodurch wiederum jeder in die Lage versetzt wurde, diese zu benutzen, zu verbessern und an seine Zwecke anzupassen. Es sollte jederzeit für jeden möglich sein, die bestmögliche Version zu nutzen und darauf aufzubauen. Auf diesem Verhalten gründete der Leitsatz:

”All information should be free.” 24

Ein weiterer Grundsatz der sich entwickelnden Hackerkultur war, dass Menschen nur nach ihren Leistungen als Programmierer, d.h. der Güte ihrer Programme zu beurteilen waren. Dies verlangte ebenfalls den Einblick in den Quellcode von Programmen, um eine wirklich objektive Beurteilung der Qualifikation eines Teilnehmers zu erreichen. Gern wird das Beispiel des 12 - jährigen Peter Deutsch zitiert, der bereits zu der Gruppe der TX-0 Hacker gehörte. Die Bewertung eines Programmes richtete sich in erster Linie an der Zielsetzung aus, also daran, ob es seinen Zweck erfüllt oder nicht. Erst danach folgte eine Beurteilung der Effizienz. ²⁵ Diese Einstellung lässt sich in diesem Leitsatz zusammenfassen :

”Hackers should be judged by their hacking, not bogus criteria such as degrees, age, race, or position.” 26

Des Weiteren bewerteten die Mitglieder des TMRC die Schönheit eines Programmes oder besser den Stil der Programmierung. Hier erfolgte demnach die Bewertung eines Codes nach Effizienzkriterien. Macht das Programm was es soll auf die beste Art und Weise? Dies ist begründet in den begrenzten Speicherressourcen der damaligen Hardware. Je weniger Platz ein Prozess einnahm, um so mehr konnte anderen zur gleichen Zeit ablaufenden Prozessen zur Verfügung gestellt werden. In Verbindung mit der knapp bemessenen Zeit die jeder Computernutzer zur Verfügung hatte, stellte diese Art und Weise der Programmierung einen logischen Schritt dar. Dieses Bemühen um die möglichst effiziente Nutzung der Hardware brachte die Hacker des Clubs regelmäßig in Programmierwettbewerbe auf der Suche nach der besten Lösung. ²⁷ Programmierer sind an und für sich davon überzeugt, dass es gute und schlechte Programme gibt und demzufolge sind sie immer auf der Suche nach

²⁴ Ebenda.

²⁵ Vgl. [Weinberg] S. 17f.

²⁶ Ebenda S. 35.

²⁷ Vgl. [Levy] S. 36f. Er beschreibt hier den Eifer der Clubmitglieder, bei der Suche nach einer Programmroutine, von unter 50 Standardzeilen, für die Umwandlung von Binär- in Dezimalzahlen. Letztendlich gelang diese Übung, obwohl es viele für unmöglich hielten.

9

dem guten Programm, dem guten Code. ²⁸ Dies entspricht ihrer Definition von Ästhetik, d.h. ein funktionierendes, effizientes Programm ist schön. ²⁹ Jedoch ist die Definition eines guten Programmes immer abhängig vom Zeitpunkt der Veröffentlichung der Funktionalität und der Adaptierbarkeit. Demnach unterliegt die Bewertung eines Programmes ständiger Veränderung, d.h. per se ist Software kein Produkt, sondern ein Prozess. ³⁰ Programmierung stellt nach Weinberg eine Art von Schreiben dar. Ist also eine kreative Tätigkeit und ein Spiel mit der Sprache. ³¹ Mit Huizingas Auffassung der Dichtkunst als Spiel mit der Sprache ³² kann die Kunst des Programmierens mit der Dichtkunst wenn nicht gleich gesetzt, so doch wenigstens verglichen werden. Spiel ist nach Huizinga immer verbunden mit Harmonie und Schönheit, ³³ Werte, die auch unter Hackern bei der Programmerstellung gelten. Diese Ansichten kulminieren in dem Leitgedanken:

”You can create art and beauty on a computer.” 34

Die Faszination, die für die Hacker von Computern ausging, erschöpfte sich nicht allein in der Programmierästhetik und im Spielen, sondern es bestand die Möglichkeit, etwas zu erschaffen: Eine eigene Welt nach einem eigenen Plan ³⁵ und in dieser Welt gelöste Probleme waren für immer gelöst. Diese Eigenschaft führte dazu, dass Programmierer Computer als eine Art Abenteuer und als eine Bereicherung ihres Lebens auffassten, somit ihr Leben eine Änderung erfuhr. Demzufolge glaubten sie an die Fähigkeit der Technik, nicht nur ihre Welt zu verändern, sondern die eines jeden Menschen. Im weiteren Sinne entstand daraus eine Art von Technikgläubigkeit bzw. dies stellt die Fortsetzung einer Überhöhung von Eigenschaften von Technik dar, welche Probleme nicht nur in ihrer eigenen Welt lösen kann. Anschließend an diesen Gedanken existierte in der Hackercommunity der Glaube, dass nicht nur sie, sondern ein jeder von den neuen, durch die von Rechenmaschinen vermittelten Möglichkeiten profitieren konnte. Es bestand folglich das Bestreben, möglichst

²⁸ Bei [Levy] S. 60ff heißt es, die Programmierer waren immer auf der Suche nach ”...the Right Thing.” und ”The Right Thing implied that to any problem, whether a programming dilemma, a hardware interface mismatch, or a question of software architecture, a solution existed that was just ... it. The perfect algorithm.” S. 65

²⁹ Vgl. [Weinberg] S. 16.

³⁰ Ebenda S. 15ff und [Brooks] S. 184.

³¹ In vielen Veröffentlichungen über die Tätigkeit des Programmierens ist vom "Herumspielen"die Rede. Vgl. [Torvalds] S.14, 47, 51 und S.81ff usw., [Levy] S.14, 18, 26, 47, 67 usw. [Raymond1997a] oder [Himanen] S. 22ff.

³² Vgl. [Huizinga] S. 12.

³³ Ebenda S. 13ff.

³⁴ Vgl. [Levy] S. 35f.

³⁵ Ebenda S. 60

10

viele nützliche Dinge - im engeren Sinne Programme - zu erstellen und die Öffentlichkeit davon profitieren zu lassen. Beispielsweise entstand so die erste Taschenrechneremulation, einzig und allein aus dem Beweggrund, dass niemand weiterhin unnötig Zeit mit der Benutzung des Abakus für die Lösung komplexer numerischer Probleme verlieren sollte. Wenn es doch die Möglichkeit gab, einen Automaten dafür zu benutzen, der die gleiche Aufgabe schneller und genauer ausführen konnte. ³⁶ In der Hackerethik heißt es dazu:

”Computers can change your life for the better. Like Aladdin’s lamp, you could get it to do your bidding.” 37

Die bis hier dargestellte Ethik der Hacker bildet den Schlüssel für ein adäquates Verständnis des Phänomenes Open Source, dessen Organisationsformen und die Motivation der Protagonisten. In den zugehörigen Kapiteln wird darauf zurückzukommen sein. Vorher gilt es jedoch, die Bezüge zu den Normen der Wissenschaftler herzustellen, auf deren Grundlage sich die Hackerkultur entwickelt hat.

2.1.2 Parallelen zwischen den Ethiken der Hacker und der

Wissenschaftler

Die Prinzipien, nach denen sich die Hackercommunity - vor allen Dingen am MIT - organisierte, sind nicht allein auf die Restriktionen oder auch Möglichkeiten der damaligen Computertechnik zurückzuführen, sondern auch auf das Umfeld, in dem die Entwickler sozialisiert wurden bzw. sich bewegten. Die Rede ist von dem akademischen Umfeld, denn die meisten der Clubmitglieder waren gleichzeitig Studenten der Physik oder Mathematik und hatten zu der gleichen Zeit, in der sie sich im TMRC aufhielten, noch Studienleistungen in ihrem Fachbereich zu absolvieren. Somit waren ihnen die Prinzipien, nach denen die Wissenschaft agierte und heute noch agiert nicht unbekannt und die im Folgenden aufgeführten Parallelen können nicht dem Zufall zugeschrieben werden. ³⁸ Die umfassendste Darstellung des Ethos der Wissenschaften findet sich wohl bei Merton ³⁹ auf die ich mich im Folgenden weitestgehend beziehen werde.

³⁶ Ebenda S. 38ff

³⁷ Ebenda S. 37f.

³⁸ Vgl. [Grassmuck] S. 46ff, [Merton1980] u. [Himanen] S. 86ff

³⁹ Vgl. [Merton1985] S. 90ff

11

Merton arbeitete vier Prinzipien heraus, nach denen sich die Gemeinschaft ⁴⁰ der Wissenschaftler organisiert.

• Universalismus

• Wissenschaftskommunismus

• Uneigennützigkeit

• Organisierter Skeptizismus

Diese vier Prinzipien werden nachfolgend in Verbindung zu den Grundsätzen der Hackerkultur gesetzt.

2.1.2.1 Universalismus

Das Prinzip des Universalismus in der Wissenschaft besagt, dass Ergebnisse oder besser deren Beurteilung in keiner Weise von Ideologien abhängig sein sollen. Somit darf die Herkunft, das Alter, das Geschlecht oder der Glauben einer veröffentlichenden Person die Wertung der Arbeit nicht beeinflussen. Bei den Hackern des MIT firmierten diese Attribute unter dem Namen ”bogus criteria”, also nicht relevante, irreführende Charakteristika sollten ebenfalls nicht zur Beurteilung einer Programmierleistung herangezogen werden.

2.1.2.2 Wissenschaftskommunismus

Dies ist wohl die am kontroversesten rezipierte Eigenschaft des wissenschaftlichen Ethos, aufgrund des von Merton bewusst provokativ ⁴¹ gewählten Begriffes Kommunismus. In diesem Zusammenhang wird darunter verstanden, dass alle Erkenntnisse wissenschaftlicher Arbeit wieder an die Gemeinschaft zurückgegeben werden müssen und niemand innerhalb der Gemeinschaft besondere Nutzungs- oder Verfügungsrechte am Wissen besitzen kann.

⁴⁰ Nach Bell, vgl. [Bell] S. 282, stellt die Gruppe der Wissenschaftler eine Gemeinschaft mit Gesellschaftselementen dar, wobei hier Gemeinschaft meint: ”... primäre durch enge Bande zusammengehaltene Gruppe, die sich mittels Tradition und gemeinsamer Ansichten selber lenkt ...”. Demgegenüber wird hier unter Gesellschaft ein ”...großer, unpersönlicher Verband sekundärer Vereinigungen, der durch bürokratische Vorschriften gelenkt und durch Ausschlussandrohung zusammengehalten wird...” verstanden. Die Gemeinde der Wissenschaft stellt nach ihm eine Gemeinschaft mit gesellschaftlichen Elementen dar, die in einem Spannungsfeld zwischen Uneigennützigkeit und Nützlichkeitsdenken, im engeren Sinne Profitabilität, agiert. Nachfolgend soll bei der Verwendung des Begriffes Gemeinschaft/Community eine Gemeinschaft mit Nützlichkeitselementen verstanden werden.

⁴¹ Vgl. [Grassmuck] S. 10.

12

Insistiert werden muss hierbei auf dem Begriff des Teilens von Wissen. Demnach gibt es keinen Tausch von Wissen in dem Sinne, als dass hierbei ein Wertäquivalent bei der Nutzung bzw. Weitergabe von vorhandenem Wissen zum Einsatz kommt. Jeder Teilnehmende kann unabhängig davon, ob er etwas zum Wissenspool beiträgt, vom vorhandenem Wis-sensstand profitieren. Genau dort liegt das, was Merton mit Kommunismus meinte: Jeder gibt nach seinen Fähigkeiten, jeder kann nehmen nach seinen Bedürfnissen. ⁴² Der Begabte gibt und kann nehmen, der Unbegabte wird trotzdem nicht ausgeschlossen und kann ebenfalls nehmen, unterliegt gleichzeitig nicht dem Zwange etwas zurückgeben zu müssen. Demzufolge kann in diesem Sinnzusammenhang nur bedingt von Wechselseitigkeit, also Reziprozität, gesprochen werden, da ein Wechselspiel zwischen Gebenden und Nehmenden nicht unbedingt erforderlich ist. Zu beachten bleibt hierbei jedoch, dass derjenige, welcher neue Erkenntnisse veröffentlicht, damit rechnen kann, Anerkennung und Ansehen zu gewinnen. Dies kann durchaus auch materielle Vorteile nach sich ziehen. Somit findet eine ”konkurrenzorientierte Kooperation” ⁴³ um Prestigepunkte statt, deren Ergebnisse dagegen ins Gemeineigentum übergehen. Da nur die Veröffentlichung garantiert, dass der Entdecker an Reputation gewinnt, ist ein Anreiz gesetzt zur Offenlegung von Wissen. Desgleichen ist es nach Merton in Bezug auf den Newton zugeschriebenen Ausspruch ”on the shoulders of giants” ⁴⁴ allgemeiner Konsens in der Wissenschaftsgemeinde, dass jegliche Erkenntnis nur zustande kommt aufgrund der Vorarbeit anderer und nur durch Publikation Fortschritt gesichert werden kann. 45

In der Hackergemeinde des MIT waren diese Grundsätze ebenfalls fest verankert. Die möglichst schnelle Erforschung des Gegenstandes Computer gebot allen, ihre Entdeckungen zu teilen, jeder sollte von den Ergebnissen der Community profitieren können.

2.1.2.3 Uneigennützigkeit

Die Anforderungen an das Kriterium Uneigennützigkeit beschränken sich darauf, dass Forscher nicht nur um des Ruhmes Willen nach Erkenntnissen suchen sollen, sondern der Entdeckung und des Fortschrittes wegen. Somit ist Uneigennützigkeit hier nicht zu verwechseln mit Altruismus im klassischen Sinne, denn derjenige Wissenschaftler, der etwas geleistet hat, soll auch mit Anerkennung rechnen können. Die Institution des ”peer review” soll

⁴² Vgl. [Marx1981] S. 17.

⁴³ Vgl. [Merton1985] S. 94.

⁴⁴ Ebenda S. 95, umfangreicher hierzu [ Merton1980]

⁴⁵ Vgl. [Bell] S. 280f.

13

sicherstellen, dass niemand mittels Betrug zu einer Anerkennung kommen kann. Voraussetzung hierfür ist wieder die Offenlegung und damit Nachvollziehbarkeit von wissenschaftlichen Forschungsergebnissen. ⁴⁶ Spätestens jedoch mit der ”Sokal-Affäre” ⁴⁷ um die Veröffentlichung eines Nonsensartikels in einem wissenschaftlichen Magazin und der erstmaligen Erstellung eines wissenschaftlichen Textes durch ein Computerprogramm, der irrtümlicherweise sogar zu einer Einladung zu einer Fachkonferenz führte, ⁴⁸ ist die Wirksamkeit dieser Institution in Frage gestellt.

Uneigennützigkeit in der Kultur der Hacker resultierte in der Offenlegung der Quellcodes von Programmen bzw. der allgemeinen Zugänglichkeit derselben, wodurch jeder Interessierte Einblick nehmen konnte und aufbauend auf der Arbeit anderer seine Probleme angehen konnte. Gleichzeitig war somit die Überprüfbarkeit von Programmierleistungen gegeben, wodurch wiederum nur derjenige, der die Leistung erbrachte, mit Anerkennung innerhalb der Community rechnen konnte.

2.1.2.4 Organisierter Skeptizismus

Eine Anforderung an Wissenschaft ist die der Objektivität der Ergebnisse, welche durch keinerlei Glauben oder Ideologie beeinflusst werden soll. Dies wird sichergestellt, durch die ständige Überprüfung von Forschungsergebnissen. Wie schon im Punkt zur ”Uneigennützigkeit” der Wissenschaft ausgeführt, bedarf es hierfür einer Offenlegung der Ergebnisse und vor allem einer Nachvollziehbarkeit derselben. Nur so ist es anderen Interessierten möglich, den Vorgang an sich zu überprüfen und eventuell zu kritisieren. Ebendaher unterliegen alle wissenschaftlichen Veröffentlichungen einem ”peer review”. Fehler, Fälschungen und Kopien sollen so schnell gefunden werden.

Ähnliches lässt sich in der Community der Hacker finden, von der insbesondere die Praxis des ”peer review” zur Anwendung gebracht wurde und wird. ⁴⁹ Dies ist unerlässlich zum Finden von Fehlern in Programmcodes, die es, obgleich es keine fehlerfreien Programme gibt, ⁵⁰ zu minimieren gilt. Das Hauptaugenmerk liegt bei Programmierern weniger im Kritisieren des veröffentlichten Werkes und damit des Autoren, als im Verbessern desselben.

⁴⁶ Vgl. [Bell] S. 280f.

⁴⁷ Vgl. [Rötzer1997].

⁴⁸ Vgl. [Köhler].

⁴⁹ Vgl. [DiBona/Ockman/Stone] S. 9.

⁵⁰ Vgl. [Weinberg] S. 17.

14

2.2 Die Entstehung von Unix

2.2.1 Das Problem der Vernetzung

Bis Anfang der 70er Jahre arbeiteten die Hackergruppen an den verschiedenen Forschungs-laboratorien relativ getrennt. Verursacht war dies hauptsächlich durch die räumliche Entfernung und die damit verbundenen eingeschränkten Möglichkeiten des Wissenstransfers zwischen den verschiedenen Forschungseinrichtungen. Dies änderte sich schlagartig mit der Entwicklung des Unix - Betriebsystems und der Vernetzung der Universitäten über das ARPA-Net. 51

2.2.1.1 Exkurs: ARPA-Net

Im Herbst 1969 wurde ein Kommunikationsnetz eingerichtet, dessen Spezifikationen im Auftrag der Advanced Research Projects Agency(→ ARPA) vom Stanford Research Institut (→ SRI) ausgearbeitet wurden. Nach diesen wurde ein Netzwerk konzipiert, welches auf Datenpacketvermittlung basiert und dezentral ist. Dementsprechend kann sich jedes abgeschickte Datenpacket autonom seinen Zielort suchen und ist nicht auf die Existenz zentraler Vermittlungsinstanzen angewiesen, die bei Ausfall auch zum Ausfall des Netzes an sich führen würden. Dieses ARPA-Net repräsentiert den Vorläufer des heutigen Internets. Anfänglich aus vier Universitäten bestehend, wuchs das Netz bis 1971 bereits auf 14 Knoten an. Standardisiert wurde das Netz mittels so genannter ”Request for Comments” (→ RFC), die nicht als gesetzliche Vorgabe zu verstehen sind, sondern als freundliche Aufforderung zum Kommentar. Daher kann die Entstehung des Internets, dessen Strukturen folglich durchaus in der Tradition der Hacker stehen, unter das Modell der Konsensdemokratie subsumiert werden. Wichtige Standards, die auf diese Art und Weise entstanden, sind TCP/IP zur Verbindung von unterschiedlichen Netzen, E-mail, FTP und andere. 52

Beginnend mit dem ARPA-Net war es also möglich, per Computer zu kommunizieren und damit computerunterstützt zusammenzuarbeiten und Dateien auszutauschen. Hierfür fehlte jedoch bisher noch eine gemeinsame Programmbasis, denn an jedem Institut wurde die Software zum Zugriff auf die grundlegenden Computerfunktionen bisher selbst geschrieben und daher existierten an jedem Ort mit Computernutzung unterschiedliche Lösungen. Die-

⁵¹ Hierwird auf das ARPA-Net eingegangen, da aus diesem, systemisch bedingt, das heutige Internet hervorgegangen ist. Versuche von Europäern bzw. Japanern, andere Standards zu forcieren, scheiterten.

⁵² Vgl. [Grassmuck] S. 182ff, [Levy] S. 119f. u. [Raymond1999a] S. 20f.

15

se Lücke füllte das Mehrbenutzer-Betriebsystem Unix aus, welches 1971 zum ersten Mal veröffentlicht wurde und eine Entwicklung der AT&T Bell Laboratories in New Jersey darstellt. ⁵³ Hierfür waren einige technische Innovationen erforderlich, die auf bisherigen Systemen unbekannt waren. Zudem wurde bei der Konzipierung darauf geachtet, das System möglichst kompakt zu halten, um spätere Erweiterungen und Ergänzungen zu erleichtern. Im Wesentlichen galt bei der Unixkonzeption der Grundsatz, dass jedes Programm nur eine Funktion erfüllt, diese jedoch besonders gut. Die ersten Versionen wurden auf einer PDP-7 von DEC geschrieben und da in den Bell Labs unterschiedliche Rechnerplattformen zum Einsatz kamen, gebot sich eine Portierung - das heißt eine Übertragung und damit Übersetzung - auf andere Systeme. Die somit auf verschiedenen Computersystemen vorhandenen Unixvarianten konnten danach zum Standardbetriebssystem von AT&T avancieren. Jedoch wurde dafür vorher das komplette System in der gleichzeitig entwickelten Programmiersprache C neu geschrieben und konnte nach dem Beginn 1971 im Jahre 1973 fertiggestellt werden. Damit wurden zukünftige Portierungen erheblich vereinfacht. ⁵⁴ AT&T war es nach einer Vereinbarung mit der amerikanischen Monopolaufsichtsbehörde aus dem Jahre 1956 verboten, in anderen Bereichen als der Telekommunikation, damals also der Telefonie an sich, kommerziell aktiv zu werden und daher wurden Kopien von Unix zum Selbstkostenpreis an Universitäten abgegeben. ⁵⁵ Dies ermöglichte eine schnelle Verbreitung des Betriebssystems an den Universitäten und anderen Forschungseinrichtungen. Der fehlende Support, bedingt durch das geringe kommerzielle Interesse AT&Ts, führte zu einem intensiven Austausch der sich aufbauenden Unix-Community. Dies basierte anfänglich größtenteils auf den in der Wissenschaft üblichen Austauschmethoden wie Konferenzen, Rundbriefen und Veröffentlichungen in Fachzeitschriften, konnte jedoch mit der Erweiterung des ”Unix to Unix Copy” (→ UUCP) Protokolls wesentlich vereinfacht werden. ⁵⁶ Hiermit war es möglich, sich per Telefonverbindung mit einem anderen Rechner zu verbinden und Dateien zu übertragen. Da dies auch Computer sein konnten, die mit dem ARPA-Net verbunden waren, bestand die Möglichkeit, Dateien an jeden Rechner im ARPA-Net zu verschicken. Die Hauptinfrastruktur der Unix-Community bildete jedoch das Usenet, einer Art Schwarzes Brett, in dem nach Themen geordnete Diskussionen stattfan-

⁵³ Vgl.[Grassmuck] S. 212 u. [ATT]

⁵⁴ Vgl. [Raymond1999a] S. 22f u. [Grassmuck] S. 212.

⁵⁵ Vgl. [ATT], [Weber2004] S. 22. Der Sherman Antitrust-Act trat am 24. Januar 1956 in Kraft und betraf neben AT&T noch die Firma Western Electric. Seit 1979 mit der Veröffentlichung des Unix-System V7 betrieb AT&T eine stärkere kommerzielle Vermarktung seines Unix-Betriebssystems.

⁵⁶ Vgl. [Raymond1999a] S. 23

16

den und das ebenfalls einen Dienst des ARPA-Net darstellte. Auf diese Weise entstand eine sich lebhaft austauschende Community, die das System Unix ständig pflegte und erweiterte. Bemerkenswert an der ganzen Entwicklung ist das vollständige Fehlen eines Entwicklungsauftrages, eines großen Planes oder eines kommerziellen Interesses. Der Hauptgrund für einen Beitrag war das eigene Bedürfnis zur Lösung eines Problemes, dessen Ergebnis bereitwillig an Interessierte weitergegeben wurde. 57

2.3 Software wird zur Ware

2.3.1 Die Einführung von Softwarelizenzen

Wie in Kapitel 2.1 auf S. 6 angeführt, gab IBM im Jahre 1969 die Praxis des Software-Bundlings auf und eröffnete damit die Möglichkeit zur Entstehung von eigenständigen Softwarefirmen. Diese Option wurde auch hinreichend genutzt, und zwar dahingehend, als dass in der Folgezeit bereits Standardsoftware wie Buchhaltungsprogramme und Textverarbeitungen in - nicht nur für ”wahre Programmierer” - redundanter Art und Weise parallel programmiert und verkauft wurde. ⁵⁸ Bezeichnend für die Veränderung, die sich im Umgang mit den Quellen von Software vollzog, ist der offene Brief von Bill Gates - dem wohl heutzutage bekanntesten Protagonisten der Softwareindustrie - an seine Hobbykollegen im Jahre 1976. In diesem wirft er ihnen vor, Software nur zu stehlen und damit letztendlich die Entwicklung guter Software zu verhindern, da den Programmierern jeglicher Anreiz, ihre Zeit zu investieren, genommen wird. ⁵⁹ Sein im Schlusssatz angekündigtes Vorhaben den Hobbymarkt mit ”guter Software” zu überschwemmen, wurde von ihm in die Tat umgesetzt, nachdem er Harvard verließ und Microsoft gründete.

Dieses Beispiel steht stellvertretend für den Konflikt, der in der noch überschaubaren Programmierszene ausgetragen wurde und in dem es nicht um die Bezahlung von Programmierleistungen ging, wie es in dem Brief von Gates suggeriert wird. Im Gegenteil handelt es sich dabei um den Umgang mit Wissen in Softwareform. Soll der Quellcode von Programmen für jeden einsehbar und damit verwend-, erweiter- und verbesserbar sein oder hat der Schreiber das ausschließliche Recht auf den Zugang zum Bauplan von seinem Erzeug- ⁵⁷ Ebendau. [Grassmuck] S. 212f.

⁵⁸ [Grassmuck] S. 203f.

⁵⁹ Vgl. [Gates]. Hier finden wir die klassische Sicht bezüglich der Anreize zu Innovationen wieder.

17

nis? ⁶⁰ Die Auseinandersetzung zwischen diesen beiden Lagern im Bereich der Softwareproduktion erinnert stark an die Frühzeit des Kapitalismus, in der mit den Einhegungen ein ähnlicher Konflikt, jedoch über einen weitaus längeren Zeitraum, zu bewältigen war. ⁶¹ So ist - in der Marxschen Lesart - erst über die Enteignung und Vertreibung der breiten Masse von kleinen Landbesitzern und Pächtern die Notwendigkeit für einen Arbeitsmarkt geschaffen worden, da für die nun ohne Produktionsmittel existierenden Menschen keine andere Form der Reproduktion als über die Vermittlung des Marktes mehr möglich war. Ähnliches vollzog sich in den 70er Jahren bei der Einrichtung eines Softwaremarktes. Erst über die Verwendung von Lizenzen - die vorher unbekannt waren - welche lediglich das Benutzen der Software erlaubten, jedoch ausschlossen diese zu untersuchen, zu verändern, weiterzugeben und in Verbindung mit der Zurückhaltung des Quellcodes, also des Bauplanes, konnte etwas wie ein Markt für Software entstehen. Durch die Einhegung des Quellcodes ⁶² konnten Nutzer ausgeschlossen und somit Software als Ware angeboten werden. Den auf die Software angewiesenen Nutzern, die reine Anwender waren bzw. sind, blieb als einzigelegale - Möglichkeit der Erwerb der Softwarelizenz einschließlich der damit verbundenen Einschränkungen.

2.3.2 Die Community löst sich auf

Diese Einschränkungen blieben vorerst auf Bereiche außerhalb der Lehr- und Forschungseinrichtungen beschränkt, da in diesen die bisher praktizierte Freizügigkeit in der Nutzung von Software fortgesetzt wurde. Dies änderte sich jedoch schrittweise ebenfalls, da Firmen wie AT&T, IBM und DEC ebenfalls in diese neu entstandenen Märkte eintraten und so die bereits vorhandene Software, die von ihren Angestellten programmiert worden war, zuerst überhaupt mit Lizenzen versahen und diese dann allmählich restriktiver gestalteten. So war

⁶⁰ Hier muss angemerkt werden, dass Gates vielleicht in den 70ern das Recht des Autoren an der Verwertung seines Produktes einklagte. Er würde sich heute jedoch dagegen verwahren, wenn ein ehemaliger Programmierer von Microsoft den von ihm geschriebenen und Microsoft überlassenen Code bspw. für Office zurückfordern würde. Rechtlich gesehen ist dies zwar nicht einwandfrei möglich, da im Arbeitsvertrag von Microsoft in jedem Falle eine ”Work made for hire” enthalten ist, jedoch auf der von Gates damals argumentativ beschrittenen Ebene vorstellbar. Zum rechtlichen Hintergrund dieser Problematik vgl. Kapitel 3.1.2.1 ab S. 29.

⁶¹ Vgl. [Smith] S. 206ff u. [Marx1951] S. 751ff, der Bezug wurde inspiriert durch die Artikel von [Benkler1999], [Boyle], welche diesen Ansatz auf die weitergefasste Entität der Public Domain anwandten und auch die Anspielung bei [Grassmuck] S.387ff.

⁶² Demnach kann proprietäre Software im Gegensatz zu quelloffenener Software auch als ”gated” oder eingezäunte Software aufgefasst werden. Nachfolgend werden die Begriffe kommerziell, gated-source und closed-source Software synonym verwendet.

18

Anfang der 80-er Jahre keine Rechnerplattform mehr ohne proprietäres Betriebsystem zu erhalten. 63

Für die bestehende Programmiergemeinschaft hatte das erhebliche Folgen. Es änderten sich nicht nur die Lizenzierungen, sondern zudem wurde es üblich, Arbeitsverträgen so genannte ”nondisclosure agreements” hinzuzufügen, die jedem Angestellten untersagten, über den Quellcode zu sprechen. ⁶⁴ Somit war der freie Informationsfluss zwischen Anwendern und Programmierern - die oftmals beides in einer Person waren - gestört und dies nachhaltig. Bei Richard M. Stallman, dem nach Levy ”...last of the true hackers...” ⁶⁵ , wurde die Problematik aus der Sicht der Softwareindustrie in folgende Worte gefasst:

”If you share with your neighbor, you are a pirate. If you want any changes, beg us to make them.”

So war es nur folgerichtig, dass von ihm mit der Initiierung des GNU-Projekts ⁶⁶ ein Gegengewicht zu proprietären Softwaremodellen geschaffen werden sollte.

2.4 Das GNU-Projekt

2.4.1 Am Anfang steht ein Problem

Bevor es zur Gründung des Projektes im Jahre 1984 kam, stand die Lösung eines Problemes an. Der spätere Gründer des GNU-Projektes Richard M. Stallman, scheiterte daran auf einem Netzwerkdrucker von Xerox im AI Lab des MIT ein Dokument auszudrucken. An sich stellte diese Aufgabenstellung bis zu dieser Zeit für einen Programmierer kein Problem dar; er besorgte sich den Sourcecode, suchte den Fehler und schrieb das Programm um. Stallman machte auch konsequenterweise den Programmschreiber in der Firma Xerox ausfindig und bat ihn um Einsichtnahme in den Code, so dass er das Problem schnell hätte lösen können. Jedoch musste dieser ihm die Herausgabe aufgrund einer vorher eingegangenen Geheimhaltungsverpflichtung verweigern. ⁶⁷ Die Lösung hätte nun darin bestanden, die Firma um

⁶³ Vgl. [Stallman1999] S. 48ff, [Raymond1999a] S. 23ff u. [Grassmuck] S. 215ff Dies gilt auch für die unter der freien BSD-Lizenz (Vgl. Kapitel 3.2.2.2 auf S. 38 und Anhang B ab Seite 109.) vertriebene Berkeley Software Distribution, da sie immer noch auf dem Unix-Code der AT&T Bell Labs basierte und eine Lizenz von AT&T zur Benutzung des Systemes erworben werden musste.

⁶⁴ Vgl. [Levy] S. 292f, [Stallman1999] S. 49f, [Grassmuck] S. 220ff

⁶⁵ Vgl. [Levy] S. 341ff.

⁶⁶ GNU is Not Unix(→ GNU). Dies ist ein rekursives Akronym.

⁶⁷ Vgl. [Stallman1999] S. 49f.

19