|
Datenbank: MySQL • Version: 5.5 • Zugriff über: ZEOS
ZEOS 7.0 ohne libmysql?
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 |
AW: ZEOS 7.0 ohne libmysql?
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 |
AW: ZEOS 7.0 ohne libmysql?
Zitat:
Man sollte bedenken wenn man die libmysql.dll einsetzt das man bei MySQL in der GPL-Falle sitzt. |
AW: ZEOS 7.0 ohne libmysql?
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 |
AW: ZEOS 7.0 ohne libmysql?
@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. |
AW: ZEOS 7.0 ohne libmysql?
Zitat:
Zitat:
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) |
AW: ZEOS 7.0 ohne libmysql?
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? |
AW: ZEOS 7.0 ohne libmysql?
http://www.heise.de/newsticker/meldu...L-1759765.htmlMit UniDAC ( zwar nicht mySQL) habe ich gute Erfahrungen gemacht. |
AW: ZEOS 7.0 ohne libmysql?
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. |
AW: ZEOS 7.0 ohne libmysql?
@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. |
AW: ZEOS 7.0 ohne libmysql?
Zitat:
Das Protokoll ist nicht komplett veröffentlicht (es fehlen die Teile zur Passwortkodierung). Deshalb muss eine neue Implementation immer auf den Quellcode der Lib zurückgreifen und benutzt damit GPL-Code. DevArt kommt nur deshalb da raus, weil sie eben mehrere Datenbankserver unterstützen. Würde DevArt ausschließlich mysql unterstützen (wie z.B. directsql) dann würde DevArt genauso in der sog. GPL-Falle sitzen wie alle anderen auch. |
AW: ZEOS 7.0 ohne libmysql?
Wenn man da so herum dran geht, ist MariaDB eigentlich immer ein gültiger Ausweg. Imho lässt sich MySQL völlig transtaprent mit MariaDB substituieren. Zumindest ist das das, was ich in meinen Recherchen zum Thema herausgelesen habe. Probieren konnte ich es mangels Zeit und Gelegenheit noch nicht.
|
AW: ZEOS 7.0 ohne libmysql?
Zitat:
Zitat:
Zitat:
|
AW: ZEOS 7.0 ohne libmysql?
Wobei man Oracle als solche zu dem Thema zwar fragen könnte, aber mit Sicherheit keine liberale Antwort bekommen dürfte.
Ich würde da noch eine ganz andere Frage in den Raum werfen: Lässt sich die GPL nur auf Sourcecode anwenden oder auch auf Protokolle? Denn wenn dem so wäre, dann wäre jede Art von Reimplementierung eines Protokolls unter einer anderen Lizenz ein Verstoß gegen die GPL. Ich sags ja, die GPL rechtlich ein ganz heißes Eisen und wurde juristisch noch kaum bis gar nicht aufgearbeitet. Und dadurch ist jetzt das passiert, was die Schöpfer der GPL eigentlich vermeiden wollten: Das Softwarelizenzen als Waffe gegen Konkurrenten eingesetzt werden, sei es auch nur in einer Art "kalter Lizenz-Krieg". |
AW: ZEOS 7.0 ohne libmysql?
Wie ist das eigentlich, wenn man ODBC verwendet?
Für MariaDB gibt es ja keinerlei ODBC-Connectoren, daher muss man zwangsläufig die von MySQL verwenden... Darf man das einfach so, wenn die eigene Software nicht unter der GPL veröffentlicht wird? |
AW: ZEOS 7.0 ohne libmysql?
Zitat:
Der einzige Weg dürften alternative Client-Implementierungen wie z.B. libmariadb oder UniDAC sein. Denn die Netzwerkprotokolle scheinen nach gängiger Meinung die Final Frontier der GPL zu sein. |
AW: ZEOS 7.0 ohne libmysql?
Also lt. MariaDB-Hersteller hat der Einsatz des MySQL-ODBC-Connectors keinen Einfluss auf die GPL-Falle...
Zitat:
|
AW: ZEOS 7.0 ohne libmysql?
Zitat:
Ich bleibe dabei und die Vorredner bestätigen mich darin: Oracle könnte theoretisch die GPL als Waffe einsetzen gegen jeden kommerziellen Software-Hersteller, der sich über Clientbibliotheken mit MySQL verbinden, welche unter der GPL stehen. Ob sie es tatsächlich täten oder im konkreten Fall nur durch Einschüchterung auf Lizenzeinnahmen hoffen, wer weiß das schon. Wer hat schon das Sitzfleisch, sich gegen einen US-Großkonzern durch die internationalen Instanzen zu klagen? Dann doch lieber UniDAC oder auf eine native ZEOS-Version warten... |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 12:15 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz