Qt Company sluit broncode Qt 5.15 na verschijnen commerciële LTS-release

Qt Company sluit de Qt 5.15-branches voor nieuwe commits van opensource-ontwikkelaars. De sluiting valt samen met de release van Qt 5.15 LTS, een release die alleen beschikbaar komt voor betalende gebruikers van het applicatieframework.

De commerciële LTS-fase van Qt 5.15 is aangekondigd door Tuukka Turunen van Qt Company. "Alle bestaande 5.15-branches blijven publiekelijk zichtbaar, maar ze zijn gesloten voor nieuwe commits", meldt hij. Qt Company wordt daarmee verantwoordelijk voor verdere patches voor Qt 5.15 LTS. Die eerste Qt 5.15.3 LTS-patch staat op de planning voor februari en komt dus alleen beschikbaar voor betalende gebruikers.

Qt is een cross-platform applicatieframework en gebruikers kunnen de toolkit inzetten om interfaces en apps voor onder andere Android, Linux, macOS en Windows te ontwikkelen. De software heeft zijn oorsprong in Noorwegen, waar de ontwikkeling begin jaren negentig van de vorige eeuw werd gestart door Trolltech. In 2008 nam Nokia Qt over, maar in 2012 stootte Nokia het weer af. Sinds 2014 valt Qt onder Qt Company.

Ook niet-betalende opensource-ontwikkelaars hebben wel toegang tot Qt 6.0. Die volgende release van Qt 6.0 is sinds december beschikbaar, al volgt ondersteuning voor de meeste add-on-modules van Qt 5.15 pas met de release van Qt 6.2, zoals The Register aantekent. Qt 6.0 vereist een compiler die compatibel is met C++ 17 en bevat een nieuwe grafische architectuur, die minder afhankelijk is van OpenGL en standaard Direct3D op Windows en Metal op macOS gebruikt.

Opensource-ontwikkelaars tonen zich kritisch over de plannen, omdat Qt 6.0 vele add-ons nog niet ondersteunt en Qt 5.13 en Qt 5.14 niet meer ondersteund worden, wat risico's met zich meebrengt op het gebied van veiligheid. Enkelen bespreken de mogelijkheid van een fork van de 5.15-release, al is niet duidelijk of die plannen haalbaar zijn of toegestaan worden door Qt Company.

Dat bedrijf kondigde vorig jaar aan de LTS-releases van Qt exclusief voor commerciële gebruikers beschikbaar te maken. De reden is volgens het bedrijf dat inkomsten nodig zijn om Qt voor langere tijd stabiel te houden en nieuwe functies toe te voegen, iets waar opensource-ontwikkelaars volgens Qt ook baat bij hebben.

Update, donderdag, 10:30: Qt Company heeft opensourceontwikkelaars wel aangeboden om toegang te verlenen tot externe modulemaintainers van de commerciële repositories, maar in ieder geval Intel-software-architect Thiago Macieira meldt dat daar geen interesse voor is.

Reacties (85)

[himlims_]

loop al tijdje mee in opensource land, maar dit soort acties begrijp ik niet goed. (commericeel begrijp ik) maar hoe kan een reeds open en vrij systeem geprivatiseerd en gesloten worden? want is gewoon lgpl https://www1.qt.io/qt-licensing-terms/

[Eonfge]

wat @grasmanek94 zegt klopt deels, maar er ontbreekt een belangrijk ding: Qt eist namelijk dat als jij wilt bijdragen aan het project, dat ze jouw code onder MIT voorwaarden in handen krijgen:

https://www.qt.io/legal-contribution-agreement-qt

Dit is een klassieke CLA-trapdoor. Je maakt een project vrije software, maar je geeft jezelf een achterdeur waardoor je die voorwaarden op elk moment kunt aanpassen, ongeacht de GPL. Zie hier wat uitleg:

- https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
- https://www.finnegan.com/...open-source-projects.html
- https://opensource.com/article/19/2/cla-problems

Grote bedrijven die hier misbruik van maken zijn onder andere Google, Apple, Oracle, en Microsoft. Als je in meewerkt aan dit soort CLA constructies, moet je dus niet raar opkijken als de volgende versie van de software opeens niet meer FLOSS is.

Wijziging: Ik zei eerst 'Populaire' bedrijven... maar het moge duidelijk zijn dat dit soort juridische trucerij weinig populair is.

Nog een goede toevoeging: Dit ondermijnd het doel van de GPL zoals Stallman dat ooit heeft voorgesteld. Het idee van een (L)GPL project is namelijk dat iedereen via een juridische weg gedwongen kan worden om de vrijheid van anderen te respecteren. Dat Qt dus de GPL gebruikt naar anderen, maar niet naar zichzelf, is een doorn in het oog van vele fanatieke FLOSS gebruikers.

