Lerntheorien und neuere kognitionswissenschaftliche Erkenntnisse: Implikationen für den Unterricht

Die wissenschaftlichen Positionen zum Lernen und Lehren (Lerntheorien) werden in diesem Beitrag anhand aktueller Literatur nachgezeichnet. Das Konstrukt der pedagogical content beliefs, wie es von Peterson et al. (1989) sowie Staub und Stern (2002) genutzt wird, stellt ältere Theorien zu den Teachers’ Beliefs und neuere kognitionswissenschaftliche Erkenntnisse gegenüber.

Ausführungen zu den lerntheoretischen Schulen sind nach der Auffassung von Wissen, dem Verständnis des Lernprozesses und Implikationen für den Unterricht unterteilt. In den jeweiligen Abschnitten werden die Sichtweisen beider lerntheoretischen Überzeugungen einander gegenübergestellt. Natürlich können die Theorien in diesem Beitrag nicht allumfassend erläutert werden. Deshalb beschränken sich die Ausführungen auf einige wesentliche Aspekte, die ich als besonders fruchtbar für weitergehende Überlegungen betrachte.

Zu Beginn des 20. Jahrhunderts dominierte die Assoziationspsychologie und später der Behaviorismus die wissenschaftlichen Auffassungen zu Lernen und Lehren. Wie Staub und Stern (2002) berichten, prägt diese Sichtweise bis heute den Schulalltag (siehe auch Handal, 2003; Pajares, 1992; Thompson, 1992). Die daraus herrührende Vermittlungsüberzeugung bedient sich weiterhin behavioristischer Prinzipien. Die Darstellungen der Vermittlungsüberzeugung in diesem Beitrag gründen sich vor allem auf die Überblicksartikel von Collins et al. (2001), Greeno et al. (1996), Handal (2003), Holzinger (2001), Mayer (2003), Shuell (2001) und Slavin (1994) sowie den Aufsatz von Staub und Stern (2002).

Seit die kognitive Wende in den 1960er Jahren in der westlichen Psychologie allmählich das Bild des Reiz-Reaktions-Lernens abgelöst hat, etablierten sich neue Paradigmen, welche zum einen die Konzeption von Wissen grundlegend veränderten und zum anderen damit auch Verarbeitungs- und Konstruktionsprozesse in der lernenden Person anders zu betrachten verlangten (vgl. A. M. Collins et al., 2001; Greeno et al., 1996; Handal, 2003; Holzinger, 2001; Kunter, 2005; Mayer, 2003; Oerter, 2001; Reimann-Rothmeier & Mandl, 1998; Shuell, 2001; Slavin, 1994; Staub & Stern, 2002, die auch Grundlage für die folgende Darstellung der Konstruktionsüberzeugung bilden). Die Konstruktionsüberzeugung erhält ihren Namen aufgrund umfassender Einbeziehung von Argumenten konstruktivistischer Lerntheorien. In die Darstellung werden auch soziohistorische (Keiler, 1997; Wygotski, 1974) und weitere kognitivistische Ansätze eingeflochten. Dies entspricht neueren Darstellungen, die gelegentlich soziohistorische den konstruktivistischen und diese den kognitivistischen Theorien zurechnen (siehe exemplarisch Collins, Greeno, & Resnick, 2001; Greeno et al., 1996; Mayer, 2003; Sfard, 1998; Slavin, 1994).

Wissen

Vermittlungsüberzeugung. Es wird in der behavioristischen Tradition davon ausgegangen, dass der Lerninhalt sich vollständig auf Reiz-Reaktions-Verküpfungen reduzieren lässt. Diese lassen sich wie Objekte durch den Lernenden erwerben’. Der ‚Besitzer’ des Wissens hat damit „(…) an organized collection of connections among elementary mental or behavioral units. These units may be elemetary sensory impressions that combine to form percepts and concepts, or stimulus-response associations (…)” (Shuell, 2001, S. 8614). Diese Verknüpfungen können beobachtet oder gemessen werden, wie beispielsweise der erhöhte Speichelfluss beim Pawlow’schen Hund oder ein Gedichtvortrag eines Schülers in der Schule. Damit ist in dieser Konzeption Wissen auf das Zeigen bestimmter Verhaltensweisen in bestimmten Situationen beschränkt.

Konstruktionsüberzeugung. Während der frühe Kognitivismus Wissen noch als eine objektive Größe ansieht, wird diese Ansicht durch den Konstruktivismus revidiert. Das Wissen jedes Individuums wird als eng verknüpft mit individuellen Erfahrungen und Vorstellungen und damit als hochsubjektiv betrachtet. Im Lichte dieser kann eine objektiv identische Situation von verschiedenen Menschen interindividuell unterschiedlich repräsentiert werden. Von den Personen werden Informationen nicht als einzelne Einheiten im Gedächtnis gespeichert, sondern zu komplexen Konzepten verbunden. In diesen Konzepten können beispielsweise subjektive Erfahrungen, Regeln, Ideen und geeignete Anwendungen einer Domäne eine übergeordnete Einheit bilden. Der Begriff des konzeptuellen Verstehens gründet sich auf der gerade beschriebenen Vorstellung. Die soziohistorische Schule fügt dem Bild noch hinzu, dass Wissen nicht in isolierten Individuen existiert, sondern von der Kultur und ihren Gütern getragen wird.

Lernprozess

Vermittlungsüberzeugung. Der Schüler nimmt nach behavioristischer Auffassung das Wissen am besten auf, wenn der Lehrer mit zeitnah eingesetzter Verstärkung arbeitet, das heißt gewünschtes Verhalten belohnt und/oder ungewünschtes Verhalten bestraft. Werden einzelne Fertigkeiten oder komplexeres Problemlösen oft genug geübt, kann sich Verständnis entwickeln. Dabei ist die Rolle des Lerners eher passiv. Er nimmt lediglich den Unterrichtsstoff auf, den der Lehrer in möglichst kleinen, überschaubaren und gut strukturierten Einheiten vorträgt. Der Lehrer hingegen sollte das Lernumfeld kontrollieren, um gezielt beim Schüler neue Stimulus-Reaktions-Verkettungen zu erzeugen. Damit trägt er natürlich auch die direkte Verantwortung für den erzielten Lernerfolg. Fehler sollten aus der Vermittlungsüberzeugung nach Möglichkeit unterbunden werden, da sonst das Risiko falscher Assoziationen, also ungewollter Verknüpfungen von Wissensbausteinen besteht. Diese müssten dann mit großem Aufwand gelöscht und neu ausgeprägt werden. Eine gute Unterrichtseinheit ist aus der Vermittlungsüberzeugung dann erfolgt, wenn es dem Lehrer gelungen ist, sein Wissen möglichst verlustfrei an die Schüler weiterzugeben.

Konstruktionsüberzeugung. Die Umstrukturierung (conceptual change) oder Erweiterung (conceptual growth) der bereits vorhandenen Wissensbasis beziehungsweise eines Teils aktueller Überzeugungen (Sinatra und Kardash, 2004; Sfard, 1998) sind entscheidende Merkmale des Lernprozesses aus konstruktivistischer Perspektive. Eine Veränderung aktueller Konzepte ist vor allem dann wahrscheinlich, wenn der Lernende mit alten Erklärungsmustern unzufrieden ist und neue plausibel, überzeugender und nützlicher sind, sowie sich in alte Konzepte integrieren lassen. Aus diesem Grunde sind auch Fehler des Lernenden durchaus günstig für seinen Lernfortschritt. Dabei wird aus der Konstruktionsüberzeugung davon Abstand genommen, Lernstoff in kleine und abstrakte Informationseinheiten (so genannte chunks) aufzuteilen und diese einzeln zu lehren. Stattdessen wird angenommen, dass es günstiger ist, den Lerner mit komplexen, aber lebensnahen und bedeutungsvollen Inhalten zu konfrontieren. Diese helfen ihm, bisher bereits erarbeitete Konzepte zu nutzen und mit Unterstützung fachkundiger Lehrer (scaffolding) auszubauen oder abzuändern. Damit kommt dem Vorwissen des Lerners eine entscheidende Bedeutung zu.

Zudem wird in gegenwärtigen Modellen Lernen als ein aktiver und sozialer Konstruktionsprozess der Schüler betrachtet. Das bedeutet, dass Lernen immer innerhalb eines Kulturkreises stattfindet, dass der Lernende durch soziale Interaktion motiviert wird, seine Ziele unter Berücksichtigung seines sozialen Umfeldes entwirft und nicht zuletzt in der Auseinandersetzung mit anderen Lernern oder Experten seine Vorstellungen überprüft, gegebenenfalls revidiert und differenziert. Diesen Prozess nennt man auch Ko-Konstruktion. Beim Vertrautwerden mit Konzepten stärkt der Schüler zudem seine Interaktionsfähigkeit durch die Zusammenarbeit mit anderen bei der Bearbeitung bedeutungsvoller und lebensnaher Aufgaben (Shuell, 2001).

Implikationen für den Unterricht

Vermittlungsüberzeugung. Für die konkrete Unterrichtssituation umgesetzt impliziert eine behavioristische Perspektive, dass der Lehrer zunächst sein großes Lehrziel in viele kleine und übersichtliche Teilschritte unterteilen sollte. Diese Schritte sollte der Lehrer zur Vermeidung von Fehlern in der Information und ihrer Übertragung einzeln selbst vor der Klasse erarbeiten oder für eine effiziente Vermittlung durch Medien wie Computerprogramme oder Videos sorgen. Dann sollten diese kleinen Einheiten in ihrer Reihenfolge mit aufsteigender Komplexität von den Schülern ausgiebig geübt werden. Die Lernziele, welche die Lehrkraft zu Beginn einer Unterrichtseinheit präsentiert hat, können dann als Orientierung genutzt werden, um die Schüler regelmäßig mit klaren Rückmeldungen über ihren Lernfortschritt zu versorgen, sie zu Loben und Noten zu vergeben. Um das Wissen zu festigen sollten die Schüler die Aufgaben zu Hause erneut üben. Damit die Wissensvermittlung effizient ist, sollte die Lehrkraft im Lernumfeld potentielle Störquellen wie laut redende oder umherlaufende Schüler unterbinden. Am Ende einer Lerneinheit kann der Lehrer den Lernerfolg mittels Leistungstests leicht feststellen. Dazu entwirft er standardisierte Aufgaben, die messen, in welchem Maße die Schüler einzelne Wissenskomponenten wiedergeben können oder erlernte Fertigkeiten ausüben können.

Konstruktionsüberzeugung. Eine konstruktivistische Position heißt, dass die Rolle des Lehrenden sich besonders darauf bezieht, sowohl individuelle als auch interindividuelle Lernprozesse zu initiieren, zu moderieren und zu fördern. So sollte die Lehrkraft ein anregendes Lernumfeld schaffen, das Lernende animiert, sich aktiv mit dem Lerngegenstand auseinanderzusetzen und ihre Konzepte zu erweitern. Dies schließt auch den Ausbau von Kompetenzen in der Lösung von Problemen, dem Schlussfolgern und der Zusammenarbeit mit anderen ein. Dabei sollte die Lehrperson dem Vorwissen der einzelnen Schüler besondere Beachtung schenken (Staub und Stern, 2002; Holzinger, 2001). Da Konflikte neuer Erkenntnisse mit bereits vorhandenem Wissen zu entscheidenden Lernschritten führen können, ist es für den Lehrenden oft günstig, Fehler der Lernenden nicht zu vermeiden, sondern soweit verfolgen zu lassen, bis ihnen Unstimmigkeiten offenbar werden. Andererseits gehört es zu seinen Aufgaben, die Schülerinnen und Schüler an bestimmte Konzepte heranzuführen. Dies kann beispielsweise dadurch geschehen, dass er geeignete Strategien zur Problemlösung oder Interaktionsskripte zur gemeinsamen Bearbeitung in Gruppen anbietet, wie dies zum Beispiel beim Reciprocal Teaching (Palincsar & Brown, 1984) oder dem Ansatz des Cognitive Apprenticeship (A. Collins, Brown, & Holum, 1991a) der Fall ist.

Die Einschätzung des Lernerfolges kann nach konstruktivistischen Maßstäben kaum aus der Abfrage von Faktenwissen hergeleitet werden. Stattdessen sollte der individuelle Fortschritt in der Konstruktion von Problemen, die Interaktion bei der gemeinsamen Bearbeitung von Aufgaben oder die Nutzung von geeigneten Strategien prozesshaft evaluiert werden. In einer erfolgreichen Unterrichtsstunde aus der Konstruktionsüberzeugung haben die Schüler also ihr konzeptuelles Verständnis einer Problematik grundlegend verändert, erweitert oder ausdifferenziert.

