QT Widgets v5.3 LGPL Lizenz Bedienungen für kommerzielle Nutzung
-
Hallo,
bin gerade dabei von MFC auf QT QWidgets mit QPainter umzusteigen. Soweit ich gelesen habe, müssen folgende Regeln eingehalten werden, um eigene QT 5.3 Programme unter der LGPL Lizenz zu veröffentlichen:
1. Dynamisches Linken der QT Bibliotheken
2. Dabei besteht keine Pflicht den eigenen Sourcecode des QT Programms zu veröffentlichen, solange die QT Bibliotheken unverändert bleiben.Gibt es noch weitere Bedienungen / Einschränkungen zu beachten?
Zu Punkt 1:
Worin liegt da die Einschränkung? Soweit ich weiß, werden doch heute viele kommerzielle Programme dynamisch gelinkt und die nötigen DLL's über die Installer / Setup Programme installiert bzw. mitgeliefert. Beispielsweise die C++ Runtime oder MFC- oder .NET Framwork DLLs.Zu Punkt 2:
Ist es erlaubt z.B. QT Widgets Steuerlemente zu überschreiben, um sie eigenen Anforderungen anzupassen? Dabei wird die QT Bibliothek DLL ja nicht verändert.Ich frage mich, ob ich die QT LGPL Linzenz wirklich vollständig verstanden habe? Denn sie scheint aus meiner Sicht doch für die große Mehrzahl der Programmentwickler mehr als einfach einzuhalten zu sein, oder?
Grüße,
Bernd
-
Das dürfte schon in etwa stimmen. Ich bin jetzt nicht der Verantwortliche für Lizenzfragen bei uns in der Firma, aber so in etwa läuft das bei uns auch. Wir linken dynamisch gegen die Qt und verwenden die LGPL Version. Und wir haben Qt auch ziemlich stark angepasst. Wir geben den angepassten Qt Source auch raus, aber nicht unseren. Das dürfte also auch kein Problem sein.
Dynamisches Linken reicht fast immer. Statisches Linken kann ab und zu interessant sein, wenn du z.B. eine möglichst kleine Dateien haben willst (z.B. Browserplugin oder etwas, was von einer CD gestartet wird) und nur die Klassen einkompilieren würdest, die du auch wirklich brauchst. Oder wenn du einfach eine Datei haben willst, die du weitergibst, ohne dass die 20 Dlls dabei hat. Sind aber alles Sonderfälle.
-
Mechanics schrieb:
Wir geben den angepassten Qt Source auch raus, aber nicht unseren. Das dürfte also auch kein Problem sein.
Was genau ist darunter zu verstehen? Gebt ihr die angepassten QT Elemente als offenen Source Code an den Käufer weiter?
Mechanics schrieb:
Oder wenn du einfach eine Datei haben willst, die du weitergibst, ohne dass die 20 Dlls dabei hat.
Müssen mit jedem QT Programm (Windows) ca. 20 Dlls weitergegeben werden? Die MFC ist dagegen ja in einer DLL verpackt.
-
Ich würde nicht von Qt "Elementen" sprechen. Wir haben an der Qt als Framework insgesamt einiges angepasst und erweitert, einzelne Widgets haben wir soweit ich mich erinnere nicht angepasst, die sind auch so ganz gut erweiterbar. Wenn man das sehr intensiv nutzt, muss man auch sehr tief eingreifen, z.B. im IO oder im Netzwerkmodul oder auch im Window Handling.
Genau, die Käufer bekommen auch den angepassten Qt Source.Üblicherweise hat man pro Modul eine Bibliothek, z.B. QtCore, QtGui, QtNetwork, QtXml usw... Spricht jetzt auch nichts dagegen, das ist eben modular und du nimmst nur die Bibliotheken, die du brauchst. Du darfst aber denk ich auch eine eigene QtMy Dll zusammenstellen und da reinlinken was du brauchst und nur die ausliefern.
-
Im Grunde ist mein Programm nicht sehr anspruchsvoll in der GUI Programmierung. Deshalb besteht womöglich gar kein Bedarf QT Steuerelemente zu überschreiben und ich komme gut mit den vorgegebenen QT Elementen aus. Da ich QT aber noch nicht so gut kenne, kann ich das augenblicklich noch nicht endgültig beurteilen.
Beim Wechsel zu QT ging es mir hauptsächlich um die Grafik. Zu Testzwecken habe ich deshalb Teile meiner GDI+ Grafik auf QPainter portiert. Mein erster Eindruck:
QT QPainter im Vergleich zur MFC:
+ Das Antialiasing der Grafik (Elipsen, Linien, Polygone etc.) ist besser.
+ Selbst das Antialiasing der Fonts ist weicher.
+ Als Ganzes gesehen, sieht die Grafik einen Tick edler aus.
+ Die standard QT GUI (Toolbars etc.) sieht moderner aus.
+ Die Klassen sind in modernerem C++ Code geschrieben.
+ Insgesamt ist das Programmieren komfortabler und es wird um Vergleich zur MFC weniger Code für die gleiche Funktionalität benötigt.
- Das QT Widget Programm startet etwas langsamer als ein MFC Programm.Kaum zu glauben, aber Insgesamt ein wirkliches Armutszeugnis für die anscheinend hoffnungslos veraltete original Microsoft Windows MFC.
Noch eine abschließende Frage:
Sind mit C++ programmierte QT Widgets Programme genauso sicher vor Spionage wie normale native C++ oder Windows MFC Programme?
So sind beispielsweise mit C# programmierte NET Framework Programme nicht geschützt davor. Mit geeigenten Programmen ist es nicht sonderlich schwer, große Teile des Soucecodes zu sichten. Da ich schon lange Jahre an meinem Programm schreibe ist das ein wichtiger Punkt für mich.
-
Hallo,
verstehe ich das richtig, dass wenn man Statisch Linkt, dass man dann den Source Code von QT Veröffentlichen muss, auch wenn man an QT nichts verändert hat?
Gruß
-
mireiner schrieb:
Kaum zu glauben, aber Insgesamt ein wirkliches Armutszeugnis für die anscheinend hoffnungslos veraltete original Microsoft Windows MFC.
Das Hauptproblem für mich ist, dass die MFC Klassen einfach hässlich sind. Das fand ich schon immer total hässlich, lange bevor ich Qt kannte. Die ganze Namensgebung sagt mir überhaupt nicht zu, diese ganzen spezialisierten Klassen wie CMapStringToString oder CMapStringToOb, diese IDs, die schlechte Kapselung, die vielen Macros... Kompiliziert und kann von sich aus nicht viel.
Muss aber natürlich auch sehr stark relativieren, es hat schon auch seine Gründe, warum die MFC so ausschaut, aber mögen muss man sie trotzdem nicht.Kann gut sein, dass Qt etwas langsamer ist als MFC. Ich hab das bisher nur noch nie beobachten können
Qt macht im Hintergrund tatsächlich viel mehr als MFC. Bei MFC ist alles mehr oder weniger direkt, bei Qt werden viele einfach erscheinende Operationen durch 20 Klassen durchgeschleift, die eingreifen dürfen... Aber das das nur GUI ist und kein Number Crunching, merkt man in der Regel nichts davon.Ich weiß nicht, was du mit "QT Steuerelemente zu überschreiben" meinst. Du kriegst ja nur evtl. Lizenzprobleme, wenn du im Qt Code selber was ändern musst. Aber das musst du so gut wie. Du kannst von den Widgets ableiten, ihr Verhalten ändern, Event Filter setzen usw... Das ist alles dein Code, da wird nichts "überschrieben".
qtasker schrieb:
verstehe ich das richtig, dass wenn man Statisch Linkt, dass man dann den Source Code von QT Veröffentlichen muss, auch wenn man an QT nichts verändert hat?
Ich glaube nicht. Wenn du nichts verändert hast, wird es sicher reichen, auf den Originalcode zu verweisen.
-
qtasker schrieb:
Hallo,
verstehe ich das richtig, dass wenn man Statisch Linkt, dass man dann den Source Code von QT Veröffentlichen muss, auch wenn man an QT nichts verändert hat?
GrußDen Sourcecode von Qt muss du nicht veröffentlichen, der ist ja öffentlich! Das Problem ist, dass du deinen eigenen Sourcecode, also dein Programm, offenlegen musst. Egal ob du am Qt-Code etwas änderst oder nicht.
Das Problem ist die LGPL, diese besagt, das dein eigenes Werk (der von dir geschriebene Teil) nicht mit dem Qt-Code (der von Trolltech/Nokia/Digia geschriebene Teil) in einem Werk vermischt werden darf. Das erreicht man durch dynamisches Linken. Die Windows-Exe enthält nur deinen "Code" und der Qt-Code ist in den Qt-DLLs die beim Starten des Programms geladen werden.
-
Mechanics schrieb:
qtasker schrieb:
verstehe ich das richtig, dass wenn man Statisch Linkt, dass man dann den Source Code von QT Veröffentlichen muss, auch wenn man an QT nichts verändert hat?
Ich glaube nicht. Wenn du nichts verändert hast, wird es sicher reichen, auf den Originalcode zu verweisen.
Sorry, ich hab deine Frage falsch verstanden. Die Antwort von Softwaremaker ist richtig.
-
Danke für die schnelle Aufklärung.
-
Softwaremaker schrieb:
Das Problem ist die LGPL, diese besagt, das dein eigenes Werk (der von dir geschriebene Teil) nicht mit dem Qt-Code (der von Trolltech/Nokia/Digia geschriebene Teil) in einem Werk vermischt werden darf. Das erreicht man durch dynamisches Linken. Die Windows-Exe enthält nur deinen "Code" und der Qt-Code ist in den Qt-DLLs die beim Starten des Programms geladen werden.
Nun bin ich völlig verwirrt. Habe ich denn bislang alles falsch verstanden?
Muss ein Programmierer, den QT Source Code, mit dem er die QT Bedienungsoberfläche (Menüs, Toolbars, Dialoge, Steuerelemente) und andere QT Elemente, wie beispielsweise QPainter, programmiert, gesondert in eigene selbst erstellte DLLs auslagern und von seinem sonstigen C++ Programmcode, der sich in der EXE-Datei befindet, trennen? Entspricht das so wirklich der Wahrheit???
Ist das überhaupt in der Praxis immer so einfach möglich? Denn nicht selten ist ja der QT Code eng mit dem eigenem Code vermischt (Beispiel QPainter). Verstehe im Augenblick nur noch Bahnhof.
Kann das vielleicht bitte jemand einmal möglichst unmißverständlich klarstellen?
-
Die Qt Klassen sind in Qt Dlls. Da musst du nichts machen, das ist bereits so. Wie du sie benutzt, ist deine Sache, das ist dein Code. Den musst du nicht freigeben, wenn du dynamisch gegen die Qt Bibliotheken linkst.
-
Danke Mechanics für die Klarstellung und überhaupt für die QT Starthilfe.
Dann steht aus meiner Sicht einem Wechsel zu QT nichts mehr im Wege!
-
Man muss auch nicht unbedingt seinen Sourcecode veröffentlichen oder unter die LGPL stellen, wenn man statisch linkt. In dem Fall würde es auch reichen, den ungelinkten Object Code mitzuliefern, damit der User selbst wieder (statisch) linken kann (und so z.B. die Qt-Lib austauschen gegen neuere Version oder andere kompatible Lib).