MySQL, GPL, UniDAC - Ist das alles rechtens so?

[Medium]

Mahlzeit!
Auch wenn es dazu ja schon einige Threads gibt, muss ich das Thema nochmals aufgreifen (nicht zuletzt, da zwischenzeitlich ja Oracle ins Spiel kam, und viele Infos möglicherweise veraltet sind). Dass MySQL Lizenzmäßig nicht mit Transparenz glänzt ist wohl klar, mir geht es auch eher darum meinen konkreten Fall zu betrachten, als denn die Lizenz mit all ihren Details und Auswirkungen zu verstehen.

Mein Fall schaut so aus:
- Applikation aus unserem Hause
- Zugriff via UniDAC
- Verkauft wird unser Programm, Kunde bekommt gesagt "installier dir nen MySQL Community Server, Binaries findest du unter <insert URL here>, und wir konfigurieren dir den dann"

So weit ich das jetzt durchblicken konnte, sind die 2 wesentlichen Knackpunkte bei MySQL:
1) die libmysql.dll steht unter GPL, und linkende Programme müssen diese erben
2) sobald ich den Server mit ausliefere, bin ich mindestens dazu verpflichtet die Quellen unseres Programmes auf Anfrage offenzulegen (egal ob die libmysql.dll verwendet wird oder nicht?), ggf. auch, sie sofort beizulegen

Meine Fragen:
- Ist Punkt 1 durch die Verwendung von UniDAC (welches imho die libmysql.dll oder Abkömmlinge davon nicht benötigt) umgangen?
- Ist durch den Verweis auf die URL zum Download, die Installation durch den Kunden, trotz Einstellungsarbeiten von uns das "Mitauslieferproblem" gelöst?
Oder summa summarum: Ist die Verwendung des freien Servers auf diese Weise rechtlich i.O., so dass weder wir noch der Kunde irgendwann mal Pipi am Bein befürchten müssen?

Die Ausführungen der GPL selbst sind da irgendwie zu allgemein um diese Konstellation abschließend zu klären, und auf der MySQL Seite findet sich (verständlicherweise) nicht so arg viel zu konkreten "Kniffen" wie die Verwendung von UniDAC.

Kann man da irgendwie eine Aussage treffen, bzw. hat jemand mit o.g. "Strategie" schon mal Stress bekommen?

Danke euch schon mal!

[mkinzler]

Zitat:

"...Binaries findest du unter <insert URL here>, und wir konfigurieren dir den dann"

Problem könnte imho höchstens das Konfigurieren sein

Zitat:

- Ist Punkt 1 durch die Verwendung von UniDAC (welches imho die libmysql.dll oder Abkömmlinge davon nicht benötigt) umgangen?

Im Grundsatz ja, Oracle sieht das u.U. aber anders.

zu 2.) Wird ja von vielen Programmen so gemacht. Der Server ist so ja nicht Teil deines Programmes und der Kunde ist für die Beschaffung/Lizenzierung usw. zuständig.
Knackpunkt könnte hierbei die Konfiguration sein. Diese könnte man aber als Leistung von der Lieferung des Programmes trennen.

[franktron]

Also wir haben das Problem mit MariaDB umgangen da die Diese Falle nicht haben.

MariaDB ist ein MySQL Fork und Komplett unter GPL

[CCRDude]

Wenn ich den Threadersteller richtig verstehe, ist das "Problem" aber doch gerade eben die GPL, und nicht nur konkret MySQL?

[Bernhard Geyer]

Zitat:

Zitat von CCRDude (Beitrag 1131490)

Wenn ich den Threadersteller richtig verstehe, ist das "Problem" aber doch gerade eben die GPL, und nicht nur konkret MySQL?

Nicht unbedingt. MySQL/Sun/Oracle haben bei der MySQL-DB eine eigene interpretation der GPL-Reglen.
Normalweise bindest du ja bei Verwendung einer DLL keine GPL-Teile in dein Programm sondern verwendest die nur. Nach MySQL/Sun/Oracle (Anwalts-)Interpretation ist diese "GPL-Einbindung" auch dann gegeben wenn dein Programm ohne MySQL nicht lauffähigt wäre, als nur MySQL als DBMS unterstützt.
Dem gehst du aus dem Weg wenn du mindestens eine alternative DB wie MS SQL-Server oder ähnliches unterstützt.

