Brave GNU World

(jpeg 7k)

Willkommen zu einer weiteren Ausgabe von Georg´s Brave GNU World. Beginnen werde ich wie üblich in der Praxis, um mich dann schrittweise der Theorie zu nähern.

Sawmill

Bei Sawmill [5] handelt es sich um einen Window-Manager von John Harper, der ähnlich dem GNU Emacs über eine eigene Skriptsprache erweitert werden kann. Diese Sprache war ursprünglich dem Emacs Lisp sehr ähnlich, hat aber nun auch Züge von Scheme angenommen und ist damit zu einer Mischung der Beiden geworden.

Um trotz dieser Erweiterbarkeit schlank und schnell zu bleiben, verzichtet Sawmill auf alles, was auch von anderen Programmen erledigt werden kann, wie z.B. Hintergründe oder "Application-Docks". Seine einzige Funktion besteht darin, Fenster auf beste, flexibelste und attraktivste Art und Weise zu verwalten.

Das Programm besteht aus einem primitiven C-Kern, alle höheren Funktionen werden durch die Skriptsprache implementiert, was es erlaubt, diese den eigenen Wünschen anzupassen. Mir persönlich ist dabei sehr wichtig, daß sich jede Funktion an eine beliebige Taste binden lässt - und zwar selbst in Abhängigkeit vom Kontext, also der Position des Maus-Fokus.

Selbstverständlich ist Sawmill auch Theme-fähig [6] und kommt komplett mit den Imitationen einiger bekannter Enlightement Themes. Dies kombiniert mit der guten GTK+ und GNOME Integration geben Sawmill das Potential, zum "de-facto" Standard Window-Manager von GNOME zu werden.

Übrigens sollten sich "reine Benutzer" nicht durch die beschriebene Komplexität abschrecken lassen, denn nahezu alles kann auch über ein graphisches Konfigurationstool eingestellt werden.

Für die Zukunft plant John Harper, auch KDE Support einzubauen und die letzten Bugs zu eliminieren. Zudem hofft er, das "Überfrachten" mit neuen Funktionen verhindern zu können, damit Sawmill auch weiterhin schnell und effizient bleibt.

Weiter geht es mit einem Projekt, welches sich gerade in der Entstehung befindet.

Free Unix Benchmark Project

Stefan Carstens hat mir bescheid gegeben, daß er das Free Unix Benchmark Project ins Leben gerufen hat. Die bisher verfügbaren Benchmarks betreffen entweder nur kleine Teilaspekte, bzw. ignorieren wichtige Unix-spezifische Fragen oder sind proprietär und damit nicht nachvollziehbar. Außerdem besteht ein großes Problem darin, daß sie über das Netz verstreut sind, es also keine zentrale Anlaufstelle gibt.

Das Ziel ist, eine in sich geschlossene "Benchmark-Suite" zu schaffen, die es ermöglicht, alle interessanten Tests aus einem Paket heraus durchzuführen. Geplant ist unter anderem auch ein Benchmark für die Netzwerk-Teile wie z.B. den TCP/IP Stack. Da ein solcher Test bisher noch nicht existiert, wird das Projekt vermutlich schnell großes Interesse wecken. Der raschen Verbreitung wird auch die Wahl der Lizenz zuträglich sein. Es ist geplant, die GNU General Public License bzw. GNU Lesser General Public License zu verwenden. Dies erfüllt durch den offenen Sourcecode zudem noch die wichtige Voraussetzung der Nachvollziehbarkeit, die gerade bei Benchmarks von extremer Bedeutung ist.

Auf der Benutzerseite sollen die Ergebnisse der Tests in verständlichen Einheiten ausgegeben werden, mit denen auch normale Anwender umgehen können. Es wird also möglich sein, bestimmte Leistungsprofile über eine Art von "PS-Zahl" zu vergleichen. Ein Ausgabe-Modul zur Verwendung von gnuplot ist ebenfalls geplant und ich bin mir sicher, dass bei entsprechendem Interesse auch eine direkte Ausgabe in eine Datenbank möglich sein wird.

Wer nun Interesse hat, dieses Projekt sofort zu installieren, den muß ich leider noch etwas vertrösten. Falls jedoch Interesse besteht, sich in die Entwicklung dieses Projektes einzubringen, dann verweise ich an Stefan Carstens [7]; er hat alle Interessenten ausdrücklich eingeladen, sich an ihn zu wenden.

