Die Lizenz der Qt Library fördert das nicht stopfen von Sicherheitslücken



  • Das wird deutlich, wenn man die Punkte 2.2, 2.8, 2.9, 2.11 und vermutlich auch 2.13 sich einmal durchliest:
    https://www1.qt.io/faq/

    Im Prinzip muss man, wenn man die Software weiterpflegen will, ein Dauerabo bezahlen und das für jeden Arbeitsplatz.
    Das Problem fängt dann an, wenn man das Projekt abgeschlossen hat und eigentlich die Software nur noch weitervertreiben oder warten möchte.

    Denn hierfür muss man weiterhin das Abo bezahlen.
    Leider ist es nun so, dass sich gerade Stangensoftware in den ersten Wochen gut verkauft und das dann immer weiter nachlässt, je älter die Software wird.

    Dadurch sinken gegen Ende hin natürlich die Einnahmen und die Lizenzgebühren werden im Verhältnis zu diesen kleineren Einnahmen teurer.
    Dies gilt vor allem dann, wenn für Folgeprojekte nicht mehr die Qt Lizenz verwendet wird.

    Man müsste also selbst bei Mindereinnahmen die vollen Lizenzgebühren bezahlen. Eine Regelung wie, dass man bspw. nur x % vom Gewinn der verkauften Softwareprodukte abtreten muss, die viel besser und fairer wäre, gibt es nicht.

    Jede vernünftig denkende Firma wird also den Vertrieb der entwickelten Software einstellen müssen, also nicht mehr verkaufen können, das gilt selbst dann, wenn es noch eine Handvoll Kunden im Jahr geben könnte, die die Software kaufen würden.

    Ebenso darf man später gefundene Sicherheitslücken nicht mehr fixen, denn Entwickeln darf man nur, wenn man eine gültige Lizenz noch besitzt.
    Der Endkunde muss diesen Mist also ausbaden.

    Natürlich könnte der ein oder andere noch argumentieren, dann nimm doch die LGPL Lizenz und linke dynamisch.
    Ja, das könnte man natürlich anstreben, aber zum einen kann man nicht hinterher von der Bezahllizenz zur LGPL Lizenz wechseln und zum anderen ist es in der Praxis schwierig, diese dynamische Trennung strikt einzuhalten, vor allem bei der Qt Lizenz, weswegen die LGPL Lizenz für kommerzielle proprietäre Projekte eigentlich nicht empfohlen werden kann.
    Siehe dazu auch folgender Artikel:
    https://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/article.html

    Ebenso steht völlig offen, wie hoch die Lizenzgebühren für das Dauerabo in späteren Jahren sein könnte. Da entwickelt man die Katze also im Sack.

    Daher wundert es mich auch nicht, dass sich die Qt Lizenz im kommerziellen closed source Bereich nur wenig durchgesetzt hat und die Firmen lieber bei Windows bleiben anstatt sich auf eine crossplattform Library zu verlassen.

    Für Anwender ist die Sache insofern problematisch, da sie bei so einer Lizenzpolitik erst recht damit rechnen können, dass sie keine Updates mehr erhalten.
    Es ist zwar leider oft der Fall, dass Unternehmen ohnehin nicht mehr alte Software pflegen, aber wenn das durch die Lizenz der Libraries, die sie nutzen auch noch forciert wird, muss man sich nicht wundern wenn die dann keine Patches mehr nachreichen.

    Meiner Meinung nach sollte die Qt Company ihre Lizenzbedingungen überarbeiten und insbesondere für die Zeit, nach dem eine Software entwickelt und released wurde ein anderes Bezahlmodell, wie bspw. ein Prozentualer Gewinn anhand des Gewinns, der mit der Software dann noch verdient wird, anbieten.
    Dadurch würden zur wesentlichen Entwicklungszeit weiterhin die normalen Lizenzgebühren bezahlt werden, aber später, wenn die Software schon lange nicht mehr rentabel ist, könnte dann die Software immer noch gepflegt und verkauft werden und die Qt Company dadurch vielleicht sogar mehr verdienen als wenn die Firmen einfach die SW gar nicht mehr vertreiben und somit gar nichts verdient wird.

    Bis dahin sind Firmen mit Bibliotheken die unter der BSD, zlib, MIT Lizenz oder vergleichbares besser bedient.



  • computertrolls schrieb:

    , nach dem eine Software entwickelt und released wurde ein anderes Bezahlmodell, wie bspw. ein Prozentualer Gewinn anhand des Gewinns, der mit der Software dann noch verdient wird, anbieten.

    Kleiner Verschreiber.
    Ich meine natürlich eine Gebühr prozentuale abhängig vom Gewinn.



  • Aha.



  • Das ist der Grund, warum ich mich entgegen aller guten Ratschläge so sehr mit der Windows API abärgere.

    Also eigentlich ärgere ich mich gar nicht mehr so sehr damit ab, weil ich mittlerweile eine gewisse Übung habe, aber es gab Zeiten, in denen ich wirklich an die Decke gehen konnte, und wenn ich dann zusätzlich zu dem Lizenzproblem noch hier lese, dass da öfter einfach etwas nicht mit QT machbar ist.......



  • Bitte? Wenig verbreitet? Wo treibst du dich rum? Die Qt (und nicht nur die, sondern viele andere L-GPL Libraries ebenso) sind überall um uns herum. Auch in Fahrzeugen, Luft- und Raumfahrt und Medizinprodukten. Die L-GPL ist absolut unproblematisch und die Bedingungen einzuhalten ebenso. Man kann sich aber natürlich auch das Leben schwerer machen als notwendig, aber zum Glück sind die in der Minderheit.

    Und wenn du hier schon anprangerst Sicherheitslücken pflegen zu wollen, dann ist es nur logisch, dass du die Commercial Qt Lizenz weiter behältst und nicht kündigst. Meinst du TQC lebt von Luft und Liebe?

    Aber im Grunde bin ich bei dir. TQC ist leider ein reiner profitgieriger Laden, der mit Angst Marketing betreibt und das Qt Project ausbeutet. Aber dafür gibt es eben die L-GPL und die zum Glück durch das Free Qt Agreement geschützt.



  • pica schrieb:

    Bitte? Wenig verbreitet? Wo treibst du dich rum? Die Qt

    Es geht hier um Closed Source Software und für Qt wird aufgrund der Probleme, die sich aus der rechtlichen Fallstricke durch die LGPL ergeben, lieber die proprietäre Lizenz genommen, womit man dann genau das Problem hat, was oben angesprochen wird.
    Denn die proprietäre Lizenz muss man abonnieren, die kriegt man nicht für einen Pauschalbetrag.

    Als L-GPLE wird die für closed Projekte nicht angerührt, das ist auch rechtlich viel zu gefährlich. Zumindest sehen das alle so, die sich darüber wirklich ernsthaft auch mal Gedanken gemacht haben.

    (und nicht nur die, sondern viele andere L-GPL Libraries ebenso) sind überall um uns herum.

    Die meisten von uns werden als Closed Source Software wohl ein Sammelsurium an Spielen haben. Scanne also einfach mal unter Windows deinen Spieleordner nach *.dll Dateien ab.
    Da ist wirklich gar nichts dabei, dass die L-GPL nutzt.

    Du findest darunter dann aber bspw. massenhaft Bibliotheken wie bzw. für:

    • Python -> Pyhton Software Foundation Lizenz
    • zlib -> zlib Lizenz
    • SDL 2.0 -> auch zlib Lizenz (Wichtig: für die Version 2.0 wurde die Lizenz extra geändert weil die L-GPL bei der alten SDL 1.x keiner angerührt hat und es somit auch keine Synergieeffekte zwischen professionellen Entwicklern und der Entwicklung der SDL Version 1.x gab. Seit Version 2.0 mit der anderen Lizenz wird die SDL sehr wohl benutzt und das Projekt profitiert davon, weil Code von professionellen Studios zur SDL zurückwandert. Also ein Win-Win Effekt für beide, den es bei der L-GPL nie gab.)
    • libvorbis -> BSD artige Lizenz
    • mono -> MIT Lizenz
    • libxml2 -> MIT Lizenz
    • Lua -> MIT-Lizenz

    Also alles Bibliotheken mit BSD und MIT artige Lizenzen bzw. Lizenzen mit ähnlicher Freiheit und die Freiheit vermeidet eben, dass man rechtlich in ein Minenfeld tritt.

    Die L-GPL rührt keiner an, verdenken kann man es den Entwicklerstudios nicht, immerhin ist sie ein rechtliches Minenfeld, lies sie dir mal durch und die meisten, vor allem kleinere, Studios haben keine eigene Juristenabteilung mit Dutzenden an Anwälten.

    Wenn du die qt mal in Verwendung findest, dann wird dafür die proprietäre Lizenz im Abo bezahlt, womit das L-GPL Minenfeld auch vom Tisch ist, also umgangen wird.
    Allerdings dann halt mit der Konsequenz, dass man ein Abomodell abschließt und die Sicherheitslücken beim Nutzer mangels weitere Support zuschlagen, wenn das Abo gekündigt wurde. Also genau das hier angesprochene Thema.

    Und wenn du hier schon anprangerst Sicherheitslücken pflegen zu wollen, dann ist es nur logisch, dass du die Commercial Qt Lizenz weiter behältst und nicht kündigst.

    Ein kleines Studio arbeitet ein paar Monate an einem Projekt mit Qt Lizenz auf Kundenwunsch, danach wird ein ganz anderes Projekt in Angriff genommen mit anderen Vorraussetzungen ohne Qt.
    Warum sollte man dann das Abo noch weiterbezahlen? Das ist für kleine Entwicklerstudios viel zu teuer.
    Also lieber gar nicht nutzen oder wenn, dann nur für die Zeit der Projektentwicklung und mit dem Kunden vereinbarten Supportzeitraums.
    Falls der Kunde der einzige ist, der die Qt haben will, sollte es im gewerblichen Bereich, also zwischen Firma und Firma kein Problem sein, die Abokosten auf den Kunden abzuwälzen. Das muss also in die Supportkosten mit rein.

    Meinst du TQC lebt von Luft und Liebe?

    Die würden von mehr Umsatz und einem größeren Nutzungsgrad viel besser leben.
    Außerdem kann man Pauschallizenzen anbieten und die dann an Majorreleases koppeln.
    So wie es jetzt ist, ist es aber ein Abobezahlmodell wie bei Adobe, also schei**.
    Selbst ein paar Windows Lizenzen sind da günstiger.

    Aber dafür gibt es eben die L-GPL und die zum Glück durch das Free Qt Agreement geschützt.

    Du kannst dich gerne auf das Minenfeld begeben, ich werde dich nicht aufhalten und die Qt Lib für eigene CS Projekte definitiv nicht anrühren solange die proprietäre Lizenz nur im Abo zu haben ist.


Log in to reply