Freie Software, Open Source und Linux

Inhaltsverzeichnis

1 Einleitung

2 Quellcode und Objektcode
2.1 Programmiersprachen
2.2 Die Unumkehrbarkeit des Übersetzens

3 Free-Software und Open-Source-Software
3.1 Proprietäre Software
3.2 Freie Lizenzen
3.2.1 Die BSD-Lizenz
3.2.2 Die GNU General Public License (GPL)
3.3 Free Software versus Open Source Software

4 Linux Userperspektive
4.1 OSS als Projekttionsfläche von Idealen
4.1.1 Ideologischer Diskurs
4.1.2 Bildungsbereich / Wissensallmende
4.1.3 OSS in Nicht-G8-Länder
4.2 OSS in der ökonomischen Nutzung
4.2.1 Kosteneinsparung
4.2.2 Systemadministration
4.2.3 Implementierung
4.2.4 Kooperative Hilfe

5 Geschäftsmodell „Free Software / Open Source Software“
5.1 Allgemeine Software-Value-Chain
5.2 Geschäftsmodelle mit proprietärer Software
5.3 Geschäftsmodelle mit Open-Source-Software

6 Akteure und Akteurskonstellation
6.1 Akteure
6.1.1 Entwicklergemeinde
6.1.2 Hardwarehersteller
6.1.2.1 Aktuelle Entwicklungen
6.1.2.2 Wirtschaftliche Motivation
6.1.3 Softwareproduktion
6.1.3.1 Aktuelle Entwicklungen
6.1.3.2 Microsoft / Initiative for Software Choice . .
6.1.4 IT -Dienstleister
6.1.5 Kunden
6.1.6 Staatliche Einrichtungen
6.2 Akteurskonstellation
6.3 Ausblick

7 Das Softwarepatent
7.1 Definition
7.2 Koexistenz von Urheberrecht und Softwarepatent
7.3 Trivialpatente
7.4 Volkswirtschaftliche Auswirkungen
7.5 Der europäische Mittelstand
7.6 Zukunft von OSS?

A Über dieses Dokument
A.1 Verwendete Software für diese Arbeit

1 Einleitung

Bei der vorliegenden Arbeit handelt es sich um die Ausarbeitung ei- nes Referats, welches von den Autoren im Rahmen der Lehrveranstal- tung „Soziologie und politische Ökonomie des Internet“, die unter Lei- tung von Dr. Ulrich Dolata im Sommersemester 2004 an der Univer- sität Bremen stattfand, gehalten wurde. Es soll im Folgenden der Ver- such gemacht werden, einen Einblick zu gewähren, in die Sphäre der Open Source Software (im folgenden auch kurz OSS) bzw. Free Soft- ware. Begonnen wird mit einer grundlegenden Einführung zu infor- mationstechnischen (Kapitel 2: Quellcode und Objektcode) und recht- lichen Belangen (Kapitel 3: Free Software und Open Source Software). Anschließend wird Open Source Software aus der Benutzerperspekti- ve beleuchtet (Kapitel 4), dabei wird sowohl auf ideologische Beweg- gründe von Benutzern, wie auch auf den Einsatz von OSS im Vergleich zu proprietärer Software beispielsweise in der Bürolandschaft einge- gangen. Ökonomische Aspekte werden größtenteils in den Kapiteln 5 und 6 herausgearbeitet, wobei in Kapitel 5 anhand einer allgemeinen Software-Value-Chain Geschäftsmodelle mit proprietärer Software und OSS vorgestellt werden. In Kapitel 6 folgt eine Beschreibung der öko- nomisch relevanten Akteure rund um OSS in ihrem Verhältnis zuein- ander, außerdem wird hier versucht, sowohl eine Akteurskonstellation wie auch einen Ausblick zu skizzieren. Das Kapitel 7 ist dem Software- patent gewidmet, welches im direkten Zusammenhang mit der Zukunft der Open Source Bewegung steht.

2 Quellcode und Objektcode

