AK's weblog

Lange Zeit ist mir das schon auf der Zunge gelegen, aber Fefes Artikel zu Lizenzen hat endlich das Fass zum Überlaufen gebracht.

Um es mal direkt auszudrücken: ich hasse dieses mitschwingende Überlegenheitsgefühl, wenn FOSS-Leute die achso tolle GPL als bestes Geschenk an die Menschheit anpreisen und im selben Atemzug über andere Open-Source-Lizenzen herziehen. Nicht nur bei Fefe, in den letzten Jahren ist mir das nur zu oft untergekommen. Ich war so vor ca. 10 Jahren selbst so naiv, ähnlich zu agieren. Das Free-Software-Mitläufertum. Der (überspitzt gesagt) Gutmenschenlizenzterror gegen alle, die nicht mit der Einheitsmeinung konform gehen. Jaja, "Gutmensch" ist ein verbranntes Wort und so, aber GPL-Apologetik ist in meinen Augen in den meisten Fällen unglaublich moralinsauer.

Es gibt Gründe, andere Lizenzen als die GPL einzusetzen. Ich werde exemplarisch ein paar aufzählen.

Mein persönlicher Grund, eine andere Lizenz als die GPL einzusetzen (zugegeben, ich habe bis ca. 2006 auch unter der GPL veröffentlicht), ist, dass ich Komplexität hasse. Komplexität nicht nur in Software, sondern auch in ihrer Lizenzierung. Ich will die Lizenz, die ich verwende, vollständig lesen und verstehen können. Bei meiner favorisierten Lizenz, der MIT License, da geht das. Der gesamte Lizenztext besteht aus gerade mal 162 Wörtern (sagt wc), in relativ leicht verständlichem Englisch, das mal schnell überfliegt und man danach trotzdem noch gut erklären, was die wichtigen Punkte der Lizenz sind. Wer kann das von der GPL behaupten?

Und genau darin sehe ich einen entscheidenden Nachteil der GPL, egal in welcher Inkarnation: niemand (außer ein paar wenigen Spezialisten) versteht die GPL tatsächlich in ihrer Gesamtheit. Die GPL ist sprachlich auch in einem teilweise eher komplexen Legalese gehalten, und auch extrem lang. Und was erlaubt bzw. verbietet die GPL eigentlich? Tja, darüber scheiden sich die Geister. Zumindest, wenn man mit "Otto Normal-Entwickler" spricht. Die Gesamtheit der Mythen über die GPL ist unfassbar lang, dementsprechend viel "debunking" findet man etwa auf Google. Und woran liegt das letztendlich? Weil niemand die GPL liest und versteht! Niemand wendet sich der Primärliteratur zu, und quasi jeder kriegt seine Meinung aus Sekundärquellen, die die GPL interpretieren. Und gerade wenn man die Interpretationen von GPL-Apologeten wie Richard Stallman liest, merkt man, dass die GPL nur allzu schön dargestellt wird. Und ein "Herr Richter, bitte, RMS, die FSF und Eben Moglen haben aber gesagt, dass..." kann bei einer gerichtlichen Auseinandersetzung schon mal schön nach hinten losgehen.

Insgesamt halte ich das vollständige Verständnis von Lizenzen, die man selbst einsetzt, für einen Emanzipationsschritt, für eine Befreiung von den herrschenden Meinungen sogenannter Vordenker. Jeder Entwickler sollte sich ernsthaft zurücklehnen und fragen, "was will ich denn eigentlich mit der Lizenzierung meiner Softwarebezwecken?"

Ein weiterer Aspekt neben dem Verständnisargument ist meiner Meinung nach auch folgender: Software ist Infrastruktur für andere Software. Software kann (de-facto-)Standards prägen. Um diese Möglichkeit überhaupt zu eröffnen, ist eine weite Verfügbarkeit zweckmäßig, ja sogar notwendig. Warum mehrere Implementierungen von Kompressionsalgorithmen schaffen, wenn man eine einzige schaffen kann? Warum mehrere proprietäre, unvollständige und buggy Implementierungen eines HTTP-Clients, wenn man libcurl einsetzen kann? Die zlib steht unter der zlib-Lizenz. bzip2 steht unter einer BSD-artigen Lizenz. libcurl steht unter der MIT License. Ich nenne das als Beispiele für essentielle Infrastruktur. Würden diese (und andere) Libraries unter der GPL stehen, dann hätten wir mit Sicherheit etliche Interoperabilitätsprobleme und proprietäre buggy Implementierungen mehr, evtl. noch mit einer Prise Sicherheitslücken oben drauf. Eine Vielfalt an Open-Source-Lizenzen kann auch eine Verbesserung von code reuse bedeuten.

