LINUX.ORG.RU

Qt Company объявила о изменении модели лицензирования фреймворка Qt

 ,


1

3

Официальное заявление от Qt Project

Чтобы поддерживать непрерывный рост, необходимый для сохранения актуальности Qt как платформы разработки, Qt Company считает необходимым внести некоторые изменения:

  • Для установки бинарных файлов Qt потребуется учетная запись Qt
  • Выпуски с долгосрочной поддержкой (LTS) и offline-установщик станут доступны только для коммерческих лицензиатов
  • Появится новое предложение Qt для стартапов и малого бизнеса за 499$ в год

Эти изменения не окажут никакого влияния на существующие коммерческие лицензии.

Про учетную запись

С тех пор, как была введена учетная запись Qt, количество зарегистрированных пользователей Qt неуклонно растет, и сегодня достигает уже почти миллиона.

Начиная с февраля, всем, включая пользователей Qt использующих версии с открытым исходным кодом, потребуются учетные записи Qt для загрузки бинарных пакетов Qt. Это нужно для возможности наилучшим образом использовать различные сервисы, а так же для возможности пользователям с открытым исходным кодом помочь улучшить Qt в той или иной форме, будь то с помощью отчетов об ошибках, форумов, обзоров кода или тому подобного. В настоящее время все это доступно только из учетной записи Qt, поэтому ее наличие станет обязательным.

Учетная запись Qt также предоставляет пользователям доступ к Qt Marketplace, который предлагает возможности приобретать и распространять плагины для всей экосистемы Qt с одной централизованной платформы.

Это также позволит Qt Company наладить связь с коммерческими компаниями, которые в основном работают с open-source версиями Qt.

Обратите внимание, что исходники по-прежнему будут доступны без учетной записи Qt!

LTS версии и offline-установщик станут коммерческими

Начиная с Qt 5.15, долгосрочная поддержка (LTS) будет доступна только для коммерческих версий. Это означает, что пользователи с open-source версией будут получать версии исправлений 5.15 до тех пор, пока не станет доступен следующий дополнительный выпуск.

Qt Company вносит это изменение, чтобы поощрять пользователей с open-source версией быстро внедрять новые версии. Это помогает наладить обратную связь, которую Qt Company может получить от сообщества, и улучшить поддержку LTS версий.

Релизы LTS поддерживаются и работают в течение более длительного периода времени с целью обеспечения стабильности. Это делает выпуски LTS идеальным выбором для компаний, чья жизнедеятельность основана на конкретном выпуске и они полагаются на него в течение длительного времени в соответствие с ожиданиями. Дополнительными преимуществами являются первоклассная поддержка, эксклюзивные инструменты разработки, полезные компоненты и инструменты сборки, которые сокращают время выхода на рынок.

Основные выпуски за пределами LTS-версий, включающие новые функции, технические обзоры и так далее, будут доступны для всех пользователей.

Offline-установщик также станет только коммерческим. Было установлено, что эта функция весьма полезна компаниям, что позволяет сделать коммерческие лицензии более привлекательными для предприятий без существенных неудобств для пользователей с open-source версией.

Заключение

Qt Company привержена Open Source’у сейчас и в будущем, в него инвестируются сейчас больше, чем когда-либо. Qt Company считает, что эти изменения необходимы для их бизнес-модели и экосистемы Qt в целом. Роль сообщества все еще очень важна, и Qt Company хочет убедиться, что еще в силах инвестировать в него. Qt Company намерены сделать платную версию Qt более привлекательной для бизнеса, и в то же время не отнимать у пользователей бесплатной версии основные функциональные возможности. Доход от коммерческих лицензий идет на улучшение Qt для всех, включая пользователей с open-source версиями. Итак, хотя вы можете или не можете потерять небольшое удобство в краткосрочной перспективе, Qt Company хочет, чтобы все выиграли в долгосрочной перспективе!

Дополнение

На OpenNet озвучили следующую проблему, связанную с тем что LTS выпуски больше не будут присутствовать в open-source версии, а так же ее возможное решение:

