Lars Kiesow [email protected] | www.larskiesow.de

Forks - Über Projektspaltungen, deren Hintergründe und Auswirkungen.

Zusammenfassung

Im Laufe der Geschichte von quelloffener Software ist es nicht selten vorgekommen, dass sich Softwareprojekte aufgespalten haben und fortan getrennt voneinander weiterentwickelt wurde.

Häufig wird eine solche Aufspaltung dabei grundsätzlich als ein negatives Ereignis dargestellt. In der folgenden Ausarbeitung wird der Frage nachgegangen, ob dieses immer der Fall sein muss, oder ob eine Aufspaltung auch etwas positives bewirken kann.

Um dieses darzustellen werden diverse Beispiele aus den letzten 40 Jahren Softwaregeschichte betrachtet. Dabei wird zunächst auf die Entwicklung der Projekte eingegangen, daraufhin wird versucht die Gründe für die jeweilige Aufspaltung darzulegen und abschließend werden die Folgen betrachtet.

Inhaltsverzeichnis

1 Fork
1.1  GNU/Linux-Distributionen
1.2  „Pretty Good Privacy“ und „GNU Privacy Guard“
1.3  Definition: Fork (Softwareentwicklung)
2 Beispiele von Forks
2.1  GNU/Linux-Distributionen
2.2  UNIX
2.3  Berkeley Software Distribution (BSD)
2.4  Emacs
2.5  NCSA httpd
2.6  GCC
2.7  GNU C Library
2.8  XFree86 und X.Org
2.9  SSH
2.10  OpenOffice.org & LibreOffice
3 Freie Lizenzen und Forks
3.1  Copyleft-Lizenzen
3.2  Nicht-Copyleft-Lizenzen
4 Fazit
4.1  Ergebnisse von Forks
4.2  Sind Forks nun gut oder schlecht?
Quellen

Fork! … oder doch nicht?

Begibt man sich im Internet auf die Suche nach einer Definition für den Begriff Fork, so wird man schnell feststellen, dass dies gar nicht so einfach ist. Nicht das Finden einer Definition ist schwierig. Von diesen gibt es eine Vielzahl. Schwierig ist es, nein, fast unmöglich, eine einheitliche Definition zu finden. Tatsächlich wird an so mancher Stelle ein Beispiel als offensichtlicher Fork angeführt, der an anderer Stelle als Beispiel für etwas, das gerade kein Fork ist, genannt wird. Bereiche, in denen es häufig zu Unklarheiten kommt, sind beispielsweise Reimplementierungen oder Softwaredistributionen.

Folgend soll versucht werden, zumindest für diese Ausarbeitung, Klarheit zu schaffen, was hier mit dem Begriff des Forks gemeint ist. Um dieses zu erreichen werden einige umstrittene Beispiele vorgestellt und bewertet. Abschlißend wird dann versucht, eine möglichst genaue Definition eines Forks zu geben.

GNU/Linux-Distributionen

1992 stellte Peter McDonald die erste GNU/Linux-Distribution unter dem Namen „Softlanding Linux System“ (SLS) zusammen. Dieses wurde schnell sehr populär, doch war leider nicht sehr stabil. Frustriert durch die vielen Fehler brachten Ian Murdock und Patrick Volkerding im Jahre 1993 jeweils eine eigene Distribution heraus. Diese waren Slackware und Debian. Volkerding entwickelte Slackware dabei nicht von Grund auf neu, sondern nutzte SLS als Grundlage. Er veränderte und erweiterte die Distribution und versuchte möglichst alle Fehler zu entfernen.

Nun zur Frage ob diese Distributionen Forks sind. Hat beispielsweise Patrick Volkerding SLS geforkt, als er Slackware gründete? Manchmal wird angeführt, dies sei nicht der Fall, da eine Distribution lediglich eine Zusammensetzung bestehender Software sei und diese Teile auch problemlos von anderen Systemen genutzt werden können, ohne das Konflikte auftreten. Dies trifft sicherlich auf große Teile einer Distribution zu. Dagegen spricht jedoch wiederum, dass jede Distribution auch sehr spezifische Teile enthält, deren Portierung problematisch sein kann. So kann beispielsweise schon nicht ohne weiteres ein Debian-Softwarepaket auf einem RedHat-Linux installiert werden. Auch kann nicht einfach YaSt, das grafische Programm zur Konfiguration von openSuse, zur Konfiguration von Fedora genutzt werden.

Wird eine neue Distribution als auf einer bestehenden aufgebaut, so soll diese im Rahmen dieser Arbeit daher als Fork gelten.

„Pretty Good Privacy“ und „GNU Privacy Guard“

Der US-Amerikaner Phil Zimmermann veröffentlichte 1991 das Programm “Pretty Good Privacy”’ (PGP). Dies sollte jeder Person ermöglichen einfach Daten verschlüsselt zu übertragen. Das ganze sollte vor allem aber ohne Hintertür geschehen. Um dieses sicherzustellen veröffentlichte er nicht nur das kompilierte Programm selbst, sondern auch dessen Quelltext.