Geschichte der Softwareprogrammierung: „Freie Software für Freiheit und Gerechtigkeit“

Es ist eine oft zitierte Tatsache, dass wissenschaftliche Entwicklungen weit häufiger von den Weltanschauungen und persönlichen Vorlieben der Wissenschaftler abhängen, als dies der Anspruch der Exaktheit, den Akademiker oft für sich beanspruchen, zulassen sollte. Ein Beispiel ist Richard M. Stallmans GNU-Projekt, das mit der Absicht gegründet wurde das Betriebssystem UNIX zu ersetzen. Als Stallman dieses Projekt 1983 ins Leben rief, tat er dies nicht um bessere Software zu schreiben als UNIX sie bot, sondern um seinen Vorstellungen von Freiheit und Gerechtigkeit Ausdruck zu verleihen.*

Um ein Verständnis der Verhältnisse zu bekommen, die Stallman zu seinen Vorstellungen und Idealen brachten, gebe ich in diesem Beitrag einen Überblick über wichtige Ereignisse der Geschichte der Softwareprogrammierung und erläutere hierbei die grundlegenden Ideen und Konzepte von freier Software.[1] Die Geschichte kann in zwei Teilen dargestellt werden. Der erste Teil schließt die Entwicklung bis zur Entstehung der ersten Betriebssysteme und die 1950er und 60er Jahre ein. Im zweiten Teil rücken die Zustände, die zur Entwicklung des GNU-Systems führten, also etwa die 1970er und die frühen 1980er Jahre, in den Mittelpunkt. Er beschäftigt sich hauptsächlich mit der Entwicklung des UNIX-Systems und dessen BSD-Variante, die er bis zu ihrer endgültigen Lösung von der Universität im Jahr 1995 verfolgt.

Daneben werden in dem Beitrag erste Schritte in Richtung der so genannten „intellectual property“ (Geistiges Eigentum[2] ) dargestellt. Gemeint sind dabei erste Versuche, Entwicklern von Software Rechte an ihren Produkten zu sichern, wie dies für Texte, Bilder oder Musikstücke seit längerem möglich war. Dazu richte ich den Blick insbesondere auf die entsprechende Diskussion in den Communications of the ACM[3] .

Softwaregeschichte der 1950er und 60er Jahre

Eine Geschichte der Softwareentwicklung zu schreiben ist allein deshalb ein Problem, weil dabei die Entscheidung getroffen werden muss, ab wann von Software gesprochen werden kann. Paul E. Ceruzzi datiert den Begriff auf die Zeit um das Jahr 1959[4] , allerdings ohne dafür eine bestimmte Quelle anzugeben.

In den 1950er Jahren begannen Computerhersteller mit ihren Produkten auch Software auszuliefern, die zu diesem Zeitpunkt noch Zugabe zum eigentlichen Produkt – der „Hardware“[5] – war. In den 1980er und 90er Jahren dann – mit der weiteren Verbreitung der Personal Computer (PC) – wurde Software dann zu einer eigenständigen Produktklasse, die unabhängig vom Kauf des eigentlichen Rechners vertrieben wurde.[6]

Ceruzzi sieht den Beginn der Softwareprogrammierung im Jahr 1944.[7] In diesem Jahr wurde am Computation Lab der Harvard Universität der Mark I[8] vorgestellt, ein elektro-mechanischer Rechner, der mathematische Anweisungen von Lochkarten lesen und verarbeiten konnte. Howard Hathaway Aiken, der die Maschine entwickelt hatte, wurde Grace Murray Hopper an die Seite gestellt, um die Rechenanweisungen auf die Lochkarten zu bringen und so den Mark I zu programmieren. Während Aiken also für die Maschine zuständig war, oblag es der Mathematikerin Hopper[9] die Recheninstruktionen zu erstellen.[10] Mit dieser Einteilung waren zum ersten Mal die Bereiche der „Hardware“ und der „Software“ erkennbar in zwei Produktionsbereiche getrennt.

Während die ersten Aufgaben, mit denen sich Hopper beschäftigte, noch Umsetzungen vergleichsweise einfacher Rechnungen waren, stellte sie bald fest, dass für viele größere Berechnungen bestimmte Nebenrechnungen immer wieder verwendet wurden. Es schien also sinnvoll, diese gesondert zur Verfügung zu stellen, um so überall dort, wo es nötig war, auf sie zugreifen zu können. Auf diese Art und Weise wären die Nebenrechnungen nur einmal zu programmieren bzw. in die Karten zu stanzen gewesen, was viel Zeit erspart hätte. Der Mark I hatte aber noch keine Möglichkeit die, später als Subroutinen bezeichneten, Nebenrechnungen extra zu speichern.[11]

Der Mark III, ein Nachfolger des Mark I, hatte dann die Fähigkeit elektro-magnetische Speichermedien einzulesen, so dass aus dieser Quelle auch Subroutinen zur Verfügung gestellt werden konnten. Für den Mark III hatte Aiken auch ein Zusatzgerät entwickelt, mit dem es möglich war, Anweisungen in der normalen mathematischen Form zu notieren. Diese „Tastatur“ wandelte die mathematische Notation in eine für den Computer verarbeitbare Form um. So standen die Anweisungen in zwei Formen zur Verfügung: In der mathematischen Notierung – die von der den Rechner programmierenden Person gelesen werden konnte – und in der binären Form, die vom Mark III verarbeitet werden konnte.

Mit der Möglichkeit elektro-magnetische Speichermedien zu lesen ergab sich also ein Weg Subroutinen immer wieder zu verwenden. Hopper arbeitete nun an einem Programm, das in der Lage war, Subroutinen von einem Band einzulesen und zusammenzustellen. Dieses Programm nannte sie „Compiler“.[12] In den Jahren 1952-53 entwickelte Hopper mehrere Versionen dieses Compilerprogrammes für den von John Mauchly gebauten UNIVAC-Rechner. Die dritte Version dieser Programme, die Hopper A-2 – die erste Version hieß A-0 – nannte, wurde mit den UNIVAC-Rechnern an Kunden ausgeliefert.[13] Wie bereits erwähnt, gehörten Computerprogramme lange zum Lieferumfang der Rechner und mussten nicht wie heute extra erstanden werden.[14]

Die den Compilern zu Grunde liegende Idee war es, ein Programm zu erstellen, das wie eine Fabrik im Ford’schen Sinne funktionierte. Wie ein Auto am Fließband (englisch: assembly line) sollte ein Compiler „automatisch“ ein Programm aus vorgegebenen Programmteilen zusammenstellen (to assemble). Aus Weiterentwicklungen der Compiler entstanden später die ersten Computersprachen, die unter der Bezeichnung „Assembler“ bekannt wurden.

Assembler sind recht einfache Sprachen, bei denen jede Anweisung direkt in die ihnen entsprechende Binärzahl umgewandelt wird. Zusätzlich können so genannte Macros angewandt werden, wobei ein Macro jeweils mehrere Anweisungen zusammenfasst. Zu den grundlegenden Aufgaben von in Assembler geschriebenen Programmen gehört es zum Beispiel, jedem laufenden Prozess jederzeit genügend Speicherplatz zur Verfügung zu stellen.

Firmen, die Computer herstellten, lieferten zwar mit ihren Maschinen passende Software aus, oft waren es aber die Benutzer, die für ihre Rechner die Programme schrieben. Für diese Benutzer war es beim Wechsel von einer Rechnergeneration zur nächsten immer ein Problem, die vorhandene Software an die neuen Gegebenheiten anzupassen. Aus diesem Grund trat im Jahr 1955 eine Gruppe von Nutzern des IBM 704 zusammen, deren Ziel es war, Software vom Vorgänger 701 auf den 704 zu übertragen.[15]

SHARE[16] , wie sich diese Gemeinschaft nannte, bestand aus Mitarbeitern verschiedener Firmen aus der Gegend um Los Angeles. Obwohl diese Firmen zum Teil miteinander in Konkurrenz standen, scheint der Vorteil, der sich daraus ergab Erfahrungen und Wissen miteinander zu teilen, wichtiger gewesen zu sein, als die Konkurrenz der Firmen untereinander. Während IBM – wie andere große Computerfirmen – an so genannten höheren Programmiersprachen (high-level languages) arbeitete, entwickelte die stetig wachsende SHARE-Gruppe im Laufe der Zeit eine recht umfassende Bibliothek an Routinen für den IBM 704, was in der Folge dazu führte, dass sich dieser Rechnertyp relativ schnell verbreitete.[17] Bald war SHARE wichtiger für die Unterstützung des 704 als der IBM-eigene Support. Hier zeichnete sich zum ersten Mal jene Art von Kooperation ab, die Richard Stallman etwa 30 Jahre später mit der Gründung des GNU-Projektes am Leben erhalten wollte.

Zu den oben erwähnten höheren Programmiersprachen zählten vor allem FORTRAN[18] und COBOL[19] . FORTRAN wurde 1957 von IBM für den 704 vorgestellt und wird bis heute in immer wieder veränderter Form verwendet. Zu den Vorteilen, die FORTRAN mit sich brachte, gehörte, dass beim Programmieren nicht – wie bei Assembler-Sprachen – die Struktur des Computers im Vordergrund stand, sondern die Lösung des gestellten Problems. Ein Compiler, im modernen Sinne des Wortes[20] , übernahm dann die Übertragung in die maschinen-lesbare Form.

Die andere wichtige Sprache, COBOL, die etwa zur selben Zeit entstand, verdankt ihre weite Verbreitung vor allem den Bestrebungen des U.S. Department of Defense (DoD), das 1959 ein Komitee damit beauftragte, Spezifikationen für eine Programmiersprache zum Einsatz in Wirtschaftsunternehmen zusammenzustellen. Das Department of Defense sollte von da an die weitere Entwicklung im Bereich der Softwareentwicklung durch verschiedene Vorgaben dieser Art beeinflussen und damit Quasi-Standards produzieren, deren Einhaltung für Unternehmen wichtig war, die ihre Produkte an staatliche Stellen vertreiben wollten.

Ein wichtiges Merkmal von COBOL war, dass sein Aufbau dem der englischen Sprache glich. Dadurch sollte der Umgang mit Computern vor allem für Geschäftsleute leichter werden. Zusätzlich sollte erreicht werden, dass Programme, die mit COBOL geschrieben waren, keiner weiteren Dokumentation bedurften. Ein großes Problem beim Schreiben von Computerprogrammen ist es jedoch bis heute, dass sie nicht selbsterklärend sind. Es muss also zu jedem Programm eine Dokumentation erstellt werden, die dessen einzelne Routinen erklärt. Ohne eine solche Dokumentation ist es im Nachhinein schwer oder gar unmöglich, das Programm zu verändern. Aber auch COBOL löst dieses Problem nicht. Es ist zwar grundsätzlich möglich, ein selbsterklärendes Programm in COBOL zu schreiben, dies ist aber nicht zwingend.[21] Wie FORTRAN ist auch COBOL heute noch in Gebrauch. Allerdings würden die meisten Programmierer weder FORTRAN noch COBOL als die Programmiersprache nennen, die sie hauptsächlich benutzen.

Mit der Entwicklung leistungsfähigerer Computer wurden an diese immer komplexere Aufgaben übergeben. Aus diesem Grund konnte ein einfacher Benutzer bald nicht mehr alle Verwaltungsaufgaben lösen, die während des Gebrauchs des Computers nötig wurden. Deshalb entwickelten Firmen und Benutzergruppen immer mehr kleinere und größere Programme, die solche Aufgaben während des Betriebes übernahmen. Diese Programme, die zunehmend auch untereinander Daten austauschten und im Hintergrund ihre Tätigkeiten verrichteten, sind allgemein unter der Bezeichnung „Systemsoftware“ bekannt. Solche „Systeme“ kamen in der Mitte der 1950er Jahre auf und sind heute Basis für den Gebrauch von Computern.[22]

Die Veränderungen in der Namensgebung dieser in Umfang und Einsatzmöglichkeiten stetig wachsenden Softwaregruppen verdeutlicht ihre zunehmende Bedeutung: Erste Systeme wurden noch als „monitor“ bezeichnet, da ihre Aufgabe vornehmlich darin bestand, während des Betriebes den Verlauf der Rechnungen zu kontrollieren. Diese Aufgaben wuchsen und so hießen die Systeme dann „supervising system“, wobei hier der Gedanke des Systems als Gruppe interagierender Programme schon im Namen steckt. Später erst bekamen diese Systeme die Bezeichnung „operating system“ (OS) oder Betriebssystem. Heute ist es kaum denkbar, einen Computer einzusetzen, ohne dass dabei ein Betriebssystem im Hintergrund läuft.