Quell-Code¹ und Objekt-Code² sind Begriffe aus der Welt der Computerprogrammierung. Um zu verstehen, was an quelloffenen, freien Programmen überhaupt so besonders ist, ist es notwendig zu verstehen, was diese beiden Begriffe bedeuten und was die technische Entsprechung ihres Verhältnisses zueinander ist.

2.1 Programmiersprachen

Ein Rechner ist von sich aus eigentlich nicht in der Lage, richtig zu rechnen. Ein Rechner arbeitet intern mit einer Informationseinheit, die Bit³ genannt wird. Was ein Rechner tun muss, um zwei reelle Zahlen in Bits darzustellen und miteinander zu multiplizieren, muss dem Rechner sozusagen Bit für Bit beigebracht werden.

Eine Programmiererin, die ein Problem zu lösen hat, kann sich na- türlich nicht damit herumschlagen, jedesmal von neuem dem Rechner diese Grundlagen beizubringen. Stattdessen gibt es fertige Bibliothe- ken, die eine große Menge an Standard-Funktionen und Datentypen bereitstellen, mit denen sich Daten wie zum Beispiel reelle Zahlen oder komplexere Daten wie Grafiken definieren und manipulieren lassen. Ebenso sind viele komplizierte Konzepte, die die Wissenschaft der In- formatik hervorgebracht hat bereits in diese Bibliotheken eingeflossen — wie zum Beispiel effiziente Verfahren, um große Mengen an Daten alphabetisch zu sortieren. Ein Beispiel für eine solche Bibliothek ist die C++-Bibliothek. Die Menge der aus dieser Bibliothek zur Verfügung ge- stellten Funktionen und Datentypen und die Definition derer Notation stellt — vereinfacht gesagt — eine Sprache dar. Ein Beispiel-„Text“ in der C++-Sprache sieht wie folgt aus:

Abbildung in dieser Leseprobe nicht enthalten

Dies ist ein vollständiges Programm in der Sprache C++. Es tut nichts weiteres, als die Zeile „hello world!“ auf dem Bildschirm auszugeben. Die Zeile, die mit #include anfängt, stellt alle Funktionen, die in der C++-Bibliothek unter iostream verzeichnet sind, im Kontext dieses Programmetextes zur Verfügung. Dieser Text sieht zwar kompliziert aus, jedoch versteckt hier die Funktion cout, die in iostream definiert ist, eine Menge an Detailwissen, um das sich die Programmiererin nicht zu kümmern braucht: wie nämlich die Zeichenkette, die in message[] zuvor gespeichert wurde, auf dem Bildschirm ausgegeben wird. Des- weiteren braucht sich die Programmiererin nicht darum zu kümmern, wie die Zeichenkette im Arbeitsspeicher im Rechner verwaltet wird. Es genügte, einen Datentypen auszuwählen, der für eine Zeichenkette (die auszugebende Zeile) angemessen ist.

Dieser Text wird dann von Programmen, die man Übersetzer⁴ nennt, in ein Zielobjekt übersetzt, den sogenannten Objektcode oder auch Binärobjekt. Weil der programmierte Text die Quelle für diesen Vorgang ist, wird er Quelltext oder Quell-Code genannt. Erst das Binärobjekt enthält die Anweisungen auf Bit-Ebene, die auf der zentrale Recheneinheit⁵ ausgeführt werden können.

Diese von der zugrunde liegenden Maschine abstrahierende Distanz zu verbinden ist das, was die Programmiersprachen und deren Übersetzer leisten. Der Quellcode wird in einer formellen Sprache geschrieben (der Programmiersprache), die aus Sicht des Menschen an Problemlösungskonzepten angelehnt ist.

Wenn eine Softwareentwicklerin ein gegebenes, realwirkliches Problem zu lösen hat, versucht sie, es in kleine, möglichst simple und bekannte Teilprobleme zu zerlegen, zu qantifizieren und zu algorithmisieren. Daraufhin modelliert sie in einer dem Problem angemessenen Sprache (wie zum Beispiell C++) Objekte (hier: eine Zeichenkettenvariablen), die möglichst nah an Abbildungen der Problem-Teilgegenstände herankommen (ein auszugebender Text).