Zu dieser Zeit existierten jedoch in den USA, wie auch in einigen anderen Ländern, strenge Restriktionen für den Export von Kryptografiesoftware, der mit einem Waffenexport gleichgesetzt wurde. Aufgrund der Genehmigung zur freien Weitergabe geschah es natürlich, dass das Programm den Weg über das Internet aus den USA fand, woraufhin Phil Zimmermann wegen illegalen Waffenexports angeklagt wurde1. Zwar wurde für den Export eine Lösung gefunden: MIT Press veröffentlichte den komplette Quellcode als Buch, das dann, aufgrund einer Gesetzeslücke, exportiert werden durfte und daraufhin im Außland abgescannt werden konnte. Die Software konnte aber dennoch nicht frei verbreitet werden.

Eine weitere Einschränkung von PGP war dessen Lizenz. PGP-2 erlaubte keine kommerzielle Nutzung ohne vorherige Absprache mit Zimmermann, der in einem solchen Fall für die Software Lizenzgebühren verlangte2.

Diese Restriktionen führten zu dem Wunsch nach einer neuen Software, die bei gleicher Funktionalität, von diesen Restriktionen befreit war. Als 1997 die Patente auf einige asynchrone Verschlüsselungsverfahren ausliefen, begann Werner Koch eine solche Software im Rahmen des GNU-Projekts zu entwickeln. Diese wurde zu GnuPG (GNU Privacy Guard, GPG). Koch selber war als deutscher Staatsbürger in einer Position, in der durch ihn geschaffene Software nicht von Exporteinschräkungen betroffen waren, da in Deutschland Verschlüsselungsverfahren nicht als Waffen gelten. Tatsächlich wurde er später sogar, zum Ärger der US-amerikanischen Regierung, vom deutschen Wirtschaftsministerium unterstützt.

Ist aber nun „GNU Privacy Guard“ ein Fork von „Pretty Good Privacy“ wie es öfter behauptet wird? Zwar kommt die Idee für GnuPG von PGP und auch die Kompatibilität zu PGP wurde gewahrt, aber abgesehen von der Idee wurde nichts übernommen. GnuPG wurde komplett unabhängig von PGPs Quellcode neu implementiert. Im Rahmen dieser Arbeit soll dies daher nicht als Fork gelten.

Definition: Fork (Softwareentwicklung)

Nachdem wir nun zwei grenzwertige Beispiele betrachtet haben, bei denen wir gesehen haben, dass der Begriff Fork in der Regel nicht ganz eindeutig ist, folgt hier nun der Versuch einer möglichst genauen Definition:

Ein Fork in der Softwareentwicklung ist eine, auf der Codebasis eines bestehenden Projektes basierende, von diesem jedoch unabhängige Weiterentwicklung eines Produktes mit der Intention, sich von seinem Ursprung abzugrenzen und ein neues Produkt zu schaffen. Forks verfolgen dabei häufig andere Ziele als ihr Ursprungsprojekt.

Forks sind nicht zu verwechseln mit Branches, die eine Abspaltung vom Hauptentwicklungszweig zu Testzwecken o.ä. darstellen und somit der Weiterentwicklung des Ursprungsprojektes dienen.

Beispiele von Forks

Nachdem nun dargelegt wurde, was ein Fork ist, – hoffentlich ist es zumindest klarer wie zuvor – soll nachfolgend auf einige konkrete Beispiele von Forks eingegangen werden und betrachtet werden, warum es zu einem solchen kam und wie sich die Projekte anschließend weiterentwickelt haben. Auch hierfür wird wieder kurz die Geschichte der einzelnen Projekte vorgestellt, da es ohne diese Grundlage schwierig ist die Auslöser eines Forks zu beschreiben und vor allem, sie zu verstehen.

GNU/Linux-Distributionen

