Mit der Veröffentlichung von MySQL 4.0 hat MySQL verhältnismässig still und leise die Lizenz der Client Library von der LGPL auf die GPL umgestellt. Was an sich nicht spektakulär klingt, hat für ordentlich Wirbel gesorgt, als die ersten Betaversionen von PHP 5 auf einmal ohne MySQL-Extension ausgeliefert wurden. Von einem Tag auf den anderen geisterte ein Schreckgespenst durch das WWW, und unzählige Entwickler fragten sich, ob sie bald all ihre Webapplikationen mit MySQL-Back-end auf eine andere Datenbank portieren oder Lizenzgebühren an MySQL entrichten müssten.
Um das ganze Problem beleuchten zu können, muss man ein bis zwei Jahre zurückgehen. Damals war, wie der Grossvater sagen würde, vieles besser. Der MySQL-Datenbank-Server, veröffentlicht unter der GPL, konnte noch nichts, und die passende Client Library stand unter der LGPL und durfte ohne grosse Bedenken jeder Open-Source-Software beigelegt werden. Frei und kostenlos war das Motto. Das nötige Kapital zur Bezahlung der Entwicklung beschafften sich die Schweden durch kommerziellen Support, Schulungen und Lizenzverkäufe an Kunden. Wenn man sich nun fragt, was es denn da zu kaufen gäbe, wenn die Software unter der GPL respektive LGPL veröffentlicht ist, heisst das Zauberwort, damals wie heute, Dual Licensing.
Jeder Verfasser eines Objekts, das unter das Urheberrecht fällt, darf es so lizenzieren, wie er will. Er bleibt auch nicht auf eine einzelne Lizenz beschränkt, so kann man beispielsweise eine Software-Bibliothek unter der GPL veröffentlichen. Wem die GPL nicht gefällt, kann dafür eine Lizenz verkaufen, die ihn von der GPL befreit. Eigentlich noch immer ein einfaches Prinzip, denn für die Autoren von GPL-Software ist somit alles klar, sie können die GPL-Version der MySQL Client Library verwenden. Und Entwickler kommerzieller Software kaufen eine Lizenz. Doch gibt es eine nicht unerhebliche Anzahl an Software, die in keine der beiden Schubladen passt. Es handelt sich dabei um Programme, die unter einer der Nicht-GPL-Lizenzen veröffentlicht wurden, beispielsweise der Apache-Lizenz (vgl. InfoWeek 06/2004), aber trotzdem der Open-Source-Definition entsprechen. Da die GPL nur mit sich selber kompatibel ist und eine Verwendung von GPL-Code in nicht GPL-kompatibler Software nicht gestattet, beginnt hier ein grosses Problem: Open-Source-Software wie PHP darf nicht mit der MySQL Client Library ausgeliefert werden.
Die Frage, warum MySQL jetzt den Lizenz-Wechsel vollzogen hat, lässt sich relativ einfach beantworten: Die Schweden möchten mehr Lizenzen verkaufen. Das kann man ihnen nicht verübeln, muss man doch von etwas leben. Doch ist dies relativ schwierig, kann man schliesslich einen MySQL-Server, da GPL, irgendwo hinstellen und damit sein Geschäft machen, ohne eine Lizenz kaufen zu müssen. Auch das Geschäft mit dem Support dürfte harzen, da die meisten Administratoren wohl noch nie einen Crash von MySQL erlebt haben oder, sollte doch einmal etwas kaputtgehen, die Community weiterhelfen kann – MySQL ist einfach zu gut.
Auch beim Client, da LGPL, war für MySQL wenig Geld zu holen. Die LGPL ist eine GPL ohne Zähne und darf in praktisch jeder, auch kommerziellen Software verwendet werden, egal unter welcher Lizenz sie steht. Firmen konnten somit MySQL einsetzen, ohne etwas bezahlen zu müssen. Dies mag lange Zeit gutgegangen sein, doch hat MySQL Venture-Kapital aufgenommen und viele Entwickler eingestellt, um das Produkt vorantreiben zu können. Jetzt muss vermehrt Geld in die Kasse kommen, der Switch zur GPL für die Client Library lag somit nahe: Firmen müssen so nämlich für ihre darauf aufbauende kommerzielle Software eine Lizenz erwerben.
Doch haben die Schweden die Rechnung ohne den Wirt gemacht und die grosse Gruppe von Open-Source-Lizenzen, die nicht kompatibel zur GPL sind, unter den Tisch fallen lassen. Dies hat auch dazu geführt, dass die ersten Betas von PHP 5 ohne MySQL Client Library ausgeliefert wurden. Um dieses Problem zu beheben, hat man bei MySQL etwa ein Jahr gebraucht, obwohl man eine derartige Lösung bereits am letztjährigen Linux-Tag ausgetüftelt hatte. So ist Mitte März die FOSS License Exception herausgekommen. In ihr listet MySQL die Open-Source-Lizenzen auf, welche zu einer Befreiung der GPL und somit zur Auslieferung der MySQL Client Library mit einer Nicht-GPL-kompatiblen Software berechtigt. Soweit so gut, und das Thema ist auch für PHP vom Tisch, was Andi Gutmans, Vizepräsident von Zend, der Firma hinter PHP, begrüsst. Doch warum man die Lizenzen explizit auflistet, statt zu sagen, dass eine Lizenz der Open-Source-Definition entsprechen muss, um von der GPL befreit zu werden, weiss wohl auch nur MySQL selber. Doch gibt es noch weiteres Ungemach mit der neuen Lizenzierungspolitik von MySQL, die sich um die Auslegung der GPL in bezug mit dem Server dreht. So ist man, mit Absegnung der Free Software Foundation, der Meinung, dass Software, welche eine MySQL-Technologie, beispielsweise durch Reverse Engineering, reimplementiert, auch zu MySQLs geistigem Eigentum gehört und somit auch unter MySQLs Lizenzbedingungen fällt – eine Argumentation, die man schon von SCO her kennt. Zwar möchte man auch hier eine Lösung für Open-Source-Software finden, doch wann, steht auf einem anderen Blatt.
Die Konsequenzen, welche die MySQL-Geschäftspolitik für die Verbreitung und die Nutzer der Datenbanklösungen hat, lassen sich bisher nur schwer abschätzen. Auch wenn bisher einzig RedHat nicht mehr den MySQL-Datenbankserver mit ihrer Distribution ausliefern will, beginnt der Rückhalt für MySQL langsam zu bröckeln. So scheint bei PHP die Trennung auf Zeit endgültig zur Scheidung in Freundschaft zu führen. Auch wenn die Lizenzprobleme ausgeräumt wurden, ist man mittlerweile in der Entwicklergemeinde zur Überzeugung gelangt, dass die MySQL-Client-Bibliotheken auch weiterhin nicht mehr mit PHP 5 ausgeliefert werden, aber nun aus technischen Überlegungen heraus. Somit würde der MySQL-Support zu einer klassischen Extension wie die API für Oracle oder PostgreSQL degradiert werden, bei denen sich jeder selber um die Libraries kümmern muss. Für die Anwender dürfte sich vorerst wenig bis gar nichts ändern, je nachdem, ob sich die Entwickler der jeweiligen Software mit MySQLs neuen Ideen arrangieren können. Anders dürfte dies für die GPL aussehen. Die Lizenz, die bisher als Garant für freie Software stand und für den Wunschlos-glücklich-Faktor sorgte, kann durch ihre Inkompatibilität zu anderen Lizenzen je länger je mehr zum Hemmschuh werden, wenn sie für Bibliotheken verwendet wird. Ein zweiter prominenter Fall, neben MySQL, ist Trolltechs Qt-Framework, das beim Desktop KDE verwendet wird. Die Gründe für die Veröffentlichung unter der GPL und die Auswirkungen für die Community sind fast identisch. Dass dies keine wünschenswerte Entwicklung ist und Firmen, wenn sie bei Freigabe ihrer Produkte auf die GPL setzen, der Community einen Bärendienst erweisen, scheint sogar die Free Software Foundation zu erkennen, ist man doch im MySQL-Fall erstaunlich ruhig geblieben und kann bei den Desktops sogar zum Gnome-Lager gezählt werden, dessen Grundlage die LGPL darstellt. Dies, obwohl der flächendeckende Einsatz der GPL ein Hauptziel der FSF ist und dabei die LGPL nur einen Notnagel darstellt. Ob die Beispiele Schule machen und sich als praktikables Geschäftsmodell für Open-Source-Firmen bewähren, ist ungewiss. Sollte dem aber so sein, ist zu hoffen, dass die FSF über die Gestaltung der GPL wieder einmal nachdenkt.
MySQLs Interpretation der GPL zeigt, dass der Wirkungsbereich der GPL alles andere als klar definiert ist. Etwas, das vor allem beim viralen Aspekt der GPL sauer aufstösst.
Der Grundsatz der GPL besagt, dass ein Programm, das von einer GPL-Software abgeleitet wurde, ebenfalls unter der GPL stehen muss. Umstritten ist dabei das Wort «abgeleitet», zu dessen Bedeutung es zwei grundsätzlich unterschiedliche Auffassungen gibt.
Die erste Interpretation besagt, dass «abgeleitet» im Sinne von «verwendet» verstanden werden muss. Wer beispielsweise seine Software gegen eine GPL-Blibliothek linkt, um über eine API auf eine Datenressource Zugriff zu haben, muss seine Software unter der GPL freigeben.
Die zweite Auslegung, der die Free Software Foundation, MySQL und auch SCO folgen, versteht «abgeleitet» im Sinne von «sieht aus wie» oder «hat Kontakt mit». Dies sieht dann in der Praxis so aus, dass ein Programmierer ohne einen Blick auf die Sourcen der MySQL-Produkte zu werfen, mit Hilfe von Reverse Engineering eine MySQL-Client-Bibliothek schreiben kann, sie aber nicht unter der Lizenz veröffentlichen darf, die er mag. Dies weil er unter die Lizenzwünsche von MySQL fällt, da ein Produkt geschrieben hat, das wie die originale MySQL Client Library aussieht (d.h. das Gleiche tut) und dazu noch über TCP/IP Kontakt mit dem MySQL-Datenbank-Server hat. Solange bei diesem Aspekt ein Interpretationsspielraum besteht, kann und wird es vermutlich weitere Streitigkeiten über die Auslegung geben, vor allem im Zusammenspiel mit Nicht-GPL-kompatiblen Lizenzen, die aber der Open-Source-Definition entsprechen.