[Reactie gewijzigd door Eonfge op 22 juli 2024 18:22]

[Cergorach]

Qt company heette niet voor niets voorheen Trolltech... ;-)

[Eonfge]

Daar had ik nog niet eens over nagedacht

Wat ook leuk (of depressief) is om toe te voegen aan deze discussie: Qt is al langer bezig om FUD te verspreiden over de GPL, om zo meer klanten naar hun betaalde versie te jagen. Hier zijn ze in 2016 mee begonnen, en toen was er ook al veel kritiek vanuit het KDE project. KDE is 1 van de desktop projecten welke zich richten op Linux, en KDE is de grootste gebruikers van Qt's technologie, dus die leven op gespannen voet met elkaar.

Om nog maar wat zout in de wonden te wrijven: Hierom was het GNOME project gestart. KDE was 1 van de eerste desktop projecten voor Linux, maar dat draaide toen ook al op het gesloten Qt Framework. Andere ontwikkelaars maakte zich daar zorgen over en toen zijn ze GNOME begonnen.

[Cergorach]

Dat mensen zich 'zorgen' maakte in het copyleft open source project dat GNU Project is, is niet vreemd. De meeste copyright van de GNU Project projecten is van de Free Software Foundation (FSF), wat weer een non-profit is. Qt Framework is altijd van een commercieel bedrijf geweest, wat begon met Quasar Technologies. De licenties waaronder het beschikbaar was, is altijd een doorn in het ook van de FSF geweest: Qt Free Edition License (1995) en later de Q Public License (1999). Men begon echter al te werken aan GNOME in 1997.

Het is natuurlijk niet vreemd dat men vraagtekens zet bij een commercieel bedrijf op de lange termijn. Maar een non-profit 'foundation' is zeer zeker ook niet allemaal rozengeur en manenschijn. Zie bv. het gelazer van Mambo CMS, wat begon als closed source CMS en eindigde in een non-profit 'foundation' waarbij alle developers wegliepen... Wat uiteindelijk zorgde voor de fork Joomla! Wat imho juist een erg goed voorbeeld is van een fork.

[jimshatt]

Aan de andere kant kan het problematisch zijn om het niet te doen. De Linux kernel zit op GPLv2 gedeeltelijk omdat het onmogelijk is van alle bijdragers goedkeuring te krijgen om over te gaan op GPLv3.

De FSF verzoekt vriendelijk om copyright over te dragen zodat zij daardoor beter de voorwaarden kunnen afdwingen. Maar het hoeft niet op welk moment je voor jezelf moet opkomen als het nodig is. Lijkt me fair.

CLA's zijn echter niet de oplossing als je het mij vraagt.

[Eonfge]

De Linux kernel zit op GPLv2 gedeeltelijk omdat het onmogelijk is van alle bijdragers goedkeuring te krijgen om over te gaan op GPLv3.

Dat is niet helemaal accuraat. De GPL heeft namelijk een 'update'-clausule... alleen is die wel optioneel.

De Linux Kernel is gelicenceerd onder de GPL2.0-Only, dus dat betekend dat ze niet zomaar de licentie kunnen updaten naar GPL 3.0. Hier kun je de hele lijst vinden:
https://www.gnu.org/licenses/licenses.en.html

Andere projecten die iets meer vooruit denken, hebben wel de GPL2 geüpdatet naar de GPL 3 toen het daar tijd voor werd.

[Reactie gewijzigd door Eonfge op 22 juli 2024 18:22]

[jimshatt]

Dat klopt, Linux zit op GPLv2-only, en dat was een bewuste keuze. In die zin niet "problematisch" zoals ik zei maar precies zoals bedoeld.

Het gevolg is dat je van iedereen toestemming moet krijgen, of beter gezegd, dat je voor alle contributies die ooit onder GPLv2-only gemaakt zijn een nieuwe licentie moet ontvangen (maar ik gok dat het juridisch afdoende is om via een mail van iedereen toestemming te krijgen). Linus gaat zijn toestemming sowieso niet geven omdat hij problemen heeft met sommige clausules in GPLv3 dus daar houdt het al op, maar in principe kan iedere bijdrager roet in het eten gooien.

Mijn oorspronkelijke punt was dat als iedere bijdrager zijn copyright af zou staan aan Linus of The Linux Foundation of whatever, dan zou het een stuk makkelijker zijn voor Linus/TLF om Linux onder een andere licentie uit te brengen (indien hij dat zou willen). Dat heeft niet zoveel te maken met of er een update clausule of niet in de huidige licentie staat, als eigenaar van de code mag je ermee doen wat je wil.

[trapper]