2.2 Die Unumkehrbarkeit des Übersetzens

Nachdem ein Quelltext übersetzt wurde, ist im resultierenden Binärob- jekt nicht mehr von den Zusammenhängen, die in der abstrakten Spra- che formuliert waren, erkennbar. Die obige Zeichenkette sieht dann so aus: 1101000 1100101 1101100 1101100 1101111 100000 1101111 1100010 1101100 1100100 0001010 0000000. Diese Bits stehen ir- gendwo im Speicher zusammen mit allen anderen Daten und mit allen auszuführenden Anweisungen; es ist nicht erkennbar, dass diese Bits Kodierungen für eine Kolonne von Buchstaben sein sollen. Die Anwei- sungen manipulieren einfach bitweise in diesem Bereich herum, ohne sogar selbst zu wissen, wo das Ende dieses Bereiches ist und wo andere Daten anfangen. All dies Wissen war nur im Verlaufe des Übersetzens vom Quelltext in den Binärcode bekannt und ist bei diesem Prozess verloren gegangen. Der Rechner braucht dieses Wissen auch nicht, er verläßt sich sozusagen darauf, dass der Übersetzer schon alles richtig gemacht hat.

Binärcode auf das ursprünglich gemeinte zurückzuführen, ist prak- tisch unmöglich und wenn doch, dann meist nur mit einem Arbeits- aufwand, der dem Programmieren selbst gleichkommt. Joseph Weizen- baum hat in Weizenbaum (1977) ein ganzes Kapitel darauf verwendet, nachzuweisen, dass selbst unter der Annahme, dass eine übernatür- liche Intelligenz in der Lage wäre, zu jedem beliebigen Zeitpunkt den vollständigen Zustand eines Computersystems zu erfassen, nicht ver- stehen kann, wie dieses Computersystem gerade etwas tut. Zu beob- achten ist nur, dass bestimmte Eingaben (vom Benutzer oder von einer beliebigen Datenquelle) unter bestimmten, aber in ihrer Ganzheit un- bekannten, inneren und äußeren Bedingungen, bestimmte Ausgaben oder Aktionen hervorrufen. Diese Sichtweise auf ein System wird auch als Blackboxing bezeichnet. Wenn nun jemand versuchen muss, die Funktionsweise eines Softwaresystems zu verstehen, bleibt ihm nichs anderes übrig, als zu versuchen, Ein- und Ausgabe zu analysieren und daraus kausale/funktionale Zusammenhänge zu schließen.⁶

Das Verfassen eines Programmtextes vereint zwei Prozesse, die au- ßerhalb der Computerdomäne auseinanderfallen: Die Formulierung ei- ner Theorie und das Konstruieren eines Modelles. Man vergegenwärtige sich zum Vergleich die Arbeit einer Psychoanalytikerin. Sie hat im Lau- fe ihrer Ausbildung theoretisches Wissen, Kategorien und Zusammen- hänge erlernt. Dieses theoretische Wissen wendet sie auf einen Patienten an: Mit ihren theoretischen Begriffen bildet sie sich ein Modell von ihrem ihr gegenübersitzenden Patienten und läßt Wirkzusammenhänge modellhaft in ihren Kopf durchspielen, mit der Absicht, Resultate und Konsequenzen mit der realen Person im Gespräch rückzukoppeln, also zu verifizieren. Danach entscheidet sie sich anhand dieses Modells für einen therapeutischen Ansatz, woraufhin sich hoffentlich beabsichtigte modellhafte Prozesse real wiederholen.

Die Programmiererin, die mit einem Problem konfrontiert ist, muss sich nun theoretischen Wissen über jenes Problem beschaffen und er- lerntes Wissen, theoretische Gegenstände und Zusammenhänge for- muliert sie in einer Programmiersprache. Ein Programmtext ist also nichts anderes als eine niedergeschriebene Theorie — jedoch noch mehr: dieser Text ist im Computer ablauffähig. Es ist also gleichzeitig auch ein Modell! Beim Programmieren gilt also: Programmtext = Theorie = Modell.

