Diese Kolumne berichtet über aktuelle Entwicklungen innerhalb des GNU Projektes und versucht, Einblicke in die zugrundeliegende Philosophie zu vermitteln. In dieser Ausgabe: Tuxfamily.org, Chrooted-SSH-CVS-Server-Howto, AutoGen, freie Software und Kommerz.Georg C. F. Greve

Willkommen zu einer neuen Ausgabe von Georg’s Brave GNU World. Diesen Monat stellen mal wieder die philosophischen Hintergründe einen Schwerpunkt dar, wobei vor allem die Frage kommerzieller freier Software angesprochen wird. Vorher sollen jedoch ein paar Projekte vorgestellt werden.

Tuxfamily.org

Julien Ducros hat gemeinsam mit einer Gruppe von Leuten “Tuxfamily.org” [5] ins Leben gerufen. Vorbild war das amerikanische SourceForge [6]. Dieses stellt Projekten die zur Entwicklung und Präsentation benötigte Infrastruktur (Webserver, FTP-Server, CVS-Server, …) an einem gemeinsamen Ort zur Verfügung.

Nach dem Verständnis von Julien Ducros benötigt auch die europäische und afrikanische Community einen derartigen Service. Dies möchte das in Frankreich beheimatete Tuxfamily-Projekt bieten.

Dabei trifft Tuxfamily eine klare Aussage zu Gunsten freier Software. Die für das Hosting eingesetzte Software Vhffs untersteht selbstverständlich der GNU General Public License. Zudem werden von der Tuxfamily nur Projekte akzeptiert, die sich als freie Software qualifizieren.

Die kommende Anlaufstelle für Open Source-Projekte in Europa und Afrika?

Projekte, die im Moment auf der Suche nach einem Zuhause sind, könnten also durchaus der Tuxfamily beitreten.

Chrooted-SSH-CVS-Server-Howto

Es gibt häufig kleine Firmen, die zwar außerhalb ihres eigenen Landes fast vollkommen unbekannt sind, aber wertvolle Beiträge zur freien Software leisten. Die französische Firma Idealx ist eine davon.

Auf der Community-Seite von Idealx [7] finden sich interessante Module und Dokumente zu freier Software, die einige Standardprobleme lösen. Zur Anwendung kommt dabei die GNU General Public License für Software und die GNU Free Documentation License für Dokumente.

Unter den Paketen ist beispielsweise ein Python-Modul, das Kalender in CGI-Skripten erzeugt. Ein in XML sehr weit konfigurierbares CVS-Notify-Skript, mit dem Aktionen während des Eincheckens neuer Versionen leicht automatisiert werden, ist ebenso zu finden wie eine Anbindung der Programmiersprache Erlang [8] an Python.

Gut gefallen hat mir ein Howto von Olivier Berger und Olivier Tharan, das sich mit dem Aufbau eines sehr sicheren und vom System gut isolierten CVS-Servers beschäftigt [9].

Programmierer wissen im Allgemeinen um die Stärken und den Nutzen des “Concurrent Versions System” (CVS) [10]. Dennoch ist CVS ist ein von vielen noch unterschätztes Tool, weshalb ich eine kurze Einführung folgen lasse.

Bekanntlich wird Software in Form von Sourcecode durch einen oder mehrere Autoren entwickelt. Problematisch wird es, wenn die Arbeit mehrerer Entwicklern koordiniert werden muss.

Für diesen Zweck verwaltet das CVS (wie auch andere Versions-Kontroll-Systeme) eine zentrale Sammelstelle, das “Repository”. Jeder Entwickler kommuniziert ausschließlich direkt mit dem Repository. Er lässt sich dadurch die Änderungen der Anderen mitteilen und gibt eigene Änderungen bekannt.

Das CVS-Repository speichert nicht nur die aktuelle Version, sondern auch jede Änderung. So lässt sich die Entwicklung schrittweise nachvollziehen, und der Entwickler kann zu älteren Versionen zurückkehren. Ein Projekt kann auch gespalten werden und verschiedene Entwicklungsrichtungen können parallel laufen, um sie eventuell später wieder zu vereinen.

Hält man sich vor Augen, dass Sourcecode im Normalfall aus ASCII-Dateien besteht, so wird klar, dass dieselben Möglichkeiten auch anderen Daten zugute kommen können – speziell, wenn sie sich textbasiert darstellen lassen. Webseiten, Dokumente, E-Mail-Archive und einiges mehr sind ideale Gebiete für den Einsatz von CVS.

Der neuralgische Punkt eines CVS-Servers sind seine Zugriffsrechte. Es gibt verschiedene Möglichkeiten, die unterschiedlich sicher sind. In den meisten Fällen entspricht ein Account auf dem CVS-Server einem Account auf dem System. Einige Methoden der Authentifizierung übertragen die Passwörter im Klartext, diese können also leicht von Dritten mitgelesen werden. Auch wenn das etwa durch den Einsatz von SSH vermieden wird, ist es in vielen Fällen nicht gewünscht, jedem Teilnehmer mit CVS-Account auch unmittelbar vollen Zugriff auf das System zu gestatten.