[...]
Andere projecten die iets meer vooruit denken, hebben wel de GPL2 geüpdatet naar de GPL 3 toen het daar tijd voor werd.

De eerste versies van GPL v2 hadden geen upgrade clausule (en waren per definitie daarom GPL v2 only), dus kon (Linux) code uitgebracht onder die licence ook niet zomaar geupgrade worden naar GPL v3.
Latere versies van GPL v2 hadden een clausule waarin min of meer stond dat het ook onder een 'latere versie' van de GPL mocht worden gebruikt, deze is echter nooit voor kernel code gebruikt.

Bovendien blijkt uit discussies hierover dat Linus zelf (althans destijds) ook prima vondt, er bestond dus geen reden om moeite te steken om dit anders te gaan doen. Er werd dus wel degelijk over nagedacht.
Linus was (destijds althans) ook niet echt een voorstander van de GPL v3

[dec0de]

@Eonfge @trapper @jimshatt

Jullie vergeten by far de belangerijkste reden: linus torvalds vind de gpl v3 een K licentie, en weet ook dat linux niet meer zo succesvol zou blijven op gplv3 als op v2.

Bij gplv2 moet een fabrikant de sources beschikbaar maken, bij gplv3 niet alleen de sources, maar ook een manier om die source te compileren en flashen op een apparaat

[grasmanek94]

De eigenaar mag natuurlijk de licentie wijzigen. Dat in het verleden een bepaalde licentie gebruikt is, geldt alleen voor de oude code. Vanaf het moment dat de nieuwe licentie geldig is, is deze van toepassing op toekomstige code.
Verder is dual (multi-) licensing ook een mogelijkheid.

[himlims_]

in praktijk zie je vaak dat het project geforkt worde, een doorstart maakt. maar de huidige code is geklopt met licentie-x, wanneer die code overgaat naar een gesloten systeem, is dat toch tegen de huidige licentie voorwaarden in? bedoel als ik een commit heb gedaan op die code; is die vrij voor iedereen - maar daarna niet meer

[Reactie gewijzigd door himlims_ op 22 juli 2024 18:22]

[trapper]

maar de huidige code is geklopt met licentie-x, wanneer die code overgaat naar een gesloten systeem, is dat toch tegen de huidige licentie voorwaarden in?

Zoals eerder in de thread gemeld, code contributions worden alleen onder MIT license geaccepteerd, wat min of meer betekent dat het bedrijf er mee kan doen wat het wil (dus ook de license terms veranderen).
Blijft natuurlijk wel zo dat wanneer code gereleased is onder GPL v2 (of v3) ze die license niet meer kunnen 'afpakken'. M.a.w. het staat je vrij om te forken, en op de fork verder te gaan. (dat is dus bij Mambo / Joomla destijds gebeurd).
Qt Company heeft natuurlijk wel een punt, als zij de support en maintenance doen, moet dat wel ergens uit bekostigd worden. Ik kan me dus prima voorstellen dat ze dat onder commercial license doen. Open source community kan nog steeds hetzelfde doen, maar dan moeten er wel voldoende vrijwilligers zijn die daar tijd in willen stoppen.

[Blokker_1999]

Neen, dat is het helemaal niet. De release die onder LGPL is uitgebracht blijft onder die licentie gewoon beschikbaar. Daar kan men inderdaad niets aan veranderen. Maar nieuwe releases kunnen perfect door de eigenaar van de broncode onder een andere licentie uitgebracht worden, al zitten daar wel enkele mogelijkse pijnpunten aan vast.

Je moet namelijk kunnen aantonen dat het copyright van de volledige broncode in je bezit is of dat je van de eigenaar het recht hebt om die code onder een andere licentievorm uit te brengen. Er zijn vele FOSS projecten waarbij dit geregeld is door simpelweg mensen die een commit willen maken in de repo onmiddelijk hun toestemming te vragen om de code die ze indienen ook te mogen gebruiken onder commerciële, gesloten licenties. O.a. Canonical doet dit al jaren, en ook submits voor Android hebben het geloof ik.

Wat niet kan is dat ik bijvoorbeeld de brondocde zou nemen van iets onder GPL en die zou gebruiken om een eigen commercieel softwareproduct mee te gaan verkopen. Dat kan ik niet omdat ik de rechten niet bezit van die code.

[killercow]

Dus, de eerste beste klant die een gesloten versie van QT company koopt en er achter komt dat 99.99% van de code LGPL had moeten zijn maar het nu niet meer is kan concluderen dat de nieuwe release ook LGPL moet zijn en het dus vrij verspreiden?

[Blokker_1999]

Nee, QT is eigenaar van de code en mag een nieuwe versie perfect onder gesloten licentie uitbrengen. De klant heeft die licentie te respecteren. Bekijk het zoals een Oracle het doet met MySQL, daar is ook een gesloten, commerciële versie van. Of Canonical dat ooit Ubuntu op telefoons heeft uitgebracht met een gesloten licentie. Zolang jij eigenaar bent van de code of de nodige toestemming hebt verzameld van de eigenaars van die code mag jij gewoon het product onder gesloten licentie uitbrengen.

Als jij de gesloten versie afneemt en die staat niet toe dat je deze verzie zelf weer gaat verspreiden, dan mag je dat simpelweg niet doen.

[killercow]

Hm, zijn ze eigenaar van alle code dan? Alle commits tot nu toe lijken mij van de originele auteurs en niet van hen tenzij zij allemaal (vrij naïef) hun copyright aan het project/het bedrijf hebben gegeven.

[boudewijnrempt]

Er is een CLA, maar de belangrijkste factor als het over het open houden van Qt gaat heeft nog niemand genoemd: de KDE-FreeQt foundation: "Should The Qt Company discontinue the development of the Qt Free Edition under the required licenses, then the Foundation has the right to release Qt under a BSD-style license or under other open source licenses. The agreements stay valid in case of a buy-out, a merger or bankruptcy."

Maar goed, we hebben al vaker verandering meegemaakt in de vijfentwintig jaar dat Qt bestaat (en dat ik Qt gebruik), of er nu een community fork komt, of dat de Qt Company terugkrabbelt, het komt wel goed.

Overigens, Qt's wieg staat in Noorwegen, niet in Finland.

[Reactie gewijzigd door boudewijnrempt op 22 juli 2024 18:22]

[Anoniem: 63072]

Het hele systeem bouwt op de aanname dat niemand bereid is een fork van Qt door te ontwikkelen die steeds meer zal gaan divergeren van de commerciële variant. Een vrij robuuste aanname.

In theorie kan iemand natuurlijk wel besluiten een fork van LGPL Qt 5.15 te hosten en daar alleen security patches en bugfixes op te (laten) doen. Die bugfixes kunnen dan niet door Qt Company overgenomen worden in hun commerciële variant tenzij de auteur ze onder een dual license uitbrengt en de fork kan de bugfixes van Qt Company niet gebruiken ... tenzij deze bugfixes ook in de LGPL variant van Qt 6 terecht komen, waarna de fix onder de juiste licentie beschikbaar is en teruggeport kan worden.

Allemaal redelijk omslachtig en daarom verwacht ik niet dat iemand dat gaat doen.

[dec0de]

Nope, je bent verplicht je wijzigingen publiek te maken onder de MIT licentie voor het qt project. Dat staat in hun licentie, helaas.

[Anoniem: 63072]

Als je geen commerciële licentie hebt, heb je geen enkele verplichting dat te doen en kan je prima een wijziging alleen voor de LGPL versie maken.

Op dit moment wordt die echter door Qt company beheerd en zal niet geaccepteerd worden. De eerste persoon die dit doet zal dus zelf een form van de GPL code moeten (laten) hosten.

[jimshatt]

Dat hangt van het project af. Een van de redenen dat de Linux kernel nog GPLv2 is, is omdat het onmogelijk is om goedkeuring te krijgen van alle bijdragers, die het copyright op hun eigen code behouden. Aan de andere kant verzoekt de FSF om copyright over te dragen zodat zij de licentievoorwaarden makkelijker kunnen afdwingen, maar dit maakt het ook makkelijker om van licentie te veranderen.

In het geval van Qt blijft de bijdrage eigendom van de bijdrager, volgens https://www.qt.io/legal-contribution-agreement-qt, maar je geeft Qt gelijk ook een licentie om jouw code te gebruiken en te verspreiden. Daardoor mogen ze waarschijnlijk Qt onder meerdere licenties uitbrengen. En in dit geval dus een versie uitbrengen tegen betaling.

[Anoniem: 63072]

Heel slim dat auteursrecht jouw eigendom blijft. Er zijn namelijk landen waar je auteursrchten wettelijk helemaal niet kan overdragen. En dan is je overeenkomst opeens niet meer geldig, want dwingend recht gaat boven overeenkomst. Welke landen? Ik ken er in ieder geval één: Duitsland!

[sfranken]

En wat voor "straf" zit er op dit soort overschrijdingen? Geen, hooguit wat mensen die online "FOEI" roepen, en dat is het.

[Anoniem: 718943]

Als er iets tegen een licentie ingaat, dan kunnen er gewoon rechtszaken aangespannen worden, hoor. Zo'n licentie is geen suggestie of iets regelijks.
Moet een gedupeerde dat wel daadwerkelijk doen, natuurlijk.
(Geen idee of er ook daadwerkelijk tegen een licentie ingegaan wordt).

[Niet Henk]

Het leuke is: in principe is iedereen die toegang zou willen tot de code gedupeerd, dus kan iedereen zo'n rechtszaak aanspannen.

In de praktijk werkt dat enkel niet, omdat een rechtszaak veel hogere kosten meebrengt dan een licentie. Rechtszaken zijn voorbehouden aan incidenten die de aandacht van een stichting trekken, bijvoorbeeld de Free Software Foundation, die wel eens zaken wil starten tegen partijen die open source licenties schenden (bijvoorbeeld deze).

[sfranken]

Ik heb nog nooit gehoord dat dat gebeurd is. Ja, het kan, maar ik acht de kans zeer klein

[boschhd]

Geen idee of er in Nederland wat mee is gedaan, in Duitsland zijn er wel enige zaken over geweest.

[sfranken]

Ah, weer wat geleerd, dankje!

[disjfa]

Daarom is de 6.0 toch ook gewoon open. Dit regelt dat de doorontwikkeling van 5.x stopt. Als je deze open zou laten kan het zijn dat de 5.x zoals je aangeeft gewoon geforked word en de 6.0 genegeerd gaat worden. Maar ik ga er vanuit dat de makers de 6.x versie hebben bedacht om daar op verder te borduren.

Het is een leuke puzzel altijd, al de opties en licentiemodellen.

[LOTG]

Maar dat is toch niet het geval? Je kunt geen commits meer doen en alles wat jij gecommit hebt blijft open.

Volgens mij is het sluiten van commits hier de truc. Ze kunnen dus alleen hun eigen wijzigingen doen en die zijn niet open voor jou.

Ik ken de licentie structuur niet helemaal, maar volgens mij komt het er op neer dat er delen in verschillende licentie modellen zijn en dat ze dus gewoon de branches daar van niet publiek maken.

Alle nieuwe community toevoegingen moeten dus op de QT 6 branch gedaan worden.

[mpol]

Volgens de overeenkomst die een contributor afspreekt mag Qt Company de code van een contributor gebruiken voor GPL-code en ook voor commerciele code.
Het auteursrecht over de bijgedragen code blijft trouwens van de contributor.

Referentie:
https://www.qt.io/legal-contribution-agreement-qt

[The Zep Man]

De eigenaar mag natuurlijk de licentie wijzigen.

Niet als de code ook (L?)GPL code van andere auteurs bevat. Dan moet die eerst vervangen worden.

[Sebazzz]

Niet als de contributors een CLA hebben ondertekend waarmee ze afstand doen van hun rechten op de code. Bij contributies aan grote organisaties is zo'n CLA vrij gebruikelijk.

[Jogai]

Betaald open source, dus je krijgt de broncode netjes na betaling. Het recept bij je bier zeg maar, geen gratis bier.

[gvanvoor]

Bijkomende eigenaardigheid: Qt 6.0 bevat WebEngine niet (naar het schijnt pas gepland voor 6.2). Dus als je een applicatie hebt die WebEngine gebruikt zit je vast op 5.15.2 tot die 6.2 uitkomt (dat zou september zijn) en kan je geen ARM versie maken op macOS omdat die specifiek WebEngine niet bouwt op ARM.

[Gomez12]

Hoe bedoel je dat het geprivatiseerd en gesloten wordt?

Volgens mij verandert de licentie niet, alleen de main-repo die gooit publiekelijke commits dicht.
Volgens mij kan je nog steeds gewoon die main-repo klonen en forken als je zelf verder wilt gaan.
Alleen de main-devvers geven hiermee simpel een heel erg duidelijk signaal dat iedereen die van hun werk wil profiteren over moet gaan naar de nieuwe versie of het zelf maar moet uitzoeken.

[debroervanhenk]

Ik ben benieuwd hoeveel Qt nog wordt gebruikt, want ik heb het idee dat ik de afgelopen jaren steeds minder software zie die er gebruik van maakt. Deze beslissing klinkt ook een beetje als het voeren van een achterhoedegevecht om het bedrijf erachter in leven te houden.

[MadEgg]

Ik gebruik waar mogelijk software gebouwd op Qt. Crossplatform dezelfde ervaring en strak. Ermee ontwikkelen is ook zeer prettig (al is dat voor mij alweer wat jaartjes geleden). KDE / Plasma werkt er ook volledig mee zoals al opgemerkt door anderen. En veel embedded.

Als je zelf in een Gnome / Ubuntu-bubbel zit zal je het weinig tegenkomen inderdaad.

[sfranken]

Kijk naar KDE, dat is ~100% Qt. En daar gaat de ontwikkeling ook niet langzaam van, dus ik denk dat er nog wel wat gebruikers zijn.

[Blokker_1999]

Ik denk zelfs dat als er een fork komt van Qt, dat het het KDE project zal zijn dat hier een voortrekkersrol in zal spelen net omdat heel hun DE op Qt is gebouwd.

[dipje2]

Qt doet hele goede dingen en heeft altijd hele goede dingen gedaan. Het (rappe) tempo waarmee ze 5.x dus unmaintained maken is alleen nu het probleem. Niet dat ik het probleem daarmee probeer te verkleinen...

Maar er zit best wat mankracht achter de ontwikkeling van Qt, en als je gaat forken mag je dat allemaal zelf doen.

Juist een van de dingen die Qt voor mij altijd goed maakte is dat ze cross-platform niet alleen hebben in hun design, maar ook als doel en uitwerking. Op het moment dat Qt zegt 'we ondersteunen Windows', dan komen er builds for Windows, zijn er bugfixes en wordt er actief gewerkt aan native-integration en anderen. GTK is _jaren_ niet bruikbaar geweest onder Windows omdat er geen maintainer was! Je mocht het zelf gaan proberen te bouwen en als je problemen tegenkwam accepteerde ze wel PRs. Dat snap ik vanuit de FOSS wereld uitstekend, maar als je een commerciële applicatie wil bouwen heb je er dus geen fluit aan.

Omdat ze op deze manier ook het werk aan een Android-fork en een iOS-fork hebben omarmd, weet je ook zeker dat dat platform supported is _en blijft_ en er altijd gewoon tijdig nieuwe builds van komen. Je kan er - no pun intended - op bouwen.

Als ze het nu gaan forken, ben je dat kwijt. Dan moet je hopen dat je niet teveel gaat afwijken zodat je nieuwe wijzigingen aan Qt 6 kan meekrijgen...

... en dan praten we over Qt 6. Het probleem zit 'm juist in Qt 5.15 support. Dat kan je wel gaan forken, maar moet je zelf de bugfixes gaan doen die Qt nu achter de schermen voor geld doet. Ik denk dat je beter af bent door 'gewoon' rap naar Qt 6 over te gaan.

Ik vind het niet netjes van Qt hier, maar om gelijk te gaan forken lijkt me ook weer niet de oplossing.

Persoonlijk weet ik dat als je netjes op de deprecations hebt gelet, je code van 5.14 en 5.15 naar 6.0 super easy kan zijn. Maar ja, als je 3rd-party libraries en modules gebruikt die nog niet zover zijn moet je op 5.15 blijven die dus geen support zal hebben.

Het maakt het ook niet beter dat dus nog niet alles van Qt 5 (geloof ik) door Qt zelf nu al omgezet is naar Qt 6. Dat zijn de modules waar ze over praten die pas bij Qt 6.2 gaan komen. Daardoor verplichten ze mensen dus nog op 5.15 te blijven terwijl ze daar vervolgens geen (gratis) support op willen geven.

Qt 6 has been a very long time coming… maar ja, hij is pas final gegaan in December geloof ik.

Python2 mensen zijn (niet allemaal natuurlijk) ook aan het zeuren dat Python2 nu unsupported is, maar ja. Dat kan je ook al jaren (10+ jaar? ) aan zien komen en is netjes aangegeven... en er is een hele lang tijd van overlap geweest dat Python2 _en_ Python3 er waren zodat je kon migreren.
Dat is nu net wat Qt niet doet… het zat er al lang aan te komen, iedereen kon weten wat je moest gaan doen voor Qt 6... maar nu verplichten ze opeens iedereen om het in 3 weken maar even te doen .

[ATS]

Voor een fork is eigenlijk het opzetten van de CI een van de grootste obstakels. Dat is echt geen kattenpis, omdat er heel veel mogelijke configuraties zijn die doorgetest moeten worden.

Op zichzelf is het sluiten van LTS versies inderdaad begrijpelijk, maar de timing is hoogst ongelukkig omdat er geen bruikbaar alternatief is: een port naar 6.0 is voor veel software gewoon (nog) niet mogelijk omdat 6.0 gewoon incompleet is. Je kan gewoon niet beweren dat er een volwaardige opvolger is zoals 5.13 dat was voor 5.12 (de vorige LTS).

[ray0755]

Volgens mij wordt Qt ook veel gebruikt voor de besturingsdisplays in auto's, maar dat kan ik mis hebben.

[Heftytastic]

Klopt als een bus. Daarnaast wordt het ook gebruikt door een flink aantal airliners voor het entertainment systeem.

[Blokker_1999]

Al draaien die ook regelmatig gewoon op Android

[DataGhost]

Dat zegt nog helemaal niks over welk framework gebruikt wordt. Qt heeft gewoon Android targets om naartoe te builden.

[bzzzt]

Wordt door een paar automerken gebruikt: BMW, Honda, Hyundai, Jaguar / Land Rover, Mercedes, Nissan, Peugeot, Renault en Volvo.

[Immutable]

De GUI in een Tesla is Qt. en die is zeer geroemd.

[The Zep Man]

Ik ben benieuwd hoeveel Qt nog wordt gebruikt,

Ik denk voldoende, gezien het gebruik in KDE en embedded apparatuur. Ook zijn er zat programma's die het gebruiken, zoals VirtualBox, VLC en Wireshark.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:22]

[Anoniem: 368883]

Heel KDE is gebouwd op Qt?

En Qt wordt ook veel gebruikt voor GUI's op embedded systems. Het is misschien niet zo mainstream op de desktop-markt, maar er zijn heel wat sectoren waar ze nog steeds een grote naam zijn.

In 2109 draaide Qt company een omzet van 58.4 miljoen EUR, wat bewijst dat er wel degelijk nog genoeg bedrijven zijn die betalen voor de commerciele licentie van Qt.

Je kan gewoon ook zelf eens naar de cijfers kijken: https://investors.qt.io/financials

Het bedrijf in leven houden? Ik denk dat je eerst zelf de cijfers van een bedrijf raadpleegt alvorens uitspraken te doen.

[zyphr]

Paar voorbeelden:
- Telsa Model S
- LG (smart tv)
zie: https://en.wikipedia.org/wiki/Qt_(software)#Qt_in_use

[Anoniem: 718943]

Er zijn ook vrij veel cross-platform applicaties die het gebruiken.

https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt

[Gustaaf437]

Ik zie het nog wel eens voorbijkomen bij speciale tools met een beperkte doelgroep. Enkele cross-platform SQL-server utilities gebruiken Qt bijvoorbeeld.

[dipje2]

EA Origin? Dropbox?

De commerciële variant wordt ook best veel gebruikt in de app-wereld van Android + iOS (QtQuick / QML is leuk spul).

Qt is zo'n platform wat vaker gebruikt wordt dan je denkt, omdat je niet direct merkt waar het achter zit .

[ATS]

Het wordt heel, heel veel op embedded systemen gebruikt. Daar zijn niet zo heel veel volwaardige alternatieven voor.

[Immutable]

Denk aan Kiosk systemen. Heel veel systemen die ik tegenkom overal als embedded. Zo kwam ik laatst in de Gamma en heb je daar zo'n bestelzuil. Het virtual toetsenbord kwam tevoorschijn, en ik dacht ja hoor!! Een standaard Qt virtual keyboard, met een QtWebEngine die HTML serveert.
Qt zit in allerlei embedded systemen, koffiezet apparaten, koelkasten, setup boxen en noem het maar op. Het wordt veel meer gebruikt dan je denkt, je komt het echt overal tegen.

[janbaarda]

Daarom ben ik blij dat Ubuntu, Purism en vele anderen Gnome gebruiken.

[ray0755]

Gnome is op iedere distro te installeren, dat is het probleem niet. Het zou jammer zijn als DE's als KDE Plasma en LXQT hierdoor getroffen worden. Persoonlijk vind ik Gnome verschrikkelijk (uiteraard is er ook nog XFCE als Gnome-alternatief).

[Anoniem: 718943]

Ben zelf wel een fan van Cinnamon; De mogelijkheden van Gnome3 (ipv Gnome2, wat XFCE doet), met het resourcegebruik van XFCE.

[sfranken]

(ipv Gnome2, wat XFCE doet),

Je bedoelt de mate desktop denk ik, niet XFCE. XFCE is echt een eigen identiteit

[GekkePrutser]

Gelukkig is KDE ook allang bezig aan een versie gebaseerd op Qt 6.0!

https://blog.neon.kde.org...e-qt-6-package-available/

Hoop wel dat het snel komt.

[ATS]

Nou, een versie gebaseerd op 6.x komt er vast wel, maar niet op basis van 6.0. 6.0 is gewoon niet compleet. Uiteraard is er wel begonnen met porten van wat er al geport kan worden.

[GekkePrutser]

Ah dat wist ik niet.

Ik ben een fan geworden van KDE, omdat Gnome me teveel "Mac" is geworden. Steeds minder instellingen, alles moet weggehaald worden en achter on/off slidertjes verstopt.. Precies wat me op Mac ook irriteert.

Toen een keer KDE geprobeerd dat ik in de tijd pre-plasma visueel te 'druk' vond en te veel op Windows lijken. Maar nu is het precies wat ik zocht!

[mocem]

Bij Ubuntu betaal je ook voor extended support. Wat ik mis in het artikel hoe oud is 5.15 en hoelang is versie 6 beschikbaar. Indien versie 6 al jaren beschikbaar is kan je dit zien als extended support op slinkse manier.

[ATS]

6 is net uit. 5.15 is nu een half jaar uit ongeveer.

[Brent]

GTK is in vele opzichten beperkter, buggier en sinds een paar jaar ook zwaarder om te draaien. Om het over cross-platform dev maar niet te hebben.

[Immutable]

Maar wel geschreven in C, waardoor het beter te implementeren is in andere talen. Dat is het nadeel van C++. Het werkt niet zo lekker samen met andere talen.
Het mooie aan Rust is weer, dat Rust dat wel dus weer doet. Daarom zou een compleet GUI framework op basis van Rust echt uitermate goed zijn. Binnen GTK wordt Rust ook zeer goed ontvangen, en bij QT dus helemaal NIET. In de Linux kernel wordt Rust ook beter ontvangen dan C++. Dat heeft allemaal te maken met het beter samenwerken tussen verschillende talen, wat bij Rust een veel belangrijkere topic was dan bij C++. Qt doet dan ook niks aan Rust, en wanneer GTK bijvoorbeeld helemaal overgezet zou worden naar Rust en wat modernere renderpipelines zou gebruiken zodat moderne interfaces makkelijk zouden maken, ook voor embedded systemen. Dat zie ik Qt nog wel eens ingeruild zien worden voor Rust + XXX Gui framework wat wel beter samenwerkt met andere talen.

[ATS]

Er zijn nochtans best een hoop bindings voor beschikbaar. Zowel officieel ondersteund (Python) en 3rd party. Of bedoelde je dat niet?

[Immutable]

Ja er zijn wel wat. Maar C++ maakt het niet makkelijk om zoiets op te zetten. C wel, en Rust ook.
Maar zijn er ook echt veel C libraries / bindings geschreven in C++?

[Blokker_1999]

Je bedoelt Ubuntu waarbij Canonical aan contributers laat weten dat als zij een bijdrage leveren dat Canonical deze ook mag gebruiken in commerciële applicaties en dat hun code niet noodzakelijk enkel voor FOSS zal gebruikt worden...

[CopyCatz]

Misschien een kleine inleiding op wat QT is zou wel handig zijn. Ben er zelf enorm fan van, maar uit dit artikel kun je verder niet opmaken over wat voor soort software het gaat .

[Knielen]

Ik citeer uit het artikel:

Qt is een cross-platform applicatieframework en gebruikers kunnen de toolkit inzetten om interfaces en apps voor onder andere Android, Linux, macOS en Windows te ontwikkelen.

[Anoniem: 454358]

Dat stond er in het begin alleen niet. Die alinea is later toegevoegd

[Reactie gewijzigd door Anoniem: 454358 op 22 juli 2024 18:22]

[Knielen]

Aah okay, de boefjes.

[Anoniem: 454358]

Inderdaad, ik had werkelijk geen idee, ik dacht eerst nog even aan quick time 🙂

[ATS]

Dat is niet zo gek als "fan" @CopyCatz het al als QT ipv Qt schrijft...

[ATS]

Zeker mag je dat zelf uitmaken, en dat doe je ook:

Misschien een kleine inleiding op wat QT is zou wel handig zijn. Ben er zelf enorm fan van, maar uit dit artikel kun je verder niet opmaken over wat voor soort software het gaat .

Ik vind het gewoon vreemd dat een zelfverklaard fan Qt verkeerd schrijft.

[Exirion]

We zitten hier wel op Tweakers he. Voor wie het relevant is, is het duidelijk. Voor de rest het artikel toch al niet interessant.

[nvaert1986]

Dit is zeker wel relevant voor velen. Er zijn ook veel Open Source projecten die gebruik maken van Qt en bepaalde versies kunnen vereisen om succesvol te compileren. Dit geldt ook voor de voorverpakte binaire DEB en / of RPM bestanden die door veel distributies gebruikt worden, waar dit dus ook weer van invloed op is.

Tevens maak ik bijv. gebruik van een KDE desktop en compileer mijn packages zelf (Gentoo). Dus ook daarvoor is het relevant

[Exirion]

Zoals ik zei: wie hier mee te maken heeft, weet heus al wat Qt is.

[amx]

Compleet offtopic, maar hopelijk komt nu eindelijk een einde aan Youtube videos over QT waar de presentator de kijker aanleert dat QT uitgesproken moet worden als Cutie.

[ATS]

Grappig. Zeuren over de uitspraak van Qt ("Cue-tee" vs "Cute") en dan de schrijfwijze verkeerd doen ("QT" vs "Qt").

[goarilla]

Kak. Dit is toch wel het 2de serieuze slechte OSS bericht deze week.
Het eerste was dat IBM CentOS (rebuild downstream van RH) gaat vervangen met CentOS Stream (een rolling release upstream voor RH).