Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
У каждого разработчика хотя бы раз возникала мечта создать крутой продукт, который обязательно захотят купить (а не спиратить) все пользователи, а сам он станет богаче Илона Маска и будет запускать свои Falcon, но конечно же намного удачнее. Но чаще всего эта мечта спустя время разбивается о суровую реальность: софт почти никому не нужен из-за переполненного рынка, а если и нужен, то его постоянно пиратят, безжалостно и беспощадно.
Если с первой проблемой помогут справиться талант и удача, то разобраться со второй — попробуем помочь мы. Ниже рассказываем о нюансах лицензирования, с которыми сталкивается разработка.
Типы лицензирования
Лицензирование состоит из разных частей, основные из которых — то, как оно работает внутри продукта, и то, как его видит заказчик. Для того чтобы правильно реализовать внутреннюю часть продукта, нужно определить типы клиентов и представить сценарии, по которым заказчики будут работать с продуктом.
По этой причине наиболее распространенные варианты лицензирования можно разделить на три вида, каждый из которых определяется потребностями заказчика: B2C для физлиц, B2B для малого и среднего бизнеса и энтерпрайз-лицензирование для крупных корпораций (еще есть лицензирование для медиаиндустрии и игр со всякими лутбоксами, но это не наша тема, поэтому углубляться не будем).
У каждого вида лицензирования имеются свои особенности и отличия.
B2C-лицензирование
Первый вид лицензирования используется в коробочных продуктах, которые рассчитаны на установку на одной или на ограниченном разработчиком количестве машин для личного использования. Работает такое лицензирование очень просто: пользователь покупает ключ, активирует его и пользуется приложением согласно лицензионному договору. Активация происходит локально — ключ проверяется на соответствие алгоритму (шаблону) на той же машине. Другой вариант — проверка выполняется удаленно, где ключ отсылается на сервер компании.
По этим схемам, например, работают наши электронные словари Lingvo и домашняя версия ContentReader PDF (российский аналог FineReader PDF).
В основном пиратство софта распространено среди конечных пользователей, нежели среди бизнеса, ведь без совершенной покупки и лицензионного договора ни один разработчик не будет обслуживать компанию и оказывать ей техподдержку. И это не говоря о всевозможных проверках со стороны госорганов. По этой причине для разработчиков самым главным вопросом в этом типе лицензирования стоит защита продукта от возможного взлома.
B2B-лицензирование
Второй вид лицензирования рассчитан на программы, предназначенные для корпоративного использования, к примеру, наши электронные словари Lingvo (лицензия Concurrent) и ContentReader PDF для офиса. Здесь уже не требуется усиленной защиты от пиратства, также не предусматриваются изменения внутри продукта. Зато для разработчиков важно предоставить заказчикам продвинутые сценарии лицензирования, при котором софт ставится на множество машин, а админам компании предоставляется возможность расширенного управления.
У B2B-лицензирования есть два подвида:
Покупка N лицензий, которые распределяются среди сотрудников админом компании через специальный портал (ПО), где активируются полученные ключи. Общее количество лицензий может быть приравнено к количеству машин, на которых установят этот софт, или количеству пользователей, которым он будет доступен.
Для этого разработчику необходимо создать портал, который поможет админу распределять множество разных лицензий на клиентские машины. Сложность со сценарием управления большим количеством лицензий является основной проблемой в этом типе лицензирования.
Второй подвид позволяет N пользователям работать с программой на разных машинах. Естественно, точное количество пользователей и устройств прописывается в лицензии. Например, так работают наши Concurrent-лицензии.
Основная сложность — один работающий сервер, для которого нужно обеспечить отказоустойчивость и производительность в случае большой нагрузки.
Энтерпрайз-лицензирование
Третий тип лицензирования, под который рассчитаны наши продукты ContentCapture, Intelligent Search и ContentReader Engine, во многом схож с B2B-лицензированием, однако подразумевает установку софта не просто в контуре одной компании, а в нескольких офисах одной корпорации. Их основное различие – разработчики учитывают пожелания заказчиков по работе продукта и внедряют их для конкретного клиента. К примеру, заказчик хочет развертывание софта в Docker или в клаудной инфраструктуре, или вообще, чтобы все работало на кластерах. И все эти вещи сказываются не только на том, как ты это продаешь, но и как ты их лицензируешь.
Триалы
Триалы — пробные версии продуктов, которые поставляются для всех пользователей — В2С, В2В и энтерпрайзу. Как правило, в триальных версиях функциональность софта ограничена для наглядного ознакомления с основными возможностями продукта.
У триальных версий есть четыре основных типа.
Некоторые рисковые разработчики открывают доступ В2С к полнофункциональным триалам, но единоразово при запуске программы или после каждого действия пользователю будет показываться окно, сообщающее, что он пользуется триальной версией продукта, а лицензионную копию можно купить там-то. Такой вариант лицензирования используют инди-разработчики или очень маленькие компании. Иногда это просто вариант лицензирования «доната на кружку кофе», что в общем-то одно и то же.
Разработчик вырезает из полнофункционального продукта бо́льшую часть фич, оставляя лишь базовый набор для работы с софтом. Чаще всего такой вариант предлагается категории В2С (все из-за того же пиратства, ведь защищаться всегда сложнее, чем лицензировать). В этом случае доступ к полнофункциональной версии необходимо запрашивать у разработчика.
Триальная версия создается на базе полнофункционального продукта, но с ограниченным сроком использования и доступом к ряду фичей. Обычно такие триалы находятся в свободном доступе для тестирования продукта.
Частный случай предыдущего — ограничение срока действия полнофункциональной лицензии. В действительности это не совсем триал. Это лицензия, у которой есть ограничение по времени, но за которую, условно, никто не просил денег, а дали попользоваться на какой-то период. Такой вариант удобен и полезен В2В и энтерпрайзу, ведь они точно не будут рассматривать покупку кота в мешке, каким бы красивым он ни был.
Если с В2С понятно, почему разработчики иногда вырезают часть функций из триальных версий, то с бизнесом могут возникнуть вопросики.
Как правило, для крупной компании триальная версия подбирается индивидуально: заказчик сообщает, для чего ему нужен продукт, а разработчик открывает доступ именно к тем функциям, которые помогут ему решить задачи. Это нужно для того, чтобы сформировать у потенциального заказчика реалистичное представление о возможностях продукта и что он получит после покупки.
Энтерпрайзы получают триалы по той же схеме, что и В2В, но в нее еще входит техподдержка и команда разработчиков, которые саппортят клиента и помогают развернуть триалку в его контуре, учитывая все пожелания и нюансы.
Управление лицензиями
Лицензирование — это не только процесс продажи софта, определение ограничений его работы, предоставление удобного инструмента для функционирования продукта на стороне клиента, но и соблюдение лицензионного договора. По этой причине среди клиентов (в основном западного рынка) востребовано наличие средств, позволяющих отслеживать и контролировать использование лицензий. К примеру, клиенты хотят быть защищены от ошибок по установке продукта на большее количество машин или использования большего количества ресурсов, чем предусмотрено лицензией.
Причина такого желания проста и понятна — даже если подобная ситуация произойдет из-за бага, юридическая ответственность все равно ляжет на клиента.
«Ключи» лицензирования
Серийные номера (ключи) чаще всего представляют из себя обычную строку, которая подтверждает, что копия программы является оригинальной.
NB! Стоит помнить, что покупка ключа не является гарантией того, что его использование является лицензионным, ведь кроме покупки ключа еще требуется и соблюдение лицензионного договора. Его нарушение может даже привести к аннулированию купленной лицензии, особенно в случае обращения к производителю.
Лицензия физически может быть файлом, скрытым где-то в системе, храниться в реестре или на отдельной железке, которая, например, может поставляться другой компанией. А может находиться на серверах компании, к которым пользователь должен подключаться для ее активации, или, например, на серверах Amazon или Azure. Эти детали тоже играют важную роль, потому что разная инфраструктура имеет разные ограничения и требования, которые нужно подстроить под заказчиков.
Физические ключи для хранения лицензий — штука дорогая. Цена некоторых из них доходит до 3-4 тыс. руб., плюс еще тысяча рублей за лицензию. Получается, что если твоя лицензия продается за 10 тыс. руб., то половину придется отстегнуть сторонней компании за ключ и лицензию (производитель ключа может продавать отдельно и сам ключ, и лицензию на его использование), и это не говоря еще о налогах. И возникает два логичных вопроса: зачем и не проще ли это сделать дешевле?
По-другому эта ситуация выглядит, когда речь идет о миллионном контракте с корпорацией. Тут уже цена в 5 тыс. руб. за ключ особо роли не играет, плюс разработчик точно уверен в его гарантии. И даже если заказчик что-то сломает, то разработчик не зажмется купить еще один.
Также стоит сказать, что используя физические ключи и SDK для них, разработчик получает готовую систему лицензирования, которую надо интегрировать в продукт. Такое решение сокращает время разработки и позволяет использовать навесную защиту продукта.
Варианты хранения лицензий
Раньше ключи для B2C-пользователей находились в файловом хранилище либо прятались в реестре. Этот вариант проще всего, но и чаще всего взламывается. Сейчас же компании в основном используют онлайн-лицензирование, когда клиент по сути ничем не владеет, подключается к продукту через интернет и пользуется им по принципу подписок.
С одной стороны, для клиентов такой вариант довольно удобен: он может пользоваться сервисом с разных девайсов из разных локаций, нужен лишь интернет. Но с другой стороны, есть вероятность потерять свои данные, потому что компании показалось, что ты нарушил лицензионный договор. Ну, и спиратить вряд ли получится, особенно если кроме лицензии и сам исполняемый код хранится на сервере компании :)
Для компании тоже есть плюсы и минусы: у разработчика больше возможностей регулировать то, как и чем пользуется клиент, но приходится поддерживать все ресурсы у себя.
Чаще всего такой вариант подходит многим пользователям, однако лучше все-таки оставлять для клиентов опции. Например, из-за пиратства Adobe Photoshop на одно время исключил лицензии, позволяющие работать без подключения к интернету. Пользователи софта взбунтовались, высказали недоверие к такой схеме и практически объявили бойкот. По итогу Adobe был вынужден вернуть в качестве опции предыдущий вариант лицензирования. Кстати, за последний год после ухода западных компаний мы сами убедились в хрупкости онлайн-подписок, а также в том, что все данные и лицензии в одно мгновение могут превратиться в тыкву.
Если говорить о бизнесе и энтерпрайзе, то тут все сложнее. К примеру, сотрудники банков сидят за закрытым периметром ввиду обеспечения безопасности данных. Служба безопасности банка точно не позволит подключать системы к стороннему софту вне контура компании, особенно если это подразумевает сбор и отправку какой-то информации и статистики. В этом случае можно договориться выделить специальную машину, на которую будут складываться данные об использовании, и специальный сотрудник компании будет раз в заданный период просматривать полученную информацию и по итогу давать добро на их отправку разработчику.
И самое главное — с каждым клиентом скорее всего придется провести разъяснительные встречи, в рамках которых необходимо будет показать и рассказать, как все работает, куда и зачем отправляются те или иные данные. Как бы странно это все ни звучало, но у компаний есть определенные правила безопасности, и чем она крупнее, тем эти правила жестче.
На что может повлиять лицензирование
В энтерпрайз-лицензировании многое зависит от того, что именно и в каком объеме продается. В зависимости от способа реализации лицензирование может требовать разных вариаций развертывания, например, выделение отдельного сервера или даже нескольких серверов, если офисы компании находятся в разных частях света.
Как правило, небольшие компании покупают «пакет» с ограниченными ресурсами, в крупных же компаниях эта потребность может быть кратно выше. Разработчик должен быть уверен, что архитектура его ПО сможет потянуть запросы клиента, прежде чем предлагать свой продукт.
Также существуют варианты ПО, которые работают по принципу Microsoft Office 365: софт развернут на мощностях компании-разработчика и позволяет пользователю работать с ним только через интернет, предварительно пройдя авторизацию в своем аккаунте.
А что делать, если у заказчика есть какие-то удаленные офисы без интернета, но новое ПО должно быть установлено и у них в обязательном порядке? Стандартный вариант с централизованным лицензированием и подключением всех серверов здесь явно не подойдет, например, из-за сетевых задержек, поэтому заказчику нужно иметь в этом офисе подходящие мощности для самостоятельного развертывания ПО.
К тому же, придется использовать такой вариант лицензирования, который бы позволил работать одной лицензии на одной машине. Но при таком раскладе можно только посочувствовать админу, который получит условно 500 строчек с серийными номерами и будет вводить их по отдельности для каждой машины, а потом следить, за каким сотрудником какой номер закреплен, и еще как-то это все администрировать, особенно учитывая отсутствие онлайн-подключения к такому офису.
Подсчет ресурсов
Для некоторых продуктов также важен подсчет ресурсов и место их хранения. К примеру, при продаже ContentCapture важным параметром является количество страниц, которые доступны клиенту для обработки в течение года. Чем больше страниц, тем выше производительность, и тем дороже лицензия. Логично, что в этом случае внутри модуля лицензирования должен быть их счетчик, который показывает клиенту сколько уже израсходовано, а сколько еще осталось. В данном случае чем больше страниц одновременно обрабатывает ПО, тем большее влияние окажет лицензирование на скорость работы.
Как только страницы заканчиваются, лицензия автоматически прекращает работу. Такой вариант удобен тем, что мониторинг лицензии происходит в контуре клиента. Он видит, что у него скоро закончатся страницы или истечет срок лицензии.
Однако при непродуманной реализации хранения всех данных локально есть риски. Если развернуть такое ПО в виртуальной среде, заказчик сможет откатить значение страниц к нулю, просто сделав SnapShot, и таким образом самостоятельно и бесплатно изменить условия лицензии. Эту проблему можно решить разными способами, например, с помощью онлайн-лицензирования.
Онлайн-лицензирование
При онлайн-лицензировании софт устанавливается локально, однако ПО должно периодически соединяться с серверами компании и получать разрешение на работу. Обычно со стороны пользователя на сервер разработчика поступают технические данные о работе программы (включая статистику), а сервер возвращает «разрешение на работу до очередной проверки». Периодичность таких подключений может быть разной: от ежечасной до полугодовой.
По истечении срока ПО либо автоматически обновляет лицензию самостоятельно, либо присылает пользователю соответствующее уведомление. Во время апдейта ПО может сформировать и сообщить разработчику некую статистику использования продукта.
Онлайн-лицензирование может стать решением многих проблем с работой ПО, однако у него есть три значимых ограничения.
Первое. Возможность в принципе запуститься. Для начала работы всегда нужно хотя бы раз подключиться к серверам компании для получения лицензии. А бывает, что разработчик требует подключения при каждом запуске программы.
Второе. Периоды обновления лицензий. Иными словами, как долго пользователю доступна работа без подключения к серверам разработчика и использование софта — бесконечно, до какой-то даты либо лишь на определенное количество дней или часов.
Третье. Конечные и бесконечные ресурсы. К примеру, бесконечная доступность какой-то фичи или продажа какого-то набора фичей или ресурсов, на которые установлено ограничение по использованию. Например, количество доступных страниц для распознавания.
Сублицензирование
Под сублицензированием подразумевается продажа софта третьими лицами. И в данном случае продавцу необходимо отчитаться и оплатить отчисления. К примеру, компания приобрела лицензию на SDK, встроила его в свой продукт и начала реализацию нового ПО. Компании необходимо посчитать, что именно из купленной лицензии вошло в новый продукт, и заплатить за пользование своему поставщику.
Поэтому в данном случае лицензирование — это не только некий учет взаимоотношений между разработчиком и клиентом, но и регулятор работы разработчика с поставщиками других лицензий.