Frühe Diskussionen um die rechtlichen Sicherungsmöglichkeiten von Software

Ein sehr wichtiger Aspekt in der Diskussion um Freie Software ist der rechtliche Schutz, der den freien Status sichert. Dabei werden Konzepte benutzt, die ihren Ursprung in den 1960er Jahren haben. Nachdem in den 1950er und frühen 1960er Jahren entwickelte Software als notwendiger Zusatz zu den eigentlichen Computern gesehen wurde, stellten die Herstellerfirmen im Laufe der Zeit fest, dass sich aus entsprechend weit verbreiteter Software ein Wettbewerbsvorteil ergab, den es zu sichern galt. In den Communications of the ACM wurden in den 1960er Jahren Konzepte diskutiert, mit denen eine solche rechtliche Sicherung erwirkt werden könnte.

Angeregt wurden die Beiträge in den Communications unter anderem von der Diskussion um eine Veränderung des Copyrights in den USA. Dabei ging es um eine Neufassung des Copyright-Gesetzes, die sowohl den Schutz von Software, als auch die Behandlung digitalisierter Texte und Musikaufnahmen klären sollte. Auffällig ist, dass schon zu dieser Zeit viele der heute noch aktuellen Argumente für und wider das so genannte „Geistige Eigentum“[23] gebraucht wurden. Zur Diskussion standen dabei neben dem Copyright-Schutz[24] von Software auch der Schutz durch Patente und (in einem Fall)[25] durch Trade Marks (Warenzeichen).

Das Copyright, das Recht zu bestimmen wer unter welchen Umständen Kopien eines Textes herstellen und vertreiben darf, sollte „den Fortschritt in der Wissenschaft und den nützlichen Künsten […] fördern“.[26] Hier setzte – und setzt auch heute – die Kritik am Copyright selbst an. Das Copyright-Gesetz sehen viele als hinderlich an, weil in Bildung und Wissenschaft sehr viel Geld aufgewendet werden muss, um Bücher zu kaufen, Tonaufnahmen einzusetzen und öffentliche Aufführungen zu veranstalten.[27] Um diese Behinderung der Ausbildungsmöglichkeiten zu vermeiden, gibt es in der Copyright-Gesetzgebung die Regelung des „fair use“, das bestimmte Formen des Gebrauchs (bei Tonaufnahmen beispielsweise das Herstellen von Kopien für den eigenen Gebrauch) vom Copyright ausnimmt.

Auf den Computer bezogen gibt es zwei Punkte, die seit den 1960er Jahren im Gespräch sind: Zum einen sollte der neue Entwurf des Copyright-Gesetzes nun auch auf Software anwendbar sein und so Entwicklern von Software die Möglichkeit geben, ihre Arbeit bzw. deren Vermarktung zu sichern. Zum anderen ging es schon in dieser Diskussion um die digitale Repräsentation von Texten und Tonaufnahmen. Im letzten Fall war die Befürchtung wohl, dass durch die Umwandlung der Texte und Aufnahmen das auf sie angewandte Recht unterlaufen würde.

Reed C. Lawlor setzte 1964 noch die Kosten, die z.B. der kompletter Ausdruck eines digitalisierten Werkes verursachen würde, als Argument gegen das Übertragen des Copyright auf Kopien im Computer ein: „There is little danger that computers will be used for printing copies of a copyrighted book for sale. It would be too expensive“[28] . Deshalb glaubte er auch nicht, dass es sinnvoll sei, das Copyright auf digitale Repräsentationen von Copyright-geschützten Werken auszuweiten.

Bei der Übertragung von Copyright-Regelungen auf Computerprogramme sah Lawlor die verschiedenen Formen (also Source- und Binärcode) als Problem. Er schlug zur Lösung des Problems vor, neu geschriebene Programme in gedruckter Form zu veröffentlichen.[29] Da das Copyright jeden gedruckten Text schützt, stünde so auch das neu veröffentlichte Programm sofort unter Copyright-Schutz. Bei dieser Überlegung ging Lawlor offensichtlich noch davon aus, dass der Sourcecode auf jeden Fall mitveröffentlicht würde. Obwohl heute die meisten proprietären Programme gar nicht mehr als Texte zu erhalten sind, gilt für sie seit der Gesetzesänderung trotzdem der Copyright-Schutz.[30]

Als nächstes stellte sich die Frage, ob das Copyright auf den Gebrauch eines Programms im Computer ausdehnbar sei. Lawlor sah diesen Schutz, unter dem Copyright, wie es in den 1960er Jahren bestand, nicht gegeben, weil das Programm zum Gebrauch in eine andere Form überführt werden müsse. In dieser Form (als Binärcode) sei es kein Text im eigentlichen Sinne und fiele also auch nicht mehr unter diesen Schutz. Die Besitzer von Copyright-geschützten Programmen könnten also deren Gebrauch nicht verhindern. Deshalb waren für Lawlor Patente die einzige Lösung für dieses Problem.[31]

In derselben Ausgabe der Communications befasste sich Morton C. Jacobs genau dieser Frage der Patentierbarkeit von Computerprogrammen. Das Patentsystem soll für gegenständliche Erfindungen das regeln, was im geistigen Bereich das Copyright regelt. Patente werden vergeben, um Erfindern das Veröffentlichen ihrer Erfindungen schmackhafter zu machen und sie zu neuen Erfindungen zu ermutigen. Wie beim Copyright fand auch beim Patentrecht in den 1960er Jahren eine Diskussion über dessen Übertragbarkeit auf Software statt. Da Computerprogramme keine Maschinen oder Werkzeuge sind, fielen sie für Jacobs eigentlich nicht in den Bereich des Patentrechts. Dazu gab Jacobs als Beispiel mathematische Rechenschritte an, die ebenfalls nicht patentierbar waren. Im Gegensatz zu Werkzeugen oder Maschinen, die auf diese mathematischen Rechnungen zurückgingen.[32]

Ohne im Detail nachvollziehen zu wollen, wie Jacobs zu dem Schluss kam, dass Computerprogramme durchaus patentierbar seien, sollen hier einige seiner Überlegungen angerissen werden: Zum einen kam Jacobs zu der Unterscheidung von Daten (data) und den eigentlichen Programmen. Während die Daten sich für jeden Rechenvorgang ändern können, müssen die Rechenwege eines patentierbaren Programmes immer die gleichen sein. Als Menge von Daten verstanden, könnte ein Programm natürlich nicht patentiert werden. Jacobs brauchte also ein anderes Verständnis von Programmen. Er führte dazu Computer an, die nur für einen bestimmten Zweck gebaut werden. Diese nannte er „special purpose“-Computer. Solche Computer konnten als Maschinen durchaus patentiert werden. Es lag also nahe, Programme, die auf „general purpose“-Computern liefen und dort die gleichen Funktionen erfüllten, ebenfalls patentieren zu können.[33] Jacobs legte also die Programme als auswechselbare Werkzeuge der Maschine Computer aus, um sie in den Bereich des Patentschutzes zu bringen.

Diese beiden Beispiele, Lawlor und Jacobs, zeigen auf, wie schwierig der Begriff Software schon in den 1960er Jahren zu erfassen war. Die unterschiedlichen Zustände, die Software haben kann – Sourcecode, Binärcode, und als Binärcode einmal als Daten und einmal als Rechenanweisungen – führten zu verschiedenen Rechtsmitteln, die eingesetzt wurden um Software zu schützen. Keines dieser Rechtsmittel wurde aber eigens für Software geschaffen und so passt auch keines wirklich. Heute wird Software sowohl unter den Schutz des Copyrights gestellt als auch (zumindest zum Teil) patentiert. Meist gehört zu einem Programm jedoch eine Lizenz, die seinen Gebrauch regelt und die Besitzrechte garantiert. Zusätzlich werden viele Programme als Firmengeheimnisse (trade secrets) behandelt. Dies bedeutet vor allem, dass Kunden beim Kauf eines Software-Paketes nur die maschinen-lesbaren Dateien, nicht aber den dazugehörigen Sourcecode erhalten.

Von der Öffnung des Softwaremarktes zu proprietärer Software

War es 1944 die Arbeit Hoppers, die zu einer Trennung von Hard- und Software in zwei voneinander unabhängige Produktionsschritte führte, so sollte 1969 der Druck der US-Regulierungsbehörden endgültig auch zu zwei voneinander getrennten Produkten führen. Im Dezember 1968 kündigte IBM an, dass es ab dem nächsten Jahr seine Softwareprodukte unabhängig von seiner Hardware verkaufen werde. Dies geschah, um den Softwaremarkt, den IBM durch seine Vorherrschaft auf dem Computersektor bereits innehatte, für andere Softwarehersteller zu öffnen. Mit dieser Entscheidung wurde der Weg geebnet für Firmen, die ausschließlich Software herstellten und verkauften. Ein neuer Markt entstand, der im Laufe der Zeit den eigentlichen Computermarkt an Kapitalkraft bei weitem übersteigen sollte. Natürlich ging mit dieser Entwicklung auch die weitere rechtliche Absicherung von Software als Geistiges Eigentum einher.

Etwa zur selben Zeit begannen Ken Thomson und Dennis Ritchie mit der Entwicklung eines Betriebssystems, das später zum UNIX operating system[34] werden sollte. Dieses System, das in den Bell Telephone Laboratories entstand, war ursprünglich nur für den internen Gebrauch der Laboratories gedacht, fand später aber wesentlich weitere Verbreitung.

Die erste UNIX-Version, die ab 1969 entstand, war noch in einer Assembler-Sprache geschrieben und für einen PDP-7-Rechner der Digital Equipment Corporation (DEC) gedacht. Als sie UNIX wenig später auf einer PDP-11 einsetzen wollten, entwickelten Thomson, Ritchie und deren Kollegen eine eigene Programmiersprache für ihr System. Diese Sprache, die lediglich einen Buchstaben („B“) als Namen hatte, wurde 1973 zu der Grundform der Sprache „C“, die heute zu den meistgenutzten Programmiersprachen gehört. Einer der großen Vorteile von C gegenüber vielen älteren Programmiersprachen ist, dass C beim Programmieren zwar Prozeduren zulässt, wie sie bei Assembler-Sprachen noch üblich waren (also z.B. das Ansteuern einzelner Speicherplätze für bestimmte Ergebnisse von Operationen), diese aber nicht zwingend vorsieht. C eignet sich also sowohl für systemnahe (low level) als auch für problemnahe (high level) Programmierung. So entstanden parallel eines der in der Folgezeit wichtigsten Betriebssysteme und eine der einflussreichsten Programmiersprachen.

Es waren vor allem zwei Eigenschaften, die UNIX bald so beliebt werden ließen: Zum einen gehörte es zu den ersten Betriebssystemen, die „time sharing“ erlaubten. In diesem Zusammenhang bedeutet time sharing, dass mehrere Benutzer gleichzeitig an einem Computer arbeiten können, ohne dass (im Idealfall) ein Benutzer von der Arbeit eines anderen gestört wird. Wie früher einzelnen Prozessen, konnte nun verschiedenen Benutzern Rechenzeit eingeräumt werden.[35] Für die Computernutzer war das Arbeiten an einem time sharing-Computer fast wie das Arbeiten an einem PC.[36] Mit dem Computer[37] verbunden waren (und sind auch heute oft noch) eine Reihe so genannter Terminals, an denen je eine Person arbeitete. Diese Terminals – Eingabegeräte (Tastatur und gegebenenfalls Maus) und Bildschirm – konnten in unterschiedlichen Räumen stehen, so dass weder der eigentliche Computer, noch andere an ihm Arbeitende vom eigenen Arbeitsplatz aus zu sehen waren. So hatte wirklich jede Person das Gefühl an einem eigenen Gerät zu arbeiten.

Die zweite Eigenschaft, die wenig später wichtig werden sollte, war die verhältnismäßig leichte Portierbarkeit des Systems. Wie im Zusammenhang mit der SHARE-Gruppe besprochen, war eines der größten Probleme beim Wechsel von einem Rechnertypen zu einem anderen das Übertragen der Software. Diesen Vorgang bezeichnet man auch als Portieren. Wie weiter unten noch beschrieben wird, sind Unix-Systeme so aufgebaut, dass nur ein relativ kleiner Teil an einen neuen Rechner angepasst werden muss, der Rest kann ohne größere Veränderungen einfach übernommen werden.