Ironisch ist ja, dass die FSF dieses Problem erkannt hat, und die LGPL erschaffen hat, gegen die man linken kann, ohne dass die dagegen gelinkte Software ebenso unter die Lizenzbedingungen der Library fällt. Die LGPL ist noch komplexer als die GPL. Ich erinnere mich an einen Chaos Communication Congress vor etlichen Jahren, wo Fefe in einem Q&A anführte, dass die meisten Entwickler die Details der LGPL gar nicht kennen. ACH! Ich hab ja gerade selber reingeschaut, und finde etwa die Sektion 3 der LGPLv3 durchaus spannend. Warum ist das bei Templates eigentlich auf 10 oder weniger Zeilen beschränkt? Ich denke da nur an template-lastiges C++. Und trotz der LGPL ist nur wenig (L)GPL-lizenzierte Software tatsächlich Infrastruktur und "systemrelevant", mit Ausnahmen wie glibc, libgcc, libstdc++ und ähnlichem Kram. Schaut euch das selber mal auf euren Systemen an. Noch weniger im Web. Wer relevant sein will, öffnet sich auch der Möglichkeit, dass seine Software auch in proprietären Projekten verwendet werden kann.

Aber gut. Was ich allerdings wirklich unredlich von Fefe finde, ist seine Annahme, BSD-lizenzierter Code wäre geklaut. Klauen, das ist fast so schlimm wie Raubkopien!!!1! Und er moniert, dass Leute, die sowas tun, nicht mal den ursprünglichen Autoren bescheid geben müssen. Natürlich nicht. Ist ja auch völlig konform zur Lizenz. Dass der Autor der Software das möglicherweise in voller Absicht getan hat, kommt ihm gar nicht in den Sinn. Ich kann aber für mich sprechen, und die von mir unter der MIT License veröffentlichte Software ist das mit voller Absicht. ICH BIN DER AUTOR, UND ICH WILL DAS GENAU SO HABEN!!! NIEMAND "KLAUT" DA WAS!!!

Das bringt mich zum nächsten Grund, warum jemand Software unter einer anderen Lizenz veröffentlicht: weil es niemandem schadet. Für mich selbst betrachtet: welchen Nutzen habe ich, wenn ich meine Software unter die GPL stelle? Damit ich irgendjemandem mal in Zukunft verbieten könnte, meine Software in seine zu integrieren? Wenig realistisch, und dann noch dazu viel zu konfrontativ. Und: was bringt's? Niemand wird mir wegen solcher Einschränkungen eine Lizenz abkaufen wollen oder mich anstellen oder ähnliches, nein, man sucht weiter nach einer offeneren Alternative.

Seit Anfang des Monats hab ich ja einen neuen Job. Bei meinem neuen Arbeitgeber ist es Policy, dass Software, die als Open Source veröffentlicht wird, unter der 3-clause BSD license stehen soll. Und warum? Weil es niemandem schadet. Konkret schadet es meinem Arbeitgeber nicht, Dinge, die dort entwickelt werden, offenzulegen, und zwar in einer Form, die es anderen ermöglicht, diese Software zu nehmen und damit ihr ganz eigenes, proprietäres Softwareteil zu bauen, auf dem sie dann ihr Startup fußen lassen und Arbeitsplätze und persönliches Vermögen schaffen. Und damit man nicht falsch versteht, ich sehe Harald Weltes Bemühungen, GPL-Verletzungen zu verfolgen, unter dem selben Licht, nämlich dass Harald Welte schon der Meinung ist, dass es ein Schaden ist, wenn seine Software ohne Einhaltung der Lizenzbedingungen verbreitet wird, und er verfolgt das auch entsprechend. Was Fefe und mich an dem Punkt allerdings unterscheidet, ist, dass ich beide Sichtweisen für durchaus legitim betrachte, während Fefe den Einsatz aller Lizenzen außer der GPL in ihren Ausprägungen delegitimiert.

Letztlich führt dieser GPL-Radikalismus mit AGPL etc. ja nicht dazu, dass mehr Software unter der GPL veröffentlicht wird, sondern dass mehr Entwickler darauf schauen, einen weiten Bogen um die GPL zu machen, um ja nicht "infiziert" zu werden (das finde ich übrigens auch spannend, von GPL-Apologeten wird ja immer geleugnet, die GPL hätte einen viralen Charakter, während Fefe das offen ausspricht).