Разработчики дистрибутивов, имеющих длительные сроки поддержки (RHEL, Debian, Ubuntu, Linux Mint, SUSE) будут вынуждены либо поставлять устаревшие официально не поддерживаемые выпуски, самостоятельно портируя исправления ошибок и уязвимостей, либо постоянно обновляться на новые значительные версии Qt, что маловероятно, так как может потянуть за собой непредвиденные проблемы в поставляемых в дистрибутиве Qt-приложениях. Возможно сообществом сообща будет организована поддержка собственных LTS-веток Qt, не зависящих от Qt Company.

>>> Подробности



Проверено: anonymous_incognito ()
Последнее исправление: a1batross (всего исправлений: 6)

Ответ на: комментарий от RazrFalcon

На Linux, gtk считается дефолтом, а qt/kde аппликухи очень часть выглядят как инородные элементы (знаю, что настраиваются, но с бубном и не все). На винде у qt закос под натив таки получше будет из коробки.

Linfan ★★★★★
()

Обратите внимание, что исходники по-прежнему будут доступны без учетной записи Qt!

Не вижу проблем. Только вендузятникам станет хуже, но нет проблемы завести автосборку всено этого силами сообщества.

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от Linfan

На винде у qt закос под натив таки получше будет из коробки.

Так GTK-team с самого начала говорили, что они пишут тулкит под linux, и остальные ОСи их интересуют по глубоко остаточному принципу. Т.е. кому интересно - пилит, но это не в приоритете.

SkyMaverick ★★★★★
()
Ответ на: комментарий от RazrFalcon

Не на linux, а на redhat

MX Linux, Manjaro, Mint, Debian, Ubuntu, elementary, Solus, Fedora, Zorin - это еслит брать топ дистровотча по порядку. gtk не только в гноме дефолт, но и в MATE, Xfce.

У моего линукса KDE - дефолт

В минорных решениях все что угодно можно найти. Даже kde3.

Linfan ★★★★★
()
Ответ на: комментарий от dave

Мне нравится подход Rust.

Да это понятно, что «почти любой язык, кроме C и C++» здесь будет лучше. Ибо именно в этих двух тащат легаси-недомодульность на командах препроцессора.

В объектном паскале, вон, сборочная система вообще не нужна. Там главный модуль программы по совместительству является файлом проекта и по нему можно раскрутить дерево зависимостей и сделать нормальный мейкфайл. Но у паскаля других недостатков хватает, современным крестам он, конечно, не конкурент.

hobbit ★★★★★
()
Ответ на: комментарий от Dendy

Главный косяк QMake, что он не умеет в инкрементальную сборку. Это одно ставит на нём крест.

Эм, а за это разве не make отвечает? qmake делает Makefile, а make собирает только изменённые исходники. Или мы под инкрементальной сборкой имеем в виду разные вещи?

hobbit ★★★★★
()
Ответ на: комментарий от RazrFalcon

Какие-то noname’ы кроме дебиана и убунты.

Для кого и кде-дистры - ноунеймы.

Но я о том, что дефолта в лине нет и не нужно его придумывать.

Gtk стал дефолтом de-facto уже давно, а qt на подтанцовках. Особенно в свете сабжа. Это не говорит о качестве того или иного виджетсета. Это просто констатация имеющегося расклада.

Linfan ★★★★★
()
Ответ на: комментарий от RazrFalcon

В ваших фантазиях - возможно.

Попререкаться на ЛОРе - дело святое… Но рассказывать, что есть такие очень популярные дистрибутивы (но при этом вы их не знаете) которые живут одной кутей - это уже и для ЛОРа перебор.

Linfan ★★★★★
()
Ответ на: комментарий от RazrFalcon

Вы видели голосовалку о DE на лоре? Угадаете кто на первом месте?

Эту что-ли? Какое DE вы используете как основное или единственное?

