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

Willkommen zu einer neuen Ausgabe der Brave GNU World. Wie gegen Ende der letzten Ausgabe versprochen, soll diesen Monat ein Projekt vorgestellt, werden, welches mir das Leben sehr stark vereinfacht hat.

SpamAssassin

Der SpamAssassin [5] von Justin Mason erlaubt es, die Spamanteile in der eingehenden Email zu "meucheln" - zumindest markiert er sie und erlaubt so Procmail oder dem Mailreader, Spam auf die am wenigsten störende Art zu handhaben.

Kern des SpamAssassins ist ein Perl-Programm, welches wie auch Perl selber unter einer dualen GNU General Public License/Artistic License veröffentlicht wird. Dadurch kann SpamAssassin über das "Comprehensive Perl Archive Network" (CPAN) [6] verbreitet werden und problemlos Code aus dem CPAN wiederverwenden.

Die Lizenz spielte übrigens für den Beginn dieses Projekts eine wesentliche Rolle. Bevor er den SpamAssassin schrieb, benutzte Justin einen anderen, ebenfalls in Perl geschriebenen, Mailfilter, der wegen seiner statischen Tests und seiner unklaren Lizenz problematisch war.

Von diesem Projekt übernahm Justin die Idee, Punktwertungen zu vergeben, ein Konzept, welches dem "Adaptive Scoring" des GNUS News- und Mailreaders [7] sehr ähnlich ist.

In der Praxis funktioniert der SpamAssassin, indem Emails verschiedene Tests durchlaufen müssen. Es existieren beispielsweise Tests dafür, ob Emails ausschließlich im HTML-Format vorliegen, ob sie bekannte Spam-Phrasen enthalten, womöglich unter Berufung auf bestimmte Paragraphen behaupten, kein Spam zu sein, verdächtig viele Ausrufezeichen oder Fragezeichen enthalten, von "Millionen Dollars" sprechen und so weiter und so fort.

Beim Durchlaufen dieser Tests sammeln Emails Punkte, wobei der Nutzer in einem einfachen ASCII-Konfigurationsfile festlegen kann, welche Tests wie bewertet werden. Überschreitet die Gesamtpunktzahl einer Email einen bestimmten - ebenfalls vom Nutzer definierbaren - Schwellenwert, so geht der SpamAssassin davon aus, daß es sich höchstwahrscheinlich um eine Spam-Email handelt.

Auf Basis dieser Entscheidung fügt der SpamAssassin automatisch Header-Flags ein, die über die Ergebnisse seines Testlaufs informieren. Auf Wunsch wird bei vermutlichen Spam-Emails auch der Content-Type auf "text/plain" gesetzt, wodurch die spätere Überprüfung durch den Nutzer deutlich angenehmer wird. Zudem gibt es die Möglichkeit, am Anfang der Spam-Emails einen ausführlichen Testbericht einzufügen, mit dessen Hilfe nachvollzogen werden kann, wie das Ergebnis zustande kam.

Die größte potentielle Gefahr sind eindeutig die "falsch-positiven" Ergebnisse, also echte Email, die fälschlicherweise als Spam klassifiziert wurde. Daher empfiehlt es sich, bei Gelegenheit einen Blick auf den Spam-Ordner zu werfen, in den solche Mails geeigneterweise umgeleitet werden sollten, um falsch-positive Ergebnisse korrigieren zu können.

Natürlich kann auch die Empfindlichkeit des SpamAssassins reduziert werden, was jedoch zu erhöhten Anteilen an nicht-erkannter Spam-Email führt. Hier die richtige Balance zu finden ist Aufgabe desjenigen, der den SpamAssassin konfiguriert.

Um zu verhindern, daß Spammer Wege finden, den SpamAssassin zu umgehen, wird versucht, möglichst viele unterschiedliche Tests durchzuführen und das Projekt ist zudem einfach erweiterbar.