Zusammen mit dem Prozess des Übersetzens und seiner praktischen Unumkehrbarkeit ergibt sich außerdem, dass dieses Modell (mit sei- ner Entsprechung im Objekt-Code) von der darinliegenden Theorie (in seiner Entsprechung im Quellcode) abtrennen läßt. Proprietäre Soft- warehersteller machen sich diese Abtrennbarkeit zunutze. Sie liefern nur den Objectcode aus. Der zugehörige Quelltext wird verschlossen und damit das Fachwissen und das Wissen um die Lösung der Proble- me verheimlicht. Damit sichert sich der Hersteller ein Wissensmonopol, worauf er sich Alleinstellungsmerkmale aufbaut, die er dann auf dem Warenmarkt exklusiv verwerten kann.

Die Übersetung von Quellcode zu Objektcode ist also irreversibel und die Auslieferung von Software ohne den dazugehörigen Quellcode ist gleichbedeutend mit der Geheimhaltung der Funktionsweise. Dem nor- malen Anwender stört dies wenig. Für seine Belange ist es irrelevant, wie eine Software, die sich wie eine Blackbox verhält, tatsächlich funk- tioniert. Ihm ist nur wichtig, dass sie funktioniert. Für professionelle Systemadministratoren und Integratoren ergibt sich daraus allerdings eine Welt der Mauern und Hindernisse. Diese immanente Unflexibilität ist insbesondere deswegen schmerzhaft, weil eine gegebene Software ein Problem grundsätzlich nur unter einer eng umgrenzten Menge von Umständen zu lösen in der Lage ist — und jene realweltlich gekoppelten Umstände wechseln normalerweise fortlaufend und ständig.

3 Free-Software und

Open-Source-Software

Lizenzen, also Verträge über die Nutzung der überlassenen Software, die sich auf das Urheberrecht¹ bzw. auf das Copyright beziehen, sind von besonderer Bedeutung für Software — sowohl für freie als auch für unfreie Software. Jedoch sind die Sphären, die die freien und unfreien Lizenzen regeln, grundverschieden. Vereinfacht gesagt, regelt eine freie Lizenz die Handhabung des Quelltextes und eine proprietäre Lizenz die Nutzungs(un)freiheit des Endproduktes (des Objekt-Codes).

3.1 Proprietäre Software

Proprietäre Softwareprodukte werden meist in Binärversionen ausge- liefert, um das darin eingeschlossene Firmen-Know-How geheimzuhal- ten. Manche Software ist auch direkt im Quelltext ausführbar: soge- nannte Scripte, die von einem Interpreterprogramm ausgeführt wer- den. Obwohl man in diese Scripte hineinschauen kann, können sol- che Scripte proprietär sein. In beiden Formen wird die Software mit einem Nutzungsvertrag überlassen, in dem reguliert ist, wer und zu welchem Zwecke die Software verwenden darf, wie dies geschehen darf und auf welchen Computern. Insbesondere dürfen keine Änderungen vorgenommen werden; mindestens wäre sonst ein Hilfeanspruch, für den man extra bezahlt hat, verwirkt oder es ist sogar ein Straftatbe- stand erfüllt. Es ist nur die Nutzung der Software wie sie ist in einem abgesteckten Rahmen erlaubt.

Diese Einschränkung dient der künstlichen Verknappung der Ware Software, wodurch sie erst verkaufbar wird und um eine Abhängig- keitsbeziehung zwischen Hersteller und Kunde zu etablieren. Möchte ein Kunde diese Ware anders nutzen, also mit mehr Benutzern, an mehreren Standorten oder zu einen anderen Zweck, so muss er meist einen anderen Lizenzvertrag kaufen. Lizenzrechtlich kauft er sich da- mit eine andere oder größere „Leistung“ ein; dass die Software dabei ein und dieselbe bleibt, ist dabei unerheblich. Die rechtliche Dosierung der

Nützlichkeit der Software bildet die Verwertungsgrundlage proprietärer Software. Genaueres zu der Verwertung von Software wird in Kapitel 5 ab Seite 21 abgehandelt; zum Verhältnis freier versus unfreier Software zum Benutzer, siehe Kapitel 4.