Ну дык gtk - 45% и qt - 30%. Это при том, что площадка явно страдает тулкитохейтерством. Подозреваю, что кедики весьма неплохо накрутили фаны.

Linfan ★★★★★
()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от hobbit

Там бага в том, что генерируемый Makefile не учитывает как зависимости заголовки подключенные в заголовки и как результат меняя bar.h подключенный в foo.h Makefile говорит что делать нечего, в общем в зхависимости прописывается только то что подключено .c(pp) файлах

AKonia ★★
()
Ответ на: комментарий от RazrFalcon

Ну куда же нам без теории заговора.

Процентовка ЛОРа показывает верное состояние дел, но не укладывается по цыфири с более репрезентативной статой дистровотча. Потому и приходится теорию заговора привлекать :)

Linfan ★★★★★
()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от Linfan

репрезентативной статой дистровотча

Это та «стата», про которую на самом дистровотче написано,что она ничего не значит и не должна использоваться для оценки популярности дистрибутивов?

дефолт

А в Windows - IE дефолт ;)

yuran ★★
()
Ответ на: комментарий от yuran

Это та «стата», про которую на самом дистровотче написано

Про лоровский опрос и вспоминать в таком случае стыдно, не то что писать :)

А в Windows - IE дефолт

А матчасть надо знать - у них нонче Edge рулит :)

Linfan ★★★★★
()
Ответ на: комментарий от hobbit

Я выше по треду ответил за QMake и инкрементальную сборку.

Но если смотреть шире, то и make не умеет в инкрементальную сборку от слова совсем. Самые типичные примеры:

  1. Соберите проект, а потом поменяйте любую опцию компилятора или линковщика в Makefile. Почему нужный файл не перекомпилируется или не перелинковывается?

  2. Соберите проект из 2-х или более C/C++ файлов. Теперь уберите любой из C/C++ файлов из Makefile. Почему не происходит перелинковка оставшихся?

Dendy ★★★★★
()
Ответ на: комментарий от Linfan

А, Edge же теперь, точно. Я его не видел ни разу.

yuran ★★
()
Ответ на: комментарий от RazrFalcon

Ясное дело, что ЛОР-опрос это аргументация уровня ЛОР. Но как не виляй, из серьезных дистров с кедиками мы имели только Сюзю и та в 15й версии на гном ускакала.

Linfan ★★★★★
()
Ответ на: комментарий от qtm

Дистрибутивам разумнее патчить ту версию QT, которая попадёт к ним в LTS. Им просто работы прибавится. А в не LTS-выпуски совать QT-rolling.

vold ★★★★★
()
Ответ на: комментарий от qtm

Наверняка QT LTS будет открытой, а обновы будут распространяться по закрытой подписке. Какая-нибудь RHEL купит подписку, Centos скоммуниздит, а из неё и все остальные линуксы. Просто обновы в таком случае будут идти с опозданием. QT company закроет на это глаза, т.к. линуксы это 1%, а основной бюджет им делают винды.

vold ★★★★★
()

Как же теперь будут развиваться другие DE на кутях, типа LxQt?

vold ★★★★★
()
Ответ на: комментарий от Dendy

Но если смотреть шире, то и make не умеет в инкрементальную сборку от слова совсем.

Ваше «шире» недостаточно широкое.

Соберите проект, а потом поменяйте любую опцию компилятора или линковщика в Makefile. Почему нужный файл не перекомпилируется или не перелинковывается?

Если требуется такое поведение, вы можете вынести определение флагов компилятора в отдельный файл, подключать его в основном Makefile и указать в списке зависимостей.

Соберите проект из 2-х или более C/C++ файлов. Теперь уберите любой из C/C++ файлов из Makefile. Почему не происходит перелинковка оставшихся?

Это тоже можно преодолеть. Отвечает Александр Друзь Пол Смит.

Да, это всё требует дополнительных телодвижений и — если удобнее называть вещи своими именами — костылей. Но решаемо.

northerner ★★★
()
Ответ на: комментарий от Linfan

