ZEOS 7.0 ohne libmysql?

[Codehunter]

Moin!

Irgendwo hab ich was aufgeschnappt, dass das neue ZEOS 7.0 angeblich auch einen nativen MySQL-Modus beherrschen soll, also dass im Klartext keine libmysql.dll mehr notwendig sein soll. Nachdem es schon ein ziemlicher "Spaß" war, die 7.0er Beta überhaupt zu installieren, kann ich dazu jedoch nichts finden. War das nur ein Hoax oder weiß hier jemand was dazu?

Grüße
Cody

[EgonHugeist]

Hi Cody,

klare Antwort: Nein das funzt nicht. Keine Ahnung wo du das aufgeschnappt hast aber das ist definitiv im Ansatz falsch. Du könntest natürlich eine vergleichbare Library (existiert do wos, wos i net wos?) hernehmen und das Laden der Schnittstellen über TZConnection.LibraryLocation := 'C:\beispiel.dll' erzwingen. Sollte dies äquivalente Schnittstellen bieten funktioniert das sicherlich.

Gruß Michael

[Bernhard Geyer]

Zitat von EgonHugeist:

klare Antwort: Nein das funzt nicht. Keine Ahnung wo du das aufgeschnappt hast ...

Ich glaube dieses Gerücht gibt es schon seit 10 Jahren.

Man sollte bedenken wenn man die libmysql.dll einsetzt das man bei MySQL in der GPL-Falle sitzt.

[EgonHugeist]

Wußte nicht, daß ein solches Gerücht existiert, ist aber immer wieder interessant, wie hartnäckig ein solches im Raum stehen bleibt, oder?

Mit der GPL hast du recht. Kannst jedoch ohne Probleme die von MariaDB nehmen, welche du wie ich vorher beschrieben habe, laden müßtest. Jener Server und die Library sind legal zu benutzen. Ich glaub nicht, daß Monty auf einen zweiten Deal mit Oracle einsteigen wird. Somit kannst du den MySQL-GPL Problemen aus dem Wege gehen und hast trotzdem Hoch-Performanten Zugriff auf diese Server. Hatte gestern mit dem Project-Manager gechattet und in der Zeos7.1 version ist jede Art libmysql.dll für die Entwicklung der Kompo seit gestern gelöscht. Außerdem werden wir für die Tests nur noch auf MariaDB setzen und ein solches Protocol hinzufügen (welches derzeit "mysql-5" darstellt). Keine Ahnung, wie ihr da denkt, ich jedoch gehe mal davon aus, das sich da nicht mehr viel verändern wird. (seit MySQL4.1 existieren functionen wie ?mysql_stmt_param_metadata? und bis heute: Returns currently nothing!);

Zeos wird wohl nie im Leben einen eignen Protocol-Wrapper für MySQL besitzen, da es auch keinen Sinn macht das "Rad" neu zu erfinden ohnen mit drastischen Abstrichen zum bereits allerseits bekannten "Rad" rechnen zu müssen. Never change a running System!

Also nochmal: Zeos ohne Protokol-Bibliothek existiert einfach nicht! Ausnahme: ADO welches auf die OleDB zugreift.

Gruß Michael

[Codehunter]

@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.

[Bernhard Geyer]

Zitat von Codehunter:

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.
...
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.

Du kannst es ja mal darauf ankommen lassen.

Zitat von Codehunter:

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?

Nur die direkte verwendung der DLL ist problematich. Gegen das Protokoll zu implementieren nicht.


Wir hatten vor Jahren einen MySQL-Vertriebler im Haus weil wir uns überlegt hatten MySQL als Embedded-Alternative für unsere bis dorthin nicht mehr zeitgemäße Desktop-DB einzusetzen. Als dann die Lizenzkosten (40 k€/Jahr nur für MyISAM, also nicht mal Transaktionsfähig) zu hoch waren wollte er noch die GPL-Karte ziehen um seinen Weihnachtsbonus zu sichern: "Sie setzen doch sicherlich auf die libmysql.dll". Als wir das (dank DevArt-Kompos) verneint hatten hat er wohl Gedanklich die Weihnachtsgeschenke zusammenstreichen müssten und konnte seine Heimreise ohne Vetrag antreten.

