У каждого разработчика хотя бы раз возникала мечта создать крутой продукт, который обязательно захотят купить (а не спиратить) все пользователи, а сам он станет богаче Илона Маска и будет запускать свои Falcon, но конечно же намного удачнее. Но чаще всего эта мечта спустя время разбивается о суровую реальность: софт почти никому не нужен из-за переполненного рынка, а если и нужен, то его постоянно пиратят, безжалостно и беспощадно. 

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

Триалы

Триалы — пробные версии продуктов, которые поставляются для всех пользователей — В2С, В2В и энтерпрайзу. Как правило, в триальных версиях функциональность софта ограничена для наглядного ознакомления с основными возможностями продукта. 

У триальных версий есть четыре основных типа. 

1. Некоторые рисковые разработчики открывают доступ В2С к полнофункциональным триалам, но единоразово при запуске программы или после каждого действия пользователю будет показываться окно, сообщающее, что он пользуется триальной версией продукта, а лицензионную копию можно купить там-то. Такой вариант лицензирования используют инди-разработчики или очень маленькие компании. Иногда это просто вариант лицензирования «доната на кружку кофе», что в общем-то одно и то же.

2. Разработчик вырезает из полнофункционального продукта бо́льшую часть фич, оставляя лишь базовый набор для работы с софтом. Чаще всего такой вариант предлагается категории В2С (все из-за того же пиратства, ведь защищаться всегда сложнее, чем лицензировать). В этом случае доступ к полнофункциональной версии необходимо запрашивать у разработчика.

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

4. Частный случай предыдущего — ограничение срока действия полнофункциональной лицензии. В действительности это не совсем триал. Это лицензия, у которой есть ограничение по времени, но за которую, условно, никто не просил денег, а дали попользоваться на какой-то период. Такой вариант удобен и полезен В2В и энтерпрайзу, ведь они точно не будут рассматривать покупку кота в мешке, каким бы красивым он ни был.

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

Как правило, для крупной компании триальная версия подбирается индивидуально: заказчик сообщает, для чего ему нужен продукт, а разработчик открывает доступ именно к тем функциям, которые помогут ему решить задачи. Это нужно для того, чтобы сформировать у потенциального заказчика реалистичное представление о возможностях продукта и что он получит после покупки.

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

Управление лицензиями

Лицензирование — это не только процесс продажи софта, определение ограничений его работы, предоставление удобного инструмента для функционирования продукта на стороне клиента, но и соблюдение лицензионного договора. По этой причине среди клиентов (в основном западного рынка) востребовано наличие средств, позволяющих отслеживать и контролировать использование лицензий. К примеру, клиенты хотят быть защищены от ошибок по установке продукта на большее количество машин или использования большего количества ресурсов, чем предусмотрено лицензией. 

Причина такого желания проста и понятна — даже если подобная ситуация произойдет из-за бага, юридическая ответственность все равно ляжет на клиента. 

«Ключи» лицензирования

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

NB! Стоит помнить, что покупка ключа не является гарантией того, что его использование является лицензионным, ведь кроме покупки ключа еще требуется и соблюдение лицензионного договора. Его нарушение может даже привести к аннулированию купленной лицензии, особенно в случае обращения к производителю.

Лицензия физически может быть файлом, скрытым где-то в системе, храниться в реестре или на отдельной железке, которая, например, может поставляться другой компанией. А может находиться на серверах компании, к которым пользователь должен подключаться для ее активации, или, например, на серверах Amazon или Azure. Эти детали тоже играют важную роль, потому что разная инфраструктура имеет разные ограничения и требования, которые нужно подстроить под заказчиков. 

Физические ключи для хранения лицензий — штука дорогая. Цена некоторых из них доходит до 3-4 тыс. руб., плюс еще тысяча рублей за лицензию. Получается, что если твоя лицензия продается за 10 тыс. руб., то половину придется отстегнуть сторонней компании за ключ и лицензию (производитель ключа может продавать отдельно и сам ключ, и лицензию на его использование), и это не говоря еще о налогах. И возникает два логичных вопроса: зачем и не проще ли это сделать дешевле?

По-другому эта ситуация выглядит, когда речь идет о миллионном контракте с корпорацией. Тут уже цена в 5 тыс. руб. за ключ особо роли не играет, плюс разработчик точно уверен в его гарантии. И даже если заказчик что-то сломает, то разработчик не зажмется купить еще один. 

Также стоит сказать, что используя физические ключи и SDK для них, разработчик получает готовую систему лицензирования, которую надо интегрировать в продукт. Такое решение сокращает время разработки и позволяет использовать навесную защиту продукта.

Варианты хранения лицензий

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

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

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