Poah, wenn ich sowas lese, dann muss ich kotzen:

Stallman sagte, auch der Kernel enthalte nicht freie Bestandteile. Torvalds persönlich bezeichnete der GNU-Gründer als "einen Studenten, der einen Kernel geschrieben hat".Stallman wirft Torvalds vor, nicht für freie Software einzustehen sondern vielmehr den Spaß am Programmieren im Vordergrund zu sehen.

Ich sage nur: was RMS mittlerweile so von sich gibt, ist völlig überbewertet. Wenn RMS Linus Torvalds vorwirft, den Spaß an der Programmierung hochzustellen, dann ist das im Grunde genommen der Vorwurf, dass Linus Torvalds ein Hacker (im ursprünglichen Sinne) ist.

Meiner Meinung nach zeigt das doch wieder einmal, wie verbohrt RMS mittlerweile "seine" Ideologie bewirbt. Auch nion meint, dass RMS nur noch zu seinesgleichen predigt. Und dann noch sowas:

Vor allem kommt es laut Stallman darauf an, dass Schulen "allein freie Software unterrichten und einsetzen". Damit könnten sie zum einen Geld sparen. Frei heiße zwar nicht unbedingt kostenlos. Aber gerade für Ausbildungsstätten sei die Freiheit wichtig, "Programme weiter zu verbreiten".

Ich sage: man darf Fundamentalisten wie RMS nicht die Deutungshoheit über den Freiheitsbegriff kampflos überlassen.

Der Richtungsstreit zum Freiheitsbegriff im Kontext Software führt ja im wesentlichen in zwei Richtungen, und zwar einerseits die individuelle Freiheit, und andererseits die kollektive Freiheit. Während GNU-Fundis wie RMS ausschließlich kollektive Freiheit fordern, und dabei individuelle Freiheiten ziemlich zugrunde richten, ist die Gegenbewegung um keinen Deut besser, nämlich die BSD-Fundis, die es zwar OK finden, dass ihre Arbeit von kommerziellen Firmen en masse gerippt wird, aber sich daran stößt, wenn sich BSD-Sourcecode in GPL-lizenzierter Software wiederfindet: individuelle Freiheit über alles, aber kollektive Freiheit wird aktiv bekämpft. Ein dringend nötiger Ausgleich zwischen den beiden fundamentalistischen Position ist dringendst notwendig, aber leider nicht in Sicht. Klar ist aber, dass diese Art von Fundamentalismus in einem Themenkomplex wie Softwarelizenzierung mittel- bis langfristig äußerst schädlich ist.

Und zu guter Letzt möchte ich noch betonen: zur wahren Freiheit gehört auch dazu, die Freiheit zu haben, zwischen Freier Software/Open Source und proprietärer Software wählen zu können.

Nachdem das Ranten über GNU so schön ist, hier noch ein kleiner Nachschlag. Wieder fast jeder, der schon mal Software unter Linux selbst compiled hat, weiß, muss man vor dem Übersetzen meist noch ./configure aufrufen, welches dann ein paar systemspezifische Konfigurationsinformationen sammelt und ein Makefile generiert.

Zum Erstellen dieses configure-Skripts gibt es ein Tool namens autoconf. Dieses generiert aus einem configure.in bzw. configure.ac File das configure-Skript. Das configure.ac wiederum kann man sich aus dem bestehenden Sourcetree generieren lassen und dann händisch anpassen. Das Makefile, das man dann zum Compilieren benötigt, wird übrigens vom configure-Skript i.A. aus dem Makefile.in erzeugt, wobei hierbei Platzhalter durch die entsprechenden ermittelten bzw. gesetzten Werte (./configure lässt sich ja relativ gut durch Commandline-Switches steuern) ersetzt werde. Makefile.in's schreiben sich ähnlich wie Makefiles. Und weil das Schreiben von Makefile.in's sooo schwer ist, gibt es auch gleich noch ein weiteres Tool, automake, mit dem man sich das Makefile.in aus einem Makefile.am erzeugen lassen kann.

Durch einen jahrelangen Reifungsprozess sind autoconf und automake schon so gut integriert, dass sie fast eine Symbiose bilden. Diese Symbiose ist so gut, dass es vom GNU-Projekt keine Dokumentation gibt, wie man autoconf ohne automake verwendet. Das heisst, jeder enthusiastische Programmierer, der auf die Vorteile von autoconf zurückgreifen will, und sich das selbst anhand der Doku aneignet, wird auch automake verwenden. Am Ende der Integration von autoconf und automake ins eigene Sourcepaket bleiben dann ein ca. 200 kB grosses configure-Skript und ein 50 kB grosses Makefile.in übrig, sowie noch 50 - 100 kB andere Dateien wie z.B. diverse Helper-Shellskripte. Das ist natürlich sehr toll, wenn das eigene, selbstgeschriebene Tool aus vielleicht 15 kB Sourcen besteht.

