Для примера будем использовать наш продукт для просмотра топологии и верификации(EDA) и расскажем, как мы построили его лицензирование.

Каждый коммерческий продукт рано или поздно упирается в один вопрос: кому именно вы продаёте право пользоваться программой.

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

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

В этот момент плохо работает модель «один бинарь и проверка лицензии есть или нет».

Лицензировать нужно не бинарь, а права

У продукта может быть несколько независимых возможностей:

• просмотр;

• редактирование;

• экспорт;

• DRC;

• LVS;

• PEX;

• AI

• Прочие фичи

Нет смысла зашивать всё это в один вечный ключ. Каждое право должно быть отдельным параметром лицензии.

Тогда университет получает viewer и ограниченный набор функций, стартап получает trial, а предприятие полный пакет. Если дешёвая лицензия каким-то образом уедет за пределы организации, вместе с ней не уедет весь продукт.

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

А если у заказчика нет интернета?

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

Онлайн-активация здесь не работает.

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

Интернет для этого не нужен.

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

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

Получается простая схема: интернет не обязателен, криптография обязательна.

Где на самом деле теряются деньги

Крякнутый бинарь заметен сильнее всего, но это далеко не всегда самая большая финансовая проблема.

Гораздо дороже ситуации, когда платящий клиент использует больше, чем купил.

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

Здесь деньги уже есть. Клиент существует, бюджет есть, продукт ему нужен. Просто система лицензирования не умеет это контролировать.

Вторая проблема возникает, когда академическая или trial-лицензия постепенно превращается в коммерческую. Университет получил дешёвый доступ для обучения, а затем тот же ключ используется в реальной разработке.

Третья проблема проще: купили дешёвый тариф, а используют функции дорогого.

Например, лицензия разрешает просмотр, но каким-то образом остаётся доступен экспорт. Или есть редактор, но отсутствует право на коммерческий DRC. Такие случаи часто возникают не из-за взлома, а из-за ошибок в самой системе лицензирования.

И только после этого стоит говорить о полностью слитом или крякнутом бинаре.

Здесь тоже есть важное различие. Человек, который скачал программу с торрента, не обязательно является потерянным клиентом. Возможно, он никогда бы её не купил.

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

Например, BSA оценивала долю нелицензионного ПО в мире в 37%, а для Азии и Центральной и Восточной Европы показатель был значительно выше. Но это не означает, что разработчики потеряли 37% выручки. Нелицензионная установка и потерянная продажа это разные вещи.

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

Почему полный бинарь это плохая идея

Представим, что полная версия содержит viewer, редактор, экспорт, DRC, LVS и PEX.

Если она утекла и защиту удалось обойти, рынок получил весь продукт.

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

Поэтому функциональность лучше разделять ещё до появления проблемы.

Утёк viewer старой версии? Это неприятно, но не катастрофа.

Утекла версия с редактором, LVS, PEX и экспортом? Это уже намного серьёзнее.

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

Что делать, если бинарь уже утёк

После слива бессмысленно переписывать всю защиту в панике.

Сначала нужно понять, что именно утекло.

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

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

Кряк при этом полностью не исчезает. Но его можно сделать привязанным к конкретной версии.

И для инженерного ПО это особенно важно. Пользователю нужна не просто программа, а актуальные PDK, новые правила, исправления, новые версии движков, поддержку и совместимость.

Старая взломанная версия постепенно становится менее полезной сама по себе.

Как сделали мы

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

Снаружи доступен только API, который нужен клиенту. Прокси пропускает /api/*, а админка и внутренняя статика наружу не публикуются.

Клиент передаёт лицензионный ключ и идентификатор машины. Сервер возвращает подписанный токен с параметрами лицензии: тарифом, набором функций, количеством мест и сроком действия.

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

Viewer, редактор, экспорт, DRC, LVS и PEX проверяются независимо.

Это принципиальный момент. Мы не делаем один бинарь с условием license == true. Лицензия описывает конкретные права.

Закрытый контур

Для предприятий без интернета используется другой путь.

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

Обратно можно получить подписанный отчёт об использовании.

Если требуется постоянная работа внутри сети, сервер лицензирования устанавливается непосредственно у заказчика. Интернет ему не нужен.

Академические и пробные лицензии

Академический канал отделён от коммерческого.

У студента может быть короткий срок и ограниченный набор возможностей. У стартапа trial на несколько недель. Коммерческий клиент получает другой набор прав и другой срок.

Это позволяет не пытаться одной лицензией обслуживать все сценарии сразу.

Самообслуживание тоже отделено от license API. Регистрация trial, выпуск ключей, отвязка машины и продление происходят через пользовательский кабинет. Платёжная система сообщает об оплате, после чего лицензия продлевается автоматически.

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

В итоге

Получается не одна система лицензирования для всех, а три контура.

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

Внутри закрытого предприятия работает подписанный офлайн-файл или локальный сервер лицензирования.

У разработчика остаётся внутренняя админка для управления лицензиями, местами, офлайн-файлами и отчётами.

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

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

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