Das erwähnte Howto [9] beschreibt ausführlich, wie auf einem Rechner beliebig viele CVS-Server parallel konfigurierbar sind. Auf diesen Servern können die Nutzer dann ausschließlich auf das spezifische Repository zugreifen. Damit sollte der durchschnittlich erfahrene Anwender in der Lage sein, auf dem eigenen Rechner einen sicheren CVS-Server zu installieren, um guten Gewissens die geschilderten Vorteile von CVS nutzen zu können.

AutoGen

Es ist mir immer eine Freude, Neuzugänge zum GNU-Projekt vorstellen zu können. AutoGen [11] von Bruce Korb ist ein solcher Neuzugang. AutoGen ist ein Tool, das die Erstellung und Wartung von Programmen erleichtern soll, die große Mengen an mehrfach vorkommendem Text enthalten. Ein klassisches Beispiel hierfür sind Schleifen für die Kommandozeilenauswertung. Im schlimmsten Fall wird der Code für jede Option per Copy-and-Paste wiederholt. Da dies häufig vorkommt, verfügt AutoGen mit AutoOpts bereits über ein Template für diesen Zweck.

AutoGen weist gewisse Ähnlichkeiten mit M4 [12] auf, dem traditionellen Unix-Makro-Prozessor. Es ist diesem überlegen, da es die Erweiterung von Funktionen um neue Parameter deutlich vereinfacht. Zudem unterstützt AutoGen verschachtelte Gruppen von Werten. Daher hat Gary V. Vaughan, neben Bruce Korb einer der aktivsten Entwickler von AutoGen, die Anfrage gestellt, Autoconf von M4 auf AutoGen umzustellen.

Die Stärken von AutoGen sieht Bruce in der sehr deutlichen Trennung von Templates und Definitionen. Dies macht die Templates um ein Vielfaches flexibler. Weiterhin werden alle Daten über Namen und nicht über Positionen adressiert. Die Definitionen sind verschachtelbar. Benannte Definitionen erlauben zudem, Dinge beliebig umzustellen und neu zu sortieren. Alte Definitionen dürfen überflüssig werden, ohne die alten Definitionsfiles ändern zu müssen. Dies reduziert Inkompatibilitäten.

Mit AutoGen Programme warten

Variablen, die die Ersetzungsstellen markieren, definieren mittels Schlüsselworten, welche Passagen weggelassen oder wiederholt werden sollen. Zudem gibt es deutlich bessere Möglichkeiten die Ausgabe zu kontrollieren als beim C-Preprocessor.

Die Nachteile von AutoGen sind für Bruce Korb vor allem seine mangelnde Bekanntheit wie auch die Tatsache, dass es zu leicht ist, Templates wie Hieroglyphen aussehen zu lassen. Die Auswertung der Definitionen geschieht momentan noch statisch. Da dies eine echte Beschränkung von AutoGen darstellt, soll hier bald Abhilfe geschaffen werden.

Ansonsten ist AutoGen weitgehend fertig und es wird daher hauptsächlich Feedback zur Frage der Portabilität benötigt. Bisher läuft es nachweislich unter GNU/Linux, BSD, SVR4-5, HPUX, SCO OpenServer und Solaris sowie unter Windows NT, falls Cygwin installiert ist.

AutoGen selber untersteht der GNU General Public License, einige der Add-Ons unterstehen der LGPL und FreeBSD-Lizenz oder sind Public Domain.

Freie Software und Kommerz

Es erreichte mich unter anderem von Tommy Scheunemann eine Anfrage zum Thema “Industrie und GPL”. Letztlich fand auf der Diskussionsliste der FSF Europe eine heiße Auseinandersetzung darüber statt, ob mit freier Software Geld verdient werden dürfe. Es wurde klar, dass es in diesem Zusammenhang noch einige offene Fragen gibt.

Bevor die Frage nach dem Kommerz und dem Wechselspiel mit der Industrie verstanden werden kann, ist es notwendig, sich mit der Definition freier Software zu beschäftigen. Hier gilt der alte Satz, dass “frei” in freier Software nicht im Sinne von “umsonst”, sondern vielmehr im Sinne von “Freiheit” gebraucht wird.

Um welche Freiheiten geht es?

Die beste Definition für freie Software liefern die vier Freiheiten der Free Software Foundation [13]. Die “Debian Free Software Guidelines” [14] sind von diesen abgeleitet und bilden ihrerseits die Grundlage der “Open Source Definition” [15]. Im Grunde beschreiben alle drei Dokumente identische Lizenzen; wegen ihrer größeren Kompaktheit werde ich jedoch von nun an nur noch von den vier Freiheiten sprechen.