UNIX wurde, wie gesagt, bald auch außerhalb der Bell Labs bekannt. Da AT&T, zu dem die Bell Labs gehörten, im Geschäftsbereich Telekommunikation ein Quasi-Monopol hatte, war es der Firma untersagt, in anderen Bereichen tätig zu werden – auch hier waren die Regulierungsbehörden ausschlaggebend für diese Einschränkung. An Universitäten wurde sowohl das System als auch der Sourcecode für relativ geringe Summen abgegeben. So konnten Studierende nicht nur an Rechnern mit UNIX arbeiten, sondern es auch ihren Bedürfnissen bzw. den Erfordernissen ihrer jeweiligen Arbeitsplätze anpassen.

Unix-Systeme sind modular aufgebaut, das heißt, sie bestehen eigentlich aus vielen kleineren Programmen und sind keine einheitlichen Systeme wie viele andere Betriebssysteme. Für einzelne Funktionen, die das Betriebssystem übernehmen soll, kann jederzeit ein neues zusätzliches Programm geschrieben oder ein vorhandenes Teilprogramm den Wünschen angepasst werden, ohne dass das ganze System verändert werden muss. So kann das System beispielsweise an einen neuen Rechnertypus angepasst werden, indem einfach der Kernel – der Teil, der unter anderem Hardware und Software miteinander interagieren lässt – verändert wird.

Der Vorteil, der für AT&T daraus entstand, seine Sourcen mit dem Programm zu verteilen, bestand darin, dass sich bald eine Tauschgemeinschaft über die ganze USA ausbreitete. Wenn zum Beispiel irgendwo ein neuer Druckertyp angeschlossen wurde, konnte bald auch an jedem weiteren UNIX-Rechner ein solcher Drucker angeschlossen werden, ohne dass AT&T erst neue Treiber auf den Markt bringen musste.

An der Universität Berkeley (Kalifornien) entstand aus den dort geschriebenen Programmen eine berühmte Distribution[38] , die unter dem Namen Berkeley Systems Distribution (BSD) bekannt wurde. Während UNIX selbst mit einer Lizenz vertrieben wurde, die alle Rechte an dem System bei AT&T beließ – wie dies heute bei den meisten Computerprogrammen immer noch der Fall ist – wurde die BSD-Distribution nur mit einer Notiz versehen, die den Anwendern alle Rechte offenließ. Einzige Einschränkung war, dass eventuelle Nachfolgeprodukte einen Hinweis darauf enthalten mussten, dass sie auf BSD fußten. Außerdem durfte für solche Produkte nicht mit dem Namen der Distribution oder dem Verweis auf die Universität von Berkeley geworben werden.[39]

An der Kombination von UNIX und BSD lassen sich nun einige Phänomene zeigen, die häufiger im Zusammenhang mit Programmen, die an einer Universität entstanden waren und mit Programmen, an denen Benutzer mitgewirkt hatten, auftraten: Das erste Phänomen ist die Abwanderung von Studenten in die Industrie, wobei diese Studenten Produkte, die im universitären Zusammenhang entstanden waren, mitnahmen und mit ihnen Firmen gründeten bzw. in Firmen neu einstiegen. Im Fall von BSD war dies Bill Joy von SUN Microsystems.

Joy hatte, unterstützt mit Geldern des Staates, an der Erweiterung der Möglichkeiten des UNIX-Systems gearbeitet. SUN, Anfang des Jahres 1982 von Vinod Khosla gegründet, hatte bereits eine erste Version seiner Workstations auf dem Markt, als Joy im Juni des Jahres in die Firma eintrat und BSD/UNIX mitbrachte. Workstations waren ebenfalls eine Universitätsentwicklung: SUN steht für „Stanford University Networked workstation“.

Sowohl die Workstations – eigenständige kleinere Rechner, ähnlich den späteren PCs, die in der Regel in einem Netzwerk (oft mit einem größeren Serverrechner) verbunden sind – als auch UNIX hatten den Austausch von Daten als eine grundlegende Designeigenschaft vorgegeben. Bei den Workstations war „networked“ bereits im Namen enthalten, aber auch die Programmierer von UNIX und BSD hatten das Arbeiten in Netzwerken bei der Entwicklung im Hinterkopf. So entstand bei SUN Microsystems aus zwei Forschungsprojekten von Universitäten eine Kombination, die der Firma lange eine wichtige Position auf dem Markt bescheren sollte. Trotz seiner Tätigkeit bei SUN beschäftigte sich Joy jedoch auch weiter mit dem BSD-Projekt an der Universität.

Ein zweiter Punkt, an dem die Entwicklungen um UNIX und BSD typisch für den ganzen Softwarebereich und, in diesem Fall, für große Teile der Wissenschaftsentwicklung in den USA waren, ist die Quasi-Standardisierung durch die Defense Advanced Research Projects Agency (DARPA).[40] Die DARPA war 1958 gegründet worden, um im Rahmen des „Kalten Krieges“ die wissenschaftlichen Entwicklungen in den Vereinigten Staaten voranzutreiben.[41] In diesem Zusammenhang wurde ab 1969 ein computergestütztes Netz zwischen unterschiedlichen wissenschaftlichen Organisationen in allen Teilen der Vereinigten Staaten etabliert. Das ARPANET, wie dieses Netz genannt wurde, ist einer der Vorläufer des Internets.

Sinn des ARPANETs war die Förderung des elektronischen Datenaustausches zwischen den angeschlossenen Organisationen. Da die unterschiedlichen Organisationen verschiedene Bedürfnisse hatten, war die Standardisierung der Hardware innerhalb des Netzes nicht möglich. Um aber den Austausch von Dateien auf den unterschiedlichen Architekturen[42] zu ermöglichen, wurde 1979 entschieden, auf allen angeschlossenen Rechnern BSD/UNIX als Betriebssystem einzusetzen. Diese Entscheidung fiel zum einen wegen der bereits angesprochenen verhältnismäßig leichten Portierbarkeit von UNIX und zum anderen wegen der weiten Verbreitung und des guten Rufes, den die dritte Zusammenstellung der Berkeley-Software bereits hatte.

Die Förderung durch die DARPA führte dazu, dass die Entwicklung der Berkeley-Distribution weit schneller voranging als die kommerzielle Version von AT&T. Besonders die Netzwerkqualitäten des Originals standen hinter denen der Universitätsversion weit zurück, denn die BSD-Entwickler hatten inzwischen Möglichkeiten geschaffen, mit denen nicht nur Dateien ausgetauscht werden konnten. Auf Rechnern, auf denen BSD lief, konnten sich Benutzer anmelden und arbeiten, die an anderen Rechnern des Netzes saßen. Der Rückstand führte dazu, dass 4.3BSD weit beliebter war als System V, die entsprechende AT&T-Variante. Obwohl dies so war, mussten Institutionen, die BSD auf ihren Maschinen laufen ließen, weiterhin für die originale UNIX-Lizenz bezahlen, die immer teurer geworden war. BSD, das auf UNIX fußte, enthielt zu diesem Zeitpunkt noch große Anteile der Bell Software. Mit Release 4.3 wurde der Wunsch immer größer eine eigenständige Variante zu haben, die nur unter der in Berkeley benutzten Lizenz zu erhalten war. Es entstand 4.3BSD-Tahoe, das 1988 wegen der besonderen Ausrichtung, die BSD durch die DARPA Förderung genommen hatte, als Networking Release 1 veröffentlicht wurde. Für diese Veröffentlichung galten zwar die üblichen Lizenz-Bedingungen aller Veröffentlichungen von Berkeley-Software, aber eine Ausgabe direkt von der Universität kostete trotzdem noch 1.000 $. Erstaunlich ist, dass mehrere hundert Bänder auf diese Art vertrieben wurden, obwohl die Software auch kostenfrei erhältlich war.

Parallel zu der nur unter der BSD-Lizenz vertriebenen Version[43] wurde auch an der Standardversion weitergearbeitet. Die zusätzlichen Programme, die hierbei entstanden, wurden bis 1991 wieder in die reine BSD-Veröffentlichung integriert, die dann unter dem Namen Networking Release 2 veröffentlicht wurde. Neben diesen beiden Versionen entstand in den 1990er Jahren noch eine Version, die nur für den Gebrauch auf der 386-Architektur gedacht war, die den inzwischen erhältlichen PCs zugrunde lag. Bill und Lynne Jolitz hatten sich dieser Aufgabe gewidmet, die jedoch bald so aufwändig war, dass eine Gruppe von Entwicklern gegründet wurde, um die als 386BSD begonnene Arbeit fortzuführen. Diese Gruppe nannte ihr Produkt NetBSD, weil die gemeinsame Arbeit hauptsächlich über das Internet koordiniert wird. Wenig später formte sich eine zweite Gruppe dieser Art, die ihre Arbeit mehr an technisch nicht besonders versierten Benutzern ausrichtete. Das Resultat wird unter dem Namen FreeBSD veröffentlicht. Als dritte Gemeinschaft löste sich die OpenBSD-Gruppe von NetBSD. Ziel von OpenBSD ist es, ihre Version möglichst sicher gegen unberechtigte Zugriffe zu machen.

Neben diesen drei Gruppen, die das freie BSD-System weiterentwickeln, wurde 1992 eine Firma gegründet, die BSD vertreiben sollte. Diese Firma – Berkeley Software Design, Incorporated (BSDi) – trat direkt in Konkurrenz zu den Unix System Laboratories (USL), die inzwischen das originale UNIX vertrieben. In einer von USL angestrengten Klage ging es neben dem Gebrauch des Markennamens UNIX auch darum, dass BSD auf das ursprüngliche UNIX zurückging und, so die USL-Vertretung, folglich Teile des Originalcodes enthalten müsse. BSDi beantwortete die Klage damit, dass ihr Produkt auf die frei verfügbare Version von BSD zurückgriff, die Schuld folglich bei der Universität zu suchen sei.

Der folgende Rechtsstreit, der sich über die nächsten zwei Jahre hinzog, sollte allen BSD-Folgeprojekten schaden, indem er große Teile ihrer Gefolgschaft verunsicherte. Am Ende der Streitigkeiten mussten aus den etwa 18.000 Dateien des Networking Release 2 ganze drei entfernt werden. Zusätzlich enthält dieser Release etwa 70 weitere Dateien, auf denen noch ein USL-Copyright liegt.

Im Juni 1994 veröffentlichte Berkeley mit 4.4BSD die letzte Universitätsversion des Systems. Wie vorher gab es eine freie Version und eine, die weiterhin USL Lizenzen unterlag. Auf der freien, als 4.4BSD-Lite veröffentlichten Version basieren heute alle erhältlichen Versionen von BSD.[44] Im Juni 1995, nach der Veröffentlichung der 4.4BSD-Lite Release 2, die noch inzwischen gefundene Fehler der ersten Ausgabe korrigierte, wurde die Produktion des Systems in Berkeley endgültig eingestellt.[45]

 


[1] Zu intensiverer Lektüre dieser Geschichte empfiehlt sich Ceruzzi 2000, der diesem Teil der Arbeit als Hauptquelle zugrunde liegt.

[2] „Geistiges Eigentum“ wird, wo der Begriff in dieser Arbeit benutzt wird, als feststehender Ausdruck behandelt und deshalb groß geschrieben.

[3] Die 1947 gegründete Association for Computing Machinery (ACM) ist die älteste wissenschaftliche Organisation im Bereich Computer und Software. Die monatlich erscheinenden Communications of the ACM sind eine der am weitesten verbreiteten Veröffentlichungen in diesem Bereich.

[4] Ceruzzi 2000, S. 315 (Endnote 22)

[5] Auch dieser Begriff war natürlich noch nicht in Gebrauch.

[6] Vgl. Ceruzzi 2000, S. 9 ff.

[7]Ich werde auch für die Zeit vor 1959 von Software sprechen, weil sich kein anderer Begriff anbietet und es sich, im Rahmen der Entwicklung, eigentlich um etwa denselben Gegenstand handelt.

[8]Im Folgenden wird es zur Identifizierung nötig sein, einzelne Computer aufzuzählen. Ich möchte aber darauf verzichten, neben der Softwaregeschichte auch noch eine Computergeschichte anzureißen. Deshalb verzichte ich auf Details wie Namenserklärung oder Versionsfolge.

[9]In diesem Zusammenhang fällt auf, dass die Geschichte der Programmierung mit einer Frau beginnt. Heute, wie eigentlich in allen folgenden Perioden dieser Geschichte, sind und waren es vor allem Männer, die Programme für Computer schrieben und noch schreiben. Frauen sind in der Geschichte der Softwareentwicklung allgemein, aber auch der Freien Software im Besonderen, Ausnahmen.

[10] Ceruzzi 2000, S. 81f.