Das Wort „Proprietär“ meint im engeren Sinne eigentlich, dass die Software jemandem gehört. Es verfügt also jemand über das Urheber- recht oder Copyright. Das ist natürlich sowohl für freie als auch für un- freie Software der Fall. Denn auch freie Software wird einem bestimm- ten Urheber (natürliche oder juristische Person) zugeordnet, auch wenn eine Vielzahl Menschen Beitragende sind und dieser offizielle Urheber eine ungewöhnliche Rechtsform in der Softwarelizenz wählt. Gemeint mit „proprietär“ ist aber, dass der Nutzer der Software vom Rechteinha- ber abhängig ist.

3.2 Freie Lizenzen

Freie Lizenzen zeichnen sich gegenüber den proprietären Lizenzen hauptsächlich dadurch aus, dass sie nicht die Nutzbarkeit der Softwa- re wie sie ist einschränkt; die Nutzbarkeit ist einfach unbegrenzt. Die- se Uneingeschränktheit ist allen freien Lizenzen gemein. Unterschiede zwischen den freien Lizenzen und das eigentlich Sujet, das die freien Lizenzen betrachten und wodurch sie sich von den proprietären Pen- dants abheben, liegen in der rechtlichen Regelung über die Nutzung des Quelltextes.

3.2.1 Die BSD-Lizenz

Die erste freie Lizenz für Software ist die BSD-Lizenz der Berkeley- Universität von 1979. Die BSD-Lizenz erlaubt das freie Verwenden und die freie Verbreitung der Software als Quellcode sowie in übersetztem Objektcode und sowohl im Original, als auch mit beliebigen Modifika- tionen. Aber es gibt dabei ein Problem: Es ist nur von der Möglich- keit der Veröffentlichung des Quellcodes die Rede, es gibt dazu keinen Zwang. Entscheidet sich eine Firma, freie Programme zu modifizieren und zu erweitern, so steht es ihr auch frei, den Quellcode für diese Er- weiterungen fortan für sich geheim zu halten und kann diese Erweite- rung gegenüber dem freien Original als „Added Value“ gewinnbringend lizenzieren. Jede Firma kann sich also auf die Schulter eines Riesen stellen, ohne etwas an den Riesen zurückzugeben.

Bekanntestes Beispiel ist zur Zeit das Betriebssystem MacOS X von Apple, welches einen BSD-Systemkern verwendet, wodurch sich die Beliebtheit von MacOS vervielfacht hat, weil es nun viele angenehme Unix-Eigenschaften geerbt hat. Dass Mensch im MacOS nun herum- schrauben darf und kann, bedeutet dies allerdings noch lange nicht. Auch Microsoft hat sich bei einem BSD-Unix bedient, nur erwähnte Microsoft dies kleinlaut nie; nur Netzwerkscanner konnten sehen, dass sich der Internetprotokollstapel vom neuesten Windows genauso wie ein BSD-Unix verhielt.

3.2.2 Die GNU General Public License (GPL)

Als Richard Stallman 1984 das GNU² -Projekt gründete, um eine freie Implementierung des Betriebssystems Unix zu programmieren, erfand er eine neuartige Lizenz: die GNU General Public License (GNU-GPL) oder einfach GPL. Diese Lizenz wird auch Copyleft genannt, weil sie ein Hack des Copyright ist. Die GPL ist eigentlich nichts anderes als eine Copyright-Klausel, jedoch kehrt sie ihre rechtliche Intention um: anstatt Nutzungsmöglichkeiten einzuschränken, schränkt sie die Ein- schränkbarkeit der Nutzungsmöglichkeiten ein. Folgende Hauptmerk- male sind verankert:

- Die Lizenz einer GPL-Software darf nicht verändert werden.
- Keine Diskriminierung eines Zweckes: Die Software darf für für alle Zwecke verwendet werden, auch kommerzielle, unkommerzielle und auch zum Bau von Atombomben oder in einer Klinik, die sich auf Schwangerschaftsabbrüche spezialisiert.
- Keine Diskriminierung von Personen oder Institutionen: Die Software darf von allen verwendet werden, auch von Mitgliedern eines „konkurrienden Gesellschaftssystems“.
- Die Software darf frei verbreitet, also auch verkauft oder verschenkt werden.
- Der Quellcode muss immer frei verfügbar und einsehbar sein und muss es auch bleiben.
- Die Software darf beliebig verändert werden und Änderungen dürfen verbreitet werden.
- Änderungen unterstehen wieder der GPL.
- GPL-Software darf nicht in unfreie Software eingebaut werden.

Die letzten beiden Punkte sind besonders wichtig. Wenn jemand eine Lösung braucht und sich freier Software bedient und darauf aufbauend eine Lösung programmiert, so muss seine Programmierleistung wieder eine freie sein. Und sobald jemand in seine eigene proprietäre Lösung freien Code verwendet, so muss er seine ursprüngliche Eigenleisung al- len frei zugänglich machen. Auf diese Weise ist sichergestellt, dass frei- er Code immer frei bleibt. Eine Reprivatisierung ist also ausgeschlos- sen. Der besondere Clou: Sobald die Menge an veröffentlichtem freien Quelltext hinreichend groß ist (und diese Schwelle ist für viele Anwen- dungszusammenhänge längst um ein Vielfaches überschritten), so ist es eine Verlockung, sich dieser Bibliothek zu bedienen, auch wenn dies bedeutet, eigenen proprietären Code der Geheimhaltung zu entreißen; woraufhin sich die Bibliothek freier Quelltexte in großen Sprüngen ver- größert.

3.3 Free Software versus Open Source Software

Zur Förderung freier Software gründete sich 1985 die Free Software Foundation (FSF), die die Hüterin der GPL ist und freie Softwareprojek- te unterstützt. Sie ist auch die Markeninhaberin von „Free Software“.

1998 gründeten Eric S. Raymond (ESR) Bruce Perens die Open Sour- ce Initiative (OSI). Stoßrichtung dieser Organisation ist die Integrati- on freier Software in die kommerzielle Verwertung. Zu Marketingzwe- cken wurde der Begriff „Open Source“ (Open Source Software; OSS) geschützt.

Unter dem Begriff von Free Software fallen Werke, die der GPL unterstehen oder einer ähnlich strengen Lizenz, die eine Schließung des Quelltextes nachhaltig verhindert. Open Source ist eine Obermenge, die zudem Werke einschließt, die zwar auch quelloffen sind, aber keine solchen Mechanismen gegen die Schließung des Quelltextes vorsehen, wie zum Beispiel die BSD-Lizenz.

4 Linux Userperspektive

4.1 OSS als Projekttionsfläche von Idealen

4.1.1 Ideologischer Diskurs

Auch wenn der ökonomischen Verwertung von OSS das Kriterium der reinen Wirtschaftlichkeit zu Grunde liegt, so sind Betrachtungen zur Nutzung quelloffener Software im nicht ökonomischen Bereich (Privat- anwender, öffentliche Institutionen) häufig von einem ideologischen Ka- non begleitet. Ob es um die Angst vor der Monopolstellung sogenann- ter Global Player oder die einfache Verwirklichung eines Freiheitsge- dankens geht, die Diskussion um OSS ist gerade bei Privatanwendern häufig emotional aufgeladen. Eine gänzlich ideologiefreie Betrachtung dieser Thematik ist im nicht ökonomischen Kontext, insofern unvoll- ständig, da die Frage nach dem Nutzen von OSS auch die Frage nach den Motiven für die Nutzung dieser Software impliziert. Folgende Aus- sage eines Lehrers der Gemeinschaftsschule Pennenfeld in Bonn Bad- Godesberg, der quelloffene Software auch beruflich einsetzt, verdeut- licht, dass der Motivation zur Nutzung von OSS ein ideologisch begrün- deter Nutzen immanent sein kann:

„Allein durch freie Software ist man in der Lage, sich informationstechnologisch von der Vorherrschaft einiger weniger Global Players zu lösen.“ (Peter Bingel, in: WOS 1, 7/1999, in: Grassmuck 2002, Seite 320)

4.1.2 Bildungsbereich / Wissensallmende

Dieser politisch-ideologisch begründete Nutzen von OSS gilt, sofern man mit der politisch-ideologischen Gesinnung übereinstimmt, sowohl für Privatpersonen als auch für Institutionen. Im Bildungsbereich, vor allem in den Universitäten, ist ein weiteres politisch-ideologisches Mo- tiv zur Nutzung von OSS anzutreffen. Software fällt hier unter die Dok- trine der Wissensallmende, die die Freiheit und Verfügbarkeit informa- tioneller Erkenntnisse deklariert. Die Wissensallmende postuliert die freie Verfügbarkeit von Erkenntnissen zum Nutzen des wissenschaft- lichen Fortschritts, der zweifellos auch praktischen Nutzen nach sich ziehen kann. Gerade im Bildungsbereich wird auch der praktische Nut- zen von OSS deutlich. Schüler und Studenten können die Software aus dem Unterricht mit nach Hause nehmen, ohne dass ihnen dabei Kosten entstehen oder sie kriminalisiert werden. Im Gegensatz zu proprietärer Software bietet OSS didaktische Qualitäten, die über die bloße kon- sumtive Bedienung eines Programms hinaus auch ein Verständnis für dessen Struktur und Funktionsweise ermöglicht, da sie in der Regel modifiziert werden kann und daher zum Experimentieren einlädt.

Die Ausstattung von Bildungsinstitutionen mit OSS wird daher von zahlreichen Initiativen und Projekten gefördert, die unter anderem OSS für Schulen zur Verfügung stellen. Zu nennen wären hier zum Bei- spiel der Verein für Freie Software und Bildung (FSuB), der für Schulen geeignete Software zusammenstellt, die Zeitschrift c’t und das offene Deutsche Schulnetz (ODS), die eine Schul-Serverlösung entwickelt ha- ben, die schätzungsweise im vierstelligen Bereich im schulischen Ein- satz ist, oder das Land Schleswig Holstein, das den Schülerdesktop km- Linux¹ hat entwickeln lassen und diese Distribution im eigenen Land kostenlos an Schulen verteilt.

