[DE | EN | FR | IT | JA | KO |

Willkommen zurück bei der Brave GNU World. Zuallererst möchte ich mich bei denen entschuldigen, die letzten Monat beim Aufschlagen des Hefts enttäuscht darüber waren, die Brave GNU World nicht an gewohnter Stelle zu finden. Direkt bevor die Kolumne geschrieben werden sollte, brach ich mir leider das Schlüsselbein, ans Tippen war nicht zu denken.

Nach dieser außerordentlich unfreiwilligen Pause soll es nun jedoch wie gewohnt weitergehen mit einer gesunden Mischung aus unterschiedlichen Projekten.

Gnuzza (CryptChat)

Noch im Beta-Stadium, doch bereits in Benutzung, ist Gnuzza (CryptChat) von Timo Schulz. Entstanden ist dieses Projekt aus der Anfrage eines Freundes, der nach einem sicheren Chat-Programm suchte, welches unter GNU/Linux und Windows laufen würde. Kurzentschlossen begann Timo mit der Arbeit und im Juli 2001 wurde die Version 0.0.3 von Gnuzza unter der GNU General Public License (GPL) als Freie Software veröffentlicht.

Gnuzza ist ein "peer to peer" (p2p) Chat-Programm mit starker Verschlüsselung, es erlaubt also zwei Leuten, sich über die Tastatur unter Wahrung ihrer Privatsphäre zu unterhalten. Zudem können sich die Teilnehmer über den verschlüsselten Kanal gegenseitig Files schicken.

Basierend auf der GNU Verschlüsselungs-Bibliothek libgcrypt [6] unterstützt Gnuzza Diffie Hellman Schlüsseltausch (1024 bis 4096 bit) sowie die symmetrischen Verfahren 3DES, Blowfish, Twofish, CAST5 und Rijndael. Standardmäßig greift Gnuzza jedoch auf asymmetrische Verschlüsselung zurück, da so die Notwendigkeit gemeinsam bekannter Passwörter entfällt. Die Nutzer können sich dabei problemlos mit OpenPGP-konformen Schlüsseln authentifizieren.

Geschrieben wurde Gnuzza in ANSI C mit einer ncurses Oberfläche, wodurch es schnell und resourcenfreundlich ist. Es läuft unter GNU/Linux, wo die benötigten Bibliotheken zum Standardumfang der meisten Distributionen gehören, und Windows, wo darauf geachtet wurde, Abhängigkeiten von den DLLs zu minimieren.

Dank ncurses verfügt das Programm über eine Text-Oberfläche, doch gibt es vermutlich einige Nutzer, die eine echt grafische Oberfläche vorzögen. Daher denkt Timo über eine GTK+/GNOME/KDE GUI nach - allerdings verfügt er über keinerlei GTK+ Erfahrung und sucht daher Freiwillige, die sich dieses Teilprojekts annehmen.

Darüberhinaus steht die Suche nach möglichen Fehlern auf der Tagesordnung. Neugierig gewordenen Lesern sei noch gesagt, daß dank geeigneter Standardeinstellungen Wissen über Kryptografie nur für die erweiterten Funktionen erforderlich ist. Wer also Beta-Software nicht scheut, sollte Gnuzza bereits ohne größere Probleme einsetzen können.

Denjenigen, die planen, es unter Windows zu verwenden, sei jedoch geraten, sich nicht zu sehr auf die Sicherheit der Applikation zu verlassen, da jede Kette nur so stark ist wie ihr schwächstes Glied. Es könnte also passieren, daß Daten sicher zum Gnuzza-Client unter Windows übertragen wurden, um dann vom Betriebssystem selbst an Dritte weitergeleitet zu werden.

Oder um es anders zu sagen: Der Einbau von Stahltüren in Papphäuser ist nur bedingt sinnvoll.

GNU Aspell

Zu den Applikationen, die normalerweise für jeden Anwender sinnvoll sind, gehören Programme zur automatischen Rechtschreibkorrektur. GNU Aspell [7] ist ein solches Programm und seit August 2002 Teil des GNU Projekts.

Bis zum Start des Aspell Projekts gab es im Bereich der Freien Software nur ein einziges Programm zur Rechtschreibkorrektur: International Ispell [8]. Ispell fand daher große Verbreitung auf Unix-Maschinen und wurde auch vom GNU System als Rechtschreibkorrektur eingesetzt. Allerdings blieb die Intelligenz der von Ispell suggerierten Korrekturen leider hinter den proprietären Lösungen zurück.

Aus diesem Grund begann Kevin Atkinson 1998 auf Basis des "Lawrence Philips' Metaphone Algorithm", welcher eine Annäherung an die englische Aussprache eines Wortes erlaubt, mit der Arbeit an Aspell. Im September 1998 wurde es zum ersten Mal und noch unter dem Namen Kspell veröffentlicht. Aufgrund des KDE Projekts zur Rechtschreibkorrektur, welches sich ebenfalls Kspell nannte, änderte er den Namen dann jedoch in Aspell.

Es folgten einige Jahre intensiver Entwicklung, in denen Kevin sich der Weiterentwicklung von Aspell widmete. Konzepte wurden erprobt, überarbeitet und teilweise verworfen. So gab es beispielsweise den Versuch, mit Pspell ein einheitliches Interface für alle auf dem System vorhandenen Rechtschreibkorrekturen zu schaffen. Die erhoffte Vereinfachung blieb jedoch aus - tatsächlich machte es das Leben für alle Beteiligten eher komplizierter. Daher ging Pspell mit Version 0.5 von Aspell in diesem auf.

Viel Sorgfalt verwandte Kevin auch bei der Überarbeitung und Ergänzung der Wortlisten, wobei er ursprünglich von den Ispell Listen ausging. Dabei verwandte er große Sorgfalt darauf, in den englischen Listen sauber zwischen der amerikanischen, kanadischen und britischen Schreibweise zu unterscheiden. Das Ergebnis dieser Arbeit hat er online verfügbar gemacht. [9]

Mit der Ende August 2002 erfolgten Release von GNU Aspell 0.5 soll Aspell sich nun zunehmend als Ersatz für Ispell vor allem in den GNU/Linux Distributionen durchsetzen. Angesichts seiner bemerkenswerten Eigenschaften sollte dies eigentlich nur eine Frage der Zeit sein.

GNU Aspell kann nicht nur direkt als Programm mit einer ansprechenden ncurses Oberfläche benutzt werden, es erlaubt auch, als Bibliothek in andere Programme eingebunden zu werden. Dabei sind die von GNU Aspell gemachten Vorschläge deutlich intelligenter als die von Ispell oder auch die von Netscape 4.0 oder Microsoft Word 97. Um dies zu quantifizieren, hat Kevin eine Testumgebung entwickelt, die mitsamt ihren Resultaten auf der GNU Aspell Seite [7] eingesehen werden kann.

Diese Tests wurden allerdings scheinbar bisher nur für die englische Sprache gemacht, auch wenn Wörterbücher für etliche andere Sprachen (auch Deutsch) existieren. Für diese Sprachen wäre es vermutlich sinnvoll, Muttersprachler zu gewinnen, die sich damit auseinandersetzten. Doch auch durch die einfache Benutzung werden die Empfehlungen von GNU Aspell besser, da es von Fehlern des Nutzers lernt.

Ob als Programm oder eingebunden über die Bibliothek ist GNU Aspell auf Multi-Prozess-Umgebungen ausgerichtet. Persönliche Wörterbücher der Benutzer sind allen Aspell Prozessen dieser Benutzer gleichermaßen verfügbar und Änderungen werden umittelbar zwischen den GNU Aspell Prozessen propagiert. Dabei sind übrigens auch mehrere persönliche Wörterbücher pro Benutzer möglich.

Um bei diesen erweiterten Möglichkeiten den Speicherbedarf in Grenzen zu halten, teilen sich alle auf einem System laufenden GNU Aspell Anwendungen die gemeinsamen bzw. allgemeinen Wörterbücher. Dennoch war der Preis, den GNU Aspell für diese erweiterten Funktionen zahlen mußte, ein höherer Speicherbedarf als der von Ispell.

Dies mag u.A. daran liegen, daß Ispell die sogenannte "Affix-Kompression" unterstützt, die in GNU Aspell momentan noch nicht implementiert ist. Die Methode der Affix-Komression greift darauf zurück, daß viele Worte einen gemeinsamen Stamm haben, der mit einem Affix, also einem Infix, Prefix oder Postfix das letztendliche Wort bildet.

Wörterbücher mit Affix-Kompression beinhalten daher den Stamm mit den möglichen Affixen. Die englischen Worte "alarm alarms alarmed alarming" würden dann im Wörterbuch beispielsweise zu "alarm/SDG". Gerade für Sprachen mit massiver Affixation, wie z.B. Deutsch, kann dies einen bedeutenden Unterschied machen.

Wichtig für Entwickler ist dabei, daß GNU Aspell, obwohl auf Multi-Prozess-Umgebungen ausgerichtet, noch nicht als "Thread-Safe" betrachtet werden kann. Dies zu gewährleisten gehört zu den dringlichsten Aufgaben auf der ToDo-Liste.

Weitere Punkte umfassen die Arbeit am Manual, Anpassung an die GNU Coding Standards, Vervollständigung des UTF-8 Supports, die Möglichkeit des dynamischen Ladens von zusätzlichen Filtern und die Schaffung eines C++ Interfaces. Auch die Anpassung des ispell.el EMACS Moduls findet sich auf der Liste der noch zu bewältigenden Aufgaben.

Und letztlich ist auch die Unterstützung der Affix-Kompression ein Schritt, der wohl in näherer Zukunft zu erwarten ist. Kevin Atkinson plant, den von Kevin Hendricks für das OpenOffice lingucomponent geschriebenen Code zur Affix-Kompression in GNU Aspell einzubauen.

Doch auch wenn noch fleißig an GNU Aspell gearbeitet wird, so sollte dies niemand davon abhalten, es einzusetzen, denn spätestens seit Version 0.50.2 muß GNU Aspell den Vergleich mit anderen im Betrieb befindlichen Rechtschreibkorrekturen nicht scheuen - auch wenn Kevin in der für Freie Software üblichen Verfahrensweise noch nicht das Gefühl hat, die 1.0 Versionsnummer vergeben zu können.

Es soll nicht unerwähnt bleiben , daß Kevin Atkinson die Arbeit an GNU Aspell bisher im Wesentlichen alleine geleistet hat. Hilfe wäre ihm allerdings sehr willkommen und wer seinen Namen gerne in einem interessanten Projekt verewigen möchte, das noch viele Jahre in den Händen unzähliger Benutzer sein wird, dem bietet sich hier eine gute Chance.

Erfahrenen Lesern der Brave GNU World wird aufgefallen sein, daß bisher nichts zu dem Lizenzstatus von GNU Aspell gesagt wurde, auch wenn klar sein sollte, daß es sich bei GNU Aspell um Freie Software handelt, ist es doch Teil des GNU Projekts.

GNU Aspell wurde zunächst von Kevin Atkinson selbst unter der GNU Lesser General Public License (LGPL) herausgegeben. Um jedoch die juristische Wartbarkeit und damit das langfristige (Über-)Leben seines Projekts zu sichern, hat Kevin seine Rechte an die Free Software Foundation Nord Amerika übertragen und diese somit zum Treuhänder seiner Interessen gemacht.

Obwohl die FSF Nord Amerika es für sinnvoller erachten würde, GNU Aspell unter der GNU General Public License (GPL) herauszubringen, wird es von ihr weiterhin unter der GNU Lesser General Public License herausgebracht, da dies Kevin sehr wichtig war.

Die hinter diesen unterschiedlichen Einschätzungen liegenden Gedankengänge sind wichtig und auch interessant, daher sollen sie für den Fall von GNU Aspell etwas beleuchtet werden.

GPL oder LGPL?

Kevin Atkinson möchte, daß GNU Aspell de-fakto dieRechtschreibkorrektur für GNU/Linux und andere Freie Betriebssysteme wird. Speziell Projekte wie OpenOffice, Mozilla und Andere sollen nach seinen Vorstellungen GNU Aspell einsetzen.

Da es von OpenOffice und Mozilla jedoch auch proprietäre Versionen gibt, fürchtet er, daß diese GNU Aspell nicht einsetzen würden, wenn es unter der GPL lizenziert wäre.

Natürlich gäbe es auch dann noch die Möglichkeit, GNU Aspell über einen externen Programmaufruf einzubinden. Dies ist weniger effektiv als das Einbinden der Bibliothek, wäre jedoch eine noch immer gangbare Möglichkeit.

Die Position von Kevin begründet sich also maßgeblich über den Wunsch, GNU Aspell möglichst weit verbreitet zu sehen und die Angst, daß es proprietärer Software zu viele Umstände bereiten würde, GNU Aspell unter der GNU General Public License einzubauen.

Unzweifelhaft wäre es von Vorteil, wenn GNU Aspell weite Verbreitung fände, würde es doch allen Benutzern die Freiheit in ihrer Rechtschreibprüfung bringen. Es gibt jedoch noch eine andere Seite.

Eine grundlegende Einsicht, die hinter der GNU General Public License steht, ist, daß es wohl immer Menschen geben wird, die bereit sind, sich auf Kosten der Anderen zu bereichern und man sich nicht allein auf die Herzensgüte von Unternehmen und Managern verlassen kann.

Oder anders ausgedrückt: Wer seine Freiheit nicht verteidigt, dem ist bestimmt, sie zu verlieren!

Die GNU Lesser General Public License (LGPL) ist eine Abwandlung der GPL, die den Schutz der Freiheit in einem wichtigen Punkt abschwächt: Sie erlaubt, den entsprechenden Code auch mit proprietären Anwendungen zu verbinden.

Dies hat sich in der Vergangenheit oft als sinnvoll oder sogar notwendig erwiesen und mit Bedacht untersteht beispielsweise eine so zentrale Komponente wie die GNU C-Bibliothek der LGPL.

Freie Software bietet ein neues Paradigma zum Umgang mit Software, welches viele Vorteile hat. Schnelle und "räuberische" Gewinne, wie sie von manchen Unternehmen angestrebt werden, gehören nicht zu ihren Eigenschaften; die Vorteile Freier Software entfalten sich vielmehr insbesondere im mittel- bis langfristigen Bereich.

Kurzfristig kann proprietäre Software teilweise unter Aufwendung massiver Finanzmittel ernste Schwierigkeiten für Freie Software schaffen, bzw. diese aus einzelnen Gebietenm möglicherweise vertreiben oder aussperren, um das eigene Monopol zu schützen.

Dies gilt um so mehr, je mehr Leute Software nur aufgrund vordergründiger, technischer Eigenschaften aussuchen und noch nicht verstanden haben, daß Software immer auch eine makroökonomische, kulturelle, soziale und ethische Komponente hat. Denn wem das Verständnis für diese Zusammenhänge fehlt, der wechselt ebenso schnell zu proprietärer Software zurück, wie er Freie Software ausprobiert hat.

Es existiert in der Freien Software-Szene eine Aufteilung in Leute, die eher der Freien Software- oder der Open Source- Gedankenwelt zuneigen. Dies zeigt, daß sich selbst innerhalb der klassischen Szene Freier Software dieses Verständnis bisher nur teilweise entwickelt hat. Außerhalb der Szene sieht es dementsprechend noch sehr viel schlechter aus.

So lange das allgemeine Verständnis für diese Fragen also fehlt, sieht sich Freie Software mit einem Problem konfrontiert: Proprietäre Software kann beliebig auf ungeschützte bzw. nicht ausreichend geschützte Freie Software zurückgreifen, während der umgekehrte Fall nicht gilt.

Unzureichender Schutz Freier Software erzeugt ein Ungleichgewicht zugunsten proprietärer Software, welches es zumindest sehr schwer macht, Freier Software auch einen kurzfristigen, technischen Vorteil gegenüber proprietärer Software zu verschaffen.

Wie bereits erwähnt, stellt Freie Software ein neues Paradigma dar, sie bildet einen neuen Markt mit neuen Regeln und anderen Mechanismen. Jeder Markt hat jedoch seine Spielregeln und es ist wichtig für alle Teilnehmer, daß diese eingehalten und geschützt werden, um den Einzelnen und auch den Markt als Ganzes zu bewahren.

Der Markt Freier Software befindet sich noch im Aufbau und in einer frühen Phase. Der Großteil der Teilnehmer versteht die Regeln und Mechanismen noch nicht, auch wenn sie sich zumeist daran halten.

Es kann angesichts des zuvor Gesagten nicht verwundern, daß sich hier die GNU General Public License mit ihrem starken Schutz der Freiheit als die dominante Lizenz herauskristallisiert hat, der deutlich über 50% der Freien Software unterstehen.

Dies scheint in meinen Augen die natürliche Folge der beteiligten Mechanismen zu sein und bildet ein starkes Indiz, daß die GPL nicht einen vorhanden Markt übernommen, sondern vielmehr einen neuen Markt geschaffen hat. Der Markt Freier Software hätte sich demnach maßgeblich wegen der und um die GNU General Public License herum entwickelt.

Um Mißverständnissen vorzubeugen, sollte noch gesagt werden, daß dies nicht bedeutet, die GPL sei die einzig zulässige Lizenz. Auch die LGPL oder andere, noch schwächer schützende Lizenzen, wie z.B. die BSD-artigen Lizenzen sind ein Teil Freier Software und können in Fällen sogar die sinnvollere Lizenzierung darstellen.

Die Frage, ob dies bei GNU Aspell der Fall ist, hat diesen Beitrag eingeleitet. Für die FSF stellt sich die Situation anders dar als für den Autor.

Mit Ispell verfügt Freie Software bereits über eine Rechtschreibkorrektur, die ihre Schwächen haben mag, diese Lücke jedoch über Jahre mit nicht-schützender Lizenz gefüllt hat.

Ein GNU Aspell unter der GPL könnte darauf aufbauend jeglicher Freier Software, die mit Text arbeitet, einen ernstzunehmenden Vorteil gegenüber konkurrierenden proprietären Produkten verschaffen, um die kurzfristigen Kräfteverhältnisse zugunsten Freier Software auszugleichen.

Außerdem würde der Anreiz, auf GNU Aspell basierende Projekte ebenfalls als Freie Software zu veröffentlichen, größer.

Im Bezug auf die Projekte OpenOffice und Mozilla, deren mögliche Schwierigkeiten ein Hauptargument für Kevin waren, sich für die LGPL zu entscheiden, so gab und gibt es kaum einen zwingenden Grund, kommerzielle Versionen proprietär zu machen.

Speziell bei OpenOffice scheinen Hauptgründe für den Kauf des proprietären StarOffice von Sun das scheinbar sehr gute Handbuch und der Support bzw. die Gewährleistung zu sein. Keiner dieser Gründe hängt jedoch davon ab, StarOffice notwendigerweise proprietär zu lizenzieren, sie wären von einer Lizenzierung als Freie Software unbeeinflußt.

Wer nun unbedingt proprietäre Versionen dieser Projekte herstellen will, kann dies natürlich tun. Es stellt sich jedoch die Frage, ob, in welcher Weise und warum wir als Freie Software Community diesen proprietären Projekten unbedingt GNU Aspell als Dreingabe schenken wollen.

Damit genug von dieser Frage, ich hoffe, es ist gelungen, dieses doch relativ komplexe Thema von beiden Seiten zu beleuchten und etwas Verständnis für die unterschiedlichen Motive und Überlegungen zu schaffen.

Wer Interesse hat, tiefer ins Thema einzusteigen, bzw. die Frage durch einen anderen Autor beleuchtet zu sehen, dem sei z.B. ein Artikel von Richard Stallman zum Thema empfohlen. [10]

Gnutemberg! Free Documentation Database

Simo Sorce, der italienische Übersetzer der Brave GNU World, empfahl das "Gnutemberg! Free Documentation Database" (GFDD) Projekt [11] aus Italien.

Das Projekt beschäftigt sich als Teil des "Gnutemberg!" Projekts [12] mit dem Aufbau und der Pflege einer Datenbank für Freie Dokumentation. Dabei kommen nur Dokumente in Frage, die unter einer durch die FSF anerkannten Lizenz für Freie Software stehen. [13]

Für die technischen Umsetzung kommen PHP und PostgreSQL zur Anwendung, wobei GFDD auf dem "Dublin Core Metadata Element Set" und dem "Open Source Metadata Framework" aufbaut. [14] Analog zum verwalteten Inhalt wird der verwandte Code natürlich als Freie Software unter der GNU General Public License herausgegeben.

Benutzerseitig ist es möglich, Dokumentation zu veröffentlichen, bzw. zu übersetzen und über eine Suchmaschine nach Feldern wie z.B. Herausgeber, Erscheinungsdatum, Titel, Sprache, Übersetzungen, ISBN-Nr., Seiten, Preis oder anderen Notizen zu suchen.

Unterhalten wird das Projekt durch Gaetano Paolone, Marco Presi, Simone Merli, Marco Milanesi, Alceste Scalas und Donato Molino, doch natürlich suchen sie immer nach Verstärkung sowohl auf der technischen Seite, wie auch beim Einstellen von Dokumentation.

Da Dokumentation ein immens wichtiges, jedoch häufig vernachlässigtes Gebiet ist, hoffe ich, daß sich noch viele freiwillige Mithelfer finden werden.

Bis dann

Das soll es für diesen Monat gewesen sein; sofern keine Katastrophen dazwischen kommen, wird es nächsten Monat weitergehen.

Doch natürlich möchte ich nicht schließen, ohne wie üblich um reichlich Feedback, Informationen, Ideen, Fragen oder Verweise auf möglicherweise interessante Projekte per Mail [1] gebeten zu haben.