[11] Ceruzzi 2000, S. 82 f.

[12]Heute beschreibt der Begriff Compiler ein Programm, das einen in einer Programmiersprache geschrieben Text (Sourcecode) in einen maschinen-lesbaren Text (Binärcode) umwandelt.

[13] Ceruzzi 2000, S. 85 f.

[14]Natürlich sind auf den meisten Computern, die heute zu kaufen sind, auch schon Systeme und Programme installiert. Sie gehören aber eigentlich nicht zu den Rechnern, sondern werden zusätzlich mitberechnet.

[15]Vgl. Ceruzzi 2000, S. 87 f.

[16]SHARE stand für Society to Help Avoid Redundant Effort. Vgl. Ceruzzi 2000, S. 330

(Endnote 32)

[17]Ceruzzi 2000, S. 88]

[18]Für Formula Translation

[19]Für Common Business Oriented Language

[20]Also ein Programm, das aus Sourcecode binären Code „kompiliert“, nicht wie bei Hopper ein Programm, das aus unterschiedlichen Subroutinen ein Programm zusammenstellt.

[21]Ceruzzi 2000, S. 93

[22]Vgl. Ceruzzi 2000, S. 96

[23]Geistiges Eigentum (intellectual property) ist der Versuch, geistige Produkte wie literarische (und wissenschaftliche) Texte und Musik, aber auch Software mit einem einzigen Begriff zu belegen. Dieser wird jedoch von Gegnern des rechtlichen Schutzes von Software abgelehnt, weil ihrer Meinung nach Texte, die eine bestimmte Meinung oder Geisteshaltung ausdrücken, nicht mit Software zu vergleichen sind, die den Versuch darstellt, ein bestimmtes Problem zu lösen, das sich beim Gebrauch eines Computers ergibt.

[24]Problematisch an dieser Diskussion ist heute, dass der Schutz durch das Copyright nicht wirklich mit dem entsprechenden Schutz in anderen Ländern vergleichbar ist. So gelten für das Urheberrecht in Deutschland ganz andere Voraussetzungen als für das amerikanische Copyright. Außerhalb der USA ist eine Lizenz, die auf der Copyright-Gesetzgebung beruht, also möglicherweise gar nicht gültig. Dieser Punkt ist gerade jetzt ein Problem für Freie Software, wo die Free Software Foundation weltweit Ableger gründet.

[25]Nämlich Galler, Mooers 1968. Da es sich hierbei vor allem um das Recht am Namen eines Produkts handelt, habe ich diese Diskussion nicht weiter ausgeführt. Galler weist Mooers dabei darauf hin, dass die einfache Umbenennung eines Derivates diese Maßnahme relativ leicht aushebelt.

[26]Siehe Lawlor 1964, S. 572

[27]Gemeint sind hier zum Beispiel Theateraufführungen an Schulen und Universitäten, bei denen Eintritt genommen werden soll.

[28] Lawlor 1964, S. 576

[29]Gedruckt, im Gegensatz zur bis dahin gängigen Praxis, den Text einfach als Textdatei mit der ausführbaren Datei mitzuliefern, was Lawlor wohl nicht als Veröffentlichung im Sinne der Copyright-Regelung verstand.

[30]Ausnahme sind Programme in der „Public Domain“, d.h. Programme, bei denen der Autor explizit auf jeglichen Schutz verzichtet.

[31] Lawlor 1964, S. 577

[32] Jacobs 1964, S. 583 f.

[33] Jacobs 1964, S. 583 f.

[34]Heute gibt es verschiedene Systeme, die alle unter dem Namen Unix zusammengefasst werden. Dabei scheint es Probleme mit der Benennung zu geben. Ich verwende Unix (bei anderen Autoren finden sich Varianten wie *nix, un*x oder auch unix) als Namen für ein beliebiges System dieser Art. Die Version in Großbuchstaben benutze ich für das Originalsystem bzw. das Nachfolgesystem, dessen Namensrecht heute bei der Firma Caldera liegt. Vgl. die Einträge „Unix“ und „UN*X“ in Raymond 2001.

[35]Wie dies genau geschieht und zur Geschichte des Begriffes, der auch vorher schon in Gebrauch war, siehe Ceruzzi 2000, S.154.

[36]PCs gab es natürlich zu diesem Zeitpunkt noch nicht, aber die Möglichkeiten von „time sharing“-Computern werden oft mit denen der späteren Personal Computer verglichen. Vgl. Ceruzzi 2000, S. 207.

[37]Dies waren so genannte „Main Frame Computer“ (oder einfach „Main Frames“) die noch ganze Räume füllten.

[38]Mit Distribution ist eine Sammlung von Programmen gemeint. GNU/Linux-Systeme werden heute auch als Distributionen vertrieben, dabei unterscheiden sich die einzelnen Distributionen dadurch, welche Programme neben dem Linux-Kernel und den GNU-Programmen noch eingebunden werden.

[39]Diese Notiz ist genau genommen eine der simpelsten Formen die Copyright-Gesetzgebung auf ein Programm anzuwenden. Heute wird diese Notiz, die ohne die Werbe-Klausel von einigen BSD-Nachfolgeprojekten benutzt wird, auch als „BSD Copyright Notice“ bezeichnet.

[40]Zur Standardentwicklung auf Betreiben der DARPA und zur späteren Freigabe von Standards siehe Newmann 1999.

[41]Bei ihrer Gründung hieß die DARPA noch ARPA (Advanced Research Projects Agency). Der Name wurde 1972 geändert. 1993 wurde das Defense im Namen auf Betreiben des damaligen Präsidenten, Bill Clinton, fallen gelassen, 1996 jedoch wieder hinzugefügt. Bis zur ersten Namensänderung unterstand die ARPA dem Department of Defense, danach war die DARPA direkt dem Office of the Secretary of Defense unterstellt. Vgl. DARPA 2001.

[42]Der technische Aufbau eines Computers wird auch als seine Architektur bezeichnet. Normalerweise wird bei der Bezeichnung einzelner Architekturen der Name des verwendeten Prozessors vorangestellt. Die 386-Architektur basiert z.B. auf dem 386-Prozessor der Firma Intel.

[43]Bei der anscheinend noch der Systemkernel des alten UNIX-Systems benutzt wurde.

[44]Das ist neben den drei freien und dem Produkt von BSDi auch der Darwin-Kernel, der dem MacOS X-System zugrunde liegt. Außer diesen und dem AT&T UNIX gibt es noch unix-ähnliche Betriebssysteme der Firmen DEC, IBM, HP und natürlich SUN. Insgesamt gibt es, wenn man Kirk Waingrow folgt, weit über 80 Varianten der beiden ursprünglichen Systeme. Vgl. Waingrow 1999.

[45]Genauere Einblicke in die hier beschrieben Vorgänge um UNIX und BSD gibt McKusick 1999.

 

 

*Dieser Text stammt aus der Magisterarbeit „Geschichte der Freien Software“ von Joachim Korb aus dem Jahr 2001. Das Originaldokument ist abrufbar unter: http://tal.cs.tu-berlin.de/korb/Magister/

 

Ich fühle mich sehr sicher in Kabul

Von zu Hause habe ich mit Astrid einen langen Spaziergang und viele Fotos gemacht, mir eine große Schreinerei angesehen (der Besitzer war total nett), einen alten Mann fotografiert, der in der heißen Sonne Steine machte (vorher um Erlaubnis gebeten und hinterher um Geld angebettelt worden) und eine ganze Meute Kinder folgte uns eine Weile. Ich fühle mich sehr sicher, sehr wohl auch unter den vielen Menschen, die auf ein bisschen Freundlichkeit total freudig reagieren. Immer wieder auch Taxifahrer, denen ich das Geld erst aufdrängen muss (“that’s because you help us”). Immer wieder sind sie auch voller Lob, weil ich ein bisschen Dari kann. Man merkt, wie es ihnen wirklich gut tut, wenn sie ernst genommen werden. So wie mir ja auch. Meine Bewegungsfreiheit gilt natürlich hauptsächlich als Mann. Aber auch Martina und Astrid staunen über die Frage eines anderen Entwicklungsdienst-Kollegen (der schon ein paar Monate hier ist): “ Wo habt ihr nur die Butter her? Ich wäre schon zufrieden mit Margarine!” Martina konnte es kaum fassen: Sowohl Butter als auch Margarine gibt es hier an jeder Straßenecke. 20.11. Mittwoch

Ich fühle mich sehr sicher in Kabul

Von zu Hause habe ich mit Astrid einen langen Spaziergang und viele Fotos gemacht, mir eine große Schreinerei angesehen (der Besitzer war total nett), einen alten Mann fotografiert, der in der heißen Sonne Steine machte (vorher um Erlaubnis gebeten und hinterher um Geld angebettelt worden) und eine ganze Meute Kinder folgte uns eine Weile. Ich fühle mich sehr sicher, sehr wohl auch unter den vielen Menschen, die auf ein bisschen Freundlichkeit total freudig reagieren. Immer wieder auch Taxifahrer, denen ich das Geld erst aufdrängen muss (“that’s because you help us”). Immer wieder sind sie auch voller Lob, weil ich ein bisschen Dari kann. Man merkt, wie es ihnen wirklich gut tut, wenn sie ernst genommen werden. So wie mir ja auch. Meine Bewegungsfreiheit gilt natürlich hauptsächlich als Mann. Aber auch Martina und Astrid staunen über die Frage eines anderen Entwicklungsdienst-Kollegen (der schon ein paar Monate hier ist): “ Wo habt ihr nur die Butter her? Ich wäre schon zufrieden mit Margarine!” Martina konnte es kaum fassen: Sowohl Butter als auch Margarine gibt es hier an jeder Straßenecke. 20.11. Mittwoch

Hoher Entwicklungsdienst-Besuch in Kabul

Ich bin früh aufgewacht und musste viel nachdenken. Die ganzen nächsten Tage ging das so. Einmal eine Liste machen, was ich als Grundausstattung anschaffen sollte für die Ausbildung in der Schreinerei. Und zusammentragen, welche Informationen ich noch brauche. Viel mehr über diese holländische Organisation, den Projektleiter, die örtlichen Amtsinhaber, den Schreinereileiter. Immerhin werde ich als einziger Europäer vor Ort wohnen. Und etliche Anfragen zur Ausbildung habe ich: Drei Monate Basic-Kurs, drei Monate Advanced- Kurs mit je 15 Leuten ist deshalb nicht möglich, weil ich so lange gar nicht in Hezarak sein werde. Was die inhaltliche Abgrenzung zwischen den beiden “Kursen” sein soll, ist mir nicht klar geworden. Ich will auch wissen, ob es wirklich keinen Bedarf an Fenstern und Türen mehr gibt, bevor ich loslege mit Möbelbau. Zusätzlich ist das ein hoher Aufwand, wenn das Ziel ist, dass sich dann nur drei Leute selbständig machen sollen. Wichtig ist mir, dass Ole mir nicht mehr reinreden kann, wenn ich Entscheidungen getroffen habe. Wenn ich da wochenlang eine Beziehung auf Augenhöhe zu den Paschtunen aufgebaut habe, einen gegenseitigen Respekt, und er dann kommt und mich lächerlich macht. Morgens gleich ging es zu einem Treffen mit Frau Saumer. Sie bekleidet eine hohe Position im Entwicklungsdienst und war für ein paar Tage in Afghanistan. Wir stellten uns alle vor und Frau Saumer erklärte, dass sie es ungern hört, wenn jemand sagt: ‚Ich arbeite in einem ZIM- Projekt’. Das wäre so ziemlich das Falscheste, was wir sagen könnten. Dass wir gleichberechtigte Partner in anderen Organisationen wären und so weiter. Mich stoßen diese reinen ‚Sprachregelungen’ eher ab, vor allem, wenn es dadurch dann immer schwieriger wird, die Wirklichkeit zu beschreiben. Klaus gab mir eine Vorlage, indem er aus Uganda erzählte, wie wenig wichtig das war, ob in einem GTZ-Projekt einer von einem anderen Entwicklungsdienst bezahlt worden ist. Und ich konnte darauf aufbauen und erklären, dass ich am Vortag erst die einsame Entscheidung des Head of Mission erfahren hätte, dass ich in diesem Bergdorf wohnen soll. Und doch offensichtlich der Entwicklungsdienst für die ZIM nur ein Personalservice sei. Dem Entwicklungsdienst-Chef Anders war die Überraschung anzumerken. Er wusste bis dahin auch nichts über meinen Einsatzort. Frau Saumer fragte, warum ich das nicht schon vorher gewusst hätte. Das konnte ich ihr natürlich nicht beantworten, blöde Frage im Grunde. Was ich sagen konnte war, dass die Zusammenarbeit mit einer solch streng hierarchischen Organisation viele der Grundsätze und Ziele des Entwicklungsdienst außer Kraft setzt, wie Partizipation zum Beispiel. Und die sind doch nicht Selbstzweck, sondern sinnvoll. Ich hätte jetzt z.B. mit Eifer Dari gelernt und käme nun in ein Paschtunen- Gebiet. Die Aufgabe als solches würde mich aber sehr reizen. Es ging noch eine Weile um das Selbstverständnis des Entwicklungsdiensts, jemand anderes kritisierte ebenfalls die Organisation. Anderen war noch die Gehaltszulage wichtig, die bisher für Afghanistan gezahlt wurde. Frau Saumer erwähnte noch, wie gut sie inzwischen Afghanistan kennt (nach drei Tagen), immerhin habe sie schon einen Rundflug über Kabul gemacht und war in Jallalabad. Afghanistan gehöre zwar nicht zu den Ländern, die Vergnügungssteuerpflichtig wären, obwohl, wenn sie sich den blauen Himmel so angucken würde… Und so weiter. Ich muss aufpassen, dass ich nicht zu sehr ins Negative verfalle. Es war zumeist schon ganz okay, was Frau Saumer gesagt hat und ich fand den Morgen ganz angenehm. Sie hat auch wirklich nach unseren Sorgen und Nöten gefragt und ich hatte das Gefühl, mit Kritik nicht auf taube Ohren zu stoßen. Und die Kollegen bringen nicht alle so blöde Sprüche, wie auf der Fahrt nach Hezarak und die, die welche bringen, bringen sie auch nicht die ganze Zeit. Nach dem Treffen sind wir wieder in die Stadt, zusammen mit Mir Afzal, unserem Sprachlehrer. Ein paar Sachen einkaufen und Geldwechseln. Diesmal wollten wir aber Kleingeld haben und nicht die neuen 1000 Afghani- Scheine (etwa 17,-€), die so schwer oder gar nicht zu wechseln sind. (Wochen später hatten die Afghanen, die vor der Währungsreform als höchste Banknote nur 10 000 alte Afghani (10 neue Afghani) kannten, sich an die ‚großen’ Scheine gewöhnt). 20.11. Mittwoch

