La Qt Company en manque de liquidités
Les prochaines versions de Qt pourraient n'être disponibles sous licence libre que dans les 12 mois, la communauté n'acceptera pas
Le 2020-04-08 21:11:10, par dourouc05, Responsable Qt & Livres
La Qt Company en manque de liquidités : les prochaines versions de Qt pourraient n’être disponibles sous licence libre que dans les 12 mois
La Qt Company est la société qui possède actuellement Qt et qui se charge de la majorité du développement de la bibliothèque, mais aussi de la vente de licences commerciales. Ces derniers temps, on dirait que la société ne se porte pas des mieux, avec notamment une restriction pour la maintenance des versions LTS : les mises à jour correctives ne seront plus disponibles que pour les clients commerciaux ; ceux qui utilisent une version libre de Qt sont priés de passer à une version mineure plus récente. Par exemple, pour Qt 5.15, seules les quelques premières mises à jour correctives seront disponibles sous licence libre : on ne verra pas d’équivalent de Qt 5.12.8, qui marque pourtant une très grande stabilité.
Ce n’est pas tout.
Qt et KDE sont très liés : si Qt n’est plus disponible sous licence libre, c’est presque la fin de KDE. C’est la raison d’être de la fondation KDE Free Qt, créée en 1998 : si la dernière version de Qt n’est pas disponible sous licence libre dans les douze mois, tout le code libre de Qt passe sous licence BSD (une licence très peu contraignante), pour garantir la survie du projet KDE. Grâce à cet accord, les développeurs de KDE contribuent très régulièrement au code de Qt.
En permanence, la communauté KDE et la société derrière Qt (Trolltech, Nokia, Digia, Qt Company, selon l’époque) négocient des petits changements dans les accords de la KDE Free Qt, mais toujours de commun accord. Par exemple, quand Qt est racheté, il faut les modifier ; pour ajouter une licence pour certaines parties de Qt, il faut aussi changer cet accord.
Ces derniers temps, les demandes de la Qt Company se font plus pressantes pour améliorer la valorisation économique de Qt. D’un côté, ils cherchent un accord pour gérer les incompatibilités de licence entre les clients qui utilisent une licence commerciale, mais publient du code utilisant Qt sous licence libre (comme KDAB). Ce point doit effectivement être résolu avant que des litiges n’apparaissent. D’un autre côté, avec la crise actuelle liée à la pandémie de COVID-19, les finances de la Qt Company ne sont pas au beau fixe et l’entreprise a besoin de rentrées d’argent à court terme. C’est pour cela qu’elle cherche à exploiter l’accord actuel au maximum, en repoussant les sorties sous licence libre de douze mois : l’objectif est d’inciter les utilisateurs de Qt à ouvrir le porte-feuille et à acheter une licence commerciale.
Cependant, bien qu’autorisée, cette pratique signifierait probablement un grand changement dans la gouvernance de Qt. En effet, depuis des années, toutes les décisions techniques sont prises en public, tout le monde peut y participer. Les mainteneurs de module (qui valident ou non les ajouts de code) ne font pas forcément partie de la Qt Company. Si les versions libres venaient à être restreintes, ce modèle de gouvernance tomberait à l’eau, puisque le pouvoir reviendrait presque exclusivement à la Qt Company. Les contributeurs se demandent aussi comment les choses pourraient évoluer, mais sont d’accord sur le fait qu’il ne leur serait plus possible de contribuer à Qt (qu’il s’agisse d’un projet libre comme KDE ou d’une société comme KDAB — de l’avis de représentants officiels, des deux côtés), chose que la Qt Company semble avoir acceptée.
Pendant ce temps, la décision concernant les versions LTS annoncée en janvier n’avait pas été discutée au sein de la fondation KDE Free Qt. On peut aussi remarquer que, depuis l’annonce officielle, les questions en suspens restent sans réponse. Notamment, qu’adviendra-t-il des correctifs de sécurité ? Seront-ils partagés avec les distributions Linux (qui sont généralement frileuses à faire une grosse mise à jour de Qt) ?
Il semblerait que ces décisions sur les versions LTS ou sur le retard des versions libres serve surtout de moyen de pression pour obtenir des concessions de la part du projet KDE dans le cadre de la fondation KDE Free Qt : selon Olaf Schmidt-Wischhöfer, un des deux représentants de KDE dans la fondation, la Qt Company a explicitement indiqué qu’elle pourrait faire marche arrière sur ces deux dossiers à condition d’obtenir des concessions importantes (faciliter la vente de logiciels en même temps que Qt ou l’intégration avec des logiciels propriétaires tiers). L’objectif est bien d’augmenter les revenus de l’entreprise, sans grande considération pour le projet libre qu’est KDE. Cette situation est entièrement opposée aux habitudes de négociation, où l’objectif était d’augmenter les revenus commerciaux sans porter préjudice au projet libre.
Si la Qt Company ne change pas d’avis sur le dossier, les clauses de l’accord KDE Free Qt ne pourront a priori pas être activées, mais cela incitera très fortement les parties prenantes à créer un fork du projet Qt. Certes, KDE n’estime pas avoir les ressources nécessaires pour y arriver, mais KDAB et probablement d’autres sociétés seraient intéressées par un tel mouvement.
Source : les points de vue de KDE et KDAB.
Que pensez-vous de la volonté (unilatérale) de la Qt Company de détruire le modèle de gouvernance libre de Qt ?
Qu'est-ce qui changerait pour vous en cas de fork de Qt ?
Avec un tel fork, les forums de Developpez devraient-ils changer de nom pour ne plus faire référence qu'au fork et plus à Qt ?
La Qt Company est la société qui possède actuellement Qt et qui se charge de la majorité du développement de la bibliothèque, mais aussi de la vente de licences commerciales. Ces derniers temps, on dirait que la société ne se porte pas des mieux, avec notamment une restriction pour la maintenance des versions LTS : les mises à jour correctives ne seront plus disponibles que pour les clients commerciaux ; ceux qui utilisent une version libre de Qt sont priés de passer à une version mineure plus récente. Par exemple, pour Qt 5.15, seules les quelques premières mises à jour correctives seront disponibles sous licence libre : on ne verra pas d’équivalent de Qt 5.12.8, qui marque pourtant une très grande stabilité.
Ce n’est pas tout.
Qt et KDE sont très liés : si Qt n’est plus disponible sous licence libre, c’est presque la fin de KDE. C’est la raison d’être de la fondation KDE Free Qt, créée en 1998 : si la dernière version de Qt n’est pas disponible sous licence libre dans les douze mois, tout le code libre de Qt passe sous licence BSD (une licence très peu contraignante), pour garantir la survie du projet KDE. Grâce à cet accord, les développeurs de KDE contribuent très régulièrement au code de Qt.
En permanence, la communauté KDE et la société derrière Qt (Trolltech, Nokia, Digia, Qt Company, selon l’époque) négocient des petits changements dans les accords de la KDE Free Qt, mais toujours de commun accord. Par exemple, quand Qt est racheté, il faut les modifier ; pour ajouter une licence pour certaines parties de Qt, il faut aussi changer cet accord.
Ces derniers temps, les demandes de la Qt Company se font plus pressantes pour améliorer la valorisation économique de Qt. D’un côté, ils cherchent un accord pour gérer les incompatibilités de licence entre les clients qui utilisent une licence commerciale, mais publient du code utilisant Qt sous licence libre (comme KDAB). Ce point doit effectivement être résolu avant que des litiges n’apparaissent. D’un autre côté, avec la crise actuelle liée à la pandémie de COVID-19, les finances de la Qt Company ne sont pas au beau fixe et l’entreprise a besoin de rentrées d’argent à court terme. C’est pour cela qu’elle cherche à exploiter l’accord actuel au maximum, en repoussant les sorties sous licence libre de douze mois : l’objectif est d’inciter les utilisateurs de Qt à ouvrir le porte-feuille et à acheter une licence commerciale.
Cependant, bien qu’autorisée, cette pratique signifierait probablement un grand changement dans la gouvernance de Qt. En effet, depuis des années, toutes les décisions techniques sont prises en public, tout le monde peut y participer. Les mainteneurs de module (qui valident ou non les ajouts de code) ne font pas forcément partie de la Qt Company. Si les versions libres venaient à être restreintes, ce modèle de gouvernance tomberait à l’eau, puisque le pouvoir reviendrait presque exclusivement à la Qt Company. Les contributeurs se demandent aussi comment les choses pourraient évoluer, mais sont d’accord sur le fait qu’il ne leur serait plus possible de contribuer à Qt (qu’il s’agisse d’un projet libre comme KDE ou d’une société comme KDAB — de l’avis de représentants officiels, des deux côtés), chose que la Qt Company semble avoir acceptée.
Pendant ce temps, la décision concernant les versions LTS annoncée en janvier n’avait pas été discutée au sein de la fondation KDE Free Qt. On peut aussi remarquer que, depuis l’annonce officielle, les questions en suspens restent sans réponse. Notamment, qu’adviendra-t-il des correctifs de sécurité ? Seront-ils partagés avec les distributions Linux (qui sont généralement frileuses à faire une grosse mise à jour de Qt) ?
Il semblerait que ces décisions sur les versions LTS ou sur le retard des versions libres serve surtout de moyen de pression pour obtenir des concessions de la part du projet KDE dans le cadre de la fondation KDE Free Qt : selon Olaf Schmidt-Wischhöfer, un des deux représentants de KDE dans la fondation, la Qt Company a explicitement indiqué qu’elle pourrait faire marche arrière sur ces deux dossiers à condition d’obtenir des concessions importantes (faciliter la vente de logiciels en même temps que Qt ou l’intégration avec des logiciels propriétaires tiers). L’objectif est bien d’augmenter les revenus de l’entreprise, sans grande considération pour le projet libre qu’est KDE. Cette situation est entièrement opposée aux habitudes de négociation, où l’objectif était d’augmenter les revenus commerciaux sans porter préjudice au projet libre.
Si la Qt Company ne change pas d’avis sur le dossier, les clauses de l’accord KDE Free Qt ne pourront a priori pas être activées, mais cela incitera très fortement les parties prenantes à créer un fork du projet Qt. Certes, KDE n’estime pas avoir les ressources nécessaires pour y arriver, mais KDAB et probablement d’autres sociétés seraient intéressées par un tel mouvement.
Source : les points de vue de KDE et KDAB.
-
LittleWhiteResponsable 2D/3D/JeuxBonjour,
Je ne pensais pas qu'une société pouvait faire en sorte de prendre contrôle d'un projet open source et de forcer les gens a payé pour celui-ci. Je ne pensais pas non plus qu'une société pouvait monopoliser un tel projet et l'enterrer au passage.
Pour les distributions Linux (et les correctifs), je pense que les mainteneurs des paquets vont commencer à compiler Qt à partir des sources (d'ailleurs, c'est peut être déjà le cas). En réalité, comme le projet est open source, est-ce que les décisions de la Qt Foundation ont vraiment un impact ? Ils font juste un accès payant à leur binaire, mais rien n'empêche quelqu'un de fournir des binaires. D'ailleurs, Developpez.com pourrait faire en sorte de compiler les binaires et les fournir, non ? (Cela a été fait à une époque). le 09/04/2020 à 7:47 -
archqtMembre émériteOui et non, car, à part firemonkey d'embarcadero qui reprend un truc similaire je crois, tous les autres systèmes d'UI sont basés sur des widgets. QML est juste une façon de décrire les interfaces qui obligent le programme a bien séparé la logique métier de la logique UI.
Ensuite ils ont rajouté des programmes pour gérer les animations et fournir les informations d'animations pour que cela se fasse automatiquement.
La grosse force pour moi c'est ça : les outils qui évitent de devoir coder à la main la création de l'UI avec une bonne intégration à l'IDE.
Et côté "libre", style glade pour GTK, wxFormBuilder pour wxWidgets ou pire pour flutter de google y a rien, l'intégration entre UI et IDE n'est pas top. Avec QtCreator tout est "autonatique". En GTK il faut se farcir la récupération des pointeurs des widgets, et relier cela après aux "call-backs",
Ah pardon Delphi faisait cela très bien avant, Lazarus aussi mais ce n'est pas du C++ (dommage) même si Pascal est un excellent langage.le 12/04/2020 à 10:45 -
dourouc05Responsable Qt & LivresLa différence avec XUL, c'est que presque tout Qt Quick pourrait être écrit en QML (si ça ne l'est pas, c'est pour des raisons de performance). Qt Quick n'est vraiment pas limité à un ensemble de widgets. (Par contre, la comparaison avec Qt Designer tient beaucoup plus la route.)
Dans les systèmes plus ou moins équivalents à Qt Quick et QML, il y a XAML, syntaxiquement beaucoup plus lourd.
Sinon, Qt Widgets devrait évoluer avec Qt 6, surtout au niveau du rendu, pour profiter de RHI (abstraction des API de rendu). Fonctionnellement, ça ne devrait pas être une révolution…le 12/04/2020 à 19:24 -
dourouc05Responsable Qt & LivresC'est sûr que le côté multiplateforme en prendrait un coup : ce n'est clairement pas l'objectif de KDE (à peine quelques applications disponibles pour Windows ou macOS : https://community.kde.org/Mac et https://community.kde.org/Windows) ; KDAB semble plutôt orienté vers l'embarqué (pas forcément Linux, donc). Ça m'étonnerait que, dans ce cas, ils saquent dedans, mais la compatibilité risque de pourrir et de finir par être supprimée parce que personne n'avait remarqué que ça ne fonctionnait plus depuis des années…le 09/04/2020 à 2:23
-
chrtopheResponsable Systèmessi le projet devient complètement libre, va t-il survivre ?
Les développeurs doivent bien gagner leur vie. Le bénévolat pur n'est pas suffisant pour des projets d'une telle envergure. Il faut donc des entités commerciales qui font dons soit de financements soit de temps offerts à leur salariés pour contribuer aux projets. Les entités commerciales utilisant l'opensource ça peut être gagnant-gagnant.le 09/04/2020 à 11:17 -
grunkModérateurNiveau UI y'a quand même pas beaucoup d'alternative de qualité malheureusement. Nous on à fait le choix de n'absolument pas utiliser QT pour le core de l'application , tout est fait en C++ standard ou avec boost pour ce qui n'est pas encore parfaitement supporté en cross plateform (les socket par exemple).
Et franchement à aucun moment on s'est dit qu'on aurait mieux fait de faire du QT. Par contre pour l'UI en QML on regrette pas ...le 09/04/2020 à 11:33 -
archqtMembre émériteA condition que le licence soit du style MIT, BSD pour permettre facilement l'utilisation en commercial/close sourcele 09/04/2020 à 19:01
-
balilooMembre régulierBonsoir, c'est juste une ancienne version du Qt, ce qui fait la force de Qt d'aujourd'hui c'est pas vraiment le Qt Widgets, mais plutot sa nouvelle orientation vers le QML et QtQuick
, le developpement du module Qt Widgets est stagné depuis un bon moment. le 12/04/2020 à 2:03 -
chrtopheResponsable Systèmes
Je ne pensais pas qu'une société pouvait faire en sorte de prendre contrôle d'un projet open sourceQue pensez-vous de la volonté (unilatérale) de la Qt Company de détruire le modèle de gouvernance libre de Qt ?Qu'est-ce qui changerait pour vous en cas de fork de Qt ?
Selon le fork ça pourrait amener la disparition à terme de Kde ou de Qt Company selon le suivi du fork par les plus gros développeurs.Avec un tel fork, les forums de Developpez devraient-ils changer de nom pour ne plus faire référence qu'au fork et plus à Qt ?le 09/04/2020 à 9:32 -
LittleWhiteResponsable 2D/3D/JeuxJ'y ai pensé, mais je ne trouve pas que les cas sont comparables. Pour moi, lorsque Oracle a pris possession du projet, les développeurs ont quitté le projet, car Oracle c'est le mal (et c'est le mal pour l'open source). Du coup, OpenOffice a été forké et abandonné.
Ici, la société est là depuis plusieurs années, elle ne semblait pas "evil" et menait le projet dans un certain sens (bon ou mauvais, à chacun de juger), mais pas nécessairement contre l'essence du projet, ni l'open source. Maintenant, aujourd'hui, la société "change" de face et me semble emprisonner le projet open source (à tel point, que j'ai l'impression que le projet n'est plus open source :aie).le 09/04/2020 à 9:41