Ob nun diese MySQL/Sun/Oracle-Interpretation vor einem Gericht bestehen würde, ist fraglich. Aber MySQL/Sun/Oracle hat mit sicherheit mehr Geld um gute Anwälte zu bezahlen ...

[mkinzler]

Zitat:

Normalweise bindest du ja bei Verwendung einer DLL keine GPL-Teile in dein Programm sondern verwendest die nur. Nach MySQL/Sun/Oracle (Anwalts-)Interpretation ist diese "GPL-Einbindung" auch dann gegeben wenn dein Programm ohne MySQL nicht lauffähigt wäre, als nur MySQL als DBMS unterstützt.

Bei der Dll ist das schon ein Problem der GPL, wäre diese unter LGPL würde sich das Problem nicht stellen. Der Zugriff ansich dürfte nicht unter die GPL fallen, auch wenn es von denen so ausgelegt wird ( nur was nützt einem das Recht, wenn man es zuerst durchsetzen muss).
Da MariaDB ein Fork ist, gilt die selbe Beschränkung auch für dafür und Oracle könnte es genauso durchsetzen, als wenn du die Originalversion verwendest.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1131535)

Bei der Dll ist das schon ein Problem der GPL, wäre diese unter LGPL würde sich das Problem nicht stellen. Der Zugriff ansich dürfte nicht unter die GPL fallen, auch wenn es von denen so ausgelegt wird ( nur was nützt einem das Recht, wenn man es zuerst durchsetzen muss).

Willst du das bei einer so großen Firma wir Oracle riskieren das Sie dich mal nur zum Ärgern verklagen?

Und das mit GPL und DLL. Wie sollte man dann Closed-Source auf Linux verkaufen können? Linux läuft doch unter der GPL.

[Medium]

Man könnte diese Konstellation also als "Graugrün-Zone" ansehen, die nicht ausreichend bzw. spezifisch genug in den angegebenen Lizenztexten definiert ist, und im Falle des Falles durch ein Gericht im Einzelfall entschieden werden müsste, wobei die Wahrscheinlichkeit, dass es dazu kommt, als recht gering einzustufen wäre? Ist ja nicht so wahnsinnig befriedigend :?
Mich macht etwas stutzig, dass Oracle da nicht längst um Klarheit bemüht ist, da das Problem augenscheinlich nicht allzu selten im Netz auftaucht. Genial fand ich auch so manche Berichte von ähnlichen Anfragen beim Oracle Support, bei denen wohl gerne zu einer Kauflizenz geraten worden sein soll, aber auch von dort keine definitive Aussage kam. Da bleibt einem ja kaum eine andere Wahl, als erstmal frei zu interpretieren. Nicht grad die Idee hinter Lizenzen :stupid:

[Bernhard Geyer]

Zitat:

Zitat von Medium (Beitrag 1131539)

Mich macht etwas stutzig, dass Oracle da nicht längst um Klarheit bemüht ist, da das Problem augenscheinlich nicht allzu selten im Netz auftaucht. Genial fand ich auch so manche Berichte von ähnlichen Anfragen beim Oracle Support, bei denen wohl gerne zu einer Kauflizenz geraten worden sein soll, aber auch von dort keine definitive Aussage kam. Da bleibt einem ja kaum eine andere Wahl, als erstmal frei zu interpretieren. Nicht grad die Idee hinter Lizenzen :stupid:

Wieso sollte Oracle (und früher) das klar machen. Die Einnahmen jemand auszuquetschen der das Integriert hat ohne sich gedanken zu machen sind viel höher als "die ganze" Welt nach Alternativen suchen zu lassen.

Wenn du ca. 30k€/Jahr (Stand vor ca. 3 Jahren) übrig hast kannst du dir eine Firmenlizenz geben lassen um MySQL mit deinem Produkt zu verteilen (jedenfalls mit transaktionsfreier Engine).

[alphaflight83]

Zitat:

Zitat von mkinzler