„Neben dem zu erwartenden Verbreitungs- und langfristi- gen Nutzungsgrad der Software sind die technische und di- daktische Qualität sowie der Innovationsgehalt der Entwick- lung für die Förderung und deren Höhe ausschlaggebend. Dabei spielt auch die in Verbindung mit dem Inhaltsange- bot parallel zu entwickelnden neuen Konzepte für zugehö- rige Dienstleistungen (spezifische Info-Angebote für Lehrer, Nutzer-Hotline, Updates, etc.) und kooperative Ansätze über eine offene Plattform gerade im Schulbereich eine entschei- dende Rolle.“ (Edelgard Bulmahn, Zitat von der Homepage des BMBF, http://www.bmbf.de/, in Grassmuck 2002, Sei- te 322)

4.1.3 OSS in Nicht-G8-Länder

Nicht nur in Deutschland und in anderen westlichen Industrienatio- nen, wie in den USA durch die Initiative SEUL oder in Frankreich durch OFSET (vgl. für USA: http://www.seul.org/edu/, für Frank- reich: http://www.ofset.org/) finden Softwarelösungen mit einer „of- fenen Plattform“ im Bildungswesen breite Unterstützung durch NGOs, Wirtschaft und der Politik. Die mexikanische Regierung hat 1998 mit dem „Scholar Net“ Programm begonnen, was zum Ziel hat, 20 Millio- nen Schülern den Zugang zu einem Computer und damit auch zum Internet zu ermöglichen. Dafür ist die GNU/Linux Distribution „Red Escolar“ entwickelt worden, da eine proprietäre Lösung von Microsoft mit 124 Millionen Dollar zu teuer gewesen ist. Gerade in den Nicht-G8- Ländern spielt der Einsatz von OSS im Bildungsbereich eine zuneh- mend entscheidende Rolle. Hierfür sprechen neben dem didaktischen Potential vor allem Kosteneinsparungen bei der Anschaffung der Soft- ware und die Kompatibilität zu den vorhandenen Hardwareressourcen für OSS. Oft stehen in den Nicht-G8-Ländern nur Hardwaregeneratio- nen zur Verfügung, die in den Industrienationen für den kommerziellen Nutzen aussortiert worden sind, da sie den Anforderungen moderner proprietärer Software nicht mehr genügt haben. Da OSS wie zum Bei- spiel GNU/Linux modular aufgebaut ist, kann sie speziell an die Anfor- derungen des Nutzers und den vorhandenen Hardwareressourcen an- gepasst werden, was es ermöglicht, alte Hardware ressourcensparend mit moderner Software auszustatten.

„Wir glauben, dass Linux eine sehr wichtige Rolle beim Mo- dernisierungsprozess in Lateinamerika und in der Karibik spielen und Netzwerke errichten helfen kann, die es einer großen Zahl von Universitäten, Colleges, Schulen und Bil- dungszentren ermöglichen, am Internet teilzunehmen und dank dieses fabelhaften Werkzeugs ihr wissenschaftliches und kulturelles Niveau zu verbessern. Kurz, Linux ist das Mittel, um die technologische Kluft zwischen den Ländern abzubauen. Linux bietet Zugang zur ‚Informatik der fortge- schrittenen Länder‘ in einer Form, die den eingeschränk- ten wirtschaftlichen Fähigkeiten in unserer Region entgegen- kommt. Linux ist eine neue Art der Informatik, bei der ‚die technische Qualität und die Solidarität der Menschen‘ das Wichtigste ist.“ (http://www.unesco.org/evevts/latin/ cd_Linux_ing.html, in: Grassmuck 2002, Seite 328)

OSS bietet zwar einen Zugang zur „Informatik der fortgeschritte- nen Länder“, jedoch genügt es nicht, ärmeren Ländern ausgemuster- te Rechner zur Verfügung zu stellen und diese mit freier Software zu bespielen. Oft fehlen grundlegende informationstechnische Kenntnis- se, um Arbeitsplätze oder Netzwerke erfolgreich betreiben zu können. Vor allem freie Software wie GNU/Linux setzt im Gegensatz zu proprie- tärer Software wie Windows erhebliche informationstechnische Kennt- nisse voraus.

[...]

¹ Eigentlich: Quelltext; engl.: source code

² Auch: Binärprogramm, Binärobjekt; engl.: binary, binary object

³ Ein Bit ist die kleinste denkbare Informationseinheit; übrigens nicht nur für einen Computer.

⁴ engl.: compiler

⁵ engl.: central processing unit (CPU)

⁶ Und genau das ist es, das die Free-Software-Gemeinde seit Jahrzehnten zu leisten verdammt ist, um Hardware, deren Eigenschaften nicht dokumentiert sind unter Li- nux ans Laufen zu kriegen oder um Linux-Maschinen in einem Windows-Netzwerk zu integrieren, etc.

¹ In Deutschland ist Software durch §2 Abs. 1 Satz 1 des UrhG geschützt.

² GNU ist ein sogenanntes rekursives Akronym: GNU is not U nix. Rekursiv deswegen, weil sich das G in GNU wieder in GNU übersetzt; im mathematischen und infor- matischen Jargon ist „Rekursion“ synonym für den im Soziologischen bekannten Begriff „Selbstreferenzierung“. Dieses Benennungsschema ist seither in der Hacker- szene beliebt (z.B. WINE: W ine is not an emulator, PINE: Pine is not Elm). Die Be- hauptung, GNU sei kein Unix bedeutet, dass GNU zwar funktionell ein Unix ist, philosopisch und technisch jedoch den Anspruch des evolutionären Nachfolgers er- hebt. Ebenso geht WINE über das Konzept eines Emulators hinaus und PINE ist ein grundlegend anderes und besseres Emailprogramm als dessen Vorgänger Elm.

¹ vgl. http://www.lernnetz-sh.de/kmlinux/