Es werden natürlich auch Online-Backlists unterstützt. Dies gilt sowohl für die DNS-blacklists, die bekannte Ursprungsorte und Relays für Spam referenzieren, als auch für Vipul's Razor, [8] eine Spam-Datenbank, die es erlaubt, bereits bekannte Spam-Email zu identifizieren.

Um das Filtern großer Mengen von Mail zu vereinfachen und um die Anbindung an möglichst viele Mail-Quellen zu ermöglichen, hat Craig Hughes den "spamd" Daemon geschrieben, der Teil des SpamAssassin Pakets ist.

Die größte Schwäche des SpamAssassin ist momentan vermutlich, daß er sich eher an den technisch versierten Nutzer wendet und (noch) nicht über eine grafische Benutzeroberfläche verfügt.

Dies zu beheben, sowie das Schreiben neuer Tests und die Anbindung an noch mehr Mail-Quellen, ist Kernpunkt der weiteren Entwicklung. Im Moment existieren Anbindungen an Procmail, ein Mail::Audit Plugin, Qmail, Postfix und Sendmail über die Milter-Library.

Es sei gestattet, zu erwähnen, daß das sendmail-milter Plugin [9] nach einer längeren ergebnislosen Recherche nach bereits existenten Lösungen von mir geschrieben wurde, um den SpamAssassin zum Filtern aller bei mir eingehenden Mail verwenden zu können. Da mir jedoch die Zeit fehlt, dieses Projekt weiter zu betreuen, hat in bester Freier Software-Tradition Michael Brown, dessen Unternehmen es im kommerziellen Umfeld anbietet bzw. einsetzt, als neuer Maintainer die Pflege übernommen.

Ein schönes Beispiel, wie bei Freier Software die klassische Selbsthilfe mit den kommerziellen Interessen eines Unternehmen zum Wohle aller Nutzer harmonisieren kann.

Angesichts der anschwellenden Flut von Spam-Emails, die droht, das Internet unter sich zu begraben, muß ich gestehen, daß sich Projekte wie der SpamAssassin bei mir großer Beliebtheit erfreuen, erspart er mir doch jeden Tag den Blick auf etwa 60 Spam-Emails.

Voxximate

Regelmäßige Leser der Brave GNU World sollten mit den Argumenten für Freie Software im wissenschaftlichen Bereich mittlerweile recht vertraut sein.

Letztlich ist Freie Software langfristig die einzig sinnvolle Wahl für alle Art von wissenschaftlicher Arbeit, da nur sie die Garantie bieten kann, auch in Zukunft einsetzbar zu sein und zudem erlaubt, sie in eigene wissenschaftliche Ergebnisse mit einzubeziehen bzw. als Teil derselben zu veröffentlichen und bei Bedarf weiterzugeben.

Voxximate [10] von Andreas Neumann ist ein solches Projekt für wissenschaftliche Freie Software unter der GNU General Public License.

Voxximate ist eine Abkürzung für "Vortex flow simulation made at home", es handelt sich um ein Programm zur Strömungs-/Wirbelsimulation in Flüssigkeiten. Das Programm arbeitet aufgrund von vorherbestimmten Startpositionen und berechnet in diskreten Schritten die gegenseitige Beeinflussung jedes Wirbels durch alle anderen Wirbel und somit die Veränderung der Positionen im Laufe der Zeit.

Besonders nützlich dürfte das Programm vor allem für Studenten sein, die im Laufe ihres Studiums mit der Dynamik von Flüssigkeiten konfrontiert werden und sich einen Einblick darin verschaffen möchten, wie Wirbel miteinander interagieren und Strukturen aufbauen können.

Geschrieben wurde Voxximate in Java, was die üblichen Java-Probleme mit sich bringt, doch sollte das niemand davon abhalten, Andreas bei der weiteren Entwicklung zu unterstützen. Das Augenmerk für die nächsten Schritte liegt auf einem grafischen Editor zum Festlegen der Anfangsbedingungen, dem Speichern von Grafiken als Datei sowie als Animation, die dann z.B. auf dem Netz veröffentlicht werden kann.

