@Egon: Ich habe den folgenden Text schon geschrieben gehabt bevor du gepostet hast, darum lasse ich das jetzt erstmal so stehen. In einigen Punkten sind wir deckungsgleich.
Eben genau wegen der
GPL-Falle frag ich ja. Ich hab schon Stunden damit verbracht, die zahl- und endlosen
MySQL-
GPL-Diskussionen im Netz zu lesen. Es dreht sich ja immer wieder darum, ob man gegen ein
GPL-Binary (Windows-
DLL, Linux-SO) linkt und sich damit die "
GPL-Infektion" einfängt.
Für mich ist das eine ziemliche Spitzfindigkeit. Denn der Vorgang des Linkens ist in der
GPL nicht eindeutig definiert. Ich finde, ob das nun direkt über den Speicher des ausführenden Rechners geschieht oder mit einem Netzwerkprotokoll als Zwischenschicht, spielt im Sinne der
GPL eigentich keine Rolle. Theoretisch könnte man jede Form von Einbindung
GPL-lizensierter Software als Linken betrachten. Spinnt man den Gedanken mal weiter, dann hat man ganz schnell eine "
GPL-Epidemie":
Da ist irgendwo ein
GPL-
Mysql-Server. Der versorgt eine Webanwendung mit Daten. Damit wäre die Webanwendung schon mal infiziert. Die Webanwendung produziert Daten in
HTML-Form und reicht sie an den Browser weiter. Schon ist der Browser auch infiziert. Der Browser (nehmen wir mal den Internet Explorer an) verarbeitet die
HTML-Daten und linkt gleichzeitig gegen die kernel32.dll. Auf einmal sitzt Microsoft aber ganz schon in der Bredouille und (ausnahmslos) sämtliche für Windows verfügbare Software fiele auf einmal unter die
GPL.
Da dem nicht so ist, kann das Linken als solches nicht zur
GPL-Infektion führen, logischerweise. Ich denke, Oracle würde sich auch vor jedem Gericht der Welt lächerlich machen. versuchten sie das durchzusetzen. Desweiteren würde das bedeuten, dass auch solche Komponenten wie Devarts UniDAC unter die
GPL fielen, auch wenn sie die
GPL-lizensierte libmysql nicht linken sondern den
MySQL-Server direkt ansprechen. Wobei, wer von uns könnte schon zweifelsfrei sagen, dass UniDAC nicht doch irgendwo "derived work" im Sinne der
GPL enthält?
Ein Netzwerkprotokoll als Zwischenschicht zieht also sozusagen eine Grenzbarriere unter die Infektiösität der
GPL. Insofern spräche vieles für die Annahme der "Proxy-Theorie": Ein
GPL-lizensierter Proxy linkt gegen
GPL-lizensiertes
MySQL und reicht seinerseits die Daten über ein Netzwerkprotokoll weiter. Wobei wir das Thema Performance da erstmal ausklammern. Sowas gibts ja, siehe
hier. Unter dem genannten Link findet sich auch eine kleine Abhandlung zum Thema
GPL.
An sich steht ja schon zwischen dem
MySQL-Server und der Client-Bibliothek ein Netzwerkprotokoll. Also wäre bereits hier ein
GPL-Bruch zu sehen. Allerdings nur, wenn die Client-Bibliothek an sich nicht unter die
GPL fiele, was ja bei der normalen libmysql der Fall ist. Bestrebungen, "freiere" Clients zu entwickeln gab es ja, siehe
hier und
hier.
Duallizensierung von "derived work" scheint also ein weiteres Schlüsselelement zu sein. Angenommen, meine Hostanwendung linkt gegen die normale libmysql und ist seinerseits sowohl unter der
GPL als auch unter der
LGPL oder der
MPL lizensiert. Desweiteren angenommen, ich lagere wesentliche Programmfunktionen in DLLs aus, welche ich ausschließlich unter die
LGPL oder
MPL stelle. Das wäre *meine* Entscheidung als Entwickler.
Soweit die Diskussion über "derived work" und
GPL. Es gibt aber noch einen weiteren Aspekt der
GPL: "Distribution". Wenn man eine Anwendung entwickelt, die auf
MySQL als Datenbank setzt, dann hat man mit Blick auf den Vertrieb zwei Möglichkeiten: Entweder man packt nur sein eigenes Programm in den Installer und weist die Nutzer an, sich
MySQL selbst zu besorgen oder aber man packt
MySQL (oder auch nur die libmysql) mit in den Installer. Das scheint nämlich auch noch einen Unterschied zu machen. Um wieder auf das Beispiel mit der Webanwendung zurück zu kommen: Die liefert ja
MySQL und "derived work" nicht mit aus sondern überlässt es dem Anwender, die Verbindung zwischen beiden herzustellen. Diesen Weg geht z.B. bis heute das Programm "CAO Faktura" (übrigens auch in Delphi geschrieben). Wobei ich das für Anwender-unfreundlich halte (nicht CAO Faktura sondern den Ansatz, den Anwender einen
MySQL-Server aufsetzen lassen zu müssen).
Machen wir uns nichts vor, die
GPL ist ein ziemlich heißes Eisen. Die ist dehnbar wie ein Gummituch und es gibt bisher kaum relevante Rechtsprechung zu dem Thema. Das einzige was mir einfällt ist ein Urteil gegen die ehemalige Firma Linksys bzgl. des WLAN-Router-Betriebssystems. Wobei das ein extremer Fall war und
GPL-Software direkt als Closed Source vertrieben wurde. Doch darum geht es ja bei
MySQL gar nicht. Zumal von der
GPL nirgends eine rechtsverbindliche deutsche Übersetzung existiert und somit die Streiterei vor einem deutschen Gericht von vornherein für beide Seiten wohl auf wackeligen Beinen stehen dürfte.
Nach reiflicher Überlegung bin ich zu der Erkenntnis gekommen, dass die
GPL MySQL gerade für kleinere kommerzielle Datenbankanwendungen disqualifiziert. Schließlich kann man die libmysql nicht separat bei Oracle lizensieren sondern nur den ganzen Server. Bei Preisen im vierstelligen Bereich ein absolutes No-Go für kleinere Projekte. Schließlich wird die kommerzielle Lizenz nicht an den Entwickler sondern an das Produkt gebunden. Habe ich mehrere kleine Projekte am Start, müsste ich für jedes einzelne eine kommerzielle Lizenz erwerben.
Eine Alternative wäre die kompatible MariaDB,
wobei diese wie oben erwähnt, noch keinen funktionierenden Windows-Client hat. Drizzle hat sich meiner Meinung nach in eine ganz andere Richtung entwickelt und kann eigentlich nicht mehr als kompatibel zu
MySQL bezeichnet werden.
Andere Alternativen wie Firebird, SQLite oder PostgreSQL sind ebenso denkbar, machen aber nur Sinn wenn die eigene Datenbank völlig für sich alleine steht und nicht mit vorhandenen,
MySQL-basierten Anwendungen wie z.B. Webapplikationen a la Joomla korrespondiert.