В предыдущей статье про Qt roadmap я обещал рассказать про Qt 3D Studio и текущую ситуацию с лицензиями. Qt 3D Studio уже было выпущено два (пока писал статью, вышел третий) внутренних релиза, но статьи про неё пока не будет, так что сегодня расскажу про лицензии. Система лицензирования Qt и раньше не особо отличалась простотой, но сейчас она особенно усложнилась, так как добавились (и добавляются) новые продукты и вместе с ними дополнительные условия соответствующих лицензий. Официальный сайт не сильно помогает разобраться, хотя и содержит текст условий и соглашений. Но речь пойдёт не сразу про лицензии, сначала я хочу рассказать немного о компании, чтобы было понятно, кто именно сейчас занимается разработкой/распространением фреймворка и вообще стоит за Qt. Мне показалось важным начать с вводной части, потому что до сих пор есть “серые” места даже в таких простых вещах как правильное произношение (“кьют”) и написание ("Qt"). Что уж тут говорить, если и во внутренней переписке и звонках можно иногда услышать "ку-ти" и увидеть "QT" (от разработчиков — никогда). Иногда на выставках задают вопросы вида: “Как, а вы ещё живы?” или “А разве Nokia не того?”. Да, компания вполне жива и не имеет ничего общего с Nokia уже несколько лет. Вот вся история компании вкратце: Вообще, в планах компании сейчас стоит цель достичь прибыли в 100 миллионов евро к 2021 году, потому сейчас идёт активный набор новых сотрудников, и помимо прочих вакансий особенно срочно нужен так называемый  sales engineer в берлинский офис. Если кому-то интересно — напишите мне, я расскажу подробнее. Говоря о Nokia, нельзя не упомянуть её вклад в распространение Qt — ведь именно Nokia сделала Qt доступным также и под лицензией LGPL. По понятным причинам, продажи лицензий её не интересовали — Nokia хотела “популяризировать” Qt, чтобы создавалось больше приложений для её мобильной платформы, а GPL этому очень мешала. И действительно, сразу же после этого начался взрывной рост сообщества Qt, так что спасибо Nokia за это. Но есть и обратная сторона: продавать ПО, лицензируемое одновременно под LGPL и коммерческой лицензией — это довольно непростая задача, так что в этом смысле LGPL-наследие Nokia "fucked up sales big time" (не буду переводить), как сказал сотрудник отдела продаж, пожелавший остаться неизвестным. Что хочу отметить особо — при всех произошедших сменах владельцев разработчики Qt оставались те же (насколько это возможно за более чем 20 лет). Некоторые, включая нынешнего chief technology officer (CTO) Lars Knoll, работают в Qt и сегодня, а начинали ещё во времена Trolltech. Вот вкратце об истории всё. Кстати, если будет интересно, расскажу, почему домен — qt.io, а не qt.com (спойлер: киберсквоттинг). The Qt Company — международная компания с офисами в нескольких странах:  И хотя юридически главный офис сейчас находится в Финляндии, исторически самый большой офис — в Осло (Норвегия). В нём же сидит большинство разработчиков (и CTO). Российское же представительство The Qt Company одно из самых маленьких (если не самое) — на всю страну только один небольшой офис в Санкт-Петербурге. Кстати говоря, после определённых событий питерский офис однажды получил такое письмо:  Новые релизы выходят обычно два раза в год, но иногда даты съезжают и в каком-то году может оказаться всего один релиз, зато в другом — три. Если рассмотреть сроки поддержки релизов, то пока ещё действует “старая” система, по которой минимальный поддерживаемый релиз — 5.4. По новой же системе начиная с Qt 5.6 релизы теперь будут делиться на обычные и LTS (long-term support): Таким образом, текущие поддерживаемые (сопровождаемые) версии: Сопровождение включает в себя выпуск корректирующих релизов (x.x.1, x.x.2 и т.д.) а также техническую поддержку. Не следует путать техническую поддержку с баг-фиксами: корректирующие релизы и баг-фиксы, разумеется, доступны для всех, но техническая поддержка предоставляется только обладателям коммерческой лицензии (об этом будет ниже). Пример с прекращением сопровождения релиза: если вы используете Qt 5.3 и по тем или иным причинам не можете/хотите обновляться до актуальной 5.9, то вы можете продолжать разработку с Qt 5.3 и выпускать свои продукты — но не ожидайте никаких обновлений/исправлений для этой версии. Даже если у вас есть доступ к тех.поддержке — обращаться с вопросами по Qt 5.3 вы не сможете, стандартная поддержка этого релиза также закончилась. Но если вам очень нужно, то есть возможность приобрести расширенную (extended) поддержку для устаревших версий, и тогда сопровождение этой версии будет возобновлено специально для вас. Qt всегда был доступен под “двойной” (dual-license) лицензией: Open Source и коммерческой. С коммерческой всё понятно: компании нужны деньги, чтобы платить сотрудникам и развивать фреймворк. Но зачем делать свой продукт доступным под лицензиями Open Source?  На графике показан вклад сторонних компаний в разработку Qt. Нетрудно видеть, что хотя вклад The Qt Company и самый большой, немалая часть разработки ведётся силами Open Source сообщества. А в некоторых модулях вклад сторонних разработчиков даже больше — к примеру, появление Qt 3D является заслугой сервисной компании KDAB. Поэтому важно, чтобы Qt был и оставался быть доступным не только под коммерческой лицензией, но и под Open Source. Далее ещё будет отдельно про KDE Free Qt Foundation. Положительную роль играет и такая сторона Open Source — допустим, некоторая компания Chamomile решает использовать Qt в разработке своего нового продукта. Выделяются ресурсы, и разработка ведётся в течение какого-то времени. Затем компания Macrohard неожиданно покупает The Qt Company и, по своему обыкновению, уничтожает её (и продукт). Что это означает для компании Chamomile — проект обречён, все ресурсы потрачены впустую, ведь разработка Qt прекратилась? Нет — его исходники доступны, и разработка будет продолжаться независимо от существования того или иного юридического лица. Конечно, повисает вопрос с лицензиями, но самое главное — Qt как технология останется жив и будет продолжать развиваться. При всём вышесказанном, неподготовленные сотрудники отдела продаж на ситуацию с Open Source смотрят с плохо скрываемым ужасом. Для них это означает только одно — мы раздаём наш продукт бесплатно! Точно так же на бизнес-модель The Qt Company смотрят и люди со стороны. Но на самом деле всё не так просто, и далее в статье я надеюсь это объяснить. Для дальнейшего разбирательства с лицензиями (отличиями между ними) нужно рассказать о продуктах. Разные продукты имеют разные условия лицензирования (и разную стоимость). Сейчас список продуктов такой: Эти три продукта можно представить так:  То есть, с технической точки зрения последующий продукт включает в себя предыдущий и добавляет новые компоненты и инструменты. Однако кроме технической есть и юридическая составляющая. Например, вы создаёте кофемашину и используете Qt в разработке ПО для неё. По условиям лицензии Qt for Application Development вы не можете распространять/продавать ваши кофемашины — для этого вы должны обладать лицензией Qt for Device Creation, потому как именно она лицензирует такое использование Qt (распространение в составе “устройства”, подробности чуть ниже. Через некоторое время ожидается появление новых продуктов. Скорее всего, они тоже будут базироваться на Qt for Device Creation и расширять его дополнительным функционалом (и условиями лицензирования), специфичным для определённых индустрий (например, ТВ-приставки, медицина и т.п.). Есть ещё один, обособленный продукт — лицензия на создание SDK на основе Qt. Этот пакет существует на случай если кто-то захочет взять Qt, внести в него свои изменения (добавить в состав новые библиотеки, расширить Qt Creator дополнительными плагинами, ещё что-то) и распространять/продавать как свой продукт на своих условиях (виртуальный оператор сотовой связи, как аналогия). Такой вариант лицензирования встречается очень редко (и стоит очень дорого). Вероятно, пример с кофемашиной вызвал некоторое недоумение, а может и возмущение, потому хочу рассказать о “юридических“ отличиях между продуктами Qt for Application Development и Qt for Device Creation подробнее. Qt for Application Development предназначен для разработки приложений на десктопах и мобильных платформах, где такое приложение будет лишь одним из множества других, использующихся в системе. Примеры: Telegram, VLC, VirtualBox и другие — то есть “обычные” приложения, которые могут быть установлены на любой компьютер (смартфон, планшет) или размещены в магазине приложений (App Store, Google Play, Windows Store). Условия этой лицензии покрывают следующие операционные системы: Windows, Linux, Mac OS, iOS, Android, Windows Phone — все они уже включены в стоимость лицензии (выкинуть “ненужные” нельзя). Qt for Device Creation предназначен для создания “устройств”, когда продукт — это не просто приложение, но комбинация софта и железа, то есть приложение разрабатывается для конкретного устройства, и конечный продукт будет распространяться/продаваться именно в таком виде — устройство и предустановленное (или устанавливаемое позже) на него ПО, без которого устройство просто “не будет работать”. Это может быть графический интерфейс пользователя либо другая существенная функциональность устройства, реализованная с использованием Qt. Условия этой лицензии покрывают только одну операционную систему из списка: Embedded Linux (в общем-то, тот же Линукс, но на embedded платформе), Embedded Windows (UWP, WinRT, Windows EC/WinCE), QNX, VxWorks, INTEGRITY — в стоимость лицензии включена только одна из них, и каждая дополнительная ОС добавляется за дополнительную плату (со скидкой за каждую последующую). Кроме того, есть ещё так называемая “лицензия на распространение” — об этом будет далее. На всякий случай хочу пояснить, что лицензирование ОС затрагивает только “конечную” (deployment) ОС. Разработку же можно вести в любой ОС, какая нравится (Windows, Linux, Mac OS). Некоторое проекты могут требовать наличия лицензии Qt for Device Creation даже несмотря на то, что “устройство” представляет собой обычный настольный компьютер на Windows. Например, это может быть рабочая станция на каком-то заводе, на которой работает некоторое приложение для мониторинга каких-нибудь датчиков — и это единственное предназначение этой рабочей станции. С технической точки зрения здесь нет никакой нужды в компонентах из состава Qt for Device Creation (Boot to Qt, виртуальная клавиатура, эмулятор и т.д.), но юридически — это “устройство”, а значит требуется именно эта лицензия. Определение "устройства" дано в условиях и соглашениях. Может быть и такая ситуация: у некоторой компании два разных проекта: медиа-плеер под Windows и погодная станция на Raspberry Pi и Linux. В этом случае ей нужно приобрести обе лицензии — так называемую “комбо-лицензию”: Qt for Application Development плюс Qt for Device Creation (стоит дешевле этих двух по отдельности). Опять же, с технической точки зрения вполне себе можно работать над проектом медиа-плеера используя версию Qt for Device Creation (ведь она содержит все библиотеки из Qt for Application Development), но “юридически” по условиям лицензии это не разрешается. Для работы над проектом с использованием Qt каждый разработчик должен обладать лицензией. Она именная и привязывается к e-mail адресу (Qt Account). Несмотря на такую привязку, на самом деле лицензия принадлежит вашей компании, и потому когда разработчик с лицензией, например, уволится, вы сможете “переназначить” его лицензию на другого. Однако, это не означает, что у вас в руках “плавающая” лицензия, которую можно переключать между сотрудниками по несколько раз в день — переназначение лицензии регулируется The Qt Company. Если команда большая, то есть возможность приобрести “массовую” (site license) лицензию на всю компанию, которая не будет зависеть от реального количества разработчиков и, соответственно, обойдётся дешевле. Свою лицензию каждый разработчик может использовать на неограниченном количестве рабочих станций и операционных систем, при условии что пользоваться ими будет исключительно он. Пример: на работе у меня стоит десктоп с Windows 10 и ноутбук с Ubuntu, а дома я использую Mac — можно установить Qt на все три машины и спокойно работать над проектом на любой из них. Часто задают вопрос про сервера сборки, нужна ли им отдельная лицензия? Нет, лицензия требуется только для “живых” разработчиков, которые работают с Qt (“touching the Qt code”). Вообще, лицензии для разработчиков являются пожизненными (perpetual), но Qt for Application Development имеет опцию приобретения лицензии по подписке (subscription) (в том числе и “инди”-лицензия для стартапов). Такая лицензия оплачивается за каждый месяц использования. Подписочная модель имела смысл для краткосрочных проектов, когда разработка длится, скажем, пару месяцев, после чего вы только распространяете своё приложение. Как только требуется возобновить разработку, выпустить новую версию приложения — вы оплачиваете новый месяц, осуществляете задуманное и опять останавливали подписку. Почему я "имела смысл"? Потому что какая-то светлая голова из менеджмента придумала сделать так, что с недавних пор (где-то с полгода назад) действующая подписка стала требоваться не только на период разработки, но и на распространение приложения. То есть теперь, если ваша подписка неактивна, то вы не можете не только заниматься разработкой, но и распространять/продавать своё уже готовое приложение. Кстати, почему на сайте указана цена на подписку, но нигде нет цены на пожизненную? Руководство решило, что всю важную информацию в паре абзацев на сайте не уместить, и потому желающие приобрести коммерческую лицензию должны связаться с отделом продаж, который сначала объяснит систему лицензирования применимо к конкретному проекту, и только после этого объявит стоимость и условия соответствующей лицензии. Qt for Device Creation (и все производные продукты, начиная с Automotive Suite) помимо лицензий для разработчиков имеет вторую составляющую — “лицензии на распространение” (distribution licenses или runtimes (не самый удачный термин)). То есть, компания-разработчик, распространяющая/продающая “устройства” с Qt внутри (ПО, разработанное с использованием Qt), должна пробрести эти самые рантаймы по числу распространяемых устройств. Например, пусть та же контора Chamomile продаёт 20 000 кофемашин в год, значит она должна приобрести “рантаймы” для как минимум 20 000 устройств (или сразу 100 000, чтобы на пять лет). Чем больше объём, тем меньше стоимость рантайма за одно устройство (и наоборот). Более того, существует минимальный порог числа рантаймов — вы должны купить как минимум 5 000 рантаймов независимо от вашего реального плана поставок. Но некоторые компании (и необязательно стартапы) просто не нуждаются в таких объёмах — скажем, производитель МРТ-сканеров продаст от силы 500 сканеров за 10 лет, что ему делать с остальными 4 500 рантаймами? В общем, довольно странное требование (но к счастью не такое "жёсткое"). Лицензия для разработчика включает в свою стоимость один год технической поддержки и "получения"" новых версий Qt. Через год у вас есть выбор, “продлить” (renew) поддержку и обновления или нет. Если не продлевать, то вы по-прежнему можете вести разработку (лицензия же “пожизненная”) с последней версией Qt, которая была выпущена в течение этого года, но вы больше не можете обращаться в техническую поддержку а также использовать более новые версии Qt. У лицензий на распространение (рантаймов) срока действия нет. Вы можете использовать их хоть пять лет, хоть пятьдесят — до тех пор, пока не исчерпаете приобретённый объём. Например, вы приобрели 10 000 рантаймов, и ежегодно вы выпускаете 1 000 единиц вашего продукта (кофемашин) — это означает, что новый пакет рантаймов вам понадобится только через 10 лет. Чтобы не покупать кота в мешке, можно запросить “триальную” (evaluation) версию Qt. Это ознакомительный дистрибутив, ограниченный по времени (действует 30 дней) и который содержит все коммерческие компоненты, то есть вы можете собственноручно пощупать образы Boot to Qt, попробовать удалённую отладку и профилирование на устройстве, замерить эффект от использования Qt Quick Compiler, оценить удобство Qt Configuration Tool для Qt Lite и прочее. Также в течение этих 30 дней у вас будет доступ к специалистам тех.поддержки. Триал доступен как для Qt for Application Development, так и для Qt for Device Creation. Что касается Automotive Suite, то этот продукт ориентирован на “крупных игроков” уровня BMW, Volvo и прочих, потому его заполучить будет не так просто. Для получения ознакомительной версии нужно связаться с отделом продаж. Одним из важных (а для некоторых — ключевым) отличием коммерческой лицензии от Open Source является наличие технической поддержки. С Open Source версией вы можете либо бороться с проблемами самостоятельно, либо полагаться на Stack Overflow, форумы, IRC-каналы и т.д. Помогут вам или нет (а также насколько быстро) зависит исключительно от уровня альтруизма участников. При наличии же технической поддержки вы можете использовать систему тикетов в вашем Qt Account. Вы получаете гарантированное время ответа (48 часов) и доступ к специалистам Qt. Можно даже выйти на разработчика той или иной библиотеки напрямую. Нет никакой “первой линии” с “маринками”, вы общаетесь сразу с техническими специалистами. Задавать можно любые вопросы, даже если они вам кажутся глупыми и "нубскими", без ограничения на их количество. Хотя если у вас всего одна лицензия, но при этом от вас поступают сотни тикетов в день — это вызовет определённые встречные вопросы. Кроме тех.поддержки, ваши баг-репорты и фича-реквесты получают повышенный приоритет (и помечаются внутренним маркером “коммерческий клиент”). Также есть возможность приобрести премиум поддержку: выделенный специально для вас специалист, время ответа снижается до 24 часов, ещё больший приоритет для баг-репортов и реквестов, не нужно предоставлять минимальный пример проекта для воспроизведения бага и даже возможность удалённого подключения. Если и премиум поддержки недостаточно, то The Qt Company также оказывает сервисные (consultancy) услуги. Это вебинары/тренинги в офисе (обучение по стандартным программам или по вашему списку интересующих тем), семинары/воркшопы (анализ архитектуры вашего проекта, оптимизация производительности), изготовление proof-of-concept, срочная реализация фича-реквестов, а также просто аутсорс разработки. Open Source пользователи тоже могут заказать сервисные услуги у The Qt Company. Однако для них этого будет стоить дороже, чем для обладателей коммерческой лицензии. Ну и наконец про Open Source лицензии. Текущая Open Source версия Qt доступна под условиями и ограничениями GPLv3 или LGPLv3. До Qt 5.7 это были GPLv2.1 и LGPLv2.1. LGPL является менее “строгой” лицензией по сравнению с GPL, и в подавляющем большинстве компании, решившие пойти путём Open Source, выбирают именно её. Однако, кроме более “мягких” требований LGPL отличается от GPL тем, что не все компоненты Qt доступны под LGPL — например, Qt Charts, Qt Data Visualization и Qt Virtual Keyboard доступны только под GPL, то есть вы не можете использовать их в LGPL-проекте. Следует отметить, что LGPLv3 основывается на GPLv3, расширяя её. То есть, кроме требований LGPL нужно учитывать и ряд требований из GPL. Другой момент, которому далеко не все придают должное значение, это необходимость соответствия полному тексту лицензии, то есть выполнение всех требований и соблюдение всех ограничений соответствующей лицензии (GPL/LGPL). Например, очень сильно распространено заблуждение, что достаточно линковать Qt динамически и на этом все требования LGPL будут выполнены — на самом же деле это требование лишь одно из многих (да и то не полностью, если не ошибаюсь). Вообще, лицензии Open Source не принадлежат The Qt Company, потому она не может предоставить чёткий список требований и ограничений GPL/LGPL по пунктам — это личная ответственность каждой компании, которая хотела бы использовать Qt под той или иной лицензией Open Source. Если юристы компании, изучив текст соответствующей лицензии, выносят вердикт, что продукт компании соответствует требованиям лицензии — это их решение и их ответственность. Потому, если какая-то компания-разработчик заявляет, что им коммерческая лицензия не нужна, и они будут использовать Qt под LGPL, так как полностью ей соответствуют — мы даже не спорим. Может, они и правда соответствуют. Мы не юридическая фирма, и потому не можем консультировать по вопросам использования СПО. The Qt Company отвечает только за свою коммерческую лицензию. Выполнение требований лицензий Open Source регулируется не нами. Пока что я почти не видел сколько-нибудь крупной компании, которая выбрала бы Qt под Open Source лицензией для своего коммерческого проекта. Если говорить, например, о Германии, то там отдел продаж вообще работает в режиме “алло — сколько, вы говорите, нужно лицензий — отправляю договор”. Мало кто хочет рисковать своим бизнесом, когда текст лицензий попросту не совершенен (переход с GPL/LGPLv2.1 на v3 из-за тивоизации, нечёткое определение “consumer product” и прочие “серые” места), а также когда судебные процессы в этой сфере выдают непредсказуемый результат (GPL внезапно рассматривается как договор). Я представляю, да, в реалиях какой страны я тут расписываю за Open Source лицензии и их требования. Далеко не отходя за примерами — первые мои работодатели в России, где я начинал как раз-таки разработчиком C++/Qt, имели весьма слабое представление о каких-то там лицензиях-шмицензиях. Вот же страница загрузки, вот ссылка на установщик — всё ставится, ничего не просит, платить не надо, Далее — Далее — Принять — Далее — Готово, можно работать. Кроме России таким же подходом к лицензиям Open Source отличаются Индия и некоторые страны юга Европы (Италия и Испания, например). Компаниям из этих регионов в подавляющем большинстве случаев бесполезно рассказывать про условия и ограничения Open Source лицензий — тебя выслушают, кивая головой, а в конце всё равно спросят про разницу в компонентах. Потому что это единственное, что для них важно — что есть в коммерческой версии, и чего нет в Open Source. Ну, я сам был таким, потому не могу осуждать. Однако, в других странах к вопросу лицензирования ПО относятся смертельно серьёзно. А ещё вот кстати: одной из метрик анализа данных о посетителях сайта с недавних пор является количество загрузок Open Source версии. То есть, если в каком-то регионе активно грузят “свободный” Qt, то в глазах менеджмента этот регион является очень перспективным, и значит надо усилить в нём присутствие, потому что скоро начнут расти продажи коммерческих лицензий. Лишним будет говорить, что по числу загрузок лидируют Россия, Индия ну и далее по списку. Я пытался объяснять руководству, что цифры эти означают нечто совсем другое, но мне, скажем так, не совсем поверили. Для них это реально невообразимая ситуация — что кто-то может игнорировать текст лицензионного соглашения. По условиям лицензионного соглашения нельзя смешивать коммерческий и Open Source код. К примеру, нельзя иметь одного разработчика с коммерческой лицензией и десять разработчиков с LGPL, и чтобы все они работали над одним проектом или использовали общие компоненты. Также иногда встречаются ситуации, когда та или иная компания пару лет вела разработку своего проекта под Open Source лицензией, а перед релизом продукта “вдруг” узнала об её ограничениях и захотела приобрести коммерческую лицензию. Вообще, такое не допускается, лицензия должна выбираться на старте проекта, до начала разработки, и если вы взяли Open Source, то и распространение должно осуществляться в соответствии с требованиями GPL/LGPL. Но если такое всё-таки случилось не “вдруг”, а действительно по незнанию — свяжитесь с The Qt Company и опишите ситуацию. Различия в доступных компонентах есть не только между коммерческой и Open Source версией Qt, но также и между GPL и LGPL (какие-то компоненты доступны только в GPL). Вот тут надо сказать о KDE Free Qt Foundation. В 1998 году между сообществом KDE и тогда ещё Trolltech было заключено соглашение, что Qt всегда будет доступен как свободное ПО, и это соглашение соблюдалось и соответствующе обновлялось при смене владельцев Qt. Но относительно недавно условия соглашения были, скажем так, нарушены — в составе Qt появился ряд библиотек, которые были доступны только под коммерческой лицензией — это как раз-таки Qt Charts, Qt Data Visualization, Qt Virtual Keyboard и другие. В общем, отношения начали слегка портиться. К счастью, руководство всё-таки приняло решение сделать эти библиотеки доступными и в Open Source, что и произошло в релизе Qt 5.7 — они стали доступны под GPL. Но кстати говоря, разрыв между GPL и LGPL в этом плане в дальнейшем будет только увеличиваться — новые фичи будут лицензироваться преимущественно под GPL (и коммерческой лицензией, конечно). Кроме разницы в доступных компонентах отдельного внимания заслуживает техническая поддержка, которая, как уже говорилось, доступна только с коммерческой лицензией, а также необходимость (или её отсутствие) соблюдать требования и ограничения соответствующей Open Source лицензии. И всё же, если ставить вопрос ребром, что доступно в какой лицензий, и в какой чего наоборот не хватает, то для начала можно ознакомиться с таблицей сравнения на сайте, но её актуальность оставляет желать: там содержится не полный перечень отличий, а некоторые пункты и вовсе просто повторяются, предлагая одно и то же разными словами. В общем, я попытался создать более подробную таблицу. Хотя не исключено, что и моя тоже окажется неполной — в фреймворк входит слишком много компонентов (положительный такой минус).  Возможности разметки таблиц небогаты, потому пришлось картинкой. Ссылки на компоненты, понятное дело, теперь в виде пикселей. И несколько комментариев по таблице. За Open Source лицензии не нужно платить в явном виде, однако следует понимать, что некоторые расходы всё-таки последуют, пусть они и неочевидны на первый взгляд:  Те самые компоненты, которые раньше были доступны только в коммерческой лицензии. Начиная с Qt 5.7 они доступны и под GPL (но по-прежнему недоступны под LGPL). Qt Quick Compiler был (и остаётся) доступным только в коммерческой версии Qt. Его обещали отдать в Open Source с релизом 5.7, потом 5.8, потом 5.9, а сейчас вроде как больше не обещают, только предложили “взамен” механизм кэширования (который всё же не то же самое). Этот модуль был раньше только коммерческий, потом стал доступен и в GPL, а после релиза 5.8 перестал быть отдельным модулем, и теперь интегрирован в Qt Quick и доступен также под LGPL. Готовые "из коробки" наборы инструментов сборки для кросс-компиляции, отладки, деплоя и профилирования с хост-машины на присоединённом устройстве. На скриншоте ниже показано меню выбора “таргета” для проекта в Qt Creator — под какую платформу компилировать (кросс-компилировать) и где запустить приложение. Конкретно тут я собираю проект под Raspberry Pi 3 и хочу запустить своё приложение на подключённом по сети устройстве:  А на этом скриншоте показан полный список устройств, для которых "из коробки" имеются готовые образы и инструменты сборки:  Разумеется, это не означает, что больше ни на каких устройствах разработку с Qt вести не получится. Свой образ Boot to Qt можно собрать для любой платформы, которая соответствует требованиям. Существует также проект "образовательной" лицензии для преподавателей и студентов университетов. Подразумевается, что она будет бесплатной. В состав такого дистрибутива входят не только Open Source компоненты, но и коммерческие тоже. Также предоставляется ограниченный доступ к тех.поддержке (пониженный приоритет, нет фиксированного времени ответа и т.д.) и некоторые обучающие материалы. Однако, следует ожидать ограничений в условиях использования. Проект "образовательной" лицензии всё ещё в пилотном режиме, потому особо не афишируется. Я тоже в этом обзоре не стал её включать в общую лицензионную структуру. Как станет известно больше — добавлю новую информацию. Глядя на весь этот километр текста, думаю, стоит показать лицензионную структуру Qt в виде картинки:  Иногда задают вопрос: “Каковы условия использования Qt без лицензии?”. Ответ содержится на картинке: нет таких условий — невозможно использовать Qt без лицензии. Вы либо приобретаете коммерческую лицензию, либо используете Qt под условиями соответствующей Open Source лицензии (GPL/LGPL). После приобретения коммерческой лицензии ваше общение с The Qt Company не прекращается. Кроме продления лицензии, приобретения рантаймов, общения с технической поддержкой, заказом сервисных услуг, обучения и запросов новых фич, есть ещё два вида взаимодействия. Первое — это маркетинговое сотрудничество. Например, у вас классный продукт, вы выходите на рынок и потому заинтересованы в продвижении. The Qt Company, разумеется, тоже заинтересована, чтобы появлялось больше классных продуктов на Qt, и была бы рада объявлять о новых у себя на сайте. На этой взаимовыгодной почве и пополняется галерея Built with Qt. Если же продвижение вам не сильно интересно, зато хотелось бы получить скидку на лицензии — это тоже возможно. Второе — это compliancy check. Что-то вроде проверки соблюдения условий лицензии. Время от времени The Qt Company может (по условиям договора) проводить такие проверки, и если будут выявлены нарушения, то это чревато последствиями. Пример: вы описали свой проект как “просто приложение под винду” и приобрели Qt for Application Development, а на самом деле у вас хаб для “умного дома” на Windows 10 IoT, поставляемый на рынок в количестве нескольких тысяч устройств ежегодно — это весьма грубое нарушение. Или другой пример: компания заявляет, что в команде проекта будет всего один разработчик, но при этом в LinkedIn от имени этой же компании висит штук десять объявлений поиска программистов Qt — как-то не сходятся цифры. Надеюсь, теперь система лицензий Qt стала немного понятнее. Если хотите, чтобы я рассказал о чём-то подробнее (например, таки перечислил хотя бы основные ограничения GPL/LGPL), напишите в комментариях — я дополню статью. В комментариях достаточно часто в той или иной форме задают вопрос: "А что мне будет, если я нарушу условия лицензии?". Надо сказать, это характеризует. Я писал статью с целью рассказать о видах лицензий и продуктов Qt, а не о подробностях судебной практики в сфере программного обеспечения, о которых мне мало что известно. И видимо, зря я вообще вступил в обсуждение. И всё же, пытаясь ответить на вопрос: если вы нарушите условия коммерческого лицензионного соглашения, то, очевидно, The Qt Company может подать на вас в суд. Но этого хотелось бы избежать, и мало кто (если вообще кто-то) нарушает условия коммерческой лицензии умышленно — мне сложно придумать условия, в которых это принесло бы ощутимую выгоду. Если же вы нарушите условия той или иной Open Source лицензии, то я отвечал в комментариях, что эти лицензии не принадлежат The Qt Company, не она писала их текст (а Free Software Foundation), соответственно и затевать судебное разбирательство должна не The Qt Company, а FSF. Судя по всему, это не так. Как на самом деле — я не знаю. Кстати, в русской версии статьи про FSF на Википедии есть фраза: "Программы, распространяемые на условиях GPL, но не принадлежащие Фонду, могут быть защищены только их владельцами, поскольку Фонд не имеет нужного юридического статуса для этого". Из этого следует, что как раз-таки The Qt Company должна судиться с нарушителем. Но в английской версии статьи это фразы нет. Как на самом деле — не знаю. У меня даже появился встречный вопрос: если завтра The Qt Company исчезнет (заработает все деньги в мире и самораспустится), то кто будет подавать в суд за нарушения GPL/LGPL? Ведь сам Qt от этого не исчезнет, останется Open Source (как я и приводил пример в статье). Означает ли это, что тогда можно будет спокойно использовать Qt в своих проектах, игнорируя условия GPL/LGPL? Я подозреваю, что нет. Ещё раз хочу повторить, что всё сказанное не является юридической консультацией, потому что я не юрист и не специалист по лицензированию ПО, а также не говорю от имени компании. оператор ЭВМ