Auf den ersten Blick sieht es zwar nach mehr Freiheit und Flexibilität bei der Lizenzwahl aus, aber man darf nicht vergessen, dass ein Lizenznehmer der sogenannten "commercial licence" von Qt praktisch alle Lizenzoptionen offen hat und darüber hinaus auch rechtlich in der Lage ist, Qt statisch in sein Produkt zu linken ohne die Objectfiles seiner proprietären Teile mit zu liefern.
Die Lizenzunterschiede sehen zwar vom Laienstandpunkt immer sehr wichtig aus, speziell für Firmen sind diese marginalen Differenzen aber meist anderen Kriterien untergeordnet.
Die Lizenzunterschiede sehen zwar vom Laienstandpunkt immer sehr wichtig aus, speziell für Firmen sind diese marginalen Differenzen aber meist anderen Kriterien untergeordnet. Deshalb hatte sich Adobe für den Reader für Gtk+ entschieden?
Natürlich gibt es auch Grenzfälle, wo der Hauptvorteil von Qt - gemeinsame Codebasis über alle Plattformen - nicht zum Tragen kommt, weil der Hersteller für gewissen Produkte noch an die überholte Form der Parallelentwicklung und Portierung gebunden ist.
Es ist natürlich auch immer eine Frage des Produkts. Für ein Freeware Programm, dessen Hauptzweck das Verbreiten eines Datenkonzepts als Standard ist, gelten natürlich andere Einflüsse wie für ein Programm, dass den eigentlichen Kern des Geschäftsmodells bildet.
> Die Lizenzunterschiede sehen zwar vom Laienstandpunkt immer sehr wichtig aus, > speziell für Firmen sind diese marginalen Differenzen aber meist anderen > Kriterien untergeordnet.
Das kommt ganz darauf an welches Produkt man entwickelt. Ich behaupte mal es gibt viele Projekte bei denen die GUI nur ein Mittel zum Zweck ist, welche man schnell mit einem GUI Builder zusammen klicken kann. Gerade in der Auftragsbezogenen Softwareentwicklung, wo das Geld nicht durch die Masse entsteht, und wo man ein sehr eingeschränktes Zeilpublikum hat, ist die GUI oft nur eine Nebensache - Hauptsache es funktioniert. Hier machen ein paar tausend für ein Toolkit (von vielen), dessen Details letztendlich sowieso vom GUI-Builder versteckt werden, sehr wohl einen Unterschied.
Mal abgesehen davon, haben die Distributoren ein gewaltiges Wörtchen mitzureden, immerhin legen diese mit der Entscheidung des Standard Desktops mehr oder weniger das Standard Toolkit fest. Gerade für Gewinn orientierte Unternehmen wie RedHat, Novell, & Co ist hier die GPL wohl ein Dorn im Auge. Liefert man den Standard Desktop mit QT aus, hat immer noch ein dritter die Hand im Spiel, welcher nach belieben im Bereich der CSS-Entwicklung "abschöpfen" kann. Man selbst hätte keinen Einfluss auf die Preisgestaltung und Weiterentwicklung des Standard-Toolkits des eigenen Produktes.
Gerade in der Auftragsbezogenen Softwareentwicklung, wo das Geld nicht durch die Masse entsteht, und wo man ein sehr eingeschränktes Zeilpublikum hat, ist die GUI oft nur eine Nebensache - Hauptsache es funktioniert.
Da ich für eine Firma tätig bin, die genau in diesem Bereich ihr Geschäftsfeld hat, erlaube ich mir zu widersprechen :)
Selbst bei wenn ein bestimmtes Produkt oder Teil eines Produkts mal keine GUI braucht, kann man die Stärken eines Multiplattform und Multiarchitektur Frameworks gut einsetzen, um sich haufenweise Zeit zu ersparen und vorallem um flexibel auf Plattformwechsel der Kunden reagieren zu können.
Im Falle eine Kunden begann das Produkt serverseitig auf Tru64 mit den zugehörigen Clients auf Windows. Dann wechselte dieser Kunde die Clientplattform zu Linux und vor Kurzem die Serverplattform ebenfalls.
Also ein Wechsel von einer 64Bit Big Endian Architektur auf eine 32Bit Little Endian und ein Wechsel von Windows nach Linux/Unix.
Wenn man in so einem Fall nicht einfach nur neue Binaries baut und ausliefert, ist man geliefert.
Dieses ganze Lizenzgerede verstehe ich nicht, was wollt ihr denn nun eigentlich? Wollt ihr nun Open-Source-Software entwickeln (dann sind die Lizenzen von GTK/Qt egal) oder wollt ihr die Software verkaufen, die dann betriebswirtschaftlich korrekt auch die Mittel zur Erstellung miteinberechnen muss? Dann fallen die Lizenzkosten kaum ins Gewicht und lassen sich in dem Preis, den ihr für eure Software verlangt auch abbilden. Es ist schon verwirrend ständig von Freiheit zu reden und dabei Verkaufen zu meinen.
Die Lizenzunterschiede sehen zwar vom Laienstandpunkt immer sehr wichtig aus, speziell für Firmen sind diese marginalen Differenzen aber meist anderen Kriterien untergeordnet.
Deshalb hatte sich Adobe für den Reader für Gtk+ entschieden?
Natürlich gibt es auch Grenzfälle, wo der Hauptvorteil von Qt - gemeinsame Codebasis über alle Plattformen - nicht zum Tragen kommt, weil der Hersteller für gewissen Produkte noch an die überholte Form der Parallelentwicklung und Portierung gebunden ist.
Es ist natürlich auch immer eine Frage des Produkts. Für ein Freeware Programm, dessen Hauptzweck das Verbreiten eines Datenkonzepts als Standard ist, gelten natürlich andere Einflüsse wie für ein Programm, dass den eigentlichen Kern des Geschäftsmodells bildet.
> speziell für Firmen sind diese marginalen Differenzen aber meist anderen
> Kriterien untergeordnet.
Das kommt ganz darauf an welches Produkt man entwickelt.
Ich behaupte mal es gibt viele Projekte bei denen die GUI nur ein Mittel zum Zweck ist, welche man schnell mit einem GUI Builder zusammen klicken kann. Gerade in der Auftragsbezogenen Softwareentwicklung, wo das Geld nicht durch die Masse entsteht, und wo man ein sehr eingeschränktes Zeilpublikum hat, ist die GUI oft nur eine Nebensache - Hauptsache es funktioniert.
Hier machen ein paar tausend für ein Toolkit (von vielen), dessen Details letztendlich sowieso vom GUI-Builder versteckt werden, sehr wohl einen Unterschied.
Mal abgesehen davon, haben die Distributoren ein gewaltiges Wörtchen mitzureden, immerhin legen diese mit der Entscheidung des Standard Desktops mehr oder weniger das Standard Toolkit fest.
Gerade für Gewinn orientierte Unternehmen wie RedHat, Novell, & Co ist hier die GPL wohl ein Dorn im Auge. Liefert man den Standard Desktop mit QT aus, hat immer noch ein dritter die Hand im Spiel, welcher nach belieben im Bereich der CSS-Entwicklung "abschöpfen" kann. Man selbst hätte keinen Einfluss auf die Preisgestaltung und Weiterentwicklung des Standard-Toolkits des eigenen Produktes.
Da ich für eine Firma tätig bin, die genau in diesem Bereich ihr Geschäftsfeld hat, erlaube ich mir zu widersprechen :)
Selbst bei wenn ein bestimmtes Produkt oder Teil eines Produkts mal keine GUI braucht, kann man die Stärken eines Multiplattform und Multiarchitektur Frameworks gut einsetzen, um sich haufenweise Zeit zu ersparen und vorallem um flexibel auf Plattformwechsel der Kunden reagieren zu können.
Im Falle eine Kunden begann das Produkt serverseitig auf Tru64 mit den zugehörigen Clients auf Windows. Dann wechselte dieser Kunde die Clientplattform zu Linux und vor Kurzem die Serverplattform ebenfalls.
Also ein Wechsel von einer 64Bit Big Endian Architektur auf eine 32Bit Little Endian und ein Wechsel von Windows nach Linux/Unix.
Wenn man in so einem Fall nicht einfach nur neue Binaries baut und ausliefert, ist man geliefert.
Es ist schon verwirrend ständig von Freiheit zu reden und dabei Verkaufen zu meinen.