![[image of the Head of a GNU]](/graphics/gnu-head-sm.jpg)
(jpeg 7k)
(jpeg 21k)
no gifs due to patent problems
Hallo allerseits, ich freue mich, Euch zur vierten Ausgabe der Brave GNU World begrüßen zu können. Diesen Monat möchte ich beginnen, indem ich ein paar Reaktionen auf die erste Ausgabe aufgreife.
Kommerzielle GPL Software?
Auf den Artikel zur Umbenennung der LGPL habe ich einige Emails erhalten, die sich darüber beschwerten, die LGPL sei eigentlich sogar wichtiger als die GPL. Beispielhaft sei hier ein Zitat aus einer Email von Marcel Ruff angeführt: "Ich allerdings finde daß möglichst alle freie Software der LGPL unterliegen sollte, da es für Mixturen von kommerzieller und freier Software absolut wichtig ist.". Diese Argumentation scheint logisch zu sein, basiert jedoch auf einer unzulässigen Annahme - doch dazu gleich.
Was genau ist der Unterschied zwischen LGPL und GPL? Die GNU General Public License garantiert jedem Nutzer das Recht, ein Programm zu benutzen, zu modifizieren und weiterzugeben wie es seinen Bedürftnissen entspricht. Damit dieses Recht dem User nicht vorenthalten werden kann, verbietet die GPL den Einsatz in proprietären Programmen. Dies ist bei der LGPL nicht der Fall. Auch wenn die Lizensierung des Codes nicht geändert werden darf, so ist die Verwendung in proprietären Programmen doch ausdrücklich erlaubt. Proprietär bedeutet, daß eine Person oder Firma den Anspruch erhebt, nur sie dürfe kontrollieren, wer dieses Programm besitzen bzw. benutzen darf. Nun wurde jedoch von kommerzieller Software gesprochen, also Software, mit der eine Person oder Firma Geld verdient. Die Frage ist also, ob kommerzielle Software notwendigerweise proprietär sein muß. Das GNU Projekt hat schon lange darauf hingewiesen, daß dies nicht der Fall ist und spätestens seit GNU/Linux ist der Beweis erbracht.
Es gibt viele Gründe, Software als Freie Software zu veröffentlichen, und der Versuch, dies den Entscheidungsträgern klar zu machen, beschäftigt einige Leute seit Jahren. Bekanntestes Resultat dieser Versuche ist sicherlich die "Open Source" Bewegung.
Doch es geht in diesem Beitrag nicht direkt um die Vorteile Freier Software, es geht vielmehr um die Frage, ob man der GPL oder LGPL den Vorzug geben sollte. Für manche Software ist die LGPL sicherlich sinnvoller, Sinn oder Unsinn sollte hierbei jedoch im Einzelfall abgewogen werden. Allgemein ist aus Sicht des GNU Projektes die GPL vorzuziehen, denn dadurch wird gerade kommerzieller Freier Software ein Wettbewerbsvorteil verschafft, der es angesichts der anderen Vorteile Freier Software auch kleinen Firmen ermöglichen kann, im Wettbewerb zu bestehen.
Soweit zur Theorie, der nächste Beitrag ist bestimmt auch gerade für kommerzielle Software von Interesse, da es in der Praxis extrem wichtig ist, die richtige Organisation zu wählen. Auch bei nur einem Entwickler kann eine solide Struktur viele Arbeitsstunden sparen, für verteilte Projekte mit mehreren Entwicklern ist teilweise geradezu lebenswichtig. Aus diesem Grunde möchte ich das nächste Projekt vorstellen.
Aegis
Aegis [4] von Peter Miller ist ein Projekt, welches auf nahezu allen Unix-Plattformen läuft und durch verwendung von GNU Autoconf leicht und schnell zu installieren ist. Ähnlich wie verwandte Projekte besitzt Aegis ein zentrales Archiv, das sogenannte Repository. In diesem Repository sind alle Versionen des bearbeiteten Projektes seit seiner Erstellung vorhanden und es besteht so z.B. die Möglichkeit, zu älteren Versionen zurückzugehen oder zwei verschiedene Entwicklungsrichtungen eines Projektes parallel zu verfolgen.
Das Repository wird niemals direkt bearbeitet. Entwickler legen sich lokale Sourcebäume an, mit denen gearbeitet wird. Änderungen an dem Sourcecode werden zunächst in "Change Sets", also einer Sammlung von Änderungen zusammengestellt. Da Aegis darauf bedacht ist, die aktuelle Version fehlerfrei und lauffähig zu halten, gehört zu jedem Change Set auch immer mindestens ein Test. Diese Tests werden beim Einfügen der Änderungen ins Repository ein Teil desselben; auf diese Art und Weise können auch "historische" Tests gefahren werden, um sicherzustellen, daß eine Änderung keine Probleme bei alten Funktionen hervorruft. Da Aegis auch Abhängigkeiten zwischen Sourcefiles im Repository ablegt, kann es sogar von sich aus die für die aktuellen Änderungen sinnvollen Test-Programme vorschlagen. Nur wenn die spezifizierten Tests und ein Compiler-Durchlauf erfolgreich waren, wird das Change Set angenommen. Bevor es dann endgültig zum Teil des Repositories wird, muß es noch einmal durch eine Kontrollinstanz freigegeben werden.
Dies mag auf den ersten Blick recht kompliziert klingen, bietet aber einige Vorteile. Ein wesentliches Problem ist oft, daß andere Systeme ein File sperren sobald ein Entwickler bekannt gibt, er plane, Änderungen daran durchzuführen. Dies erzeugt einen Flaschenhals, der durch die Verwendung der Change Sets umgangen wird. Zudem findet ein großer Teil der Qualitätssicherung bereits im Entwicklungsprozeß statt ohne diesen merklich zu verlangsamen. Die Freigabe kann je nach Bedürftnissen des Projektes z.B. durch den einzelnen Entwickler, einer zentraler Gruppe von Entwicklern, einer unabhängigen Kommission oder einem Projektleiter vorgenommen werden. In jedem Fall gibt es jemanden, der die Änderung authorisiert. Außerdem stellt dieses System sicher, daß aus dem Entwicklungsprozeß direkt lauffähige und getestete Versionen herauskommen. Dies dürfte speziell für Firmen von großem Wert sein, denn sie können zu jedem beliebigen Zeitpunkt einem Kunden eine aktuelle und lauffähige Version zukommen lassen.
Was mir persönlich noch sehr gut gefällt, ist die Tatsache, daß die lokalen Versionen der Entwickler nicht vollständig vom Repository getrennt sein müssen. Aegis unterstützt sowohl "push" wie auch "pull" Updates. Also kann bei einer Änderung am Repository die Arbeitsversion des Entwicklers automatisch auf den neuesten Stand gebracht werden.
Um den Rahmen nicht zu sprengen möchte ich nur noch kurz erwähnen, daß Aegis multiple, verteilte Repositories unterstützt, als Transportmedien der Change Sets auch Email und HTTP anbietet und unter Berücksichtigung der Sicherheit geschrieben wurde.
Doch nun zu zwei Projekten, die auch für normale Anwender von Interesse sein dürften. Der Maintainer von GNU Enscript, Markku Rossi, hat mich gebeten, ein wenig über den Status und die Pläne seines Projektes zu berichten.
GNU Enscript
Bei GNU Enscript handelt es sich um ein Programm zum umformatieren von ASCII Texten. Als Ausgabeformate stehen dabei PostScript, ANSI (Terminal Kommandosequenzen), HTML, Overstrike (dies sind die nroff Kommandosequenzen, die z.B. in Manpages verwendet werden) und RTF zur Verfügung.
Auch wenn der Mechanismus zur Texterkennung augenblicklich überholt wird, verfügt Enscript bereits seit Version 1.5.1 über eine text-sensitive Stilvergabe, die den "font lock modes" des Emacs ähnelt. Dabei wird die Art des Files erkannt und es werden Stilarten (Farben, Schrifttypen, Schriftattribute) nach Kontext vergeben. Dadurch wird es möglich, über ein einzelnes Kommando beispielsweise Quelltexte zur Veröffentlichung auf dem Web aufzubereiten. Wem die mitgelieferten Stildefinitionen noch nicht genügen, dem sei die Enscript Homepage von Markku Rossi [5] empfohlen; augenblicklich unterstützt Enscript 42 verschiedene Sprachen und Filetypen.
Die neue Texterkennung ist deutlich schneller und vor allem besser konfigurierbar als die vorherige Version, da sie drei Ebenen (Hervorhebungs-Regeln, Stile und Ausgabe-Files) definiert, die unabhängig voneinander konfigurierbar sind. Wer sich das schon einmal anschauen möchte, kann die Betaversion [6] auf dem Netz finden.
Ein weiteres in diesem Zusammenhang nützliches Tool ist
Ted
Bei Ted [7] handelt es sich um einen einfachen Rich Text Prozessor von Mark de Does. Der User erhält die Möglichkeit, "mal eben schnell" einen Brief oder eine Email im WYSIWYG Modus zu erstellen. Da RTF als natives Fileformat benutzt wird, kann Ted problemlos Dokumente mit Microsoft Word oder Wordpad austauschen. Zudem kann Ted als RTF-Viewer für Netscape benutzt werden. Ziel des Projektes ist es, eine kleine und für jeden leicht bedienbare Applikation zu schaffen, die die bestmögliche Kommunikation mit der "Windows-Welt" erlaubt.
Auch wenn der Autor mittlerweile das GTK+ Toolkit vorziehen würde, ist Ted noch Motif basiert; die exakte Skalierung zwischen Bildschirm und Drucker sowie die Implementation anderer Alphabete als Latin1 hat im Augenblick jedoch Vorrang. Hilfe ist hierbei sehr willkommen.
Schließen möchte ich auch diesen Monat mit einer Anregung. Als ich letzlich eine Webpage zusammenstellte, fiel mir auf, daß ich keine "We run GNU" Icons für Webpages finden konnte. Genau gesagt habe ich bisher nirgendwo ein solches Icon gesehen. Design-Ideen dazu sowie Fragen, Anmerkungen und Kommentare zur Kolumne bitte wie üblich per Email an mich [1].
| Infos |
|
[1] Ideen, Anregungen, Kommentare an Brave GNU World:
column@gnu.org
|
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.
Updated: 10 Jul 1999 greve