Большинство лицензионных нарушений в канале происходит не от намерения сэкономить, а от невнимательности: продали не тому типу заказчика, посчитали лицензии не по той метрике, использовали демонстрационную версию в бою или встроили компонент в своё решение без права на это. Проверка занимает полчаса и делается до отгрузки, а не после запроса на подтверждение соответствия.
Пять типичных мест
- Метрика подсчёта. На пользователя, на ядро, на устройство, на объём. Ошибка в метрике даёт расхождение в разы, и обнаруживается она при проверке.
- Тип заказчика. Академические, некоммерческие и государственные условия обычно дешевле и имеют ограничения по применению. Продажа коммерческой организации по такой цене — нарушение.
- Демонстрационные и тестовые лицензии. Остаются в рабочей среде после пилота. Формально это использование без права.
- Территория. Право продажи и право использования могут быть ограничены странами. Для регионального проекта это проверяется отдельно.
- Встраивание в своё решение. Право перепродать не равно праву включить компонент в состав собственного продукта.
Проверка перед отгрузкой
- Сверить метрику с фактической конфигурацией заказчика. Не с той, что в заявке, а с той, что будет развёрнута.
- Проверить тип заказчика и применимые условия. Отдельно для дочерних структур: они не всегда попадают под те же условия.
- Уточнить территорию использования. Если у заказчика есть филиалы за границей, это отдельный разговор с вендором.
- Зафиксировать срок и порядок продления. Автопродление без уведомления — источник конфликтов с заказчиком.
- Сохранить переписку с вендором. Письменное подтверждение условий от менеджера вендора — ваша защита при проверке.
Кто отвечает
| Ситуация | Кто обычно отвечает перед вендором |
|---|---|
| Заказчик развернул больше, чем купил | Заказчик, но репутационно и партнёр |
| Партнёр посчитал по неверной метрике | Партнёр |
| Партнёр продал по неприменимым условиям | Партнёр, вплоть до потери статуса |
| Тестовая лицензия осталась в бою | Обе стороны, разбирается по договору |
Что писать заказчику
В коммерческом предложении полезно отдельной строкой указать, по какой метрике посчитаны лицензии и при каком изменении конфигурации потребуется докупка. Это выглядит как лишняя строка, а работает как защита: через год при расширении заказчик не будет считать доплату вашей ошибкой.
Оговорка
Как считается метрика на конкретном примере
Заказчик просит лицензии на систему защиты для 120 сотрудников. Кажется очевидным: 120 лицензий. На практике вопросов оказывается больше.
Считается ли по пользователям или по устройствам? Если у половины сотрудников по два устройства, при подсчёте по устройствам нужно 180. Учитываются ли сервисные учётные записи? Обычно да, и их может быть ещё двадцать. Считаются ли подрядчики, работающие в системе заказчика? По большинству условий — да. Есть ли у заказчика филиалы, которые он не упомянул, потому что для него это одна компания?
Разница между 120 и 200 лицензиями — это разница между выигранным конкурсом и убыточным контрактом, если вы её обнаружите после подписания. Полчаса вопросов до расчёта стоят этой разницы.
Вопросы заказчику до расчёта
- Сколько сотрудников, сколько устройств, сколько сервисных учётных записей. Три разных числа.
- Есть ли подрядчики и внешние пользователи с доступом.
- Входят ли дочерние компании и филиалы, в том числе за границей.
- Планируется ли рост численности в течение срока лицензии. Лучше заложить сразу, чем докупать по более высокой цене.
- Какая среда: только рабочая или тестовая тоже. Тестовые среды по разным условиям бывают бесплатными, платными или требующими отдельного типа лицензии.
Что фиксировать письменно с вендором
| Что | Зачем |
|---|---|
| Расчёт количества с метрикой | Защита при проверке соответствия |
| Применимость условий к типу заказчика | Особенно для государственных и некоммерческих |
| Территория использования | Если у заказчика есть подразделения за границей |
| Право на встраивание, если оно нужно | Перепродажа и встраивание — разные права |
| Условия продления и индексации | Чтобы через год не объяснять заказчику неожиданный рост цены |
Отдельно про открытые компоненты в своём решении
Интеграторы часто собирают решение из открытых компонентов и продают его как своё. Здесь есть отдельный слой рисков, не связанный с вендорскими лицензиями. Часть открытых лицензий требует раскрытия исходного кода при распространении, часть запрещает предоставление продукта как сервиса третьим лицам, часть требует сохранения указания авторства в интерфейсе.
Практическая мера — вести перечень используемых компонентов с их лицензиями и обновлять его при каждом изменении состава. Это занимает время один раз и снимает вопрос, который иначе всплывает в самый неудобный момент — при продаже компании или при крупном контракте с проверкой.
Что делать при запросе на подтверждение соответствия
- Не игнорировать. Молчание трактуется хуже, чем любой ответ.
- Собрать документы до ответа. Договоры, счета, переписку с расчётами.
- Проверить самим раньше, чем проверят вас. Найденное самостоятельно почти всегда урегулируется мягче.
- Разграничить свою зону и зону заказчика. Если заказчик развернул больше купленного, это его ответственность, но подтвердить свою добросовестность придётся вам.
Частые вопросы
Полчаса проверки метрики и типа заказчика до отгрузки стоят дешевле, чем один разговор о несоответствии после. И почти всегда достаточно письменного подтверждения от вендора — просто его нужно попросить.
Материал обновлён 3 сентября 2026