Op de Qt-blog, de verantwoordelijke vice-president Petteri Holländer kondigt aan dat de langetermijnondersteuningseditie van Qt het is alleen inbegrepen in zakelijke licenties. Hetzelfde geldt voor het offline installatieprogramma.
Qt Company heeft een wijziging in zijn licentiemodel aangekondigd voor het Qt-framework, dat kan een aanzienlijke impact hebben op gemeenschappen en distributies die Qt gebruiken. Net zo vanaf versie 5.15, QTS LTS-branches zullen worden ondersteund tot de vorming van de volgende belangrijke versie, dat wil zeggen ongeveer een half jaar (updates voor LTS-versies worden voor drie jaar uitgebracht).
Volgens Petteri Holländer:
“De wijzigingen worden van kracht vanaf versie 5.15 LTS. Bovendien vereist de installatie van de binaire bestanden in de toekomst een Qt-account en deze nieuwe wijziging moet uiterlijk in februari worden toegepast "
Met het gebruikersaccount, Qt-groep, dat eigendom is van het bedrijf Digia, wil er zeker van zijn dat gebruikers gebruik maken van de diensten die via haar worden aangeboden.
Bovendien heeft volgens Holländer, open source gebruikers in het bijzonder zou met deze wijziging het product QtOfwel door middel van bugrapporten, codebeoordelingen of forumberichten. Tegelijkertijd opent het Qt-account ook de weg naar de Qt Marketplace, waar onder meer plug-ins worden uitgewisseld.
Deze stap moet de introductie van nieuwe versies van QT versnellen en zal het aantal bedrijven dat een commerciële Qt-licentie gebruikt aanzienlijk vergroten, waarvan de kosten $ 5508 per jaar per ontwikkelaar bedragen (terwijl voor startups en kleine bedrijven - $ 499 per jaar).
De veranderingen voor LTS-versie invloed hebben op de open source-gemeenschap sinds bij het toepassen van deze wijziging, ze krijgen alleen een release op patchniveau totdat de volgende kleine versie verschijnt.
Vanaf februari heeft iedereen, inclusief open source Qt-gebruikers, geldige Qt-accounts nodig om binaire Qt-pakketten te downloaden. We hebben dit gewijzigd omdat we van mening zijn dat u met een Qt-account optimaal gebruik kunt maken van onze services en kunt bijdragen aan Qt als open source-gebruiker.
We willen dat open source-gebruikers Qt op de een of andere manier helpen verbeteren, of het nu gaat om bugrapporten, forums, codebeoordelingen en dergelijke. Momenteel zijn ze alleen toegankelijk via een Qt-account, dus het hebben van een account is verplicht.
Terwijl aan de andere kant de ontwikkelaars van LTS-distributies (dwz met langdurige ondersteuning) zoals RHEL, Debian, Ubuntu, Linux Mint, SUSE en andere.
Ze zullen ertoe worden gedwongen stuur verouderde versies officieel niet ondersteund, port bug en kwetsbaarheden zelf opgelost of voortdurend updaten naar nieuwe significante versies van Qt, wat onwaarschijnlijk is aangezien dit kan leiden tot onvoorziene problemen in Qt-applicaties die in de distributie worden geleverd.
Misschien zal de gemeenschap de ondersteuning voor hun eigen Qt LTS-versies mede organiseren, onafhankelijk van Qt Company.
Het gedeeltelijk aanpassen van het licentiebeleid verzacht het feit dat Qt Company heeft beloofd alle fixes uit te voeren via de openbare repository waarop Qt is ontwikkeld.
De patches worden toegevoegd aan de ontwikkelingstak en overgebracht naar de takken met de laatste versies stabiel, wat hun extractie vereenvoudigt om over te zetten naar distributies.
Bovendien zijn de LTS-versies waarnaar Qt Company de correcties zal dragen, beperkt.
helaas, beleidswijzigingen met betrekking tot Qt ze zijn niet beperkt tot het wijzigen van de licentie en vanaf februari Iedereen die QT wil gebruiken, moet een account bij de service registreren Qt-account om de binaire Qt-bestanden te downloaden.
Deze stap wordt verklaard door de wens om bestandsdistributie te vereenvoudigen en integratie met Qt Marketplace te verzekeren.
Toegang tot Jira's bug-volgsysteem, review-interface en forums vereist ook een Qt-account, terwijl het ontwikkelings- en projectmanagementmodel hetzelfde blijft.
Terwijl ik las, vroeg ik me af waar dit alles in zou vertalen, aangezien Debian en anderen leveren met KDE en niet met LTS waarop patches worden toegepast. Ik begrijp niet helemaal hoe Qt zal worden gepolijst via een ander account dan om geld te verdienen met het ontwikkelingskader. Ik moet opnieuw lezen en zien hoe de gemeenschap reageert. Het klinkt niet als goed nieuws. Tussen systemd en Qt zijn er steeds meer punten om naar BSD te verhuizen.
En wat zullen zusterprojecten als LXQt denken ...
Ik zie het vanuit het perspectief van een bijdrage aan de gemeenschap, hoewel het feit dat nu een onafhankelijke ontwikkelaar bijna noodzakelijkerwijs moet betalen voor een licentie, daar niet op slaat.
Nu is het dwingen van distributieontwikkelaars om bij te dragen aan de ontwikkeling van QT iets dat lang moest gebeuren. Nou, aan het eind van de dag gebruiken ze een baan waarvoor verschillende mensen geld moeten uitgeven om het overeind te houden.
En dit deel is niet slecht, want het is een bijdrage om te behouden wat je gebruikt en wat ook helpt om je project te financieren. Sinds grote distributies zoals Debía, Ubuntu, Fedora, OpenSUSE, Linux Mint, onder anderen. Ontvang geld door donaties of door producten op te nemen waarmee ze worden gefinancierd.
En als deze distributies bijdragen met donaties aan deze projecten, is het een punt en apart, dat ze met elkaar moeten omgaan, omdat ze praktisch zullen zeggen: "Ok, ik ben niet van plan om een positie te betalen voor de ontwikkeling van uw product, maar we zal u donaties sturen om het te veranderen ”.
Dat is het geval met WebOS, haar nieuwe ontwikkelraamwerken voor onder meer de auto-industrie.
Tot zover goed, maar zoals ik in het begin al zei, betreft onafhankelijke ontwikkelaars ...
Ze moeten die focus zeker veranderen en ombuigen in een richting waarin iedereen een win-win heeft.
KDE zal naar GTK moeten gaan !!! Wat eigenlijk beter zou zijn.
«» Terwijl aan de andere kant de ontwikkelaars van LTS-distributies (dat wil zeggen met langdurige ondersteuning) zoals RHEL, Debian, Ubuntu, Linux Mint, SUSE onder anderen.
Ze zullen gedwongen worden om zelf officieel niet-ondersteunde verouderde versies, port bugs en kwetsbaarheidsfixes te verzenden, of constant updaten naar belangrijke nieuwe versies van Qt, wat onwaarschijnlijk is omdat dit kan leiden tot onvoorziene problemen in Qt-applicaties die in de distributie worden geleverd. »»
Daar is een punt.