[DE | EN | FR | JA | ES | KO | PT]

Willkommen zu einer weiteren Ausgabe von Georg's Brave GNU World. Diesen Monat werde ich mal wieder einen Schwerpunkt auf die philosophischen Hintergründe werfen, wobei vor allem die Frage kommerzieller Freier Software angesprochen wird.

Vorher jedoch sollen zumindest ein paar Projekte vorgestellt werden.

TuxFamily.org

Nach dem Verständnis von Julien Ducros benötigen 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 zugunsten 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.

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

Chrooted SSH CVS-Server Howto

Auf der Community-Seite von Idealx [7] finden sich etliche 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 vorhandenen Paketen findet sich beispielsweise ein Python-Modul, welches es erlaubt, Kalender in CGI-Skripten zu erzeugen. Ein in XML stark konfigurierbares CVS-notify Skript, mit dem Aktionen während des Eincheckens neuer Versionen leicht automatisiert werden können, ist ebenso zu finden wie eine Anbindung von Erlang an Python.

Von großem Interesse ist dabei auch ein Howto von Olivier Berger und Olivier Tharan, das sich damit beschäftigt einen sehr sicheren und vom System gut isolierten CVS Server aufzubauen [8].

Programmierer wissen im Allgemeinen um die Stärken und den Nutzen des "Concurrent Versions System" (CVS) [9], doch ist gerade CVS ein von vielen noch unterschätztes Tool, weshalb ich kurz eine Einführung geben werde.

Es dürfte bekannt sein, daß Software im Allgemeinen in Form von Sourcecode geschrieben wird. Dieser Sourcecode wird im Laufe der Entwicklung eines Programms durch einen oder mehrere Autoren weiterentwickelt. Dabei stellt sich das Problem, wie die Arbeit von verschiedenen Entwicklern am Sourcecode koordiniert werden kann, da im Normalfall jeder Entwickler an einem Computer sitzen wird, um dort Veränderungen vorzunehmen. Dies bedeutet, daß der Sourcecode sich an mehreren Stellen unabhängig voneinander ändert.

Für diesen Zweck verfügt CVS (wie auch andere "Version Control Systems") über eine zentrale Sammelstelle, das sogenannte "Repository". Jeder Entwickler kommuniziert nur direkt mit dem Repository, indem er sich die Änderungen der Anderen mitteilen läßt oder eigene Änderungen bekanntgibt. Natürlich kann es vorkommen, daß zwei Autoren die gleiche Stelle ändern, doch auf die einzelnen Möglichkeiten, derartige Konflikte zu lösen oder zu vermeiden soll hier nicht genauer eingegangen werden.

Entscheidend ist die Tatsache, daß im CVS Repository nicht nur die aktuelle Version, sondern auch jede Änderung gespeichert wird. So läßt sich die Entwicklung schrittweise nachvollziehen. Es ist daher möglich, zu älteren Versionen zurückzukehren oder ein Projekt zu spalten und verschiedene Entwicklungsrichtungen parallel laufen zu lassen, um sie evtl. später wieder zu vereinen.

Dies ist jedoch nicht nur für Entwickler relevant. Hält man sich vor Augen, daß Sourcecode im Normalfall aus einfachen ASCII Files besteht, so wird unmittelbar klar, daß dieselben Möglichkeiten auch jeder anderen Form von Daten zugute kommen kann - speziell, wenn sie sich textbasiert darstellen läßt.

Webseiten, Dokumente, Email-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 und einige Methoden der Authentifizierung übertragen Passwörter im Klartext, können also ohne große Probleme von Dritten mitgelesen werden.

Auch wenn dies beispielsweise durch den Einsatz von SSH vermieden wird, so ist 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 [8] beschreibt ausführlich, wie auf einem Rechner beliebig viele CVS-Server parallel konfiguriert werden können, bei denen die Nutzer ausschließlich auf das spezifische Repository zugreifen können. Damit sollte der Großteil der durchschnittlich erfahrenen 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

Ein klassisches Beispiel hierfür sind Schleifen für die Kommandozeilenauswertung. Im schlimmsten Fall wird der Text per cut & paste für jede Option wiederholt, um sie dann irgendwo abzulegen, wo sie später für die Routinen zur Verfügung steht, die sie benötigen. Da dies eines der Standardprobleme ist, verfügt AutoGen mit AutoOpts bereits über ein Template für diesen Zweck.