Aber trotzdem gibt es Mittel und Wege, um ohne automake auszukommen, was die Gesamtgröße der generierten Dateien um einiges herabsetzt. Wie das im Detail geht, wäre jetzt zuviel des guten, jedoch nur ein kurzer Tipp: wer Makefiles schreiben kann, und /usr/local durch _prefix und gcc durch _CC ersetzen kann, der kann Makefile.in's schreiben, und braucht kein automake.

Hier noch mal die Erklärung: autoconf sorgt für das configure-Skript, das Systemkonfiguration sammelt und das Makefile erzeugt, und automake sorgt für das Makefile.in-Template, sodass der Programmierer sich um weniger Makefile-Details kümmern muss (muhahahaha). Eigentlich eine gute Trennung. Theoretisch. Wie sieht es praktisch aus? Nun, das Dokumentationsproblem habe ich schon erwähnt, aber etwas wesentlich perfideres hab ich heute wieder mal entdecken müssen: autoconf ist ja m4-basiert, und bringt einige fertige m4-Makros zum Testen auf bestimmte Konfigurationen mit. Allerdings gibt es noch wesentlich mehr Makros. Zum Beispiel bei automake. Bei automake sind wirklich jede Menge m4-Makros dabei, die wesentlich mehr können, und die einfach eingebunden werden können. Welche Möglichkeiten hat Joe Average Programmer hier? Entweder er kopiert die m4-Makros aus dem automake-Paket in seinen eigenen Sourcetree, oder aber integriert einfach automake in sein eigenes Buildsystem.

Warum GNU diese Makros nicht zu autoconf dazugepackt hat? Nun, das weiß nur Gott ("Gott? welcher Gott?"). Auf jeden Fall haben diese Beobachtungen bei mir den schalen Nachgeschmack hinterlassen, GNU will möglichst viele Programmierer mit autoconf und automake "zwangsbeglücken". Mittlerweile ist es ja fast nicht mehr möglich, ohne das Konfigurieren des Sourcetrees auf Systemeigenheiten noch portable Programme zu schreiben, die "out of the box" unter einem Allerwelts-Unix wie Linux, *BSD und Solaris compilieren und linken. GNU hat sicherlich seines dazu beigetragen, und bringt gleichzeitig ein "Wundermittel" mit, das halt zu 300 kB Scheisse in jedem Sourcepaket führt. Leider sind autoconf und automake als de-facto-Standard etabliert, andere Buildsysteme dagegen finden kaum Beachtung oder Einsatz.

Manchmal könnte man die GNU-Leute so richtig schön verprügeln. Weil die linke Hand nicht weiß, was die rechte tut. Konkret ärgere ich mich derzeit wegen iconv(), der SuSv3-standardisierten Funktion zum Konvertieren zwischen verschiedenen Zeichensätzen, bzw. der Signatur ebendieser.

SuSv3 schreibt vor:

die glibc hat:
die dietlibc hat:
GNU libiconv hat (wenn das System keine iconv-Implementierung hat):
und NetBSD hat diesen Bloedsinn gleich nachgemacht:
Wer immer auf diese hirnrissige Idee gekommen ist, gehört einmal ordentlich verprügelt. Standards aren't there for no reason. Und falls sich jemand denkt, "ach, das macht doch nichts, char ** ist sowieso auf const char ** zuweisungskompatibel", der hat sich geschnitten. Noch dazu bin ich völlig unmotiviert, für kaputte Systeme Workarounds zu basteln. Oder anders ausgedrückt: glibc und dietlibc gut, GNU libiconv und *BSD böse.

Soweit ich übrigens rausfinden konnte, liefern FreeBSD und OpenBSD keine eigene iconv-Implementierung mit, sondern es gibt lediglich die GNU libiconv in den Ports. Was ich übrigens nicht verstehen kann, eine rudimentäre iconv-Implementierung, die UTF-8, UTF-16[bl]e, ISO-8859-x, und die gängigsten Codepages unterstützt, ist in einer Woche gebastelt. Nur halt nicht von mir.

Update: ich hab den Grund für die Diskrepanzen gefunden. Und zwar ist das const in der SuSv2-Definition drinnen, in der SuSv3-Definition jedoch nicht mehr. *gna*