Qt und die Lizenzänderung
by Viktor Garske on Jan. 5, 2021, 10 a.m., with 6 commentsGerade habe ich bei LinuxNews das gelesen, was ich schon seit einigen Monaten befürchtet habe: zwar ist es bei der Veröffentlichung von Qt 6 ein wenig untergegangen, aber das Team hinter Qt zieht die Daumenschrauben für Open-Source-Entwickler kräftig an an. Kurzzusammenfassung: die Open-Source-Aktivitäten werden weiter heruntergefahren und Lizenznehmer der proprietären Lizenz bevorzugt.
Lesenswert in diesem Zusammenhang wäre einerseits die Mail von Olaf Schmidt-Wischhöfer vor einigen Monaten oder auch die Zusammenfassung von heise online.
Die ganze Geschichte ist ehrlich gesagt schwer durchsichtig, denn einerseits wurde ja entgegen der Befürchtung Qt 6 quelloffen veröffentlicht, andererseits machen die Maintainer mit dem auslaufenden LTS-Support ernst.
Dass erst kommerzielle Kunden die neuen Versionen erhalten und dann die Open-Source-Community wäre aus meiner Sicht auch eine Loose-Loose-Situation, denn zahlende Kunden wollen sicherlich ausgereifte, getestete Software und die Open-Source-Entwickler probieren eher Neues aus. Scheint aber (vorerst?) noch nicht so eingetreten zu sein.
Aus Entwicklersicht wird der Einsatz von Qt zunehmend problematischer – aber nicht wegen des Frameworks selber. Qt ist quasi wie ein Aufsatz auf C++ und in extrem vielen Komponenten besonders verzahnt. Das war mitunter noch kritischer als die C++-STL nicht so umfangreich war, gilt aber meines Erachtens weiter uneingeschränkt für die GUI-Komponenten.
Bei Qt droht tatsächlich wieder die Lizenzpolitik zum Ausschlusskriterium zu werden. Wieder? Ja, denn das hat 1998 schon einmal zu Problemen geführt. Da hat eines der größten Qt-basierten Projekte, die Desktopumgebung KDE, mit der Lizenz Schwierigkeiten gehabt. Zwei Ergebnisse hiervon sind die Desktopumgebung GNOME als Antwort auf genau dieses Lizenzproblem (GNOME setzte von Anfang an auf das freiere GTK) sowie eine Vereinbarung bzw. Intermediärsorganisation zwischen dem Qt- und KDE-Team, die erlaubt, bei Einstellung der Qt Free Version die letzte Version unter einer BSD-Lizenz o. ä. zu veröffentlichen.
Die Folgen wären allerdings für alle Beteiligten wenig wünschenswert, was wir an Forks wie LibreOffice oder LEDE (mittlerweile wieder zusammengeführt) sehen können.
Bleibt also die präventive Frage nach Alternativen, allerdings sieht es hier schlecht aus. Ich kenne bisher kein vergleichbares Framework in Umfang, Plattformunabhängigkeit und Stabilität. Am nächsten würde vielleicht noch Electron kommen, aber ich würde eher etwas Kompiliertes für Desktopanwendungen vorziehen.
2021 beginnt also mit so einigen offenen Fragen.
Viktor Garske
Viktor Garske ist der Hauptautor des Blogs und schreibt gerne über Technologie, Panorama sowie Tipps & Tricks.
Comments (6)
Comments are not enabled for this entry.
tux.
Ich kenne bisher kein vergleichbares Framework in Umfang, Plattformunabhängigkeit und Stabilität.
EFL, das Framework hinter Enlightenment. Es hat den zusätzlichen Charme, dass es nicht als eigene Programmiersprache zu verstehen ist - einer der Gründe, warum ich Qt nicht ausstehen kann: Man braucht schon ein aufgeblasenes IDE (und sei es nur der QtCreator), damit man in ihm erstellte Projekte sauber kompilieren kann.
Die bisherige Lizenz war aber auch die Pest, insbesondere unter Systemen, die eher nicht auf shared libraries setzen (zum Beispiel Windows): Ein Dutzend DLLs mitliefern zu müssen ist nichts, was ich für akzeptabel halte, und statisches Linken ist halt verboten.
Qt 6 werde ich daher ebenfalls meiden.
Netter Gedanke, ich habe mir EFL und Enlightenment mal angeschaut. An die UI kann man sich ja noch gewöhnen, aber das, was da unter der Haube läuft, soll wohl berüchtigt für seine Codequalität sein. Moderner in einer Hochsprache verfasster Code muss zwar bei weitem nicht objektorientiert sein, aber das Typenkonzept hat schon einige Vorzüge bei der Entwicklung. Hier mal ein (bekannter?) Rant: https://what.thedailywtf.com/topic/15001/enlightened
Ob sich am Code was in den letzten Jahren getan hat, kann ich nicht sagen, aber wenn es einen Punkt gäbe, der mir – jetzt wo ich EFL gesehen und die Resonanz von vor 5 Jahren gelesen habe – noch bei einem GUI-Framework wichtig wäre, würde es das Ökosystem sein. Und das beginnt schon bei einer aussagekräftigen Referenz und guten Dokumentation. Man muss ja mit Code auch arbeiten können, wenn man Projekte aus dem echten Leben umsetzen möchte. Am ehesten würde ich mich da noch mit wxWidgets abfinden...