Damit möchte ich gerne zu einem Teil kommen, der mir persönlich sehr am Herzen liegt.

Informationelle Menschenrechte - Teil II

Auf meine Deklaration der Informationellen Menschenrechte in Ausgabe 8 der Brave GNU World habe ich eine große Menge an wirklich positivem Feedback erhalten. Unter anderem hat sich Ken Engel mit ein paar Zusätzen an mich gewendet, die ich Euch nicht vorenthalten wollte.

Sein erster Zusatz zu den Informationellen Menschenrechten lautet: "Die Freiheit, 'reverse engineering' zu betreiben darf nicht eingeschränkt werden". Sein Beispiel war, daß es völlig in Ordnung ist, ein Auto zu demontieren und wieder zusammenzusetzen, man darf es sogar reparieren. Bei proprietärer Software ist dies unter Strafandrohung verboten.

Die zweite Ergänzung ergab sich für ihn aus einem Projekt, in dem er eine Applikation mit Hilfe einer proprietären Umgebung erzeugen mußte. Unabhängig von der Tatsache, daß die Umgebung proprietär ist, sind nun seine eigenen Daten in einem undurchsichtigen Binärformat eingesperrt und der einzige Weg zu ihnen führt durch ein umständliches und langsames graphisches Interface. Daher lautet sein zweiter Zusatz zu den Informationellen Menschenrechten: "Die Daten von keinem Kunden oder Benutzer dürfen in dem Produkt einer Firma gefangen sein."

Der letzte Punkt richtet sich gegen die "Fliessbandarbeit", die in manchen Softwarehäusern üblich ist und die Tatsache, daß angestellte Entwickler häufig nicht das beste Werkzeug für ihre Zwecke verwenden dürfen: "Die Wahl der Software soll nicht von Arbeitgebern diktiert werden, die die Erfahrung und das Wissen ihrer Angestellten ignorieren und auf diesem Wege die Möglichkeiten ihrer Entwicklungsabteilung und damit auch deren Produktivität einschränken."

Ich bin mir sicher, daß sich ein Großteil der Leser mit mindestens einem dieser Punkte identifizieren kann.

Damit möchte ich nun zum versprochenen zweiten Teil meiner Systems Nachlese kommen.

Die Sun Community Source License

Etwa eine Woche bevor ich zur Systems fuhr, hat Marco Boerries, der Gründer von StarDivision, in einer Englischen Zeitung erklärt, er verstünde nicht, warum die SCSL so negativ aufgenommen würde, sie sei doch der GPL deutlich überlegen.

Als Beleg für seine Worte führte er im Wesentlichen den Punkt an, ein Kunde erwarte gesicherte Eigentumsrechte an dem Code, den er erwirbt und die GPL könne dies nicht garantieren. Das mag in einem herkömmlichen produzierenden und verkaufenden Betrieb eine logische Aussage sein, zeugt in diesem Zusammenhang jedoch von dem Unverständnis für Geschäftsmodelle Freier Software.

Zunächst einmal geht er davon aus, daß der Kunde Software als "Eigentum" erwirbt. Sollte es sich dann um "gestohlenen" Code handeln, könnten ihm seine erworbenen Eigentumsrechte aberkannt werden, was den Verlust von Werten bedeuten würde. Jetzt auszuführen, warum der "Diebstahl" von proprietärem Sourcecode (Freie Software kann nicht gestohlen werden) für die Verwendung in Freier Software keinen Sinn macht, würde von dem wichtigeren Punkt ablenken. Daher erlaube ich mir, ihn hier zu ignoreren - sollte Interesse bestehen, so werde ich darauf gerne zu einem anderen Zeitpunkt eingehen.

Diesmal möchte ich mich auf die Frage beschränken, warum das Eigentumsmodell im Bezug auf Software überholt ist. Zur Erklärung muß ich jedoch ein wenig ausholen.

Im herkömmlichen Geschäftsfeld geht es darum, ein Produkt zu entwerfen, welches dann produziert wird. Die Massenproduktion läßt dabei kaum Spielraum für Individualität, denn sonst explodieren die Kosten. Daher geht es darum, das Produkt an eine möglichst gut gewählte Durchschnittsperson anzupassen, die häufig nicht einmal existiert. Danach ist es die Aufgabe des Marketings, nach Möglichkeit allen Personen klar zu machen, daß sie dieses Produkt erwerben sollten, weil es das einzig glücklich machende sei.