Die erste Freiheit ist, ein Programm zu jedem Zweck benutzen zu dürfen. Eine Nutzungseinschränkung irgendeiner Art führt also dazu, dass sich die Software nicht als freie Software qualifizieren kann.

Die zweite Freiheit erlaubt es, ein Programm zu untersuchen, um zu lernen, wie es funktioniert. Darauf basierend darf ein Programm auch den eigenen Bedürftnissen angepasst werden. Zugriff auf den Sourcecode ist hierfür eine notwendige Bedingung.

Freiheit Nummer drei besagt, dass es erlaubt sein muss, Kopien weiterzugeben. Die vierte Freiheit schließlich ist die Summe der Rechte aus der zweiten und der dritten Freiheit. Sie besagt, dass man die Möglichkeit haben muss, Änderungen zum Wohle aller weitergeben zu dürfen; dies erfordert ebenfalls den Zugang zum Sourcecode.

Dabei ist zu beachten, dass vor allem die zweite, dritte und vierte Freiheit nicht zwingend sind. Es gibt keine Verpflichtung, ein Programm zu kopieren oder eigene Veränderungen weiterzureichen. Tatsächlich ist die Verpflichtung, eine Veränderung öffentlich zu machen, der Grund, warum sich beispielsweise die “Apple Public Source License” nicht als Freie-Software-Lizenz qualifiziert.

Die Frage, ob Software als Frei anzusehen ist oder nicht, entscheidet sich durch ihre Lizenz. Von den Lizenzen für freie Software [16] besitzt die GNU General Public License den höchsten Bekannheits- und Verbreitungsgrad. Neben der GNU Lesser General Public License, die eine Variation der GPL darstellt, hat ansonsten die FreeBSD-Lizenz die größte praktische Bedeutung.

Wo bleibt da der Kommerz?

Freie Software unterscheidet bewusst nicht zwischen kommerzieller und nichtkommerzieller Nutzung. Ein Nutzungsausschluss für kommerzielle Zwecke würde die erste Freiheit verletzen – freie Software ist also immer auch kommerziell einsetzbar. Kombiniert mit der Tatsache, dass es keine Verpflichtung dazu gibt, die eine oder andere Freiheit wahrzunehmen, wird ersichtlich, dass freie Software sogar verkauft werden kann.

Es sollte nun verständlich sein, dass freie Software kommerziell sein kann, aber nicht muss.

In der Softwareindustrie herrscht jedoch noch das proprietäre Nutzungsmodell vor, bei dem der Preis durch Vorenthalten der Freiheiten künstlich in die Höhe getrieben wird. Ein Unternehmen könnte also in Versuchung geraten, seinen Kunden die Freiheiten vorzuenthalten, um den Gewinn zu erhöhen.

Dies geschieht auf zwei Arten. Lizenzen wie die FreeBSD-Lizenz gehen davon aus, dass niemand seine persönlichen Interessen über die der Allgemeinheit stellen wird. Sie erlauben bewusst die Relizensierung zu einem proprietären Programm.

Die GNU-Lizenzen besitzen für diesen Fall einen “Proprietarisierungs-Schutz”. Denn: Wer auf der Arbeit von vielen Anderen aufbaut, darf das Gesamtprodukt nicht unter einer proprietären Lizenz herausbringen. Die einzige Möglichkeit, hier wieder proprietär zu werden, besteht darin, vom Ursprungsprogramm technisch getrennte Module zu schreiben. Dies bedeutet einen deutlich größeren Aufwand und wird nicht immer gut möglich sein.

In beiden Fällen wird das proprietarisierte Endprodukt dann gerne als “value-added” Software verkauft, bei der der Benutzer über Zusatzeigenschaften dazu überredet werden soll, seine Freiheiten aufzugeben. Dies kann sowohl auf kommerziellem, als auch auf nichtkommerziellem Weg geschehen.

Trotz des Schutzes, den die GPL bietet, kann also nur das Bewusstsein der Benutzer die Rückkehr zum proprietären Modell verhindern.

Es gibt demnach ohne Frage kommerzielle freie Software, so wie es auch nichtkommerzielle freie Software gibt. Im Punkt der Kommerzialität gibt es also die Freiheit der Wahl. Dabei sollte man unabhängig vom kommerziellen Aspekt darauf achten, die Freiheit nicht aus dem Blickwinkel zu verlieren, da sie die Grundlage der gesamten Bewegung ist.

Genug für diesmal

So, das soll für diesmal genug gewesen sein. Ich hoffe sehr, dass die Frage kommerzieller freier Software ausreichend gründlich und verständlich behandelt wurde. Wie immer bitte ich um Kommentare, Fragen, Anregungen, Ideen und Projektvorstellungen an die übliche Adresse [1]. ( tfr/fjl)