Hezarak – Auf dem Weg zu meiner zukünftigen Arbeits- und Ausbildungsstätte auf dem Land in Afghanistan

Um 7 Uhr sollte ich abgeholt werden von den ZIM-Leuten. Um 10 vor 7 kam Arnold zu uns rein und ich sollte gleich mitkommen, ich war noch am Essen. Im Büro mussten wir dann eine dreiviertel Stunde warten, bis Ole Van den Berg auch so weit war. Er war mir sehr viel sympathischer, als ich nach den ganzen Vorinformationen gedacht hätte. Er beklagte sich, dass er mich nicht eher zu Gesicht bekommen hätte. Dann wüsste er besser, wie er mich einplanen solle. Auf dem Weg nach Hezarak (einer meiner Kollegen sagte: “Wenn ich diese Berge sehe, muss ich immer an Frauen denken”) habe ich länger darüber nachgedacht, wie ich es schaffen könnte, nicht im ZIM- Gästehaus wohnen zu müssen. Lieber in einer afghanischen Familie, eigenes Zimmer, Toilette im Haus, Kochmöglichkeit für mich selbst. Die Fahrt war atemberaubend. Erst auf der Straße nach Jallalabad, überall Kinder, zum Teil auch, wo weit und breit kein Haus zu sehen war. Militärposten, riesige Höfe aus braunem Lehm, von außen nur die Mauern wie Trotzburgen. Eine besonders große Burg: Das ehemalige Zentralgefängnis, jetzt nicht in Benutzung. Dann ging es in die Berge, durch wüstenähnliches Gelände erst, später in ein Tal, die Berge völlig ohne Bewuchs und vor sich hin erodierend, auf dem Boden nur ab und zu ausgedörrte Sträucher oder Grasbüschel. Eine Gruppe Hirten. Neben uns die ganze Zeit ein Flussbett, erst völlig ohne Wasser. Das Tal wird immer enger, wir sind dicht am Fluss, der nun etwas Wasser führt. Das ist allerdings vereist (es ist schon ein gutes Stück kälter als in Kabul, in dem engen Tal mit wenig Sonne sowieso). Gegen Ende des Tales völlig unerwartet eine Reihe Bäume im Talgrund. Kurz darauf müssen wir den Bach überqueren (hier ist er kleiner), ganz viel Geröll, ein Auto (wir waren mit dreien unterwegs) bleibt erst mal stecken, bevor der Fahrer das Allradgetriebe in Gang setzt. Das normale Taxi, das seit einer Weile hinter uns her fuhr, hat es da schwerer, schafft es aber nach einiger Zeit dann auch. Auf der Strasse sehen wir ganz ab und zu ein Motorrad, einmal ein LKW, der Steine auflädt, einmal eine Gruppe Arbeiter, die mit viel Getöse Steine den Hang hinab auf die Strasse fallen lassen. Ich nehme an, Steine für den Hausbau. Aus dem Tal heraus geht (in der Nähe eines Staudammes) eine Serpentine auf eine Hochebene, an gekennzeichneten, weitläufigen Minenfeldern vorbei. Später sehen wir eins, zwei, drei Ansammlungen von Häusern, zum Teil heftig zerstört, und höchstens mal Kinder, sonst niemanden. Bis wir um einen Berg herum an eine Stelle kommen, wo viele arbeiten, zum Teil an einem größeren Gebäude. Wir fahren daran vorbei zu einem Hof, der die Schreinerei beherbergt. In der Schreinerei arbeiten etliche Arbeiter an Fenstern, mit großen Langhobeln (Rauhbänken) ohne Strom. Drei, vier pakistanische Maschinen gibt es aber auch. Eine davon ist nicht benutzbar, eine Bandsäge, die anderen sind mehrfach kombinierte: Kreissäge, Dickte, Abrichte und Bohrmaschine. Ole Van den Berg führt auf Englisch ein Gespräch mit dem Projekt-Manager der Partnerorganisation NGE, einem Afghanen, dem ich nur mühsam folgen kann. Plötzlich dämmert mir aber, dass dieses Gespräch darum geht, dass ich in diesem Hof wohnen und arbeiten soll. Kurz darauf wird mir ein kleines Zimmer als mein Schlafraum gezeigt, mit kaputter Tür nach draußen und möbliert mit etlichen Matratzen. Zum Wochenende will mich Van den Berg jeweils abholen lassen. Es gibt Funkkontakt nach Kabul, wie ich verstehe, zu ihm. Wir schauen uns noch die Umgebung an, ich versuche mit den Leuten auf Dari zu reden, was auch meistens geht (eigentlich sprechen viele nur Pashtu). Öfter verschwinde ich in einer Gruppe von Afghanen, während die anderen Deutschen zusammenstehen. Ich finde die Art, wie Van den Berg mir meinen Einsatzort nahe gebracht hat, unter aller Sau, aber ansonsten bin ich begeistert: Nicht in Kabul arbeiten, sondern hier, wo Hilfe nötig ist, mit Afghanen leben und arbeiten und nicht im Ausländer-Ghetto und trotzdem den Kontakt zu Kabul nicht verlieren. Von diesem Hof aus, der genau am Abhang steht, hat mensch einen weiten Blick über das Tal. Unten ist es tatsächlich grün, Felder gibt es dort. Ich weiß nicht, was sie dort anbauen, von oben sieht es aus, wie das frische Grün von jungem Weizen, also mehr grasartig (später weiß ich: Es ist auch Weizen). Ringsumher Berge, Steine, weiter hinten die Berge, gewaltig und schneebedeckt. Wir fahren dann zu dieser Baustelle von vorhin. Eine holländische Organisation mit hauptsächlich einheimischem Personal, ist hier im Tal zu Gange. Die Baustelle ist eine Schule, etliche Arbeiter sind dort. In der Mitte ist ein Zelt, in dem ein alter Mann wohnt. Ich frage um Erlaubnis, es fotografieren zu dürfen. Auch eine Krankenstation ist dort, ich kann nur nicht erkennen, in wie weit sie in Betrieb ist. Anschließend fahren wir etwa 10 Minuten zu einem der nächsten Orte, vielleicht, zehn, zwölf Höfe. In einem offenen Innenhof, gebildet aus mehreren Höfen, gibt es eine Wasserpumpe, Hühner laufen und ein alter Schreiner arbeitet dort im Freien an einem Fenster. Er ist wohl einer der beiden Ausbilder in der Schreinerei oben, wir werden vorgestellt, fragen uns nach unserem Befinden. Kurz sehe ich auch die einzige Frau während meines Aufenthaltes in Hezarak, bevor sie in einem Haus verschwindet. Ole hebt irgendein auf dem Boden liegendes Geschoss auf und zeigt es dem afghanischen Counterpart, schmeißt es dann wieder weg. Ich wundere mich, weil wir ja gehört haben, dass wir besser nichts aufheben, was es an Munition und sonstigem Metall auf afghanischen Boden so gibt. Aber weil die beiden das so unbedenklich angefasst haben, nehme ich es mit. Später bittet Ole mich, das Teil irgendwo auf der Fahrt weg zu schmeißen. Das sei nicht ein Projektil aus vollem Material, sondern es habe innen hohl geklungen. Wahrscheinlich sei das eine Leuchtmunition gewesen, die nachts für Maschinengewehre als jedes zehnte Projektil benutzt würde, um das Ziel auszuleuchten. Ich war ganz dankbar für diese Information und habe es später dann auch weggeworfen. Auf dem Rückweg habe ich mich zu Ole in den Wagen gesetzt, um etwas mehr über das Projekt zu erfahren. Das ganze Tal war wohl ziemlich entvölkert, erst vor einem Jahr sind die Leute wieder aus Pakistan zurückgekehrt (was, wie sich später heraus stellte, so nicht stimmte), im Wesentlichen Paschtunen, die von Haus aus nicht Dari sprechen, was ich gerade lerne. Die Schreinerei wird von NGE unterhalten, mit Geldern vom UNHCR, damit die Häuser wieder Fenstern und Türen bekommen. Später sollen dann Möbel gefertigt werden. 2 Klassenräume sollen noch gebaut werden bis zum 10. Dezember, also dem Ende von Aid, dem Fest nach Ramasan. Es gibt noch Unstimmigkeiten mit dem Besitzer des Hofes, wegen des Ausbaues der Klassenräume, irgendwie will er dafür nichts bezahlen, aber dann mehr Miete. Ich soll dort drei Monate einen Basic-Kurs leiten, danach 3 Monate einen Advanced-Kurs. Später sollen daraus zwei, drei Betriebe entstehen. Nach diesen Informationen meinte Ole zu dem Entwicklungsdienst-Kollegen, der mit uns im Auto fuhr: “Dich schicke ich auch demnächst nach Mazar-i-Sharif!” Der Kollege wurde sehr unruhig. Ich sagte ihm, das Mazar wirklich eine schöne Stadt sei, viel besser als zum Beispiel Kandahar. Ole fragte dazwischen, wie ich denn das meinte. Ich antwortete, Kandahar sei ein Wüstenloch, sei mir erzählt worden, aber Mazar-i-Sharif solle wunderschön sein, ähnlich wie Herat. Ole erklärte daraufhin dem Kollegen, er würde ihn vielleicht auch nach Kunduz schicken. Das würde er entscheiden, je nachdem, was sinnvoll wäre. Es könnten ruhig einige Leute sauer auf ihn sein, er habe einen breiten Rücken, auf dem das hinunter rutschen könne (Ole ist Holländer, deshalb die unorthodoxe Ausdrucksweise). Zurück im Büro gab es ein superleckeres Mittagessen (zwei Köche, die auch ein- und abdeckten) und ich klärte noch einige Termine mit Ole ab (die alle nicht zustande kamen). Zu Fuß bin ich an die nächste große Straße, mir ein Taxi suchen und nach Taimani ins Gästehaus gefahren. Gelernt haben wir mit Neda, ich bin mit Astrid und Klaus ins Interkonti und habe Svenja und meinem Sohn eine E-Mail geschrieben. 19.11. Dienstag

Ein deutscher Entwicklungsdienst’ler aus Jallalabad zu Gast