Da MariaDB ein Fork ist, gilt die selbe Beschränkung auch für dafür und Oracle könnte es genauso durchsetzen, als wenn du die Originalversion verwendest.

Das glaube ich so nicht, da MySQL ja nicht rein auf die GPL setzt, siehe Bernhards Beitrag, sondern ein duales Lizenzsystem verwendet. Die zweite Lizenz soll bei allen kommerziellen Anwendungen greifen, weshalb die natürlich so kleinlich ausgelegt wird wie möglich. Da der Fork sich aber komplett auf die GPL bezieht, kann ich mir nicht vorstellen, dass Oracle/MySQL da irgendwelche Chancen hat auf Lizenzverletzungen zu pochen. (Ansonsten wäre ja die ganze GPL Sache für die Füße)
Und dann greift im Endeffekt wieder das was Bernhard gesagt hat, da du keine Codebestandteile integrierst sondern ein fertiges Kompilat verwendest, solltest du (vor allem mit UniDAC) auf der sicheren Seite sein.

[franktron]

Zitat:

Zitat von alphaflight83 (Beitrag 1131541)

Zitat:

Zitat von mkinzler

Da MariaDB ein Fork ist, gilt die selbe Beschränkung auch für dafür und Oracle könnte es genauso durchsetzen, als wenn du die Originalversion verwendest.

Das glaube ich so nicht, da MySQL ja nicht rein auf die GPL setzt, siehe Bernhards Beitrag, sondern ein duales Lizenzsystem verwendet. Die zweite Lizenz soll bei allen kommerziellen Anwendungen greifen, weshalb die natürlich so kleinlich ausgelegt wird wie möglich. Da der Fork sich aber komplett auf die GPL bezieht, kann ich mir nicht vorstellen, dass Oracle/MySQL da irgendwelche Chancen hat auf Lizenzverletzungen zu pochen. (Ansonsten wäre ja die ganze GPL Sache für die Füße)
Und dann greift im Endeffekt wieder das was Bernhard gesagt hat, da du keine Codebestandteile integrierst sondern ein fertiges Kompilat verwendest, solltest du (vor allem mit UniDAC) auf der sicheren Seite sein.

So sehe ich das auch.

[mkinzler]

In diesem Fall meint aber Herr Stallman etwas anderes

Zitat:

The GNU Project has two principal licenses to use for libraries. One is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice of license makes a big difference: using the Lesser GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs.

Eine Libary unter der GPL darf nur dann in nicht GPL-Anwendungen verwendet werden, wenn diese eine "linked to" Klausel in der Lizentvereinbarung besitzt (GPL linking exception). Sonst nicht. Diese wird die Lizenz von MySQL aber nicht vorweisen.
http://en.wikipedia.org/wiki/GPL_linking_exception

[alphaflight83]

Zitat:

Zitat von mkinzler (Beitrag 1131550)

In diesem Fall meint aber Herr Stallman etwas anderes
Eine Libary unter der GPL darf nur dann in nicht GPL-Anwendungen verwendet werden, wenn diese eine "linked to" Klausel in der Lizentvereinbarung besitzt (GPL linking exception). Sonst nicht. Diese wird die Lizenz von MySQL aber nicht vorweisen.

Deswegen ja die Verwendung von UniDAC, da das nicht gegen die libmysql.dll linkt.

[Medium]

Halt, Moment! Die DLL spielt ja überhaupt nicht mit in meinem Fall! Das ist ja grad der Knackpunkt, um den es mir überwiegend geht: Ich Linke nirgends GPL lizensierten Code, auch nicht als Binary, sondern mittels der von DevArt entwickelten, von uns erworbenen Komponenten, die imho eben genau diese DLL nicht verwenden.
Alles was nachher bleibt ist, dass wir via non-GPL Programm auf eine vom Kunden, beim Kunden installierte MySQL DB zugreifen (die er jedoch von uns "wärmstens empfohlen" bekommt). Die Konfiguration der DB zur Verwendung mit unserem Programm ist eine separate Dienstleistung, oder Kulanz.