AutoGen weist gewisse Ähnlichkeiten mit m4 [11], dem traditionellen Unix Makro-Prozessor auf. Allerdings ist es diesem überlegen, da es beispielsweise die Erweiterung von Funktionen um neue Parameter deutlich vereinfacht. Zudem unterstützt AutoGen verschachtelte Gruppen von Werten. Daher gibt es von Gary V. Vaughan, dem neben Bruce Korb aktivsten Entwickler von AutoGen, die Anfrage, autoconf von m4 auf AutoGen umzustellen.

Die speziellen 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 Positionen adressiert und die Definitionen sind verschachtelbar. Die Verwendung von benannten Definitionen erlaubt zudem, Dinge beliebig umzustellen und neu zu sortieren. Alte Definitionen können überflüssig werden, ohne die alten Definitionsfiles ändern zu müssen. Dies reduziert Inkompatibilitäten.

Über Variablen, die die Orte von Ersetzungen markieren, kann mittels Schlüsselworten definiert werden, welche Passagen weggelassen oder wiederholt werden sollen. Zudem gibt es deutlich bessere Möglichkeiten als beim C-Preprocessor, die Ausgabe zu kontrollieren.

Die Nachteile von AutoGen sind für Bruce Korb vor allem seine mangelnde Bekanntheit wie auch die Tatsache, daß es zu leicht ist Templates wie Hieroglyphen aussehen zu lassen. Da die Auswertung der Definitionen momentan noch statisch geschieht und dies eine merkliche Beschränkung von AutoGen darstellt, sehen die Pläne vor, die Auswertung zu dynamisieren.

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

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

Freie Software und Kommerz

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. Der erste Schritt ist, zu verstehen, daß "Frei" in Freier Software nicht im Sinne von "umsonst" sondern vielmehr im Sinne von "Freiheit" gebraucht wird.

Um welche Freiheiten geht es? Die präziseste Definition für Freie Software liefern die vier Freiheiten der Free Software Foundation [12]. Die "Debian Free Software Guidelines" [13] sind von diesen abgeleitet und bilden ihrerseits die Grundlage der "Open Source Definition" [14]. Technisch beschreiben also 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. Nutzungseinschränkungen irgendeiner Art führen also dazu, daß eine Software sich nicht als Freie Software qualifizieren kann.

Die zweite Freiheit besagt, ein Programm untersuchen zu dürfen, um zu lernen, wie es funktioniert und darauf basierend ein Programm auch den eigenen Bedürftnissen anpassen zu dürfen. Zugriff auf den Sourcecode ist hierfür eine notwendige Bedingung.

Freiheit Nr. 3 besagt, daß es erlaubt sein muß, Kopien weiterzugeben und Freiheit Nr. 4 ist die Summe der Rechte aus den Freiheiten 2 und 3. Sie besagt, daß man die Freiheit haben muß, Änderungen zum Wohle aller weitergeben zu dürfen; dies erfordert ebenfalls Zugang zum Sourcecode.

Dabei ist zu beachten, daß vor allem die Freiheiten 2, 3 und 4 nicht zwingend sind. Es gibt keine Verpflichtung, ein Programm zu kopieren oder eigene Veränderungen weiterzureichen. Tatsächlich ist die Verpflichtung, eine Veränderung öffenltlich 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 [15] 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 bewußt nicht zwischen kommerzieller und nichtkommerzieller Nutzung. Ein Nutzungsausschluß für kommerzielle Zwecke würde vielmehr die erste Freiheit verletzen - Freie Software ist also immer auch kommerziell einsetzbar. Kombiniert man dies mit der Tatsache, daß es keine Verpflichtung dazu gibt, die eine oder andere Freiheit wahrzunehmen, so wird unmittelbar ersichtlich, daß Freie Software sogar verkauft werden kann.

Es sollte nun verständlich sein, daß Freie Software kommerziell sein kann, aber nicht muß.

Nun herrscht in der Softwareindustrie 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, daß niemand seine persönlichen Interessen über die der Allgemeinheit stellen wird. Sie erlauben bewußt die Relizensierung zu einem proprietären Programm.

Die GNU Lizenzen besitzen für diesen Fall einen "Proprietarisierungs-Schutz". 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, technisch vom Ursprungsprogramm getrennte Module zu schreiben, was einen deutlich größeren Aufwand bedeutet und nicht immer gut möglich ist.

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 kommerziell wie auch nichtkommerziell geschehen.

Trotz des Schutzes, den die GPL bietet, kann also nur das Bewußtsein 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 heute

Wie immer bitte ich um Kommentare, Fragen, Anregungen, Ideen und Projektvorstellungen an die übliche Adresse [1].