qtforum.de

Hallo zusammen,

wir überlegen in der Firma gerade, die Qt-Core-Bibliothek einzusetzen. Da auf der Zielplattform aber nur beschränkt Arbeitsspeicher zur Verfügung steht, wollen wir die Qt-Core soweit runterkürzen, dass nur benötigte Klassen in die Bibliothek kompiliert werden.

Dafür würden wir das Makefile (oder das pro-File) verändern, das ja unter der GPL steht. Das zu veröffentlichen ist nicht das Problem. Aber wie sieht es mit dem Kompilat des veränderten Makefiles aus? Steht diese Variante der libqtcore-modified.so dann wieder unter der LGPL oder wird das wegen der Veränderung am Makefile dann auch zur GPL?

Das hier keine Juristen unterwegs sind ist mit klar. Mir geht es mehr um Erfahrungen mit derlei Änderungen um nicht den Bescheid unserer Rechtsabteilung abwarten zu müssen, bevor das Projekt weiterläuft.

Gruß,
Christoph

Soweit ich die LGPL verstehe (ich bin kein Jurist!) ist ein Verändern des Programms (hier: Qt) kein Problem. Die Änderungen müssen aber veröffentlicht werden. In wie weit das wie bei der GPL auch bedeutet, dass die Änderungen nicht mitgeliefert werden müssen sondern auch erst auf Anfrage herausgerückt werden müssen weiß ich nicht.

Du musst halt definitiv dynamisch linken, ein Austausch gegen eine andere Version der Qt-Libs muss ohne weiteres möglich sein. Änderst du die ABI/API hast du ein Problem, keine Ahnung ob das in der LGPL abgehandelt wird...
Und ob du den Namen der lib einfach ändern darfst weiß ich auch nicht. Wahrscheinlich eher nicht, da es einen Austausch nicht so einfach ermöglicht. Willst du eine globale Qt-Installation nutzen, geht das nämlich schon nicht mehr!

Du musst halt definitiv dynamisch linken, ein Austausch gegen eine andere Version der Qt-Libs muss ohne weiteres möglich sein.

Ok, dynamisch linken ist ja eine der Grundvorraussetzungen der LGPL.
Der zweite Teilsatz macht mir mehr Probleme: Muss ich gegen eine Version der originalen Qt-Libs kompatibel sein oder gegen eine modifizierte Version meiner Qt-Libs?

Änderst du die ABI/API hast du ein Problem, keine Ahnung ob das in der LGPL abgehandelt wird...

Da ist für mich genau der nächste Knackpunkt: Ich verändere die API ja nicht, ich implementiere halt nur einen Teil.

Aber ich seh schon, dass das Thema wohl nicht so verbreitet ist und ich wohl doch auf die Bewertung unserer Rechtsabteilung warten muss.

Gruß,
Christoph

christophr hat geschrieben:Muss ich gegen eine Version der originalen Qt-Libs kompatibel sein oder gegen eine modifizierte Version meiner Qt-Libs?

Natürlich gegen eine Originallib der QtCore!
Wenn der User z.B. Probleme mit eurer modifizierten Version hat, muss er ohne weiteres eure Version gegen die Originale von Nokia austauschen können.

Änderst du die ABI/API hast du ein Problem, keine Ahnung ob das in der LGPL abgehandelt wird...

Da ist für mich genau der nächste Knackpunkt: Ich verändere die API ja nicht, ich implementiere halt nur einen Teil.

Eben! Wunderbar
Du bist damit also API-kompatibel zur originalen QtCore. Wenn du jetzt nicht dummerweise die ABI änderst sollte es kein Problem mehr sein (aus meiner Sicht). Aber da ich auch nur ein Laie bin kann es sein dass es da noch den ein oder anderen Fallstrick gibt - eure Rechtsabteilung muss grünen Licht geben, das ist denk ich die einzige Lösung.

Wenn du jetzt nicht dummerweise die ABI änderst sollte es kein Problem mehr sein (aus meiner Sicht).

Da muss ich noch ein wenig rumspielen. Bis jetzt ändert sich die ABI, wenn ich nur Teile implementiere, weil nicht mehr alle Symbole vorhanden sind und damit die Symboltabelle ein anderes aussehen hat. Evtl. kann ich da dem Linker aber noch ein wenig Nachhilfe geben...

Vielleicht hilft die Binärkompatibilität (wenn erreicht) aber der Rechtsabteilung bei ihrer Entscheidung.

Bis hierher schon mal Danke für die Gedanken zu dem Thema.

Gruß,
Christoph

Ich hab die Erfahrung gemacht, das sich Rechtsabteilungen mit so Details ueberhaupt ned auseinandersetzen wollen.
Also rechne damit, dass du ne recht konservative Antwort bekommst (LGPL und GPL sind keine Basis fuer kommerzielle Plattformen, so zumindest die Antwort unserer Abteilung ^^) .

Zumal es da schon ziemliche Unsicherheiten gibt, was den begriff dynamisches linken angeht. Da gibt es kaum grundsatzurteile auf denen sich die rechtsabteilungen berufen koennen.

unter windows z.b. sobald du ne qt*.lib anziehst und ned jede qt*.dll per loadlibrary anziehst, bist scho im unsicheren Raum.