Edit: Und warum sollte Oracle da um Klarheit bemüht sein? Vor allem um seriös zu wirken. Ich kann doch kaum daran interessiert sein, willige Kunden ins offene Messer laufen zu lassen, in dem ich duch unklare Aussagen nicht definiere, dass das Messer tatsächlich da ist. Wenn ich nicht zahlen muss, tu ich (bzw. unsere Kunden) das nicht. Wenn keine andere Interpretation als "du müsse kaufe" möglich wäre, würde es zwar was Kosten, aber dann weiss ich, dass sich der (nicht geringe) Aufwand eines Umstieges (was viel Legacy-Code Anpassungen beinhaltet) kein Minusgeschäft wär, bzw. dass ggf. eine entsprechende Lizenz dennoch lohnenswert wäre, und der Kunde fragt nicht komisch, warum er auf einmal für seine DB löhnen muss obwohl MySQL doch frei ist.

[mkinzler]

Oder besser gleich ein DBMS einsetzen, welches kein Damoklesschwert frei Haus mitliefret.

[franktron]

Ich sage nur guckt mal hier wenn das nicht eindeutig ist dann weis ich auch nicht mehr

http://kb.askmonty.org/en/about-mariadb/license/
Und hier steht
http://creativecommons.org/licenses/by-sa/3.0/

to Share — to copy, distribute and transmit the work
to Remix — to adapt the work
to make commercial use of the work

[mkinzler]

Zitat:

This page is licensed under both of the following two licenses:

Nicht das DBMS

http://kb.askmonty.org/en/mariadb-license

[alphaflight83]

Zitat:

Zitat von Medium (Beitrag 1131555)

Halt, Moment! Die DLL spielt ja überhaupt nicht mit in meinem Fall! Das ist ja grad der Knackpunkt, um den es mir überwiegend geht: Ich Linke nirgends GPL lizensierten Code, auch nicht als Binary, sondern mittels der von DevArt entwickelten, von uns erworbenen Komponenten, die imho eben genau diese DLL nicht verwenden.
Alles was nachher bleibt ist, dass wir via non-GPL Programm auf eine vom Kunden, beim Kunden installierte MySQL DB zugreifen (die er jedoch von uns "wärmstens empfohlen" bekommt). Die Konfiguration der DB zur Verwendung mit unserem Programm ist eine separate Dienstleistung, oder Kulanz.

Die einzige verbleibende Problematik ist die MySQL Lizenz, die eben auch besagt, dass ein Programm, sobald es MySQL benötigt (Also keine alternative DB unterstützt) lizenzpflichtig wird...
Allerdings könnte man nun dank der MariaDB argumentieren, dass diese, weil weitgehend identisch, auch unterstützt wird, womit man aus dem Schneider wäre ;)

Edit:
Oracle hat verständlicherweise ein Problem mit der Klarheit, denn wenn sie den Leuten genau erklären, wann die Kommerzlizenz greift, beinhaltet das im Umkehrschluss auch die genaue Anleitung diese zu umgehen, womit Großteile des Profits wegbrechen dürften.

[franktron]

Der Link von meinem Vorpost kommt hierher http://kb.askmonty.org/en/about-mariadb
ist wohl schlecht verlinkt.

[Medium]

Zitat:

Zitat von mkinzler (Beitrag 1131556)

Oder besser gleich ein DBMS einsetzen, welches kein Damoklesschwert frei Haus mitliefret.

Als freie DB bliebe da ja fast nur Firebird, welches aber grad an älteren Programmen dermaßen viel kaputt machen würde (in Punkto SQL-Eigenarten der beiden Dialekte vor allem), dass diese Umstellung für Altprojekte kaum leistbar wäre. Zeos durch UniDAC ersetzen war schon ein Akt, aber dank sehr ähnlicher Interfaces praktikabel. Wir sind leider erst nachdem wir bereits Software mit Zeos/MySQL im Einsatz hatten auf diese Unwegbarkeit gestoßen. MariaDB als Argument wäre natürlich ein Leckerli.
Und es ist ja nicht nur die DB an sich: Die ganzen Workbench-Projekte zum Design müssten ebenfalls abgebildet werden, und was ich an (freien) Tools für FB so gefunden habe, war wenig überzeugend. Kostenpflichtige mit vergleichbarem Umfang schlagen zudem recht üppig in die Kaffeekasse, so dass man für das Geld schon fast besser MySQL lizensieren könnte :)

