Qt 5.15 LTS: Lizenzänderung behindert Open Source-Projekte

Verfasst von

Im Frühjahr 2020 hatte The Qt Company ihre Roadmap für das Qt-Framework 2020 bekannt gegeben. Dort wurde festgelegt, dass ab Qt 5.15 langfristig unterstützte Versionen (LTS) und das Offline-Installationsprogramm von Qt nur noch für kommerzielle Lizenznehmer verfügbar sind. Zudem benötigen jetzt auch Open-Source-Anwender einen Qt-Account, um Qt-Binärpakete herunterladen zu können. Quellpakete sind weiterhin auch ohne Qt-Account zugänglich.

Unterschiedlich eingeschätzt

KDE-Entwickler Albert Astals Cid sah damals in seinem Blog keine allzu großen Auswirkungen auf das KDE-Projekt und Distributionen, die dessen Software nutzen. Andere Entwickler blickten mit sorge auf die Entwicklung. Aufgrund der darauffolgenden Berichterstattung in der Presse veröffentlichte das Unternehmen ein wenig aussagekräftiges knappes Dementi.

Nun ist es soweit, gestern wurde auf der Mailingliste des Qt-Projekts eine Notiz veröffentlicht, die bekannt gab, dass Qt 5.15 in die LTS-Phase eintritt. Alle bestehenden 5.15-Zweige bleiben öffentlich sichtbar, sind aber für neue Commits und Cherry-Picks geschlossen. Einzige Ausnahmen sind Qt WebEngine und das veraltete Qt-Script, die eine LGPL-Abhängigkeit von einem Drittanbieter haben.

Nach dem 5. Januar gehen die Cherry-Picks in ein anderes Repository, das nur für die kommerziellen Lizenznehmer verfügbar sein wird. Der Repository-Zugang steht kommerziellen Lizenzinhabern offen, so dass es möglich ist, zusätzlich zu den offiziellen Releases diese Repositories zu nutzen. Das erste rein kommerzielle Qt 5.15.3 LTS-Patch-Release wird voraussichtlich im Februar veröffentlicht.

Mitten im Zyklus

Befremdlich wirkt dabei die Entscheidung, diese Lizenzänderung mitten im Qt 5.15-Zyklus einsetzen zu lassen. Entwickler, die an Korrekturen für Regressionen aus früheren Qt 5.15-Punktversionen gearbeitet haben, sehen jetzt keine öffentliche Version mit diesen Regressionskorrekturen. Das erste Qt 6 LTS-Release wird erst mit Qt 6.2 in knapp einem Jahr erscheinen, was eine große Lücke für Distributoren und im Endeffekt Anwender hinterlässt, die dazu neigen, nur Qt LTS-Release-Serien ausliefern oder nutzen. Wie Qt 5.15 wird auch Qt 6.2 ein weiteres rein kommerzielles LTS nach dem gleichen Verfahren sein. Auf die offizielle Ankündigung folgte ein Bugreport, der fordert, dass in allen Repositories, die gesperrt sind, ein Zweig mit dem Namen 5.15-free des letzten öffentlichen 5.15-Commit abgezweigt wird.

Was bedeutet das nun für KDE? Offensichtlich wird KDE irgendwann auf Qt 6 umsteigen müssen, aber das wird eine Weile dauern. Der Umstieg zu Plasma 5 erfolgte, als Qt bei 5.3 stand. Nimmt man das als Maßstab, so ist KDE vermutlich für mindestens 18 Monate auf Qt 5.15.2 ohne weitere Bugfix-Versionen fixiert.

KDE Qt

Kommentare

20 Antworten zu „Qt 5.15 LTS: Lizenzänderung behindert Open Source-Projekte“

2021-01-05

perko

Es ist schön wenn der Zugang zum Quellcode ohne Anmeldung möglich ist, und QT bauen kann mit einer Distribution die das Kompilieren von Haus aus unterstützt, aka Paketmanager.

QT war schon immer ein Wenig suspekt, nicht umsonst hat es bei Debian ganz lange gebraucht bis QT im Paketmanger überhaput gelistet werden durfte wegen der Lizenzproblematik. Debian nur mit GTK/GNOME, alte Zeiten.

Aber bei QT und GTK hat man die Wahl zwischen Pest und Cholera, das wird so bleiben. Der einzige Trost ist nur, beide laufen ultra stabil. Da kann man nicht meckern, zumindest wenn man aus den Quellen baut.