Wenn die QT selber modifizierst, musst die modifikationen auch rausgeben. und die modifikationen selber muessen unter der lgpl oder gpl stehen.
Aber problem sollt das an sich nicht darstellen.

Ciao ....

Unsere Rechtsabteilung hat kein grünes Licht gegeben:

Bei "diesem GPL-Zeugs" weiß man eh nie genau was man darf. Und dann auch noch Spezialfälle... Da haben die nicht lange überlegt.

Also werden wir die Funktionalitäten wohl selbst implementieren müssen. Bleibt noch die Frage, wer den Zeitplan entsprechend streckt


Gruß,
Christoph

Wenn die Rechtsabteilung Probleme mit GPL/LGPL hat kann man ja eine kommerzielle Qt-Lizenz erwerben, dann dürft ihr damit alles machen: die Qt-Libs ändern, statisch Linken, und das alles ohne den Quellcode offenzulegen.

Kostet je nach Anzahl Plattformen (Win/Linux/Mac) ein paar tausend EUR.

Ebend mal nachgeschaut: für ein OS kostet es $3695, aber am besten Preisanfrage machen.

Ui, ham die die Preise angezogen ...
bei uns warn es mal 1200,- pro OS und Arbeitsplatz und 1 Jahr ...

Wobei trolltech recht grosszuegig Rabatte gewaehrt hat damals. Weiss ned wie es unter Nokia iss.

Ciao ...

Das wäre nicht das Problem. Wir haben andere Tools hier im Einsatz, die ein Vielfaches kosten und ohne Probleme genehmigt werden. Das Problem ist, dass wir embedded entwickeln und damit für jedes verkaufte Gerät Lizenzkosten zahlen müssten. (Wenn ich das auf der Qt-Seite richtig lese.)

Da bei den Geräten aber schon an LEDs gespart wird um wieder den ein oder anderen Cent locker zu machen, sieht es mit Lizenzkosten pro verkaufter Einheit ganz schlecht aus. Fragt mich aber nicht, wo da der Sinn steckt. Wir haben mal grob überschlagen, was es kostet, wenn wir die benötigten Funktionen selbst implementieren. Das sind dann aber einmalige Kosten - Lizenzen pro verkaufter Einheit kann man wohl nicht abschreiben...

Gruß,
Christoph

bliebe noch wxWidgets, zwar nicht so umfangreich und komfortabel wie Qt aber kostenlos und "bessere" Lizenz

Das Problem ist, dass wir embedded entwickeln und damit für jedes verkaufte Gerät Lizenzkosten zahlen müssten. (Wenn ich das auf der Qt-Seite richtig lese.)

Ich les zwar, das es ne unterscheidung gemacht wird zwischen der desktop und der embedded version, aber von kosten pro ausgelieferter version les ich nix. Macht imho auch ned viel Sinn oder ?
Bei der Platform independet version wird auch ned drauf eingegangen (die beinhaltet die embedded version).

Lass noch jemand mal ueber die license Gechischte drueber schauen ...

Ciao ...

bliebe noch wxWidgets, zwar nicht so umfangreich und komfortabel wie Qt aber kostenlos und "bessere" Lizenz

Da ich keine GUI-Funktionalität benötige, sondern so Sachen wie Unicode-Strings, das Meta-Typ-System, Threads und im späteren Ausbau QtXML und QtNetwork, bleibt bei wxWidgets nicht mehr viel über. Nun wird wohl ein Teil davon selbst implementiert bzw. mit verschiedenen anderen Bibliotheken zusammengestellt. Ein Beinbruch ist das nicht, hätte uns aber Luft bei der alles entscheidenden Größe "Time-to-market" gebracht.

Qt Licensing
Dort ist die Rede davon, dass bei "fixed systems or devices where the main functionality relies on Qt" eine "runtime distribution license" zur Anwendung kommt. Darunter würden wir definitv fallen. Zusammen mit dem weiter oben erwähnten "Charge for Runtimes" "Yes, for some embedded uses" gehe ich davon aus, dass die Trolls (bzw. Nokia) die Lizenz nicht für lau beilegen.
Ich lass zur Sicherheit aber noch mal jemanden drüber schauen.

Gruß,
Christoph

christophr hat geschrieben: Da ich keine GUI-Funktionalität benötige, sondern so Sachen wie Unicode-Strings, das Meta-Typ-System, Threads und im späteren Ausbau QtXML und QtNetwork, bleibt bei wxWidgets nicht mehr viel über. Nun wird wohl ein Teil davon selbst implementiert bzw. mit verschiedenen anderen Bibliotheken zusammengestellt. Ein Beinbruch ist das nicht, hätte uns aber Luft bei der alles entscheidenden Größe "Time-to-market" gebracht.

wxWidgets kann Unicode,Threads, XML, Network usw.
http://docs.wxwidgets.org/stable/wx_cla ... assesbycat

wxWidgets kann Unicode,Threads, XML, Network usw.

Vielleicht sollte ich meine Kenntnisse zu "fremden" Bibliotheken von Jahr zu Jahr auffrischen. Zusammen mit der L-GPL-Ausnahme ist das ja genau passend. Wer braucht nocht Qt?

Jetzt müssen wir nur noch wxWidgets lernen. Aber das gehört dann in ein anderes Forum.

Danke für den Hinweis.
Gruß,
Christoph