из серьезных дистров с кедиками мы имели только Сюзю и та в 15й версии на гном ускакала

Не вводите читателей в заблуждение. В процессе установки openSUSE 15.1 по-прежнему (как и ранее) предлагает пользователю выбор. Утверждаю как пользователь этого дистрибутива с 2006 года. И да, пересечение множества разработчиков openSUSE и KDE непусто, возможно поэтому в openSUSE плазма не падает.

northerner ★★★
()
Ответ на: комментарий от northerner

Если требуется такое поведение…

Такое поведение требуется в 100% случаев. Цели сборки это инварианты, если поменялись входные параметры, то артефакт устарел. На практике не существует ситуаций, в которых изменение командной строки не должно приводить к пересборке цели.

Это тоже можно преодолеть.

Всё можно преодолеть. Но в случае с Makefile’ом это так или иначе заканчивается костылями и мутированием его в какой-то другой язык программирования, чтобы заставить инкрементальную сборку работать. Что перечёркивает всю идею языка быть first class citizen, то-есть исходным кодом для описания дерева сборки проекта. Правильное преодоление этой проблемы — выбрать другой язык.

Dendy ★★★★★
()
Ответ на: комментарий от northerner

Надо будет еще раз глянуть - сюзю юзал только для тестирования и отложилось впечатление, что гном по умолчанию.

Linfan ★★★★★
()
Ответ на: комментарий от Linfan

Надо будет еще раз глянуть - сюзю юзал только для тестирования и отложилось впечатление, что гном по умолчанию.

Возможно, вы использовали SLED, который в 12 версии переехал на GNOME по умолчанию?

Rootlexx ★★★★★
()
Ответ на: комментарий от qtm

За Electron стоят бабки Microsоft.

А может, всё-таки Google?

vold ★★★★★
()
Ответ на: комментарий от Rootlexx

Да, SLED/SLES - в клаудах и у корпов только это. Хм… ну поковыряю тогда opensuse «на посмотреть».

Linfan ★★★★★
()
Последнее исправление: Linfan (всего исправлений: 1)
Ответ на: комментарий от qtm

За IBM не заржавеет перетянуть под свое крыло и второй тулкит.

Только вот нужно ли им это? Думаю, что не нужно. Относительно недавно промелькнула новость, что Федора не будет официально поддерживать спин с KDE.

vold ★★★★★
()
Ответ на: комментарий от anonymous

Если Qt Company закроет исходники, то предыдущие открытые версии будут открыть под пермисивными лицензиями. Можно будет строгать опенсорсные и проприетарные форки, пихать старые версии забесплатно в любую проприетарщину.

А сейчас так нельзя?

vold ★★★★★
()
Ответ на: комментарий от Deleted

Зачем мне регистрироваться, если я не разработчик?

Чтобы знать, что ты качаешь, а потом поставить на это ценник.

vold ★★★★★
()
Ответ на: комментарий от praseodim

Всё для вашего блага за ваши деньги. :)

vold ★★★★★
()
Ответ на: комментарий от vold

А может, всё-таки Google?

А может все-таки посмотреть кто купил компанию, разработавшую Electron и кто сейчас активно переводит на этот самый Electron свои продукты?

Только вот нужно ли им это? Думаю, что не нужно.

Не нужно подмять под себя всю Линукс-морду целиком? Да вы стратег :-)

Относительно недавно промелькнула новость, что Федора не будет официально поддерживать спин с KDE.

Естественно, не будет. Qt разрабатывается другой компанией, а значит влиять на нее будет невозможно. Зачем тратить ресурсы на чужой продукт? Другое дело GTK. Можно херить обратную совместимость от версии к версии, творить любую дичь и все схавают.

qtm ★★★
()
Ответ на: комментарий от RazrFalcon

Проблема GTK в том, что она работает только в гноме.

А также в Mate, в Cinnamon'е, в XFCE, в LXDE.

vold ★★★★★
()
Ответ на: комментарий от qtm