Dieses aus dem realen Raum stammende Geschäftsmodell wurde direkt und ohne Anpassung auf die Softwareindustrie übertragen. Es wird ein Ansammlung von Bits und Bytes geschaffen, die dann dem Kunden verkauft werden soll - dabei wird dem Kunden suggeriert, daß alleine der Besitz dieses Häufchens Bits und Bytes seine Probleme löst. Der ursprüngliche Grund für dieses Verhalten, die maschinelle Fertigung, existiert im virtuellen Raum nicht, Software kann nahezu beliebig an die wahren Bedürftnisse der Kunden angepasst werden. Gefangen in alten Verhaltensmustern wurden diese weiter angewendet, obwohl die Notwendigkeit dazu schon lange verschwunden war.

Geschäftsmodelle für Freie Software konzentrieren sich aus diesem Grund darauf, Probleme zu lösen, anstatt Besitz zur Lösung zu erklären. Und damit erübrigt sich die Diskussion der Eigentumsverhältnisse. Dem Kunden ist es letztendlich völlig egal, ob ihm die Software gehört, solange seine Probleme gelöst werden

Tatsächlich ist es für den Kunden besser, wenn die Software weder ihm noch der Firma gehört, von der er seine Software bezieht. Der Wert von Software hängt unmittelbar mit ihrer Pflege zusammen - ohne Wartung verliert Software sehr schnell an Nützlichkeit. Normalerweise wird bei proprietärer Software nicht die Software selbst sondern vielmehr das Nutzungsrecht an einer ganz bestimmten Version verkauft. Diese Version ist aber statisch und verliert damit schnell an Wert. Der Kunde muß bald eine neue Version erwerben, selbst wenn diese in eine Richtung entwickelt wurde, die seinen Bedürftnissen kaum gerecht wird.

Außerdem begibt sich der Kunde in ein Abhängigkeitsverhältnis, da er durch Festlegung auf ein proprietäres Produkt seinen persönlichen Erfolg nicht selten an den Erfolg seines Software-Lieferanten koppelt - auch wenn dies häufig nicht bemerkt wird. Nur Freie Software garantiert dem Kunden die Sicherheit des eigenen Erfolges durch die Unabhängigkeit von einem bestimmten Software-Zulieferer. Außerdem erhält er so die Möglichkeit, aktiv bzw. lenkend in die Entwicklung einzugreifen und so das Produkt optimal an seine eigenen Bedürftnisse anzupassen.

Und damit komme ich zum zweiten Punkt. Marco Boerries behauptete, die Ablehnung der SCSL fuße auf der Tatsache, daß sie Sun reich mache. Dies ist nicht der Fall. Die gesamte Szene der Freien Software freut sich über den finanziellen Erfolg von Firmen wie RedHat, die die GNU General Public License flächendeckend einsetzen.

Das Problem mit der SCSL liegt woanders. Wenn auch der Sourcecode einsehbar ist, so ist es dennoch untersagt, diesen zu modifizieren und dann weiterzugeben. Alle Änderungen müssen an Sun geschickt werden und nur Sun entscheidet darüber, ob diese Änderungen implementiert werden; letzten Endes bleiben die wesentlichen Rechte bei Sun. Was Sun damit geschaffen hat, ist letztendlich eine Art proprietärer Open Source Lizenz. Der wichtigste Grund für den Einsatz und Erfolg Freier Software, die Freiheit, wurde dem Benutzer dabei vorenthalten. Aus diesem Grund wird die SCSL wie jede andere proprietäre Lizenz von uns abgelehnt.

Damit soll es für diesen Monat genug sein, ich hoffe wie immer auf rege Beteiligung sowie Anregungen, Ideen und Kommentare, welche an die übliche Adresse geschickt werden können [1].

Zurück zur vorherigen Ausgabe / Brave GNU World home page

Return to GNU's home page.

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

Please send comments on the Brave GNU World column to column@gnu.org, send comments on these web pages to webmasters@www.gnu.org, send other questions to gnu@gnu.org.

Copyright (C) 1999 Georg C. F. Greve and Linux-Magazin

Permission is granted to make and distribute verbatim copies of this transcript as long as the copyright and this permission notice appear.

Last modified: Wed Feb 9 22:41:05 CET 2000