[mkinzler]

Zitat:

was ich an (freien) Tools für FB so gefunden habe, war wenig überzeugend

IBExpert/DataBase Workbench bieten in der freien Version schon viele Features und auch die Vollversionen sind ein Klacks im Vergleich zu den Lizenzkosten bei einer Mitlieferung von MySQL Server-Lizenzen.

[blackfin]

Ich finde den EMS SQL Manager für Interbase / Firebird ziemlich gelungen und Feature-reich, davon gibt es auch eine Free Version und die Vollversion ist auch nicht aaaalllzu teuer.

(und der ist btw. in Delphi geschrieben :-D)

[mkinzler]

Zitat:

(und der ist btw. in Delphi geschrieben )

Die anderen beiden auch. Deren Autoren sind auch hier im Forum aktiv ( Holger Klemt, Thomas Steinmaurer)

[CCRDude]

Zitat:

Zitat von mkinzler (Beitrag 1131550)

Eine Libary unter der GPL darf nur dann in nicht GPL-Anwendungen verwendet werden, wenn diese eine "linked to" Klausel in der Lizentvereinbarung besitzt (GPL linking exception). Sonst nicht. Diese wird die Lizenz von MySQL aber nicht vorweisen.
http://en.wikipedia.org/wiki/GPL_linking_exception

Die GPL linking exception handelt aber von statisch gelinktem Code (also etwa .obj), während DLLs schon dem Namen nach Dynamic Link Libraries sind, die man zudem noch dynamisch (LoadLibrary, GetProcAddress) statt statisch (PE Import Table) laden kann, die also doppelt dynamisch einbindbar wären.

Um etwas aus dem von Dir erwähnten Wikipedia-Artikel zu zitieren, der diese meine obige These stützt:

Zitat:

Zitat von Wikipedia

Such modified licenses enable software projects which provide "library" code, to be "linked to" the programs that use them, without applying the full terms of the GPL to the using program. Linking is the technical process of connecting code in a library to the using code, to produce a single executable file.

Dann geht es weiter mit:

Zitat:

Zitat von Wikipedia

It is performed either at compile time or run-time in order to produce functional machine-readable code.

Hier wird die Runtime mit einbezogen. Wobei zur Runtime geladene DLLs zwar mit im Prozessspeicher sind, es dort aber gar keine "Files" gibt, und das nahste Äquivalent, Module, die geladene DLL immer noch "trennt", so daß es nicht dieselbe Datei wäre. Insofern würde ich auch dies immer noch nur auf Linking im Stil von .obj sehen.

In meinen Augen bezieht sich die GPL Linking Exception daher auf einen härteren Verbund, als das Einbinden von DLLs wäre. Womit auch dieser Zusatz nicht wirklich klar wäre, schade!

[mkinzler]

Zitat:

Zitat von CCRDude (Beitrag 1131570)

Zitat:

Zitat von mkinzler (Beitrag 1131550)

Eine Libary unter der GPL darf nur dann in nicht GPL-Anwendungen verwendet werden, wenn diese eine "linked to" Klausel in der Lizentvereinbarung besitzt (GPL linking exception). Sonst nicht. Diese wird die Lizenz von MySQL aber nicht vorweisen.
http://en.wikipedia.org/wiki/GPL_linking_exception

Die GPL linking exception handelt aber von statisch gelinktem Code (also etwa .obj), während DLLs schon dem Namen nach Dynamic Link Libraries sind, die man zudem noch dynamisch (LoadLibrary, GetProcAddress) statt statisch (PE Import Table) laden kann, die also doppelt dynamisch einbindbar wären.

Um etwas aus dem von Dir erwähnten Wikipedia-Artikel zu zitieren, der diese meine obige These stützt:

Zitat:

Zitat von Wikipedia

Such modified licenses enable software projects which provide "library" code, to be "linked to" the programs that use them, without applying the full terms of the GPL to the using program. Linking is the technical process of connecting code in a library to the using code, to produce a single executable file.

Dann geht es weiter mit:

Zitat:

Zitat von Wikipedia

It is performed either at compile time or run-time in order to produce functional machine-readable code.

Hier wird die Runtime mit einbezogen. Wobei zur Runtime geladene DLLs zwar mit im Prozessspeicher sind, es dort aber gar keine "Files" gibt, und das nahste Äquivalent, Module, die geladene DLL immer noch "trennt", so daß es nicht dieselbe Datei wäre. Insofern würde ich auch dies immer noch nur auf Linking im Stil von .obj sehen.

In meinen Augen bezieht sich die GPL Linking Exception daher auf einen härteren Verbund, als das Einbinden von DLLs wäre. Womit auch dieser Zusatz nicht wirklich klar wäre, schade!

Die Dll wird im Kontext des Hauptprogrammes geladen, also dynamisch gelinkt. Diese Erweiterung erlaubt es, GPL Code gegen ein Nicht-GPL Programm zu linken, ohne geht das nicht.

[CCRDude]

Zitat:

Zitat von mkinzler (Beitrag 1131574)

Die Dll wird im Kontext des Hauptprogrammes geladen, also dynamisch gelinkt. Diese Erweiterung erlaubt es, GPL Code gegen ein Nicht-GPL Programm zu linken, ohne geht das nicht.

Entschuldigung wenn ich jetzt verwirrt bin. Ich bezog mich auf diesen Post von Dir:

Zitat:

Zitat von mkinzler (Beitrag 1131550)

Eine Libary unter der GPL darf nur dann in nicht GPL-Anwendungen verwendet werden, wenn diese eine "linked to" Klausel in der Lizentvereinbarung besitzt (GPL linking exception). Sonst nicht. Diese wird die Lizenz von MySQL aber nicht vorweisen.

Es standen hier nur zwei Zugriffsmöglichkeiten im Raum: UniDAC und libmysql.dll. Ersteres aber enthält wohl keinen Code von MySQL, und zweiteres ist nur eine DLL. Welchen Bezug hatte dann Dein Kommentar, daß MySQL die GPL Linking Exception nicht vorweisen dürfte?

Ich kenne natürlich UniDAC nicht, bindet das evtl. object files von MySQL ein, um auf die DLL verzichten zu können? Dann würde ich Deinen Einwand auch verstehen :)

Sicherlich ist der kurze Begriff Library dann auch irreführend, denn scheinbar hast Du ja keine D.L. Library sondern eine Object Library gemeint.

[Medium]

Erstmal Danke für die Tool-Tips (:))! Irgendwie müssen meine Google-Skills nachlassen. Man wird ja auch nich jünger, hust!
Ansonsten bin ich jedoch weiterhin gleichbleibend verwirrt bezüglich der GPL Geschichte. Gehört die Linking-Exception eigentlich nun fest zur GPL, oder ist das ein optionaler Zusatz, der explizit angegeben sein muss um wirksam zu sein? Was UniDAC angeht: Wenn mich nicht alles täuscht, ist da alles eine Eigenentwicklung. Sonst müsste die Komponente ja auch unter GPL stehen. Leider scheint die Seite von DevArt grad down zu sein, da stand irgendwo auch, dass man damit insbesondere die DLL umgeht. Was mich wieder zur Linking-Exception bringt - warum wäre das erwähnenswert, wenn die LE für MySQL gilt?

Edit: Ah, der Google Link war nur veraltet. MyDAC (Teil von UniDAC). Man könnte scheinbar auch mit libmysql, muss man wohl aber nicht. Mache ich auch nicht. Wird durch diese Option natürlich auch wieder alles nicht einfacher in der Auslegung. :stupid:

[mkinzler]

Zitat:

Gehört die Linking-Exception eigentlich nun fest zur GPL, oder ist das ein optionaler Zusatz, der explizit angegeben sein muss um wirksam zu sein?

Es ist eine Erweiterung.
Für MyDAC/UniDAC dürfte die Beschränkung nicht gelten, da man ja die Dll nicht verwendet. Als Anbieter eines kleinen Programmes sollte es Oracle auch nicht stören, aber grundsätzlich bedeutet dass nicht, dass Oracle nicht versuchen könnte ihr ( aus meiner Sicht nicht existente Recht) durchzusetzen.

