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

Для личного использования такой функционал лицензии, наверное, достаточен — ввёл код, и приложение запустилось. Но корпоративное ПО — это не просто «включили и пользуемся».

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

Мы разрабатываем аналитическую платформу Luxms BI, которую, в том числе, используют крупные компании с большими объёмами данных и сложной ИТ‑инфраструктурой. Поэтому лицензирование для нас тема не абстрактная, а часть реальной эксплуатации корпоративного ПО.

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

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

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

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

Именно тогда мы и задумались, а почему лицензия вообще устроена именно так?

«Мы посмотрели на весь процесс: какие бумаги уходят во все стороны, кто их подписывает, что в них отражается, что важно для аудита. И решили просто сделать цифровые документы с подписями и шифрованием».

Дмитрий Дорофеев, главный конструктор ГК Luxms

Лицензия как цифровой документ

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

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

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

И если инфраструктуру сегодня описывают в виде кода — подход Infrastructure as Code, а конфигурацию хранят в Git — подход Configuration as Code, то почему лицензия должна жить по каким‑то другим правилам?

Так появилась идея, которую мы назвали Licensing as Code.

Как выглядит лицензия в модели Licensing as Code

Если лицензия представляет собой цифровые документы, возникает следующий вопрос — в каком виде они должны существовать?

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

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

  • сведения о правообладателе и заказчике

  • реквизиты лицензионного договора

  • срок действия лицензии

  • перечень лицензируемых ресурсов и состав модулей ПО

  • историю выделения ресурсов между инсталляциями

  • историю запросов на выделение лицензируемых ресурсов и их статусы

  • необходимая техническая информация

Как устроена лицензия внутри

Следующий вопрос, который мы задали себе — как передавать такую лицензию?

Мы специально решили использовать максимально простые и понятные всему ИТ‑сообществу технологии. Поэтому лицензия в подходе Licensing as Code — это npm‑пакет. Технически это архив.tgz, внутри которого находятся машиночитаемые документы в форматах JWT и JWE. JWT — это уже «скомпилированные» версии изначальных документов. Исходные файлы, конечно, существуют в виде JSON.

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

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

И, в‑третьих, пакет одинаково удобно передавать как онлайн, так и на съемном носителе. Это особенно важно для организаций, работающих в закрытых контурах без доступа к сети. Поэтому Licensing as Code с самого начала проектировался как система, не требующая постоянного подключения к Интернету. 

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

Почему Git оказался лучшим местом для лицензии

Оставалось решить еще одни вопрос, где хранить исходные файлы лицензий?

В нашем подходе лицензия — это обычный цифровой артефакт, он постоянно меняется, требует хранения истории версий, возможности аудита и восстановления предыдущих состояний. И ИТ‑индустрия уже давно придумала инструмент, который решает все эти задачи.

Git.

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

В модели Licensing as Code история становится такой же важной частью лицензии, как и ее текущее состояние. Каждое изменение, будь то продление лицензии, перераспределение пользователей между кластерами или подключение новой инсталляции, становится новой версией лицензионного пакета. При этом предыдущие версии не исчезают, а хранятся и могут быть восстановлены в любой момент.

Как это работает на практике

Важно, что лицензия не только просто устроена, но и проста в использовании.

После покупки продукта или обновления лицензии достаточно зайти в личный кабинет LuxTor, скачать лицензионный пакет и обычным drag‑and‑drop загрузить его в административный интерфейс BI.

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

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

На этом процесс завершен: лицензия обновлена, все изменения применены, а их история автоматически становится частью лицензионного пакета.

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

Почему нам не нужен лицензионный сервер

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

При создании нашей системы лицензирования мы сознательно отказались от такой архитектуры и дополнительных зависимостей.

«Сам факт, что заказчику нужно эксплуатировать отдельный лицензионный сервер, нам не нравится. Мы хотим отдать прикладной софт так, чтобы он просто работал. Чтобы это было serverless — просто обмениваемся файлами, документами, и всё работает».
Дмитрий Дорофеев, главный конструктор Luxms BI

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

Почему это важно для White Label

Поскольку технология лицензирования построена на открытых технологиях и не зависит от отдельного лицензионного сервера, она не привязана к конкретному вендору. И для White Label и OEM‑поставок это имеет значение.

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

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

Что меняет Licensing as Code

Мы считаем, что Licensing as Code — это новый взгляд на то, чем вообще является лицензия в мире ПО.

Сегодня никого не удивляют Infrastructure as Code или Configuration as Code, хотя когда‑то эти подходы тоже казались инновационными. Но со временем стало понятно, что инженерные артефакты гораздо лучше живут в виде кода, чем в виде набора разрозненных файлов и ручных операций.

Мы верим, что лицензирование проходит тот же путь — лицензия постепенно перестает быть ключом активации, а начинает «обрастать» своей историей, версиями и жизненным циклом. И в будущем необычным будет казаться уже не подход Licensing as Code, а сама идея того, что лицензия может быть просто ключом активации.