Wieder zu Hause hatten wir einen Gast: Einen Entwicklungsdienst’ler, der in Jallalabad gearbeitet hat und nun wieder nach Deutschland zurück flog. Ein Auto stand vor unserem Haus, ein Fahrer, zwei Wachleute. Etwas unsicher fragten sie mich, ob ich wüsste, ob der Deutsche nun bald wieder fahren wolle oder was. Ich bin rein und bekam die unwirsche Antwort: ”Die sollen halt 10 Minuten warten!” Abends dann, als wir zusammen saßen, erzählte er ohne Punkt und Komma. Klaus hörte lange höflich zu, während die beiden Frauen sehr schnell verschwanden. Ich saß dabei und schrieb. Als Klaus ging, redete der gute Mann auf mich ein. Es war offensichtlich, dass er in Jallalabad recht einsam gewesen war. Umso größer war seine Klappe. Er war der tolle Kerl, umgeben von afghanischen Idioten. Ich bin dann auch schnell gegangen. Ich habe ihn noch gebeten, den Lichtschalter auch dann auszumachen, wenn der Strom schon weg ist, weil sonst das Licht nachts wieder angeht. Ob wir denn keinen Generator hätten. Doch, sagte ich, aber den solle er bitte nicht anmachen, weil der so laut sei, dass dann alle nicht schlafen könnten. Nachts bin ich aufgewacht von seinen Versuchen, den Generator in Gang zu bringen. Morgens war überall das Licht an, etwa 6 Bierdosen standen draußen und drinnen überall herum und in zwei Zimmern hatte er die Ölofen überlaufen lassen, in einem auch auf den Teppich. Als ich das Bad benutzen wollte, wollte er mich davon abhalten, weil er da jetzt rein wolle. Da habe ich doch sehr schätzen gelernt, mit den anderen dreien zusammen hier zu sein. Unter dem Strich kamen wir sehr gut mit einander aus. Montag, 18.11.

Unfreie Software – eine Gefahr für die Demokratie?

Bearbeitet von Mario Behling

Für eine funktionierende Demokratie sind politische Gleichheit sowie Partizipation der Bürger von großer Bedeutung. Politische Gleichheit und wirtschaftliche Gleichheit korrelieren positiv (vgl. Mead 2004). Ebenso hängen Partizipationsmöglichkeiten und -bereitschaft unter anderem vom wirtschaftlichen Status ab (vgl. Schultze 2004, S. 648). Unfreie Software schränkt die Möglichkeiten der Partizipation stark ein. Der folgende Beitrag wirft die Frage auf, welche Gefahren für die demokratische Gesellschaft mit der Nutzung von unfreier Software ausgehen.

Bei Software muss zwischen unfreier und Freier Software unterschieden werden. Unfreie Software stellt einen Eingriff in die Freiheiten der Menschen dar und führt zwangsläufig zu wirtschaftlicher Ungleichheit. Eine Lösung dieses Problems ist die Verwendung Freier Software, sowohl in der Bildung als auch in eigenen IT Projekten des Staates. Des Weiteren ist ein sorgfältiger und gezielter Einsatz von begrenzten geistigen Monopolen (BGMs) in der Gesetzgebung notwendig.

Arten von Software

Software kann sehr gut mit einem Kochrezept verglichen werden (vgl. Stallman 2001). Der Autor schreibt eine Liste von Anweisungen nieder aus deren Ausführung ein bestimmtes Ergebnis resultiert. Bei Computerprogrammen werden die Anweisungen im so genannten Quelltext niedergeschrieben. Es gibt eine Vielzahl von Programmiersprachen, die man dazu verwenden kann. Der Quelltext wird anschließend mit Hilfe eines Programmes, dem Kompiler, in maschinenlesbare Form gebracht. Diese maschinenlesbare Form kann dann vom Computer ausgeführt werden. Sie ist jedoch von Menschen nicht mehr interpretierbar, da sie nur aus Nullen und Einsen besteht. In Abbildung 1 sieht man den Quelltext und den schematisierten Maschinencode eines Programmes, welches in der Programmiersprache C geschrieben ist. Wird es kompiliert und ausgeführt, gibt es „Hallo Welt!“ auf dem Bildschirm aus.

Bei Software muss zwischen zwei Modellen unterschieden werden: der Freien Software und der unfreien Software. Freie Software gewährt dem Nutzer folgende vier Freiheiten: (1) unbegrenzte Nutzung zu jedem Zweck, (2) Studium und Anpassung, (3) Weitergabe durch Kopie und (4) Weiterentwicklung (vgl. Stallman 2002, S. 41ff, Stallman 1996) . Unfreie Software gewährt keine, oder nicht alle dieser Freiheiten.

Menschenlesbarer Quellcode und maschinenlesbarer Binaercode
Menschenlesbarer Quellcode und maschinenlesbarer Binaercode

Die vier Freiheiten müssen in der Lizenz der Software gewährt werden. Innerhalb der Freien Software Lizenzen wird noch einmal zwischen stark schützenden, schwach schützenden und nicht schützenden Lizenzen unterschieden (vgl. Reiter 2004, S. 85-87):

Starker Schutz / Copyleft – z.B. GNU GPL: gewährt die vier Freiheiten und schützt sie dadurch, dass die Lizenz vererbt wird. Dies „impft“ die Software dagegen, wieder unfrei zu werden.

Schwacher Schutz / Copyleft – z.B. GNU LGPL: gewährt die vier Freiheiten. Jedoch bieten schwach schützende Lizenzen nur einen begrenzten Schutz der Freiheit. Im Gegensatz zu stark schützenden Lizenzen darf unfreie Software gegen Programme unter der GNU LGPL gelinkt werden. Das bedeutet, dass zwar das Programm selbst immer frei bleiben muss, es jedoch mit anderen Programmen kombiniert werden kann, welche unfrei sind.

Kein Schutz – z.B. XFree86 License (modifizierte BSD): gewährt ebenso die vier Freiheiten, bietet aber keinen Schutz der Freiheit. Das bedeutet, dass das Programm oder Programmteile auch wieder unfrei gemacht werden dürfen. Dies hätte zur Folge, dass Benutzern die Freiheiten vorenthalten werden.

Die Abbildung 2 veranschaulicht die verschiedenen Softwarekategorien (siehe Reiter 2004, Free Software Foundation 1996). Wichtig hierbei ist, dass der gezahlte Preis für den Erwerb der Software bei dieser Definition keine Rolle spielt. Ausschlaggebend für die Unterscheidung zwischen Freier Software und unfreier Software ist nur, ob die vier Freiheiten gewährt werden oder nicht.

Software Kategorien nach (Reiter 2004, S. 86)
Software Kategorien nach (Reiter 2004, S. 86)

Probleme durch unfreie Software

Software durchdringt mittlerweile alle Bereiche unseres Lebens. Das Klingeln des Weckers, das Stellen der Stoppuhr für das Frühstücksei, das Öffnen der Straßenbahntüre, die Benutzung des Fahrstuhls, das Telefonieren mit dem Mobiltelefon und natürlich die klassischen Variante, das Benutzen des Heimcomputers; immer kommen wir mit Software in Kontakt. Nahezu jedes elektronische Gerät enthält Software. Wie stark wir von Software abhängig sind wird uns klar, wenn wir uns vorstellen welche Folgen es hätte, wenn die Geräte nicht funktionieren würden.

Unfreie Software schwächt die Wirtschaft

In unserem privaten Leben könnten wir mit den Auswirkungen einige Zeit zurechtkommen, auch wenn es uns nicht leicht fallen dürfte. Die Wirtschaft jedoch ist auf funktionierende Software angewiesen. Eine Studie der Fraunhofer Gesellschaft hat ergeben, dass 50% der deutschen Industrie und 80% der Exporte von der Informations- und Kommunikationstechnologie abhängig sind (vgl. Miller 2004). Für sie ist es fatal, wenn die Software nicht funktioniert. Förderbänder stehen still, Flugzeuge und Züge verkehren nicht, die Börse würde zusammenbrechen und fast die gesamte Büroarbeit wäre unmöglich.

Software ist also ein zentraler Bestandteil unserer Wirtschaft. Das Problem dabei ist, dass unfreie Software immer zu einem Monopol führt. Warum dies so ist wollen wir nun etwas näher betrachten.

  • Für Geschäfte ist Kommunikation notwendig.

Um Geschäfte tätigen zu können, müssen wir mit Kunden und Anbietern kommunizieren. Angebote müssen eingeholt, Verträge verschickt und Konzepte diskutiert werden. Ohne Kommunikation kann kein Geschäft stattfinden. Diese Kommunikation findet zu einem Großteil mit Hilfe von Software statt. Vermutlich werden in Zukunft immer mehr Geschäfte in elektronischer Form abgewickelt werden. Um Geschäfte ausführen zu können benötigen wir also Software.

  • Unfreie Software funktioniert nur mit sich selbst gut.

Problematisch ist, dass unfreie Software meist nur mit sich selbst gut funktioniert. Jedem wird es schon einmal widerfahren sein: eine Datei, die z.B. mit einem bestimmten Textverarbeitungsprogramm geschrieben wurde, lässt sich nur mit dem gleichen Programm wieder fehlerfrei öffnen und betrachten. Oft ist es sogar nur mit der exakt gleichen Version der Textverarbeitung möglich.

Dies ist eine zwangsläufige Folge des unfreien Softwaremodells, denn das Geschäftsmodell basiert darauf, möglichst viele Lizenzen der Software zu verkaufen. Für diesen Zweck wird es einerseits dem Benutzer schwer gemacht, zu einer anderen Software zu wechseln, andererseits werden seine Kommunikationspartner dazu gezwungen, ebenfalls diese Software einzusetzen. Dies wird dadurch erreicht, dass das Programm es zunächst ermöglicht, standardisierte Dateiformate zu öffnen. Speichert man diese jedoch wieder ab, können die Daten nicht mehr mit anderen Programmen, die den Standard befolgen, geöffnet werden1. Hierfür werden der Datei Erweiterungen hinzufügt, die von anderen Programmen nicht unterstützt werden.

Daraus folgt: benutzen wir unfreie Software, müssen wir alle das gleiche Programm verwenden, um miteinander kommunizieren zu können. Das führt zu einem Monopol beim Angebot von Software2. Für dieses Monopol müssen alle Bereiche der Wirtschaft bezahlen und die gesamte Volkswirtschaft wird durch das unfreie Softwaremodell geschwächt. Mit diesem Monopol halten einige wenige Unternehmen eine solche Marktmacht in ihren Händen, dass dadurch der Gesellschaft ein immenser Wohlfahrtsverlust entsteht. Die soziale Kluft wird dadurch immer größer.

Gefährliche Machtverteilung durch unfreie Software

[quote]„Alle Mittel, welche die Realisierung von Zwecken sozialer Akteure ermöglichen; die Akteure also mit Macht ausstatten“ werden als Machtressourcen bezeichnet (Weiß 2004, S. 499). [/quote]

Mit Software kann man sehr gut eigene Ziele durchsetzen. Der Benutzer kann die Regeln, welche in Software implementiert sind nicht missachten. Bei Software deren Quelltext nicht verfügbar ist, existiert nicht einmal die Möglichkeit, festzustellen, welche Regeln überhaupt implementiert sind. Eventuell werden manche dieser Regeln, wenn überhaupt, erst durch Zufall entdeckt.

American Online (AOL) bietet ein gutes Beispiel dafür, wie Computerprogramme Freiheiten einschränken (vgl. Lessig 1999, S. 66-71). Als Mitglied bei AOL hat man die Möglichkeit, mit anderen Mitgliedern synchron Nachrichten in einem virtuellen Diskussionsraum auszutauschen. Dazu muss man sich in diesen Diskussionsraum einloggen. Nun hat aber AOL in ihrer Software die Regel implementiert, dass nur 23 Personen pro Raum zugelassen sind. Eine Gruppe von 24 Personen hat also nicht die Möglichkeit, sich gemeinsam in dem virtuellen Diskussionsraum auszutauschen. Die Software macht hier keine Ausnahmen.

Zu diesen softwareimmanenten Beschränkungen kommen noch Beschränkungen durch das Urheberrecht hinzu. Wie machtlos dagegen sogar ganze Staaten sind, illustriert folgendes Beispiel:

[quote] „Um seine Schrift in der digitalen Welt zu bewahren und lebendig zu halten, bat [Island im Jahre 1998] Microsoft, eine Unterstützung für Isländisch in Windows zu implementieren. Es war sogar bereit, für diese Arbeit zu bezahlen, doch Microsoft sah den Markt als zu klein an und winkte ab. Ohne Zugang zum Quellcode und ohne das Recht, ihn zu modifizieren, ist das Land vollkommen abhängig von Microsofts Gnade“ (Grassmuck 2002, S. 318). [/quote]