Antworten
1. 2021-01-05
  
  no one
  
  Stellt sich nur die Frage, unter welcher Lizenz der Quellcode veröffentlicht wird. Unter einer OpenSource-Lizenz muss das, gemäß der Vereinbarung mit KDE, afaik erst 1 Jahr nach Veröffentlichung passieren.
  Das kann nun also darauf hinauslaufen, dass KDE bzw. Distributionen die weiterhin quelloffenen Entwickler-Versionen nutzen oder Patches aus diesen selbst auf die letzte stabile Version zurückportieren müssen.
  
  Antworten
2021-01-05

Mandri Vator

Irgendwie müssten Miguel de Icaza und Federico Mena jetzt auftreten und äußern: Wir haben es euch ja gleich geagt. 🙂

Antworten
1. 2021-01-05
  
  Roadrunner_123
  
  Icazas Xamarin wurde von Microsoft gekauft. Sein Mono wird zum .Net Core und die API wird alle Nase lang geändert und inkompatibel. Man baut WinForms jetzt für Windows, Linux u. Mac OS nach.
  
  GUI-Frameworks:
  Microsofts WinForms stammt noch aus Windows XP-Zeiten und ist nicht mal HighDPI-fähig, obwohl MS das immer behauptet. Die Bugmeldungen sagen etwas anderes und ich hab es auch schon erleben dürfen. Jetzt, nach 13 Jahren kommt ein Update aus heiteren Himmel, obwohl vor es vor 2 Jahren hieß, die Entwicklung ist eingestellt.
  
  WPF ist für einen normalen User nicht mehr nutzbar, da die YAML-Dateien von Hand geschrieben werden müssen. Lösung: extra Tools kaufen für mehrere Hundert bis Tausend Euro im Jahresabo.
  Wie lange das Microsoft noch unterstütz, ist fraglich.
  
  WinUI ist eine durch eine Community getriebene Entwicklung von GUI-Elementen für Windows. Auch Microsoft macht dafür Werbung.
  
  Blazor soll auch für Desktopanwendungen herhalten können. Und hier frage ich mich, was will Microsoft noch alles. Sie mischen überall mit und alles ist nur halbgar. Nichts ist wirklich in einem stabilen und für Entwickler zuverlässig unterstützten Zustand.
  
  Durch den Verkauf von Xamarin hat Icaza nur dazu beigetragen, dass die Lage schlimmer wird.
  
  GTK lassen wir mal ganz aussen vor. Da fehlt es an C++-Support. Komplexe Anwendungen in C mit Callbacks schreiben ist nicht gerade der Traum.
  
  WxWidget fehlt es leider an Unterstützung.
  
  Qts Lösung wäre, wenn sie kleineren Firmen die Möglichkeit gäben eine Lizenz zu kaufen, bei der diese Firmen den Code auch bei Änderungen geschlossen halten können und statisch linken dürften. Support bekommen sie jedoch nur den, wie die Community: Forum)t – keine anderen Extras; auch ken LTS, als Abo.
  Es gäbe viele, die dann eine solche Lizenz kaufen würden und das würde Trolltech ein gewaltiges Grundrauschen in die Kassen spülen. Jedoch gibt es nur Cholera (richtig teure Lizenzen) und Pest (Community Edition mit jetzt verzögerten Support).
  
  Ja, ich weiss, dass es inzwischen eine Lizenz für wirklich kleine StartUps gibt, jedoch fehlt wie immer die Lizenz in der Mitte. Und die stellt die breite Masse dar; vielleicht nicht finanziell, jedoch sorgt die fürs Grundrauschen.
  
  Qt wird aber mehr und mehr in die embedded Schiene mit hohen Kosten gedrückt und das ist eine sehr einseitige Bewegung. Das wird denen mal zum Verhängnis.
  
  Im Grunde gibt es gerade kein Framework, mit dem ich eine neue Software mit einer gewissen längerfristigen Laufzeit (15 – 20 Jahre) beginnen möchte. Genau vor diesem Problem stehe ich in Kürze und weiß nicht, was ich empfehlen soll/kann/darf.
  
  Frank
  
  Antworten
  1. 2021-01-06
    
    kamome
    
    Ein Fork tut not!
    
    Antworten
  2. 2021-01-10
    
    2Cent
    
    WxWidget wird von Jahr zu Jahr besser. Und wenn jetzt Qt die Entwickler davon laufen, hat WxWidget gute Chancen noch eine bessere Unterstützung zu bekommen.
    
    Antworten
    1. 2021-01-17
      
      drema125
      
      Eher anders herum. Immer mehr Projekte verlassen aufgrund von Bugs wxWidgets und gehen zu Qt.
      
      Antworten