Monica

Monica [11] ist ein Programm von Tilo Riemer zur Kalibration des Monitors. Es wurde in C++ geschrieben und greift zurück auf das Fast Light Toolkit (FLTK) [12] sowie das xgamma Programm von XFree86. [13]

Eine falsche Gammakorrektur des Monitors kann dazu führen, daß nahe beieinander liegende Farben nicht mehr unterschieden werden können, bzw. ein unbefriedigender Eindruck der Farbverhältnisse entsteht. Gerade wenn der Computer für grafische Aufgaben eingesetzt werden soll, kann dies natürlich störend sein.

Anfangs versuchte Tilo Riemer, das verwandte Projekt KGamma [14] zu verwenden, stellte jedoch fest, daß er es aufgrund von Problemen mit nicht vorhandenen KDE-Bibliotheken nicht ohne Weiteres kompilieren konnte und daß KGamma scheinbar so sehr in KDE eingebettet ist, daß es große Teile von KDE benötigt, um seinen Dienst zu tun.

Daher begann er im Januar 2002 mit der Arbeit an Monica, dessen große Vorteile sind, daß es klein und schnell ist. Dies erlaubte Monica die Einführung eines "on-the-fly" Modus, der ein dynamisches Feedback erlaubt. Auf einem 900MHz Computer benötigt dieser Modus etwa 10-20% der CPU-Leistung.

Die weiteren Stärken von Monica sind, daß über das FLTK hinaus keinerlei Abhängigkeiten bestehen und um Änderungen nicht vom Window-Manager abhängig zu machen, verzichtet es zudem auf eigene Konfigurationsfiles und modifiziert stattdessen die ".xinitrc" des betreffenden Nutzers.

Das kürzliche Erscheinen der Version 1.0 deutet an, daß Tilo nicht vor hat, in nächster Zeit weitere Arbeit in Monica zu investieren, obwohl er Freiwillige für eine Internationalisierung von Monica begrüßen würde.

Anfangs hatte Tilo vor, Monica als "Public Domain" herauszugeben, da es ihm nicht wichtig genug schien, um sich mit Lizenzen auseinanderzusetzen. Jedoch schrieb er in den Sourcecode "Copyright © Tilo Riemer", ohne sich weitere Gedanken zu machen.

Nun ist der Begriff Public Domain in Kontinentaleuropa nicht unproblematisch. In Deutschland wird er im Allgemeinen juristisch so interpretiert, daß ein Programm frei von urheberrechtlichen Ansprüchen ist - also niemand das Urheberrecht beansprucht, weil der Autor entweder nicht ermittelt werden kann oder bereits seit mehr als 70 Jahren tot ist. Beides war in diesem Fall eindeutig nicht gegeben.

Daher entschied sich Tilo nun, Monica unter einer BSD-artigen Lizenz herauszugeben, löste so die akuten Probleme und machte Monica zu Freier Software.

Diese Geschichte ist jedoch bei weitem kein Einzelfall und zeigt sehr schön, daß Entwickler einerseits nur ungern über Lizenzen nachdenken, es aber dennoch recht leicht ist, auf diesem Gebiet Unsicherheit zu erzeugen. Daher soll an dieser Stelle eine möglichst verständliche Einführung in die Problematik der juristischen Wartbarkeit Freier Software geboten werden.

Juristische Wartbarkeit Freier Software

Es ist allgemein bekannt, daß ein Großteil der Software der permanenten technischen Betreuung bedarf, um nicht sehr schnell seine Nützlichkeit zu verlieren. Oft ist nur Software, die dauerhaft gepflegt wird, auch dauerhaft einsetzbar.