Eine Machtressource also vollkommen in den Händen einiger Weniger zu belassen, stellt eine große Gefahr für die demokratische Gesellschaft dar.

Strategische Schritte gegen Monopole im Softwarebereich

Was können wir tun, um diese Gefahren zu verhindern? Welche Schritte können wir unternehmen, um unsere Wirtschaft vor Monopolen zu schützen? Wie können wir den Menschen ein Verständnis für eine wichtige Technik unserer Zeit vermitteln und dadurch verhindern, dass diese als Machtressource missbraucht wird? Die einfachste Methode, die Gefahren von Software abzuwenden, wäre eine gesetzliche Bestimmung, dass jede Software für jeden Zweck verwendet, studiert und angepasst, durch Kopie weitergegeben und weiterentwickelt werden darf; also jede Software frei sein muss. Da jedoch meiner Ansicht nach solche Veränderungen Zeit benötigen, wollen wir hier mehrere kleinere Lösungsschritte betrachten.

Bildung

Es ist wichtig, dass die Fähigkeit Software zu verstehen nicht in den Händen einiger Weniger liegt, sondern breit in der Gesellschaft verteilt ist. Die Fähigkeit Programmieren zu können darf ebenso wenig wie Lesen, Schreiben oder Rechnen Herrschaftswissen sein. Die Bürger sollten in der Schule mit Rüstzeug ausgestattet werden, um ihre späteren Arbeitswerkzeuge kontrollieren zu können. Sie sollten also auch Grundkenntnisse im Programmieren erlernen, um später nicht den Irrglauben zu haben, Software sei etwas Übermenschliches.

Mit Freier Software können wir des Weiteren wichtige demokratische Prinzipien in der Bildung durchsetzen (vgl. Free Software Foundation Europe 2004, Stallman 2003):

  • Freiheit

Die Schüler können mit Freier Software lernen, solche zu benutzen und zu verstehen. Dadurch, dass sie den Quelltext verfügbar haben, gibt es für ihren Wissensdurst keine Grenze. Niemand verbietet den Schülern nur bis zu einem bestimmten Grad die Software zu verstehen. Anders als bei unfreier Software können sie auf dem aktuellen Stand der Technik lernen und müssen sich nicht damit abfinden, dass manche Dinge geheim sind. Sie werden erkennen, dass es nicht nur immer einen Weg, oder ein Programm zur Lösung eines Problems gibt, sondern fast immer Alternativen bestehen.

  • Gleichheit

Es besteht eine Gleichheit zwischen den Benutzern. Die Schule kann allen Schülern, auch denen aus ärmeren Familien, die Software zur Verfügung stellen. So sind arme Schüler nicht dazu gezwungen, gegen Gesetze zu verstoßen, damit sie nicht benachteiligt sind und die Software auch zu Hause benutzen können.

  • Brüderlichkeit

Mit Freier Software lernen Schüler, dass sich Zusammenarbeit und gegenseitige Hilfe lohnen. Niemand vermittelt ihnen den Eindruck, dass es eine schlimme Tat ist, anderen zu helfen, indem Programme getauscht werden, und dass solche Praktiken nur von „Piraten“ verübt werden (vgl. Stallman 1994a).

Eigene IT-Projekte mit Freier Software umsetzen

Zunächst sollte der Staat darauf achten, bei seinen eigenen IT Projekten selbst Freie Software Komponenten zu verwenden. Ansonsten könnte ihm ein Schicksal, wie das oben beschriebene widerfahren.3 Des Weiteren wird durch die Verwendung von Freier Software sichergestellt, dass die Funktionsweise der Software überprüfbar ist. Und jeder Bürger sollte das Recht haben, zu wissen, welche Regeln der Staat implementiert hat, genauso wie er das Recht hat, erlassene Gesetze nachzulesen. Die derzeitige Gesetzgebung verbietet es, das System zur elektronische Patientenkarte näher zu untersuchen. Dadurch wird es nahezu unmöglich gemacht zu überprüfen, ob dabei die Privatsphäre geschützt bleibt und in diesem Sinne der Sozialstaat aufrechterhalten wird.

[quote] Bernhard Reiter kritisiert, dass „[d]ie Systementwickler […] den Datenmißbrauch wissentlich in Kauf [nehmen] und versuchen – mit Hilfe des Urheberrechts – eine Überprüfung des Sicherheitskonzepts zu verhindern. Hier wird die Gefahr deutlich, die Softwarepatente und die Verschärfung des Urheberrechts für die Gesellschaft darstellen“ (Free Software Foundation Europe 2005). [/quote]

Wenn der Staat für alle IT Projekte Freie Software verwendet, kann diese auf legale Weise überprüft werden. So können Gefahren erkannt und frühzeitig darauf reagiert werden. Das Wissen und die Fähigkeiten von staatlich finanzierter Software sollte außerdem der Gesellschaft zur Verfügung stehen. So muss in den USA „Software, die mit staatlichen Mitteln entwickelt wurde, allen zugute kommen“(Grassmuck 2002, S. 381). Dieser Praxis sollte sich auch die Bundesrepublik anschließen. Staatlich geförderte Software sollte immer unter eine stark schützende oder zumindest schwach schützende Freien Softwarelizenz gestellt werden um sicherzustellen, dass diese auch frei bleibt. Sonst würden sich Unternehmen an der Gemeinschaft bereichern können, ohne ihr wieder etwas zurückzugeben (vgl. Grassmuck 2002, S. 306).

Bewusster Gebrauch von BGMs

Verhinderung von Monopolen im Softwarebereich kann am besten dadurch erreicht werden, dass die BGMs so gestaltet werden, dass sie ihren ursprünglichen Sinn auch verfolgen. Unter „begrenzten geistigen Monopolen“ (BGM) verstehen wir Patente, Urheberrecht, Schutzmarken, sowie andere Gesetze, deren Absicht es ist, limitierte Monopole für geistige Kreativität zu gewähren (vgl. Greve 2003, S. 35).

Meist wird heutzutage der Eindruck vermittelt, „dass naturgegebene Rechte für Autoren die akzeptierte und unumstrittene Tradition unserer Gesellschaft sind“ (Stallman 1994b). Der Sinn und Zweck sowohl des angloamerikanischen Copyrights, als auch des europäischen Urheberrechts, war es jedoch, den Fortschritt zu fördern und nicht die Autoren zu belohnen. Sie belohnen zwar „die Autoren etwas und die Verleger etwas mehr, aber dies ist gewollt als ein Mittel, um ihr Verhalten zu verändern“ (Stallman 1994b). Genauso wurden Patente als „ein zeitlich begrenztes Monopol zur Förderung der Veröffentlichung und Verbreitung von wirtschaftlich interessanten Ideen“ geschaffen (Reiter 2004, S. 90). Des Weiteren sollte bedacht werden, dass manche dieser Systeme, wie z.B. das Urheberrecht, schon sehr alt sind und auch für andere Technologien als Software geschaffen wurden.

[quote] So entstand das Copyright-System „mit der Drucktechnik – eine Technologie, die Kopien in Massenproduktion ermöglichte. Das Copyright passte gut zu dieser Technologie, da es nur die Massenproduzenten von Kopien einschränkte. Es nahm den Lesern von Büchern keine Freiheit. Eine gewöhnliche Leserin, die keine Druckerpresse besaß, konnte Bücher nur mit Stift und Tinte kopieren, und sehr wenige Leser wurden dafür verklagt. Digitaltechnologie ist flexibler als die Druckerpresse: Wenn Information in digitaler Form vorliegt, kann man sie leicht kopieren, um sie mit anderen zu teilen. Genau diese Flexibilität passt schlecht zu einem System wie dem Copyright“ (Stallman 1994b). [/quote]

Das unfreie Softwaresystem wird, wie wir gesehen haben, immer zu einem Monopol führen. Es ist auf Dauer nicht machbar, immer nur die Folgen des Systems zu bekämpfen, ohne die Ursachen anzugehen. Wie schwierig sich diese Folgenbekämpfung in der Praxis darstellt, sehen wir bei dem Kartellrechtsverfahren der Europäischen Kommission gegen Microsoft. Hierbei lässt Microsoft nichts unversucht, um die Netzwerkschnittstellen von Microsoft Windows nicht offen legen zu müssen. Durch dieses Verhalten verhindern sie jegliche Konkurrenz 4.

Der Gesetzgeber muss sich dessen bei seiner Aufgabenerfüllung immer bewusst sein. BGMs müssen mit Bedacht verwenden werden, um eine gesellschaftliche Entwicklung zu ermöglichen. Und speziell bei Software sollte sehr gewissenhaft darauf geachtet werden, ob das Ziel mit diesem Mittel erreicht wird oder ob es nicht doch bessere Möglichkeiten dafür gibt.

 

________________________________________________________________

1 Diese Praktik ist recht verbreitet und wird als “Vendor Lock-In“ bezeichnet.

2 Dieses Monopol bleibt nicht auf den Softwaremarkt begrenzt. Es dehnt sich auch auf den Hardwaremarkt aus. So läuft z.B. das Microsoft Betriebssystem nur auf Intel kompatibler Hardware und Computer mit Intel Chips werden mit dem Microsoft Betriebssystem vertrieben.

3 Die Isländische Regierung setzte die Lokalisierung schließlich auf der Basis des freien Betriebssystems GNU/Linux durch (vgl. Grassmuck 2002, S. 318).

4 Microsoft hat in dem Verfahren mittlerweile mehr als drei Milliarden US Dollar, das ist das Sechsfache der von der Europäischen Kommission auferlegten Strafe, an Drittparteien des Berufungsverfahrens vor dem Europäischen Gerichtshof bezahlt. Die Drittparteien bekundeten daraufhin kein weiteres Interesse an dem Fall zu haben. In Folge dessen unterstützen derzeit nur noch zwei Parteien die Europäische Kommission in dem Verfahren.

 

Literatur

Free Software Foundation: Categories of Free and Non-Free Software. http://www.gnu.org/philosophy/categories.html vom 05.01.2006, 1996

Free Software Foundation Europe: Warum Freier Software in Schulen den Vorzug geben? http://www.fsfeurope.org/projects/education/argumentation.de.html vom 05.01.2006, 2004

Free Software Foundation Europe: Diagnosen verboten: elektronische Patientenakte krankt an der Sicherheit. http://mail.fsfeurope.org/pipermail/press-release-de/2005q4/000081.html vom 05.01.2006, 2005

Grassmuck, Volker: Freie Software zwischen Privat- und Gemeineigentum. Bonn: Bundeszentrale für politische Bildung, 2002

Greve, Georg C. F.: Fighting Intellectual Property: Who Owns and Controls the Information Societies? In: Heinrich B÷ll Foundation (Hrsg.): Visions in process, world summit on the information society. Geneva 2003, Tunis 2005, 2003, S. 35–38

Lessig, Lawrence: Code And Other Laws Of Cyberspace. New York, NY, 1999

Mead, Lawrence: The Great Passivity. In: Perspectives on Politics 2 (4) (2004), S. 671–675

Miller, Franz: Innovationstreiber Informations- und Kommunikationstechnik. 2004. – Forschungsbericht

Reiter, Bernhard E.: Wandel der IT: Mehr als 20 Jahre Freie Software. In: Praxis der Wirtschaftsinformatik HMD 238 (2004), August, S. 83–91

Schultze, Rainer-Olaf: Partizipation. In: Nohlen, Rainer-Olaf (Hrsg.): Lexikon der Politikwissenschaft Bd. 2. München : C.H. Beck, 2004, S. 647–649

Stallman, Richard M.: The Right to Read. http://www.gnu.org/philosophy/right-to-read.html vom 05.01.2006, 1994

Stallman, Richard M.: Warum Software keine Eigentümer haben sollte. http://www.gnu.org/philosophy/why-free.de.html vom 05.01.2006, 1994

Stallman, Richard M.: The Free Software Definition. http://www.gnu.org/philosophy/free-sw.html vom 05.01.2006, 1996

Stallman, Richard M. ; Pottonen, Hannu (Hrsg.): Intro des Filmes The Code. 2001. – Film.

Stallman, Richard M. ; Gay, Joshua (Hrsg.): Free Software Free Society: Selected Essays of Richard M. Stallman. 1. Boston : GNU Press, 2002

Stallman, Richard M.: Why schools should use exclusively free software. http://www.gnu.org/philosophy/schools.html vom 05.01.2006, 2003

Weiss, Ulrich: Machtressourcen. In: Nohlen, Rainer-Olaf (Hrsg.): Lexikon der Politikwissenschaft Bd. 1. München : C.H. Beck, 2004, S. 499

 

Originalposting unter: http://www.difficulties.de/mk/papers.html