2021-01-05

tuxnix

KDE und Debian haben jetzt beide ein Qt6 Problem. Man sollte sich hier zusammentun und die Qt6 Pakete gemeinsam bauen.

Antworten
1. 2021-01-05
  
  Ferdinand
  
  …zudem Debian derzeit noch gar keine Maintainer für Qt 6 hat.
  
  Antworten
2. 2021-01-05
  
  Christopher
  
  Debian ist noch nicht einmal in der Lage KDE Pakte selbst zu bauen, die werden auf openSUSE’s openBuildservice gebaut.
  
  Antworten
  1. 2021-01-05
    
    Ferdinand
    
    In der Lage sind sie schon, ist aber zuletzt nicht erfolgt. Die Gründe hierfür liegen nicht im technischen Unvermögen, sondern hat persönliche Gründe.
    
    Antworten
2021-01-05

Bodiro

Mal ’ne ganz doofe Frage: Was genau an KDE ist denn QT? Nicht nur die „Tapete“, also, irgendwie das Aussehen? Oder auch Funktionalität? Wenn nur die „Tapete“, ist es da denn so schlimm, wenn es für 18 Monate bei dem Bestehenden bleibt?

Sorry, bin halt nur höchst zufriedener Nutzer von KDE-Plasma nach einer viele Jahre währenden Odysee über die Oberflächen (und Distris) und könnte mir im Moment nur Xfce als Alternative vorstellen, aber nur mit Schmerzen.

Antworten
1. 2021-01-05
  
  Stefan
  
  Schau Dir mal Budgie an: https://github.com/solus-project/budgie-desktop
  
  Antworten
2. 2021-01-05
  
  Hans K
  
  Der Fenster Manager von KDE ist schon mit Qt aufgebaut worden. Bei KDE und Projekte, die KDE Komponenten benutzen, dürfte sehr viel mit Qt verknüpft sein. Bis ein neues KDE von Distros übernommen wird, dauert das auch noch seine Zeit.
  
  Die Qt abhängigen Projekte dürfte sicher intern beraten, wie es mit denen weiter geht. Alternativen zu Qt gibt es nicht.
  
  Antworten
2021-01-05

Stefan

Jolla hat mit Sailfish und UBports mit Ubuntu Touch übrigens das gleiche Problem!

Antworten
2021-01-05

Christopher

Der „Erfolg“ von Qt basiert auf KDE (Programmierer lernen die ersten Schritte bei der Erstellung freier Software). Insofern ist die Entscheidung Qt’s nicht ganz nachvollziehbar. Delphi war auch einmal sehr populär und ist dann ganz plötzlich in der Versenkung verschwunden.

Antworten
1. 2021-01-05
  
  no one
  
  OpenSource-Entwickler sollen die non-LTS Versionen nutzen. Und für Anwendungen/Distributionen mit kurzem Lebenszyklus geht das prinzipiell auch, für andere wird es allerdings schwierig.
  
  Antworten
  1. 2021-01-10
    
    2Cent
    
    Distributionen brauchen aber die LTS Versionen um den Patchaufwand bezüglich Sicherheitsfixes gering zu halten. Bei so riesigen Projekten wie Qt fehlt nämlich ansonsten bei den Distris sehr schnell die Manpower.
    Das ist wie bei Browsern, da fehlt auch die Manpower für regelmäßige Sicherheitupdates, deswegen nutzen so gut wie alle Distris die ESR und LTS Versionen.
    
    Antworten
2021-01-12

Armakuni

Jetzt vergeht dann noch etwas Zeit und Microsoft kauft Qt. Immer wenn so fragwürdige Entscheidungen getroffen werden, geht es um nackte Zahlen. Insofern sollten sich Projekte wie KDE und Co. wirklich überlegen, ob sie weiter auf QT bauen wollen. Sicher ist eine Umstellung auf etwas wie wxWidgets oder was Anderes (oder was Eigenes? Woher kam denn Gtk?) ein großer Schritt. Aber letztlich ist es Unabhängigkeit, die es zu erhalten gäbe.

Vielleicht wird in 5 Jahren auch die nackte Console wieder hipp…

Antworten
1. 2021-01-17
  
  drema125
  
  Woher kam denn Gtk?) ein großer Schritt.
  
  Das war ein großer Schritt für Microsoft, ja.
  
  Antworten