[CCRDude]

Zitat:

Zitat von mkinzler (Beitrag 1131647)

Für MyDAC/UniDAC dürfte die Beschränkung nicht gelten, da man ja die Dll nicht verwendet.

Habe ich Deinen vorigen Satz dann doch nicht als Bestätigung meiner These zu lesen, weil Du mit diesem die DLL doch wieder als "gelinkt" im Sinne der Linking Exception siehst?

Dann verstehe ich ihn trotzdem nicht, weil Du damit gar nicht auf meine Argumente eingegangen wärest, sondern sie mit Deinem Kommentar einfach ignoriert hättest? Oder was sollte der genau aussagen?

Wenn die GPL Linking Exception den Begriff "linking" schon mit einem Zusatz definiert, halte ich es - no offense meant - für vermessen von Dir, diesen Begriff mit Deiner nicht gleichlautenden, sondern sich entscheidend unterscheidenden, Definition von "linking" gleichzusetzen.

Denn der von Dir zitierte Wikipedia-Artikel spricht keinesfalls vom "Kontext der Hauptdatei", sondern konkret von einem "single executable file". DLL-Dateien sind per Definition ebenfalls getrennte Executable Files, siehe ihr Format, PE = Portable Executable. "Kontext" dagegen ist ein schwammiger, in der von Dir zuerst erwähnten Versien gar nicht verwendeter Begriff.

Insofern sehe ich die Einschränkung eben bei gelinktem object code, nicht bei gelinkten DLLs, und der Zusatz "da man ja die Dll nicht verwendet" ist auch nicht korrekt, um da sicher zu sein, müsste man eben wissen, ob es weder die DLL noch zur compile time statisch gelinkten Code verwendet.

[alphaflight83]

Ich denke, wie schon erwähnt, dass du mit der von dir beschriebenen Konstellation save sein solltest.
Der Kunde holt sich MySQL selbst, du linkst nicht gegen MySQL Libs (welcher Art auch immer) und MySQL könntest du theoretisch sofort durch MariaDB ersetzen. Meiner Auffassung nach sollte da durch Oracle kein Hebel ansetzbar sein.

[himitsu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1131538)

Und das mit GPL und DLL. Wie sollte man dann Closed-Source auf Linux verkaufen können? Linux läuft doch unter der GPL.

Grauzone halt ... man kann es so oder so auslegen.

Wobei die Linux-Leute selten dämlich wären, würden sie diese GPL-Auslegung für Linux durchsetzen.
Denn dann würde keiner mehr Closed-Source-Programme für Linux schreiben, was wohl quasi einem Selbstmord oder zumindestens Selbstverstümmelung gleich kommt. :stupid:

Im Falle von MySQL/Oracle wollen die damit einfach nur die anderen Versionen verkaufen und auf keinen Verzichten, welcher das sonst gratis verwenden würde.
(die hoffen wohl, daß es also welche kaufen, anstatt sich was Anderes zu suchen)

[JamesTKirk]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1131538)

Und das mit GPL und DLL. Wie sollte man dann Closed-Source auf Linux verkaufen können? Linux läuft doch unter der GPL.

So weit ich das weiß ist die GNU C-Bibliothek (zu der nahezu sämtliche Software unter Linux linkt, um auf das Betriebssystem zuzugreifen) unter der LGPL lizenziert, wie auch viele andere der üblichen unter Linux vorhandenen Bibliotheken. Selbst wenn du (wie zum Beispiel Free Pascal) direkt den Kernel aufrufst, hast du keine Probleme, da du keinen Code des Betriebssystems linkst, sondern einen vom Betriebssystem überwachten Interrupt aufrufst (bzw. einen speziellen Prozessorbefehl wie "sysenter" durchführst). Und bei C-Programmen, die Kernelheader verwenden, um auf diese Syscalls zuzugreifen gilt AFAIK auch, dass die ohne Probleme closed source sein dürfen, da es sich um die Schnittstelle zum Betriebssystem handelt. Letzteres habe ich zumindest öfters bereits gelesen.

Gruß,
Sven