А может все-таки посмотреть кто купил компанию, разработавшую Electron и кто сейчас активно переводит на этот самый Electron свои продукты?

Электрон — это фреймворк, который основан на Node.js и выводит в окно chromium'а. Ах, да оно создано гитхабом, который купила микрософт.

vold ★★★★★
()
Ответ на: комментарий от qtm

Не нужно подмять под себя всю Линукс-морду целиком?

Зачем? Им достаточно GTK/Gnome, чтобы выпускать коммерческий дистрибутив RHEL. А тянуть доп. тулкит — это лишняя трата денег.

vold ★★★★★
()
Ответ на: комментарий от vold

Хотя бы для того, чтобы скатить один из тулкитов в сраное дерьмо и тем самым сделать второй безальтернативным.

И, что-то мне кажется, что при таком раскладе скатывать в сраное дерьмо IBM будет не Qt.

qtm ★★★
()
Ответ на: комментарий от qtm

Не нужно подмять под себя всю Линукс-морду целиком?

Судя по Федорке, все что нужно корпам от линукс-морды, это терминал. А остальное по остаточному принципу. По-крайней мере, на данном этапе развития.

Linfan ★★★★★
()
Ответ на: комментарий от qtm

Хотя бы для того, чтобы скатить один из тулкитов в сраное дерьмо и тем самым сделать второй безальтернативным.

И, что-то мне кажется, что при таком раскладе скатывать в сраное дерьмо IBM будет не Qt.

Даже если предположить, что подобная теория имеет право на жизнь, - кто будет переписывать массу ПО с GTK на Qt? IBM?

И главное - зачем? Вот слепить из двух тулкитов один, взяв из каждого лучшие решения, - вот это было бы полезно.

Впрочем, все эти разговоры пока что не имеют под собой никаких оснований.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Вот слепить из двух тулкитов один, взяв из каждого лучшие решения, - вот это было бы полезно.

Да и это никто делать не будет - корпам хватает того, что есть сейчас. Их и планшетноориентированный гном вполне устраивает.

Linfan ★★★★★
()
Ответ на: комментарий от gorky

Gtk в плане лицензии гораздо стабильнее.

Ну так проект GNU, самое что наистабильнейшее LGPL.

И хотя заголовок, как я понял вполне жёлтый, лицензия у Qt всё та же смесь GPL/LGPL, и договор с cообществом KDE если Qt внезапно перестанет быть open source (необязательно путём закрытия исходников, хватит и возврата к Qt Free Edition License или переходу к какому нибудь аналогу CC-BY-SA-NC) позволяет разработчикам KDE не просто форкнуть фреймворк (оно есть у всех и всегда), но и перехватить торговую марку Qt (или я что-то не так понял?).

Но меняются условия распространения официальных двоичных сборок (что на linix.org.ru ввобще никого волновать не должно, жа и разработчикам кроссплатформа никто не запрещает самостоятельно qt компилять, что конечно долго, но это явно не повод для вселенского плача.

Более серьёзные изменения в политике поддержке LTS. Если я понял всё верно, фактически разработчики Qt заявили, что будут менять лицензирование официальных LTS ветвей продукта (имеют право, основная ветвт то остаётся свободна). И мейнтейнеры старых версий Qt просто вынуждены будут поддерживать свои форки (что, вероятно, даёт шанс форкам вроде CopperSpice стать частью мейнстрима).

be_nt_all ★★
()
Последнее исправление: be_nt_all (всего исправлений: 1)
Ответ на: комментарий от qtm

Хотя бы для того, чтобы скатить один из тулкитов в сраное дерьмо и тем самым сделать второй безальтернативным.

Скорее, тандем Микрософт+Гугл мог бы купить QT (они уже объединились на базе Electron+Chromium), чтобы приобрести нечто кроссплатформенное и альтернативное IBM, чтобы заработать на винде ещё и на QT. А 1% линукс-бомжей могли бы отдать и забесплатно ;)

Но у них уже есть электрон.

vold ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.