Eine eigene GUI
-
@trooper
Willst du jetzt wirklich diskuttieren, wer wann was geschrieben hat? Aber bitte...trooper schrieb:
Es stand trotzdem vorher da das Sourcecodes veröffentlicht werden müssen.
Welche das sind ist erstmal völlig belanglos dabei, denn bei der LGPL müssen auch Sourcecodes veröffentlicht werden, nur eben die der veränderten GUI und nicht die eigenen.trooper schrieb:
Klar kann man mittels QT erstelle Programme kommerziell verwenden, nur muss man sich dann im klaren sein, dass man die Sourcecodes veröffentlichen muss!
Es ist natürlich intuitiv sofort ersichtlich, dass du nicht die Sourcecodes des eigenen Programms meinst, sondern die von Qt. Btw: hat irgendjemand was gesagt, dass man die Qt-Sourcen verändern will?
Deine Aussage erweckte vielmehr den Eindruck, dass jedes kommerzielle Programm auf Basis von Qt open-source sein muss. Und da da früher tatsächlich so war, nahm ich an, dass du einfach noch nicht auf dem aktuellen Stand bist. Um Verwirrungen des TE zu vermeiden, habe ich die Aussage versucht richtig zu stellen.trooper schrieb:
PS: Deine Antwort war zudem noch nicht da.
trooper schrieb:
Zuletzt bearbeitet von trooper am 10:53:53 04.08.2010, insgesamt 1-mal bearbeitet
ipsec schrieb:
10:52:44 04.08.2010 Titel:
-
asc schrieb:
Die LGPL-Lizenz von QT (übrigens um kleine Klarstellungen seitens Nokias ergänzt, wegen Templates) erlaubt nur ein dynamisches Linken (+ Verwendung der Header, die für den Betrieb nötig sind [Templates]).
Ist so ne Sache. Eigentlich steht im Lizenztext nicht drinnen, dass dynamisch linken zwingend ist. Es muss nur dem Anwender möglich sein, die mitgelieferte Version von Qt gegen eine andere auszutauschen. Eine weitere Möglichkeit, um das zu erreichen, ist statisches Linken + Mitliefern der objectfiles. Mit denen kann man dann die Applikation mit einer anderen Lib wieder zusammenlinken.
trooper schrieb:
Welche das sind ist erstmal völlig belanglos dabei, denn bei der LGPL müssen auch Sourcecodes veröffentlicht werden, nur eben die der veränderten GUI und nicht die eigenen.
Was sind "die der veränderten GUI"?
trooper schrieb:
Also bei mir kam es schon öfter vor, dass ich irgendwelche Funktionen der GUI (Treebrowser, Dateibrowser etc.) an meine Vorstellungen anpassen musste. Dann bleibt einem irgendwann nichts anderes übrig als die GUI zu erweitern und schon muss man die Sourcecodes (der erweiterten GUI) mit veröffentlichen.
Oi, ich musste das noch nie! Was sind das für Änderungen, die nur mit Eingriff in die Qt-Sourcen zu bewerkstelligen sind? Schau dir mal an, was z.B. alles an genialen kde-Programmen rumkreucht, die mussten noch nie (!!!!) die qt-libs patchen. Ich bin mal gespannt auf deine Änderungswünsche. Hast du schon Featurerequests bei Nokia bageliefert?
-
Werkst du nicht wie lächerlich das ist die Zeiten hinzuschreiben (Ganze 51 Sekunden später - oh mein Gott
)Das ist kein Live-Chat hier sondern ein Forum.
Als ich meinen Text schrieb war dein Text definitiv noch nicht im meinem Computer nachgeladen bzw. irgendwo bei mir sichtbar.
Aber zur Entschuldigung. Mein Computer ist wohl zu langsam oder das Internet.
Antworte doch lieber auf die gestellten Fragen als auf den gegebenen Antworten rumzuhacken, denn das Hilft dem Fragesteller und vergrellt nicht die Antwortenden.
Viele Grüße
Trooper
-
Ich bin nun etwas verwirrt, ich habe das mit Qt bis jetzt so verstanden dass ich Closed Source entwickeln kann und auch die Software kommerziell vertreiben darf ohne auch nur einen Cent Lizenzgebühr an Nokia/Trolltech zahlen zu müssen, wenn ich dynamisch linke. Ist das so richtig?
G hibbes
-
Nachtrag: (damit ich nicht ein paar Sekunden später editieren muss
)@l'abra d'or
Das mit den Objektfiles mitgeben hab ich noch nie gehört, dass es schon irgendwo so gemacht wurde. Wäre aber durchaus denkbar.Ich habe auch nicht von explizit von QT gesprochen, denn ich verwende FLTK. Aber selbst bei QT könnte ich mir denken, dass du für bestimmte Spezialanwendungen die GUI abändern musst.
Beispiele:
- Ich möchte im Dateibrowser eine Objektvorschau von 3D-Objekten haben.
- Der Treebrowser soll zum übrigen Programmdesign passend sein.
- Die Listendarstellung soll scrollbar sein mit Icons.
Und weil es bei Dir noch nie vor kam, heißt das noch lange nicht, dass es nie vorkommen muss. Gerade bei FLTK gibt es viele Funktionen eben nicht von Hause aus. QT ist mit Sicherheit mächtiger. Aber spätestens wenn dein Kunde irgend so eine fixe Designidee hat, weist du was ich meine.
@hibbes
Ja das ist richtig so.
-
trooper schrieb:
Werkst du nicht wie lächerlich das ist die Zeiten hinzuschreiben (Ganze 51 Sekunden später - oh mein Gott
)Aber es ist später und nicht früher...
Antworte doch lieber auf die gestellten Fragen als auf den gegebenen Antworten rumzuhacken, denn das Hilft dem Fragesteller und vergrellt nicht die Antwortenden.
Ebenso
l'abra d'or schrieb:
Was sind das für Änderungen, die nur mit Eingriff in die Qt-Sourcen zu bewerkstelligen sind?
// edit:
Ok, ich hätte nicht Korrekturlesen sollen, jetzt war ich klar nach deinem Beitrag
-
hibbes schrieb:
Ich bin nun etwas verwirrt, ich habe das mit Qt bis jetzt so verstanden dass ich Closed Source entwickeln kann und auch die Software kommerziell vertreiben darf ohne auch nur einen Cent Lizenzgebühr an Nokia/Trolltech zahlen zu müssen, wenn ich dynamisch linke. Ist das so richtig?
Ja, mit der Ergänzung von l'abra d'or, das vielleicht auch statisches Linken möglich ist (Ich erinnere mich bei meiner Recherche, aber das mit dem dynamischen Linken bei einer Klarstellung von Nokia im QT-Forum gelesen zu hanben). Mit dynamischen Linken solltest du auf jedenfall sicher sein.
Fakt ist jedenfalls das du QT in der LGPL-Version (ohne Lizenzkosten) auch in Closed Source Projekten einsetzen kann. Da ich mich aber nur sehr am Rande mit QT beschäftigt habe, kann ich dir nicht die exakten Definitionen nennen (ich glaube mich z.B. auch an daran das QT-Templates nicht mehr als 5% des Codes ausmachen sollten - was imho eh nicht problematisch sein sollte).
-
trooper schrieb:
[*]Ich möchte im Dateibrowser eine Objektvorschau von 3D-Objekten haben.
Installiere einen entsprechenden Thumbnailer mit deiner Anwendung mit (so wird es MS Office/OpenOffice/Acrobat auch machen, um die Dokumente im Vorschaukasten anzuzeigen).
Beim QFileDialog hast du aber eher Probleme, denn manche Styles hooken sich hier ein und zeigen einen plattformeigenen FileDialog, dann bist du mit deinen Qt-Sourceänderungen wieder am Ende[*]Der Treebrowser soll zum übrigen Programmdesign passend sein.
Schreib einen eigenen QItemDelegate/QStyle
[*]Die Listendarstellung soll scrollbar sein mit Icons.
Eine Listendarstellung ist Scrollbar, und man kann es ganz einfach so einstellen, dass nur Icons angezeigt werden.
-
@l'abra d'or
Das wären evtl. Möglichkeiten für QT und nun das ganze für FLTK bitte...Sei doch nicht so starrköpfig. Auch mit QT geht nicht alles. QT ist mächtig keine Frage, aber auch da gibt es Grenzen. Genausogut könnte ein Fehler in QT selbst die Ursache sein, dass man den QT Quellcode anfassen muss.
-
Wow..hier hat sich eine richtige Diskussion entwickelt. Es war interessant alles durchzulesen. Lizenz hin oder her - ich werde mir zuerst Qt anschauen.
Vielen Dank
lg, freakC++
-
trooper schrieb:
@l'abra d'or
Das wären evtl. Möglichkeiten für QT und nun das ganze für FLTK bitte...Mit FLTK kommt man da nicht wirklich in Probleme, denn die Lizenz erlaubt statisches Linken, man darf dabei auch den Sourcecode ändern, muss aber die Änderungen unter der LGPL veröffentlichen:
Static linking of applications and widgets to the FLTK library does not constitute a derivative work and does not require the author to provide source code for the application or widget, use the shared FLTK libraries, or link their applications or widgets against a user-supplied version of FLTK.
If you link the application or widget to a modified version of FLTK, then the changes to FLTK must be provided under the terms of the LGPL in sections 1, 2, and 4.
Mit FLTK kenn ich mich aber nicht aus, drum ann ich dir da auch nicht sagen wie es geht.
Sei doch nicht so starrköpfig. Auch mit QT geht nicht alles. QT ist mächtig keine Frage, aber auch da gibt es Grenzen. Genausogut könnte ein Fehler in QT selbst die Ursache sein, dass man den QT Quellcode anfassen muss.
Starrköpfig? Mag sein, allerdings reagiere ich doch nur auf deine (wieder bekräftigte) Aussage, dass es eine Notwendigkeit ist, den Qt-Sourcecode zu verändern. Deine aktuelle Relativierung: Fehler in Qt. -> Bugreport! Patch veröffentlichung. Wenn es ein tatsächlich relevanter Fehler ist, wird der schnell in den Linuxdistributionen eingespielt und im nächsten Patchrelease von Qt enthalten sein.
Aber wenn es dich so stört, dass statisches Linken + Änderungen am Sourcecode von Qt sooo kompliziert ist: Verzichte auf statisches Linken, liefere deine modifizierte Library mit, samt Patches, und sag "Mein Programm funktioniert nur mit diesen und jenen Patches an Qt". Aber irgendwo geht das doch komplett an der Fragestellung vorbei. Ich denke es ist allen klar, worauf man sich bei der LGPL + kommerzielle Nutzung einlässt - man kann seinen Code verheimlichen, muss aber bestimmte Einschränkungen akzeptieren, egal wie sinnvoll diese einem erscheinen.
-
Ich glaube dem Fragesteller war genau das mit den Lizenzen eben nicht klar.
Wer entscheidet denn ob der Fehler relevant ist? Was ist wenn Du zum Beispiel in deinem Projekt eine Designentscheidung treffen musstest, weil vom Kunden so gewünscht, und dann auf den Fehler stößt, der für andere irrelevant erscheint?
Ich schrieb auch nicht dass es eine Notwendigkeit ist, sondern evtl. werden kann, bei evtl. Fehlern, Schwachstellen oder fehlender Funktionalität.
Im Prinzip kann ja jeder selbst entscheiden, was er einsetzen möchte. Wir nehmen aus den Gründen der Lizenz QT genau deshalb eben nicht...
Gruß
Trooper
-
trooper schrieb:
Sei doch nicht so starrköpfig. Auch mit QT geht nicht alles. QT ist mächtig keine Frage, aber auch da gibt es Grenzen. Genausogut könnte ein Fehler in QT selbst die Ursache sein, dass man den QT Quellcode anfassen muss.
Wenn du den Quellcode von QT oder FLTK anfassen musst, dann machst du etwas falsch. Denn dann bindest du dich an diese Version der Library und kannst nicht mehr so einfach updaten.
Das ist nur in absoluten extremen Ausnahmesituationen OK. idR ist es eine dumme Idee.
Und selbst dann ist es ja kein Problem die Quellcode zu veröffentlichen, denn man will ja das die eigenen Patches möglichst schnell in die Offizielle Version übernommen werden
-
Es heißt übrigens Qt und nicht QT.
-
@Tachyon
Aja - noch ein Klugscheißer.@Shade Of Mine
"Wenn du den Quellcode von Qt oder FLTK anfassen musst, dann machst du etwas falsch."Gut, dann machen wir alle hier seit Jahren alles falsch im Team. Wir schreiben hier erfolgreich Visualisierungssoftware für Wissenschaftler. Es ist schon öfters in der Vergangenheit vorgekommen, dass die verwendete GUI nicht das bot was gebaucht wurde - oder der Kunde wollte.
Gut das ihr es alle besser wisst, könnt oder glaubt zu können. Ich glaub was euch fehlt ist ein größeres Projekt und Kunden, die ihre Wünsche auch verwirklicht sehen wollen.
-
trooper schrieb:
Gut das ihr es alle besser wisst, könnt oder glaubt zu können. Ich glaub was euch fehlt ist ein größeres Projekt und Kunden, die ihre Wünsche auch verwirklicht sehen wollen.
Ich glaube du unterschätzt hier einige. Großprojekte sind durchaus den ein oder anderen bekannt (Projekte mit mehreren Millionen Codezeilen, oder Projekte an denen parallel 20 Entwickler [ohne QS... mitzuzählen] arbeiten, halte ich zumindest nicht als Kleinkram).
Und auch in solchen Projekten habe ich noch nie erlebt das im Code der UI-Bibliothek eingegriffen wurden ist, wohl aber (wenn auch sehr, sehr selten) um diese herum eine Ergänzung geschrieben wurden ist. Bei Plattformunabhängigen Projekten ist dies sicherlich problematischer, aber nicht ganz ausgeschlossen.
trooper schrieb:
Aja - noch ein Klugscheißer.
Vielleicht solltest du mal dein Sprachgebrauch etwas ändern.
Lies dir bitte mal deine Posts in aller ruhe und neutral betrachtet durch. Versuch dein Wissen dabei möglichst nicht einfließen zu lassen. Dann kommt dir vielleicht in den Sinn, das einige deiner Aussagen mehr als Missverständlich sind, und mehr Fragen als Antworten liefern.
Das deutet auch eine unnötige Nachfrage des OPs hin, der scheinbar bezüglich der Qt-Lizenz so verwirrt wurde, das er dennoch nochmals nachfragen musste.
Davon abgesehen, das Großprojekte ohnehin das Geld für kommerzielle Lizenzen haben sollten - wenn nicht wird an der falschen Stelle gespart (Alleine wenn man die Lizenzkosten in das Verhältnis zur Arbeitszeit setzt). Und kleine Projekte können in der Regel auch gewisse Abstriche machen. Und wenn man die kommerzielle Lizenz von Qt erwirbt, kann man eben auch die Eingriffe in die UI direkt machen (und über die kommerzielle Lizenz kann man immer noch nachdenken, wenn es wirklich soweit ist).
-
trooper schrieb:
@Tachyon
Aja - noch ein Klugscheißer.Qt == "Cute" - dasToolkit über das wir reden.
QT == QuickTime - Multimedia-Library von Apple für Mac/Win.
Keine Ahnung ob der Hinweis gleich Klugscheißerei ist...@Shade Of Mine
"Wenn du den Quellcode von Qt oder FLTK anfassen musst, dann machst du etwas falsch."Gut, dann machen wir alle hier seit Jahren alles falsch im Team. Wir schreiben hier erfolgreich Visualisierungssoftware für Wissenschaftler. Es ist schon öfters in der Vergangenheit vorgekommen, dass die verwendete GUI nicht das bot was gebaucht wurde - oder der Kunde wollte.
Keine Ahnung ob ihr was falsch macht. Wenn "ihr" (nehme an, das ist ein größeres Team in einer Softwareschmiede) merkt, dass die Lib nicht das bietet, was ihr/eure Kunden sich vorstellen (du hast ja vorher schon gesagt, dass das FLTK ist, oder?), dann solltet ihr das Toolkit wechseln. Wenn selbst so etwas wie Qt, das auch in extrem hochwertigen Programmen eingesetzt wird, nicht reicht und gepatcht werden muss, bleibt nur eins: Kauft euch Lizenzen! Wenn ihr Kunden habt, die eure Software kaufen, dann könnt ihr euch sicher irgendwann eine Lizenz leisten. Falls nicht, solltet ihr darüber nachdenken, die Software unter GPL zu veröffentlichen - ihr könnt ja immer noch den Service "für Kunden kompiliert" + Support verkaufen.
Oder aber ihr schafft es, die Software so zu gestalten, dass ihr ohne Patches auskommt. Denn irgendwann wirds happig. Entweder weil euer Patch nicht mehr angepasst werden kann, oder weil der Kunde die neueste Qt[fltk/...]-Version verwendet, aber eure Software auf den Patch pocht (btw.: habt ihr ne gute Rechtsabteilung?)... Es wird irgendwann krachen
-
asc schrieb:
und über die kommerzielle Lizenz kann man immer noch nachdenken, wenn es wirklich soweit ist
Nein leider nicht.
http://qt.nokia.com/products/licensing/licensing#qt-commercial-licenseThe Qt Commercial Developer License does not allow the incorporation of code developed with the Qt GNU LGPL v. 2.1 or GNU GPL v. 3.0 license versions into a commercial product.
Problem ist halt, dass Lizenzen pro Arbeitsplatz fällig sind. Entwickeln wir mit voller Manpower unter LGPL, dann reduzieren wir, wenn wir fertig sind für reine Bugfixes auf 1-2 Arbeitsplätze und sparen uns hunderttausende an Euro Lizenzgebühren...
Aber die Trolls sind aufgeschlossene Menschen. Du kannst sicher eine eigene Lizenz aushandeln (z.B. LGPL entwickeln (mit allen Einschränkungen) + Support kaufen == billiger als commercial).
-
l'abra d'or schrieb:
asc schrieb:
und über die kommerzielle Lizenz kann man immer noch nachdenken, wenn es wirklich soweit ist
Nein leider nicht...
Gut aber selbst dann muss man nicht seinen eigentlichen Programmcode bei der LGPL-Lizenz veröffentlichen, wenn man an den Qt-Code Anpassungen macht, sondern nur die angepassten Qt-Teile.
LGPL ... The benefit to Qt is that any changes made to Qt must be made available under the terms of this license...
Und wenn es nur um Bugfixe oder kleinere Änderungen/Erweiterungen geht, sehe ich da kaum einen Nachteil.
-
@asc: Ist schon klar, aber das meinte ich jetzt nicht. Du kannst nicht ein Projekt entwickeln, und erst die LGPL-Version der Qt verwenden, und irgendwann sagen "Ey ich brauch Support/Will den QtCode ändern ohne zu veröffentlichen/..., ich kauf mir jetzt ne kommerzielle Lizenz", um mit dieser kommerziellen Lizenz das Projekt weiter zu betreiben/veröffentlichen. Wenn kommerzielle Lizenz, dann musst du dein Projekt komplett neu entwickeln. Und hoffen, dass das schon keiner rausfindet würde ich nicht