Noch was: Unsere App unterstützt mehrer DBMS. Sollte die App nur MySQL unterstützten könnte es schon wieder problematischer werden (Nach Oracle-Anwaltsmeinung)

[Codehunter]

UniDAC von Devart ist durchaus einen Blick wert. Wenn man mal schaut, dass das in der höchsten verfügbaren Ausbaustufe (Pro mit Source Site License) grad mal fast so viel kostet wie die allerkleinste kommerzielle MySQL-Lizenz, kann man wirklich nicht meckern.

Deine Erfahrungen mit dem MySQL-Vertreter finde ich ganz interessant. Man liest ja nicht oft von direkten Kontakten. Die spielen sicherlich auch gerne die Angstkarte. Ich mein, selbst SAP hat sich ja schon mit Oracle angelegt und verloren. Wobei ich der Überzeugung bin dass es für die Rechtsabteilungen der großen Konzerne irgendwo Bagatellgrenzen gibt wo sich aus rein wirtschaftlichen Aspekten ein Gerichtsprozess nicht lohnt, es sei denn man wäre auf ein Exempel aus und Geld spielte keine Rolle.

Sei's drum, ich möchte meine Projekte, so sie denn in die freie Wildbahn entlassen werden, soweit mir machbar auf rechtlich sauberen Beinen stehen haben. Darum ist mir MySQL, je mehr ich mich mit der Lizenzproblematik befasse, einfach nur suspekt.

Mehrere DBMS zu unterstützen ist sicher eine feine Sache. Aber wie weit geht da bei UniDAC die Abstraktion? Denn jedes DBMS hat ja so seine eigenen kleinen Spezialitäten. Bricht sich das da auf den kleinsten gemeinsamen Nenner runter?

[mkinzler]

http://www.heise.de/newsticker/meldu...L-1759765.html

Mit UniDAC ( zwar nicht mySQL) habe ich gute Erfahrungen gemacht.

[Codehunter]

Ich habe gerade den libmariadb.dll Client gegen eine MySQL 5.5 Datenbank mit ZEOS getestet. Zwar nur ganz simpel mit einem TZTable aber auf den ersten Blick scheint es zu laufen. Ob der Teufel da im Detail steckt kann ich noch nicht sagen.

Ich habe aber vorsorglich meine Aussage oben zurückgenommen, dass es gar nicht gehen würde.

[EgonHugeist]

@Bernhard Geyer

Danke für deinen Erfahrungsbericht. Kann mich Codehunter nur anschließen. Mal jemand mit live Erfahrung, welcher dem GPL Problem schon mal ins Auge gesehen hat.

@Codehunter

Ich De.. hätte auf die libmariadb.dll schon eher kommen können. Ich weiß so einige, die diese schon mit Zeos und MySQL als Ersatz benutzen. Kann mir jedoch keine Hickups vorstllen, da das Protokoll und die gesamte API identisch zur libmysql.dll sind und vom gleichen Autor. Ich werde diese WE mal unsere Tiefen-Tests drüber laufen lassen. Wo ich mir sicher bin ist, daß du mit der libmariadb.dll + Zeos + MariaDB keine Probleme haben wirst. Ich muß sagen diese Lösung, wenn schon noch mit MySQL gemunkelt wird (an andere gerichtet), erscheint mir sinnvoller als die UniDAC-Lösung.

Übrigens bietet die Zeos für Delphi7 (kein WideString/Memo-Field support) auch Autoencoded strings (comming stable oder SVN) welche für SQLite (rein UTF8 oder UTF16 basierend) sehr nützlich sein kann. Gleiche Funktionalität gilt natürlich auch für alle anderen DBMRS. Du kannst quasi drauf los Arbeiten ohne die DB-Encodierung beachten zu müssen.