Dieser per se technische Vorgang beruht sowohl auf dem Zugang zum Sourcecode, wie auch auf dem Recht bzw. der Freiheit, diese Wartung durchführen zu dürfen. Das Definieren der Rechte und Pflichten des Einzelnen in einer Gesellschaft ist jedoch allgemein Aufgabe des politischen/juristischen Systems.

Wie gut oder schlecht das juristische System funktioniert soll hier nicht bewertet werden, es sollte jedoch verstanden werden, daß ein Teil der Voraussetzungen zur technischen Wartbarkeit juristischer Natur sind.

Gerade im kommerziellen Umfeld ist die Garantie der dauerhaften Wartbarkeit ein sowohl betriebs- wie auch volkswirtschaftlich ausschlaggebendes Argument für Freie Software. Dieser Vorteil hängt durchaus maßgeblich von der juristischen Wartbarkeit Freier Software ab.

Die Freiheiten, Rechte und Pflichten Freier Software werden über Lizenzen gewährt und teilweise auch geschützt, wobei die Lizenzen mittels des Urheberrechts des Autors an der Software "verankert" werden. Zwar würde Freie Software des Urheberrechts nicht zwingend bedürfen, doch da es existiert, muß sie sich damit auseinandersetzen.

Was bedeutet in diesem Zusammenhang die juristische Wartbarkeit?

Auch wenn dies dem intuitiven Empfinden vieler Menschen entgegensteht, ist das Rechtssystem nicht statisch, es verändert sich permanent.

Änderungen, die das Urheberrecht betreffen, können, wie dies kürzlich in Deutschland der Fall war, durchaus dazu führen, daß Freie Software geschwächt oder sogar illegal würde. In diesem speziellen Fall waren ifrOSS [15] und FSF Europe [16] in der Lage, eine Änderung der geplanten Urheberrechtsreform vorzuschlagen, die eine Ausnahme für Freie Software macht. Dieser Vorschlag wurde in der vom ifrOSS gemachten Form direkt in das Gesetz übernommen, welches am 25.1.2002 beschlossen wurde und bald in Kraft tritt.

Eine der Aufgaben der FSF Europe ist, auch in Zukunft solchen Entwicklungen nachzuspüren und sie nach Möglichkeit positiv für Freie Software zu beeinflussen. Ohne die Kooperation mit Organisationen wie dem ifrOSS, welches im juristischen Raum beheimatet ist, wäre die Wahrnehmung solcher Aufgaben allerdings ungleich schwieriger, weshalb die FSF Europe versucht, Kooperationen in ganz Europa auf diesem Gebiet zu etablieren und stärken.

Es wäre jedoch auch vorstellbar gewesen, daß eine Änderung der juristischen Rahmenparameter eine Anpassung der Lizenzen notwendig gemacht hätte. Juristische Änderungen oder neue technische Nutzungskonzepte wie das "Application Service Providing" (ASP) könnten beispielsweise in bestimmten Gebieten den Schutz der Freiheit unterlaufen oder unwirksam machen und so den Geist der Lizenz verletzen.

Die meisten Entwickler stellen ihre Software unter die GNU General Public License in dem Bewußtsein, damit die Freiheit ihrer Software gesichert und geschützt zu haben. Damit ist der größte und wichtigste Schritt in Richtung Sicherung Freier Software bereits geschehen. Durch die Verwendung der "or any later version" Klausel wird zudem die FSF bedingt in die Lage versetzt, die Lizenzierung unter (L)GPL weltweit und auf Dauer zu verteidigen, schützen und warten.

Manchmal jedoch kann es wichtig werden, die Lizenz explizit zu ändern. Projekte, die keine zentrale Verwaltung der Rechte etabliert haben, können in diesem Fall in ernste Schwierigkeiten geraten, speziell wenn sie die "or any later version" Klausel der GPL entfernt haben.

In einem solchen Fall müssen alle Entwickler - sofern sie auffindbar sind - der betreffenden Änderung zustimmen, was bei dem großen Spektrum an Interessen und Meinungen der an einigen Projekten beteiligten Entwickler nicht sehr wahrscheinlich scheint.