Als erstes Beispiel sollen wiederum einige GNU/Linux-Distributionen dienen. Als ein Fork von SLS wurde bereits Slackware beschrieben. Slackware selber wurde daraufhin aber wiederum die Grundlage für viele weitere Distributionen. Bekannte Beispiele dafür sind openSUSE, mit dem Ziel möglichst anwenderfreundlich zu sein, SLAX, als eine Live-CD oder Zenwalk, mit dem Ziel möglichst klein und schnell zu sein. Tatsächlich bauen fast alle der heute aktiven Distributionen auf die drei “`alten”’ Distributionen Slackware, Debian und Red Hat auf. So ist Debian beispielsweise die Grundlage für Ubuntu und Knoppix, wärend aus Red Hat unter anderem Fedora und Mandrake entstand.

Mittlerweile existieren heute etwa 300 verschiedene Distributionen, die häufig für ganz unterschiedliche Anwendungsszenarien ausgelegt sind. Es existieren Distributionen, die spezialisiert sind auf Server, für den Desktop, für eingebettete Systeme oder für Note- und Netbooks. Es gibt Live-CDs, Distributionen, die möglichst ähnlich zu Windows sein wollen und viele weitere Ausrichtungen. Doch nicht nur die Zielsetzungen der Distributionen sind häufig verschieden. Selbst Distributionen, die in etwa für den gleichen Anwendungszweck gedacht sind, sind nicht selten unterschiedlich aufgebaut und verwenden andere Programme. So dienen sie nicht nur unterschiedlichen Zwecken, sondern entsprechen auch unterschiedlichen Nutzerpräferenzen.

Es ist recht offensichtlich, dass es nahezu unmöglich wäre ein System zu schaffen, welches alle diese Bereiche abdeckt. An diesem Beispiel ist also zu sehen, dass es durchaus Fälle gibt in denen die Aufspaltung in mehrere getrennte Projekte Sinn machen kann.

UNIX

Dennis Ritchie und Ken Thompson arbeiteten seit 1965, im Rahmen ihrer Beschäftigung bei den Bell Laboratories (Bell Labs), einer Tochterfirma von AT&T, an dem Betriebssystem Multics. Multics enthielt einige revolutionäre neuen Ideen, litt aufgrund der vielen Features jedoch unter einer Reihe von Performanceproblemen. Als gegen Ende der 1960er Jahre immer deutlicher wurde, dass Multics auf absehbare Zeit nicht brauchbar sein würde, zogen sich die Bell Laboratories aus diesem Projekt zurück.

Richie und Tompson jedoch begannen daraufhin die Arbeit an einem kleineren und einfacheren System, das dennoch einige der Kernfeatures von Multics bot. So entstand bis 1971 die erste Version von UNIX und im Rahmen dessen unter anderem der erste Compiler für die Programmiersprache C und natürlich auch die Sprache selbst sowie das Textsatzsystem troff, dass in den folgenden Jahren firmenintern im Einsatz war.

Dies hatte die Einsatzfähigkeit von UNIX gezeigt, so dass folgend das Interesse an dem Projekt auch außerhalb der Bell Labs gewaltig anstieg. Problematisch war jedoch, dass es AT&T zu dieser Zeit teilweise unter staatlicher Kontrolle stand und es der Firma unter anderem verboten war den Computermarkt zu betreten.

Aufgrund dieses Verbotes wurden statt dem fertigen Produkt Codelizenzen verkauft. Dadurch wurde UNIX zwar nicht zu einem freien Betriebssystem, aber zu einem System, welches grundlegend erweitert werden konnte und durfte. Dies und die Tatsache, dass Lizenzen für Bildungseinrichtungen sehr günstig waren, führte dazu, dass UNIX an Universitäten sehr beliebt wurde, was das System wiederum noch bekannter machte. Doch auch für Firmen, die ihr eigenes Betriebssystem erstellen wollten, war das Angebot sehr interessant.

So entstanden viele verschiedene kommerzielle Varianten von UNIX. Beispiele für solche sind HP-UX von Hewlett-Packard, AIX von IBM oder IRIX von Silicon Graphics. Dabei versuchten insbesondere die Firmen ihr System als UNIX+ darzustellen. Also UNIX und noch mehr. Dies führte dazu, dass jeder sein eigenes, zu den anderen inkompatibles Betriebssystem baute. Dies schadete dem Image von UNIX sehr, da Interessenten zu der Zeit nicht sicher sein konnten, dass ein System auch wirklich weiterentwickelt werden würde und es nicht klar war wie hoch der Aufwand für die Portierung ihrer Daten und Software auf ein anderes Unixsystem sein würde.

Hier haben wir also ein Beispiel für eine Reihe von Forks die Probleme mit sich brachten und tatsächlich sogar zu einem Schaden des Gesamtsystems führten. Tatsächlich sind so heute auch nur noch wenige dieser Unixsysteme übriggeblieben. Bedeutung haben nur noch AIX, Mac OS X, Solaris und HP-UX die jedoch mittlerweile auch alle dem genormten The Open Group’s UNIX 03-Standard entsprechen.

Eine Besonderheit dieses Forks ist noch der kommerzielle Hintergrund, also dass nicht nur die Forks, sondern auch das Originalprojekt freie Software waren, was sehr selten ist.

Berkeley Software Distribution (BSD)

Nach der Betrachtung von UNIX im Allgemeinen soll nun auf einen speziellen Fall eingehen werden, der durchaus eine gesonderte Betrachtung verdient. Eine der ersten Universitäten, die sich mit UNIX beschäftigte, war die Berkley Universität von Kalifornien. Sie arbeitete stark mit den Bell Labs zusammen und gab ihre eigenen Erweiterungen zurück, so dass viele von ihnen direkt in das originale System einflossen.

Dies führte dazu, dass an der U.C. Berkeley das originale UNIX nach und nach durch eigene, freie Software ersetzt wurde. Diese Änderungen waren aber nicht nur für Berkley und die Bell Labs interessant. So wurde 1977 die erste „Berkeley Software Distribution“ zusammengestellt, die neben einigen Verbesserungen und Fehlerkorrekturen des Orginalsystems auch schon zusätzliche Software, wie beispielsweise ein Pascal-System enthielt. Spätere Releases enthielten weitere neue Features wie dem Editor nvi, sowie für die DARPA entwickelte Netzwerksoftware.

Letztendlich war es dann Keith Bostic der 1989 nach der Veröffentlichung des Networking Release 1 (Net/1) vorschlug das System von den letzten verbleibenden Teilen des AT&T-Codes zu befreien und ein komplett freies Betriebssystem zu veröffentlichen. Die damaligen Leiter der Computer Systems Research Group (CSRG) in Berkeley, Marshall Kirk McKusick und Mike Karels, stimmten zu, jedoch unter der Bedingung, dass Bostic einen Weg fand die verbleibenden Tools des orginalen UNIX und die komplette C-Bibliothek zu ersetzen. Sie nahmen an, dass sich das Projekt damit erledigt hätte. Bosnic begann jedoch auf verschiedenen Tagungen Werbung zu machen und motivierte immer mehr Leute ihm bei der Arbeit zu helfen. So konnte das Projekt tatsächlich verwirklicht werden und im Juni 1991 wurde das Networking Release 2 (Net/2) veröffentlicht. Diesem Release war nahezu ein komplettes System. Es wurden nur sechs Dateien des Kernels entfernt, die noch Teile des originales UNIX enthielten.

So dauerte es nicht lange, bis dann mit 386/BSD eine vollständige Distribution erschien. Über diese Entwicklung war AT&T natürlich nicht erfreut und ging gerichtlich gegen Berkeley, 386/BSD und weitere Redistributoren vor. Dieser Streit ging letztendlich zwar zu Berkeley Gunsten aus, Bill Jolitz, der Entwickler von 386/BSD, wollte jedoch in diesen Streit nicht involviert werden und gab deshalb das Projekt auf.

386/BSD wurde daraufhin von einigen Gruppen geforkt und weiterentwickelt. Es entstanden NetBSD, FreeBSD und später OpenBSD. Trotz mehrmaliger Überlegungen, die Projekte zusammenzuführen, werden sie aufgrund der unterschiedlich Zielsetzungen, Performance, Portabilität und Sicherheit, noch heute getrennt voneinander weiterentwickelt. Dabei findet jedoch ein reger Austausch zwischen den Projekten statt, sie sind größtenteils zueinander kompatibel und es werden Treiber et cetera bei Bedarf auch in die jeweiligen anderen Projekte übernommen.

Hier haben wir also ein mehrmals geforktes System, dessen Forks zunächst einmal das Gesamtprojekt gerettet hatten, denn 386/BSD wurde nicht mehr weiterentwickelt. Weiterhin sind diese Forks auch nach vielen Jahren immer noch erfolgreich. Sie koexistieren „freundschaftlich“ und es findet ein reger Wissens- und Codeaustausch zwischen den einzelnen Projekten statt.

Emacs

Richard M. Stallman veröffentlichte 1985 die erste Version von GNU Emacs. Dies war eine Reimplementierung von verschiedenen bestehenden, teilweise auch von ihm stammenden Emacs-Derivaten. Dieser Editor erfreute sich in den folgenden Jahren zunehmender Beliebtheit. Zwischen 1987 und 1993, die aktuelle Version von GNU Emacs war die Version 18, kam es jedoch zu starken Verzögerungen bei der Entwicklung der nächsten Version. Diese sollte signifikante und lang erwartete Verbesserungen, vor allem in der Interaktion mit dem X Window System bringen.

Daraufhin bot Lucid Inc. an, die Entwicklung von GNU Emacs 19 zu unterstützen. Hintergrund war, dass sie Emacs als Standardeditor in ihrer C+±IDE nutzen wollten. Nachdem diese Zusammenarbeit zunächst sehr vielversprechend begann wollte Stallman aber immer weitere und andere Änderungen an dem Projekt haben und Teile, die die Lucid Inc.-Entwickler bereits erstellt hatten sollten wiederum ausgetauscht werden. Diese standen jedoch unter Zeitdruck, da die Veröffentlichung ihrer IDE bevorstand. Nachdem es dann noch zu weiteren Unstimmigkeiten kam3 brachen sie die Zusammenarbeit ab und veröffentlichten innerhalb von kurzer Zeit eine eigene Emacs-Version unter dem Namen Lucid Emacs. Diese Version enthielt viele der Änderungen, die sich die Nutzer von GNU Emacs gewünscht hatten und da das Erscheinen einer neuen GNU Emacs-Version noch immer nicht absehbar war, wechselten zahlreiche Anwender zu Lucid Emacs.

Lucid Inc. betreute ihr Emacs auch in den Folgejahren weiter und übernahm teilweise auch Änderungen aus GNU Emacs. Dies war rechtlich kein Problem, da beide Projekte GPL-lizensiert sind. Stallman beziehungsweise seine Free Software Foundation (FSF) blieb jedoch stur, wollte auf keinen Fall Code aus Lucid Emacs übernehmen und verweigerte jegliche Zusammenarbeit.

So existieren noch heute beide Projekte. Lucid Emacs mittlerweile unter dem Namen XEmacs. Diese Projekte kooperieren nicht und sind in Teilen auch zueinander inkompatibel. Dieses ist also ein Fall, bei dem ein Fork die Community gespalten hat und zudem zu einer Reihe von zusätzlicher, unnötiger Arbeit geführt hat. Zum einen wurden Features doppelt implementiert, zum anderen aber auch Plugins, aufgrund der partiellen Inkompatibilität beider Programme, häufig in zwei Versionen gepflegt werden.

NCSA httpd

Nun aber wieder zu einem „guten“ Fork: In den 1990er Jahren existierten zwei zu dieser Zeit bedeutende HTTP-Server. Der NCSA4 httpd und der CERN5 httpd. Der NCSA httpd war jedoch überlegen, da er sowohl kleiner, als auch schneller war, wärend der CERN httdp vor allem aufgrund seiner Verknüpfung mit Tim Berners-Lee, dem Erfinder von HTML und dem World Wide Web, bekannt war.

Doch die Weiterentwicklung des NCSA httpd kam 1994 ins Stocken, als der damalige Hauptentwickler, Rob McCool, das NCSA verließ. Nach einem weiteren Release wurde die Entwicklung dann 1996 ganz eingestellt. Eine kleine Gruppe von Web-Entwicklern hatte sich jedoch bereits 1995 zusammengetan, um auf Basis der letzten freien Version des NCSA httpd – die letzte Version ließ nur noch private und die Nutzung in Bildungseinrichtungen zu – den Webserver weiterzuentwickeln. Dieser wurde dann später Apache http genannt und ist mit über 50% Anteil der heute meist genutzte Webserver überhaupt.

Auch dieses ist also ein Beispiel für ein Fork der dazu führte, dass ein Projekt, welches von den bisherigen Entwicklern aufgegeben wurde, gerettet wurde. Dieses war möglich, da zum einen ein großes Interesse an der Software und dessen Weiterentwicklung unter den Nutzern bestand und zum anderen die Lizenz der Software die freie Weiterentwicklung ermöglichte.

GCC

Eine Besonderheit unter den Forks stellt der GCC (GNU C Compiler bzw. später GNU Compiler Collection) dar. Er wurde von Richard M. Stallman 1985 im Rahmen des GNU Projektes geschaffen und weiterentwickelt. Er war als freier C-Compiler, der Unterstützung für viele verschiedene Plattformen bot, sehr beliebt. Doch auch bei diesem Projekt Stallmans geriet die Entwicklung ins Stocken. Dieses galt insbesondere im Hinblick auf die Unterstützung von neueren und immer beliebter werdenden Pentium-Prozessoren von Intel. So war 1997 beispielsweise die beste intelspezifische Optimierung des gcc 2.7 die für Intel 486er-Chips. Auch hier wurden wieder die vielen Anfragen zum Thema Pentiumoptimierung von Stallman und der Free Software Foundation stur ignoriert. Das führte dazu, dass der GCC zu dieser Zeit mehrfach geforkt wurde.

Der erste bedeutende Fork des GCC war der PGCC (Pentium GCC). Er war ein von Intel stark unterstützter Compiler, der die große Portabilität des ursprünglichen GCC aufgab und sich nur auf die Optimierung für Pentiumprozessoren spezialisierte. Das führte dazu, dass er für diese Systeme sehr schnellen Code produzierte. Jedoch hatten die Entwickler die komplette Struktur des Compilers umgestellt, was sowohl eine Rückführung von PGCC Code in den GCC als auch die Aufnahme von neuen GCC-Features in den PGCC sehr schwierig machte. Dennoch war der PGCC damals einer der beliebtesten C-Compiler für Pentium-Maschinen.

Ein zweiter Fork des GCC war der EGCS (Experimental/Enhanced GNU Compiler System). Dieses Projekt versuchte nicht nur die Struktur und die Portabilität des originalen GCC beizubehalten, sondern diese sogar noch weiter auszubauen und noch weitere Features zu ergänzen. Eines dieser neuen Features, auf welches viel Wert gelegt wurde, war die viel geforderte Pentiumunterstützung.

Obwohl hier eine Coderückführung wesentlich einfacher gewesen wäre, denn die Struktur des ECGS wich kaum von der des GCC ab, ignorierte die FSF auch das dieses Projekt. Doch aufgrund der stetigen Weiterentwicklungen und Verbesserungen und daraus folgend der starken Überlegenheit im Vergleich zum originalen GCC, wechselten nach und nach viele GNU/Linux-Distributionen zum EGCS. Der GCC geriet mehr und mehr in Vergessenheit.

Wie anfänglich erwähnt, ist dieser Fork jedoch etwas besonderes, denn tatsächlich bot 1999 die FSF den EGCS-Entwicklern an, die Projektleitung des GCC zu übernehmen und beide Projekte wieder zusammenzuführen. So wurde der ECGS dann zum „neuen“ GCC. Dies ist also einer der seltenen Fälle bei dem ein Fork und dessen Originalprojekt wieder eins werden und dieses unter Leitung des Forks.

GNU C Library

Noch eine Software, die im Rahmen des GNU Projektes geschaffen wurde war die C-Standardbibliothek glibc (GNU C Library). Auch Linus Torvalds benötigte für sein Linux-Projekt eine C-Bibliothek. Ihm fehlten in der damaligen GNU C Library jedoch einige Funktionen. So entschied er die glibc als „Linux libc“ zu forken und als separates Projekt für den Linux-Kernel weiterzuführen.

Obwohl die Linux libc immer weiterentwickelt wurde, mussten die Linuxentwickler um 1998 feststellen, dass die glibc wesentlich sauberer implementiert war und zudem mittlerweile über eine bessere Funktionalität verfügte. So wechselten auch immer mehr GNU/Linux-Distributionen wieder zur GNU C Library. Das führte dazu, dass im Linux-Projekt entschieden wurde, dass ihr Fork, auch wenn er damals richtig erschien, ein Fehler gewesen war. Es wurde die Entwicklung der Linux libc aufgegeben und vollständig die C-Bibliothek der FSF verwendet.

Dieses ist also ein Beispiel für ein Fork, der auf lange Sicht nicht erfolgreich war und der, obwohl er zunächst von einem großen Open-Source-Projekt unterstützt wurde, aufgegeben wurde.

XFree86 und X.Org

In den 1990er und Anfang der 2000er Jahre enthielt fast jede GNU/Linux- und BSD-Distribution die freie Implementierung des X-Window-Systems XFree86. Doch in etwa ab 2002 kam es zu Unstimmigkeiten innerhalb des Projektes. Dies resultierte vor allem aus der sehr stickten Vergabe von Commitrechten und dem Rauswurf eines Kernentwicklers. Folgende weitere interne Streitereien führten dann 2003 letztendlich dazu, dass sich das Kernentwicklerteam auflößte und einige Forks entstanden, wie beispielsweise Xouvert und der X.Org-Server.

Dennoch wurde die Entwicklung von XFree86 fortgeführt und es wurde noch immer in nahezu allen Distributionen eingesetzt. Dies änderte sich jedoch im Februar 2004, als der Projektleiter entschied, die neue Version unter einer modifizierten Lizenz zu veröffentlichen. Diese Lizenz wurde von FSF als inkompatibel zur GPL angesehen und der Einsatz zusammen mit GPL-Software war dementsprechend rechtlich bedenklich.

Dies führte dazu, dass die neue Version von den Betriebssystemdistributoren nicht eingesetzt wurde und diese nach und nach zu den Forks wechselten. Der erfolgreichste unter ihnen, welcher heute zur de facto Standardimplementierung geworden ist, ist der X.Org-Server.

Dies ist also ein Beispiel für ein Projekt, dass geforkt wurde, da in der Projektleitung einige äußerst unpopuläre Entscheidungen getroffen wurden, mit denen viele Entwickler und Nutzer unzufrieden waren und das letztendlich gestorben ist wärend einer seiner Forks seinen Platz einnahm.

SSH

1995 entwickelte Tatu Ylönen die erste Version von Secure Shell (SSH) einem Projekt, welches es ermöglichte eine sichere, verschlüsselte Verbindung zu anderen Rechner über ein unsicheres Netzwerk, beispielsweise dem Internet, aufzubauen. Dieses war ein großer Vorteil gegenüber den bisherigen, größtenteils unverschlüsselten Protokollen, wie rsh, rlogin oder TELNET. So stieg die Popularität dieses Projektes stetig an.

Die ersten Versionen der Software bauten dabei auf andere, freie Software auf und war dementsprechend auch frei zugänglich. Tatu Ylönen gründete jedoch bereits im Dezember 1995 die Firma SSH Communications Security und begann daraufhin die freien Softwareteile nach und nach zu entfernen um das Projekt letztendlich völlig zu einer proprietären Software zu machen.

Als dies geschah hatte SSH bereits etwa 2.000.000 Nutzer und der Wunsch nach einer freien Version war dementsprechend groß. Daraufhin entschied das OpenBSD-Projekt die letzte freie Version von SSH zu forken und im Rahmen ihres Projektes, welches ohnehin Sicherheit als besondere Zielsetzung hat, als OpenSSH weiterzuführen.

Dieser Fork war sehr erfolgreich und schon bald wechselte nicht nur OpenBSD zu ihrer Implementation, sondern auch nahezu alle anderen freien Betriebssysteme.

OpenOffice.org & LibreOffice

Nachdem wir nun viele vergangene Forks betrachtet haben soll abschließend noch der Blick auf die Gegenwart gelenkt werden: OpenOffice.org wurde 1999 als freie StarOffice-Version von Sun Microsystems veröffentlicht. Ziel war es eine starke Konkurrenz zu Microsoft Office zu schaffen. OpenOffice.org wurde daraufhin sehr beliebt, in sehr viele GNU/Linux-Distributionen integriert und selbst unter Microsoft Windows sehr gut angenommen.

Im Jahre 2010 wurde Sun und die Projektleitung von OpenOffice.org, sowie weitere Projekten6, jedoch durch Oracle übernommen. Nachdem Oracle daraufhin die Unterstützung von OpenSolaris als großes Open-Source-Projekt aufgab und auch die Unterstützung für OpenOffice.org zunächst immer spärlicher ausfiel, wobei Oracle die Zukunft des Projektes sogar völlig offenließ, schlossen sich einige der Hauptentwickler zusammen und gründeten „The Document Foundation“ (TDF). Diese Institution sollte die firmenunabhängige Weiterentwicklung von OpenOffice.org sicherstellen.

Auch Oracle wurde eingeladen sich dieser Initiative anzuschließen und es wurde gehofft, dass sie auch die Namensrechte von OpenOffice.org an die TDF übertragen würden. Oracle lehnte jedoch nicht nur ab, sie forderten sogar alle in Beziehung zur TDF stehenden Entwickler auf, das OpenOffice-Projekt umgehend zu verlassen, da sie mit diesem in einem Interessenkonflikt ständen.

So verließen seit Oktober 2010 bereits über 100 Entwickler das Projekt und schlossen sich der The Document Foundation an, die nun das Officepaket selbständig unter dem Namen LibreOffice weiterentwickelt und publiziert. Mittlerweile sind bereits mehrere populäre GNU/Linux-Distributionen wie beispielsweise Ubuntu, OpenSUSE und RedHat auf LibreOffice umgestiegen beziehungsweise haben angekündigt dieses zu tun.

Da dieser Fork sehr neu ist, wird sich erst im Laufe der nächsten Jahre zeigen, wie sich die Dinge entwickeln. Ein Fazit zu ziehen ist momentan daher kaum möglich.

Freie Lizenzen und Forks

Wie wir bei UNIX gesehen haben muss einem Fork nicht immer eine freie Lizenz zu Grunde liegen. Dennoch ist dies fast immer der Fall. Betrachtet man nun einmal diese freien Lizenzen, so lassen sie sich leicht in zwei für Forks bedeutende Klassen einteilen: Lizenzen mit und ohne Copyleft.

Copyleft-Lizenzen

Copyleft-Lizenzen sind Lizenzen, die fordern, dass Forks nur unter der gleichen7? Lizenz verbreitet werden dürfen wie das Projekt aus dem sie stammen.

Der Vorteil von Copyleft-Lizenzen ist, dass ein freies Projekt, welches unter einer solchen Lizenz steht, zwar geforkt werden kann, man dafür aber sicher sein kann, das das Hauptprojekt durch den Fork Unterstützung erfährt, da der Quellcode des Forks mit diesem ebenfalls frei veröffentlicht werden muss und so eine Coderückführung problemlos möglich ist.

Bekannte Beispiele für solche Lizenzen sind vor allem die „GNU General Public License“ und die „GNU Lesser General Public License“ aber auch die „Creative Commons Share-alike (sa)“-Lizenzen.

Nicht-Copyleft-Lizenzen

Nicht Copyleft-Lizenzen bieten dem Nutzer mehr Freiheit als Lizenzen mit Copyleft. Die Zurückführung des Codes aus Forks ist dabei jedoch nicht sichergestellt, so dass ein Projekt geforkt werden kann ohne das es dann von dem Fork profitiert. Viele Projekte, auch im Rahmen von Firmen, geben geänderten Code aber dennoch zurück um eine Verbesserung des Gesamtsystems zu erreichen.

Ein besonderer Vorteil von solchen Lizenzen ist, dass Firmen eher geneigt sind so lizenzierte Projekte zu nutzen, da sie sich damit nicht von vorneherein auf eine Lizenz festlegen müssen.

Auch bringt eine solche Lizenz weniger Probleme bei der Integration in andere Projekte mit sich. So können beispielsweise nicht gleichzeitig zwei Komponenten mit unterschiedlichen Copyleft-Lizenzen innerhalb eines Projektes genutzt werden, da jede Lizenz fordern würde, dass das neue Produkt unter derselben lizenziert würde. Dies ist bei Komponenten mit Nicht-Copyleft-Lizenzen kein Problem.

Bekannte Nicht-Copyleft-Lizenzen sind beispielsweise die verschiedenen Versionen der BSD-Lizenz und die MIT-Lizenz.

Fazit

Nachdem nun verschiedene Beispiele für Forks betrachtet wurden, soll nun abschließend och einmal versucht werden ein Resümee zu ziehen, die unterschiedlichen Arten von betrachteten Forks zu bewerten und diese zusammenzufassen.

Ergebnisse von Forks

Wir haben gesehen, dass die Gründe für Forks völlig verschieden sein können und ebenso der Erfolg oder Misserfolg sowohl des Forks, als auch des Originalprojektes.

Ein mögliches Ergebnis ist, dass der Fork keinen Erfolg hat und stirbt. In der Tat geschieht dies wohl bei den meisten Forks, doch in der Regel ist der Fork dann von Beginn an unbedeutend, unbekannt und wird wenig unterstützt. Ein bekanntes und zunächst stark unterstütztes Beispiel wurde jedoch mit der Linux libc angeführt, welche später zugunsten des Originalprojektes wieder aufgegeben wurde.

Es kommt auch vor, dass beide Projekte getrennt voneinander weiterentwickelt werden. Dieses ist vor allem dann der Fall, wenn Originalporjekt und Fork ein anderes Ziel verfolgen, wie es häufig bei den GNU/Linux-Distributionen der Fall ist. Doch auch GNU Emacs und XEmacs sind ein solches Beispiel, obwohl sie das gleiche Ziel verfolgen. Ebenso momentan noch OpenOffice.org und LibreOffice.

Ein dritter möglicher Ausgang der durch ein Beispiel dargestellt wurde war das Sterben des Originalprojektes, wie bei dem NCSA httpd, der zum Apache httpd wurde, oder bei XFree86, aus dem der X.Org-Server entstand.

Wesentlich seltener und tatsächlich eher ungewöhnlich ist es schließlich, dass Fork und Originalprojekt wieder eins werden, wie es bei der GCC der Fall war, der als ECGS geforkt und weiterentwickelt wurde und bei dem später dann beide Projekte wieder zusammengeführt wurden.

Natürlich sind dieses nicht alle möglichen Ausgänge eines Forks. So kann es sicherlich geschehen, dass sowohl das Originalprojekt, als auch dessen Fork stirbt, oder dass beide folgend durch ein anderes Projekt übernommen werden und so weiter. Doch zumindest sind dieses die Ausgänge, die bei den meisten beachtenswerten Forks vorkommen.

Sind Forks nun gut oder schlecht?

Wie so häufig wurde auch in dieser Ausarbeitung zu Beginn die Frage aufgeworfen ob Forks gut oder schlecht sind. Nicht selten ließt man als Antwort auf eine solche Frage, dass sie in aller Regel schlecht sind, weil sei meist mit einem Streit in der Community einhergehen.

Ich denke, dass dieses nicht grundsätzlich der Fall ist haben die Beispiele gezeigt, denn es war unbestreitbar gut, dass der NCSA httpd geforkt werden konnte und somit „gerettet“ wurde, wie das Ergebnis, der Apache httpd, zeigt. Auch schaffen Forks Projektvielfalt, so dass Nutzer heute zum Beispiel aus einer ganzen Reihe verschiedener GNU/Linux-Distributionen wählen können. Und letztendlich kann manchmal dadurch, dass ein Projekt einfach in zwei Richtungen vorangetrieben wird das beste Konzept für einen bestimmten Projekttyp ermittelt werden.

Andererseits gilt aber auch die Umkehrung offensichtlich nicht, denn mit Sicherheit wäre es besser gewesen, wenn die Entwickler von GNU Emacs und Lucid Emacs beziehungsweise XEmacs miteinander ausgekommen wären und das Projekt gemeinsam vorangetrieben hätten, anstatt einen Großteil des Codes doppelt zu entwickeln. Auch das häufig anzutreffende Argument des Streites in der Community ist nicht ganz von der Hand zu weisen.

Nun war dieses bisher keine eindeutige Antwort auf die gestellte Frage, doch ich bin mir sicher: Es gibt keine eindeutige Antwort. Die bisher beste Antwort, die ich für mich gefunden habe ist die folgende:

Ob ein Fork gut oder schlecht ist, dass kann man nur im Einzelfall entscheiden und zeigt sich oft auch erst später. Die Möglichkeit zu forken ist aber eine gute Sache, denn diese führt dazu, dass die Weiterentwicklung eines Projektes in den meisten relevanten Fällen gesichert ist. Denn im Notfall darf das Projekt unabhängig von bisheriger Leitung fortgeführt werden. Dieses ist natürlich auch den Projektleitern bekannt, was diese dazu zwingt eher auf die Bedürfnisse der Nutzer zu reagieren.

Quellen

Wikipedia, die freien Enzyklopädie In der Wikipedia sind viele Forks bemerkt und es sind weitere Details zu vielen der vorgestellten Projekte gegeben. http://wikipedia.org/

Fear of Forking essay Rick Moen beschreibt in seinem, mit „Why Linux won’t fork and why being able to fork is still a good thing.“ untertitelten Essay ebenfalls einige Beispiele für Forks. Weiterhin geht er aber insbesondere noch auf die GPL-Lizensierung des Linux-Kernels ein und warum es unwahrscheinlich ist, dass dieser geforkt wird. http://linuxmafia.com/faq/Licensing_and_Law/forking.html

Open Sources: Voices from the Open Source Revolution In „Twenty Years of Berkeley Unix“ beschreibt Marshall Kirk McKusick die Entwicklung von BSD beginnend bei der ersten Version von UNIX, die in Berkeley im Einsatz war bis zu den großen Open-Source-Projekten

FreeBSD, OpenBSD und NetBSD. ISBN-13: 978–1565925823 http://oreilly.com/catalog/opensources/book/toc.html

Unix History Timeline Éric Lévénez hat ein riesiges Poster mit nahezu allen wichtigen Releases der Unixgeschichte erstellt. http://www.levenez.com/unix/

Fußnoten

[1] Die Klage wurde 1996 fallengelassen.

[2] Aus „pgpdoc2.txt“: „Finally, if you want to turn PGP into a commercial product and make money selling it, then we must agree on a way for me to also make money on it.“

[3] Es ist noch immer unklar, wer die Ursache dieser Unstimmigkeiten war, da sich beide Parteien gegenseitig die Schuld zuweisen

[4] National Center for Supercomputing Applications an der University von Illinois

[5] European Organization for Nuclear Research

[6] Weitere durch Oracle übernommene Projekte sind beispielsweise OpenSolaris, VirtualBox und Java

[7] Manche Lizenzen lassen auch eine gewisse Menge von Lizenzen zu, unter welchen ein Fork veröffentlicht werden darf, diese sind dann aber im Sinne des Copyleft meist noch restriktiver.