Чаще всего такой вариант подходит многим пользователям, однако лучше все-таки оставлять для клиентов опции. Например, из-за пиратства Adobe Photoshop на одно время исключил лицензии, позволяющие работать без подключения к интернету. Пользователи софта взбунтовались, высказали недоверие к такой схеме и практически объявили бойкот. По итогу Adobe был вынужден вернуть в качестве опции предыдущий вариант лицензирования. Кстати, за последний год после ухода западных компаний мы сами убедились в хрупкости онлайн-подписок, а также в том, что все данные и лицензии в одно мгновение могут превратиться в тыкву. 

Если говорить о бизнесе и энтерпрайзе, то тут все сложнее. К примеру, сотрудники банков сидят за закрытым периметром ввиду обеспечения безопасности данных. Служба безопасности банка точно не позволит подключать системы к стороннему софту вне контура компании, особенно если это подразумевает сбор и отправку какой-то информации и статистики. В этом случае можно договориться выделить специальную машину, на которую будут складываться данные об использовании, и специальный сотрудник компании будет раз в заданный период просматривать полученную информацию и по итогу давать добро на их отправку разработчику. 

И самое главное — с каждым клиентом скорее всего придется провести разъяснительные встречи, в рамках которых необходимо будет показать и рассказать, как все работает, куда и зачем отправляются те или иные данные. Как бы странно это все ни звучало, но у компаний есть определенные правила безопасности, и чем она крупнее, тем эти правила жестче.

На что может повлиять лицензирование

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

Как правило, небольшие компании покупают «пакет» с ограниченными ресурсами, в крупных же компаниях эта потребность может быть кратно выше. Разработчик должен быть уверен, что архитектура его ПО сможет потянуть запросы клиента, прежде чем предлагать свой продукт.

Также существуют варианты ПО, которые работают по принципу Microsoft Office 365: софт развернут на мощностях компании-разработчика и позволяет пользователю работать с ним только через интернет, предварительно пройдя авторизацию в своем аккаунте.

А что делать, если у заказчика есть какие-то удаленные офисы без интернета, но новое ПО должно быть установлено и у них в обязательном порядке? Стандартный вариант с централизованным лицензированием и подключением всех серверов здесь явно не подойдет, например, из-за сетевых задержек, поэтому заказчику нужно иметь в этом офисе подходящие мощности для самостоятельного развертывания ПО. 

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

Подсчет ресурсов

Для некоторых продуктов также важен подсчет ресурсов и место их хранения. К примеру, при продаже ContentCapture важным параметром является количество страниц, которые доступны клиенту для обработки в течение года. Чем больше страниц, тем выше производительность, и тем дороже лицензия. Логично, что в этом случае внутри модуля лицензирования должен быть их счетчик, который показывает клиенту сколько уже израсходовано, а сколько еще осталось. В данном случае чем больше страниц одновременно обрабатывает ПО, тем большее влияние окажет лицензирование на скорость работы.

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

Однако при непродуманной реализации хранения всех данных локально есть риски. Если развернуть такое ПО в виртуальной среде, заказчик сможет откатить значение страниц к нулю, просто сделав SnapShot, и таким образом самостоятельно и бесплатно изменить условия лицензии. Эту проблему можно решить разными способами, например, с помощью онлайн-лицензирования.

Онлайн-лицензирование 

При онлайн-лицензировании софт устанавливается локально, однако ПО должно периодически соединяться с серверами компании и получать разрешение на работу. Обычно со стороны пользователя на сервер разработчика поступают технические данные о работе программы (включая статистику), а сервер возвращает «разрешение на работу до очередной проверки». Периодичность таких подключений может быть разной: от ежечасной до полугодовой. 

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

Онлайн-лицензирование может стать решением многих проблем с работой ПО, однако у него есть три значимых ограничения. 

Первое. Возможность в принципе запуститься. Для начала работы всегда нужно хотя бы раз подключиться к серверам компании для получения лицензии. А бывает, что разработчик требует подключения при каждом запуске программы.

Второе. Периоды обновления лицензий. Иными словами, как долго пользователю доступна работа без подключения к серверам разработчика и использование софта — бесконечно, до какой-то даты либо лишь на определенное количество дней или часов. 

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

Сублицензирование

Под сублицензированием подразумевается продажа софта третьими лицами. И в данном случае продавцу необходимо отчитаться и оплатить отчисления. К примеру, компания приобрела лицензию на SDK, встроила его в свой продукт и начала реализацию нового ПО. Компании необходимо посчитать, что именно из купленной лицензии вошло в новый продукт, и заплатить за пользование своему поставщику.

Поэтому в данном случае лицензирование — это не только некий учет взаимоотношений между разработчиком и клиентом, но и регулятор работы разработчика с поставщиками других лицензий.