Qt DataBase in einem DLL kapseln
-
Hallo Zusammen,
ich habe eine Application in dem ich einen Qt Database benutze.
Diese Application ist in mehrere DLL aufgeplittet davon die Qt Database (wo es dort Messdaten in die database geschrieben werden)Die Qt Database wird in einem DLL gekapselt.
Meine Fragen gezielt auf die Qt Database (DLL mit Qt Database "QODBC"): Worauf bei einen Qt Database soll ich achten?
Soll ich für die Qt Database (das DLL wo die qt Database sich befinden) auch einen .pro Datei erstellen?danke in voaus
-
Hallo,
vielleicht besser gefragt:
Soll ich für diesem DLL einen.pro File erstellen?
-
Ich versteh nicht, was du willst.
Wenn du die LGPL Variante nutzt, darfst du nicht statisch gegen Qt linken sondern nur dynamisch. Dann musst du Qt Dlls verwenden. Da sollte es eine QtSql.dll geben oder so. Die Datenbanktreiber kann man zusätzlich als Plugins bauen, da könnte dann nochmal eine QtOdbc.dll rausfallen. Oder du linkst sie statisch in die QtSql.dll rein, machen wir so. Musst aber keien pro Dateien schreiben, gibts in der Qt schon alles.
-
Mechanics schrieb:
Ich versteh nicht, was du willst.
Wenn du die LGPL Variante nutzt, darfst du nicht statisch gegen Qt linken sondern nur dynamisch. Dann musst du Qt Dlls verwenden. Da sollte es eine QtSql.dll geben oder so. Die Datenbanktreiber kann man zusätzlich als Plugins bauen, da könnte dann nochmal eine QtOdbc.dll rausfallen. Oder du linkst sie statisch in die QtSql.dll rein, machen wir so. Musst aber keien pro Dateien schreiben, gibts in der Qt schon alles.So ein Quatsch. Er darf sehr wohl statisch linken wenn er die L-GPL Variante nutzt solange er seine Verpflichtungen einhält, sprich Linkerscripts und Objectfiles funktionierend mitliefert. Nur statisch zu linken macht überhaupt keinen Sinn, das ist ein anderes Thema.
Ich verstehe vielmehr die eigentliche Frage des TE nicht. Wenn du eine DLL willst brauchst du dafür natürlich ein eigenes pro File. Du kannst soch nicht aus einem Projekt zwei Outputs generieren.
-
Hör endlich auf diesen Mist zu verbreiten, mit LGPL darfst du nicht statisch linken! Oder lass dich einfach mal hier aufklären: +49 30 63923257
@DortmunderGast
Um welche Datenbank geht es hier?
-
partsoft schrieb:
Hör endlich auf diesen Mist zu verbreiten, mit LGPL darfst du nicht statisch linken! Oder lass dich einfach mal hier aufklären: +49 30 63923257
@DortmunderGast
Um welche Datenbank geht es hier?
Den Mist solltest du lieber nicht weiter verbreiten - lesen lernen wäre aber auch mal ein Anfang.
Zitat Wikipedia: "Oder es kann durch statisches Linken geschehen – dann bekommt ein Endnutzer typischerweise die Objektdateien (oder Quelltext) des proprietären Codes und die Sourcen des LGPL-Codes und kann diese zusammenlinken."
https://de.wikipedia.org/wiki/GNU_Lesser_General_Public_LicenseUnd falls dir das nicht genug ist kann ich dir noch den GPL/L-GPL Lizenztext empfehlen: http://www.gnu.org/licenses/lgpl-3.0.html
Oder in, vielleicht auch für dich verständlicher Form, die FAQ des GNU Projektes: http://www.gnu.org/licenses/gpl-faq#LGPLStaticVsDynamic
Reicht dir das, oder verweigerst du dich immernoch der Realität?
Btw. ein Unternehmen zu fragen, dass mit fragwürdigen Methoden versucht aus einem OSS Projekt Kapital zu schlagen zeugt natürlich auch von hoher Intelligenz. Im Übrigen macht sich The Qt Company strafbar wenn Sie dir tatsächlich eine individuelle Rechtsberatung als nicht-Rechtsanwalt zukommen haben lassen.
-
Nun, ich bin Programmierer und kein Fachanwalt für Lizenzrecht. Trotzdem habe ich mich gezwungenermaßen mit der Materie beschäftigt und finde das statische Linken und bereitstellen von Objektcode äußerst gewagt. Deshalb bin ich ganz einfach der Meinung du solltest das hier nicht dauernd empfehlen.
https://www.qt.io/qt-licensing-terms/
In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.
Wegen solcher Aussagen (und der Empfehlung eines Anwaltes) gehe ich jedenfalls lieber auf Nummer sicher und linke dynamisch.
Btw. ein Unternehmen zu fragen, dass mit fragwürdigen Methoden versucht aus einem OSS Projekt Kapital zu schlagen zeugt natürlich auch von hoher Intelligenz. Im Übrigen macht sich The Qt Company strafbar wenn Sie dir tatsächlich eine individuelle Rechtsberatung als nicht-Rechtsanwalt zukommen haben lassen.
Ich habe nur die Telefonnummer gepostet, wie kommst du darauf das ich mich dort habe beraten lassen? Allerdings denke ich tatsächlich über eine kommerzielle Lizenz nach, weil vor allem das Deployment unter Linux jedesmal eine Katastrophe ist.
-
Ich empfehle gar nichts. Ich gebe nur den Lizenztext wieder und der sagt eindeutig, dass statisches Linken in Ordnung ist - sogar explizit. Selbst implizit erlaubt sie es denn die Intention dahinter ist es dem Nutzer die Möglichkeit zu geben den L-GPL Teil einer Anwendung durch seine Modifikationen austauschbar zu machen - das ist auch statisch gelinkt weiterhin möglich.
Ich empfehle jedoch niemandem statisch zu linken aus zwei ganz einfachen Gründen: 1. Es bringt keinen Vorteil, der nicht durch eine andere Technik ebenso erreichbar wäre - produziert aber viele, eben unnötige, Problemquellen. 2. Damit die L-GPL konforme Weitergabe funktioniert benötigt der Anwender die Objectfiles und die Linkerscripts. Da die aber sehr Linker- und Hostspezifisch sind produziert das einen gewissen Aufwand bei der Bereitstellung.
Dass The Qt Company sagt "zur Sicherheit kauf eine Commercial" passt in ihr Bild. Digia hat die Markenrechte eines OSS Projektes (zu dem hat Nokia Qt gemacht) gekauft und muss nun Geld damit erwirtschaften. Da das nicht gut gehen kann, so wie sie es machen, haben sie als erstes (unter anderem deswegen) Qt in eine eigene Tochtergesellschaft ausgegliedert um die eigenen Zahlen nicht zu belasten. Das nächste Thema ist genau dieses, Verunsicherung streuen, denn sonst würden ja 99% der Unternehmen die L-GPL wählen. Dazu kommt ein recht aktueller Fall wo sich herausgestellt hat, dass die pure GPL+Commercial Komponenten wie das QtVirtualKeyboard, das ein Laufzeitplugin nachlädt, selbst dann standardmäßig mitgebaut werden, wenn beim configure explizit die L-GPL gewählt wurde. Das ist in meinen Augen hinterhältig, da einem so dann GPL Code untergeschoben wird. Auch die Lizenzbedingungen der Commercial Lizenz haben es in sich - schon mal gelesen welche Rechte du TQC damit überträgst? Das nimmt fast genauso schlimme Züge wie bei Oracle an.
Wir sind primär im Embedded Umfeld tätig und da empfehle ich allen unseren Kunden die L-GPL Variante zu wählen, da sie keinen Mehraufwand bedeutet aber immense Kosten spart (> 3.500 EUR pro Entwickler pro Jahr zzgl. Runtime Lizenzen ist schon eine ordentliche Hausnummer für ein Basisframework nur um die L-GPL zu umschiffen). Zudem kann man noch nichteinmal das Argument des Supports gelten lassen - 3 Jahre Support für eine Version, 2 Tage *Response*time, und natürlich keinerlei Garantie oder Verantwortung für den Fix sind absolut inakzeptabel. Dazu kommt, wer entwickelt Qt eigentlich weiter und pflegt Bugfixes, etc.? Aktuell kommen gerade mal 20% der Änderungen von TQC selbst. Eine Spende an KDE wäre effektiver um den Fortbestand zu sichern. Oder die Beauftragung eines Unternehmens das Qt aktiv weiterentwickelt wie KDAB oder auch wir es tun.
Und wenn du die Telefonnummer von TQC postest gehe ich davon aus, dass du möchtest, dass ich mich von ihnen beraten lasse bzgl. der L-GPL - das ist natürlich Quatsch.
Wenn du ein Problem mit dem Deployment unter Linux hast, dann stell doch eine Frage - bestimmt bekommen wir das gelöst. Mit einer Commercial Lizenz wirst du daran aber nichts ändern können. Eher sogar verschlimmern, weil du dann immer deine Applikation mit den Commercial Binaries deployen musst. Erstelle doch einfach ein ordentliches RPM und/oder DEB, dann funktioniert das absolut problemlos (machen wir zB.). Oder falls du ein einfaches "Klick"-Binary möchtest, kannst du FlatPack oder UPX nutzen. Auch beides Techniken mit denen wir sehr gute Erfahrungen gemacht haben.