Zudem ist im Allgemeinen nur der Inhaber der sogenannten "exklusiven Nutzungsrechte" bzw. des "Copyright" berechtigt, die Einhaltung der Lizenz vor Gericht einzufordern. Solche Projekte können also zusätzlich in Schwierigkeiten kommen, wenn es um die Vertretung der gemeinsamen Interessen des Projekts vor Gericht geht.

Bei ausreichend vielen Autoren müssen sich immer mehrere Autoren zusammenfinden und gemeinsam agieren, um ihre einzelnen Interessen schützen zu können. Dies erfordert viel Koordination, Zeit und Aufwand. Auch sind nicht alle Autoren willens oder fähig, einen unter Umständen langwierigen Rechtsstreit durchzustehen.

Es wäre gut, wenn sich in Zukunft mehr Projekte dieser Zusammenhänge bewußt wären und entsprechende Vorkehrungen träfen. Durch Ernennung eines Treuhänders kann sich ein Autor auch wieder mehr auf die Verbesserung der Software an sich konzentrieren.

Ein Projekt mit in dieser Hinsicht geordneten Verhältnissen hat zudem sicherlich einen Pluspunkt bei den Anwendern, denn es ist wahrscheinlich, daß Anwender immer häufiger auf diese achten werden.

Um in diesem Sinne die juristische Wartbarkeit Freier Software - speziell im Kernbereich des GNU-Projekts, aber auch darüber hinaus - auf Dauer sicherzustellen, arbeitet die Free Software Foundation bereits lange mit den sogenannten "Copyright Assignments", die es ihr erlauben, die Rechte Freier Software (notfalls auch vor Gericht) zu schützen und die Lizenzen den veränderten Verhältnissen anzupassen.

Da sich zudem das kontinentaleuropäische Urheberrecht maßgeblich vom anglo-amerikanischen Copyright unterscheidet, hat die FSF Europe gemeinsam mit Axel Metzger, Carsten Schulz und Till Jaeger vom ifrOSS an einer treuhänderischen "Übertragung exklusiver Nutzungsrechte" gearbeitet, die der FSF Europe die Möglichkeit gibt, als Treuhänder der Interessen der Autoren zu agieren.

Dem Autor werden dabei unbegrenzt viele sogenannte "einfache Nutzungsrechte" garantiert, was auch die Möglichkeit der Duallizenzierung unter einer proprietären Lizenz durch den Autor offenhält.

Gleichzeitig wird dem Autor garantiert, daß die FSF Europe die ihr übertragenen Rechte nur verwendet, um Freie Software voranzubringen und daß die Software ausschließlich unter einer Freien Lizenz veröffentlicht wird - andernfalls fallen alle Rechte zurück an den Autor.

Diese Vereinbarung befindet sich im Moment in der letzten internen "Review-Phase" und wird in absehbarer Zeit veröffentlicht werden.

Als Präsident der FSF Europe erscheinen mir die Free Software Foundations für diese Aufgaben am geeignetsten, da sie diesen Herausforderungen mit der gleichen Zuverlässigkeit begegnen werden, für die die FSF in langen Jahren bekannt geworden ist.

Sie besitzen nicht nur das größte Wissen und die umfangreichste Erfahrung mit der GNU General Public License und Lesser GPL, sie können auch weltweit agieren und stehen zurecht in dem Ruf, die Interessen Freier Software zur Not auch mit juristischen Mitteln durchsetzen zu können.

Genug für heute

Damit soll es genug sein. Ich hoffe, es ist mir gelungen, gerade im letzten Teil mehr Bewußtsein für die Zusammenhänge und auch für die Aufgaben und Arbeit der Free Software Foundation schaffen zu können.

Wie üblich bitte ich um zahlreiche Anregungen, Kommentare, Ideen, Fragen und neue Projekte per Email. [1]