Ситуация «хочу выдать лицензию на софт, но боюсь потерять права» почти всегда связана не с самой лицензией, а с тем, что договор маскирует отчуждение, даёт слишком широкие способы использования или допускает сублицензию «в бесконечность». В итоге правообладатель теряет рычаги контроля: кто, где и как использует программу, можно ли менять условия, и кто получает деньги.
Дополнительный риск — доказательственный: если в договоре и переписке нет ясной модели (исключительная/неисключительная лицензия, территория использования, срок, вознаграждение, запрет на модификации и декомпиляцию), то при конфликте суд толкует не в пользу правообладателя или признаёт условия несогласованными. А несогласованность по ключевым условиям может обнулить ожидаемую защиту и усложнить взыскание задолженности.
Кратко по сути: Хочу выдать лицензию на софт, но боюсь потерять права
- Лицензия не равна отчуждению: исключительное право остаётся у правообладателя, если это прямо следует из текста и конструкции договора.
- Определите модель: неисключительная лицензия (по умолчанию безопаснее) или исключительная (нужна только при осознанной монетизации с «закреплением» клиента).
- Фиксируйте объём: способы использования, количество пользователей/инсталляций, территория использования, срок, версии и обновления.
- Контролируйте цепочку: запрет/лимит сублицензии, запрет передачи доступа третьим лицам, порядок аффилированных лиц и подрядчиков.
- Закладывайте доказательства: акты, отчётность по использованию, логирование, порядок приёмки, переписка и реестр версий.
Тактика и стратегия в ситуации: Хочу выдать лицензию на софт, но боюсь потерять права
Стратегия строится вокруг трёх контуров контроля: (1) юридический контур — чёткая квалификация договора как лицензионного и разделение с отчуждением; (2) коммерческий контур — вознаграждение, метрики использования, санкции и право приостановки; (3) доказательственный контур — документы и технические следы, подтверждающие объём использования и нарушение. В тексте договора я обычно «простраиваю» матрицу: вид лицензии (неисключительная/исключительная), территория использования, срок, способы использования (установка, запуск, доступ через API, SaaS), правила обновлений, допустимость модификаций и обратной разработки, а также режим сублицензии. Отдельно важно согласовать вознаграждение так, чтобы оно было проверяемым: фиксированная плата, плата за пользователя, за транзакцию, за сервер, по отчётам. Если клиент просит «максимально широкие права», это не повод отдавать контроль: широта может сочетаться с лимитами по цели использования, территориям и каналам распространения, а также с запретом на передачу прав «вниз по цепочке».
Нормативное регулирование и правовые институты
В РФ лицензионные договоры по программам для ЭВМ опираются на нормы гражданского законодательства об исключительных правах, лицензиях и авторском праве. Ключевые институты: исключительное право (как «пакет» правомочий правообладателя), простая (неисключительная) и исключительная лицензия, пределы использования результата интеллектуальной деятельности, вознаграждение и последствия нарушения, а также допустимость сублицензирования. Отдельно учитывается режим служебных результатов (если софт создавался в рамках трудовых отношений) и вопросы фиксации авторства/правообладания. Для некоторых объектов важна государственная регистрация, но по софту регистрация носит факультативный характер и чаще работает как усилитель доказательств, а не как условие возникновения права.
Как это работает на практике
Сценарий 1: Клиент просит «эксклюзив» ради инвестора
Ситуация: заказчик требует исключительную лицензию «на всё и навсегда». Риск/ошибка: по сути это превращается в квази-отчуждение, а вы теряете возможность лицензировать другим и развивать продукт. Верное решение: ограничить исключительность по территории использования и сфере (например, отрасль/рынок), установить срок с последующим пересмотром, запретить сублицензию без согласия, привязать вознаграждение к KPI и закрепить возвратность прав при существенном нарушении оплаты.
Сценарий 2: SaaS-доступ оформляют как «передачу копии программы»
Ситуация: доступ предоставляется через облако, но в договор вставляют формулировки про «передачу экземпляра» и «право распоряжения». Риск/ошибка: появляется почва для спора о передаче прав третьим лицам и о допустимости тиражирования. Верное решение: описать модель как предоставление права использования функционала (удалённый доступ), прописать ограничения по пользователям и интеграциям (API), запретить извлечение/копирование, установить требования к информационной безопасности и аудит доступа.
Сценарий 3: Партнёр-реселлер хочет сублицензировать конечным пользователям
Ситуация: реселлер просит право выдавать сублицензии без согласований. Риск/ошибка: вы теряете контроль над текстами конечных лицензий, ценой, ответственностью и территорией использования. Верное решение: разрешить сублицензию только по утверждённому шаблону, в пределах территории и сегмента, обязать вести реестр конечных клиентов, предусмотреть право аудита, запретить модификации и обратную разработку, закрепить солидарную ответственность реселлера за нарушения конечных пользователей.
Типичные ошибки в данной ситуации
- Подмена лицензии отчуждением через формулировки «передача исключительных прав», «право распоряжения» или «владение» без оговорок.
- Отсутствие чёткого перечня способов использования (включая облако, API, копирование, адаптацию, интеграции).
- Неопределённость по территории использования и сроку, из-за чего спор уходит в толкование и «разумные пределы».
- Сублицензия «по умолчанию» без лимитов и без контроля текста конечных условий.
- Смешение разработки/поддержки и лицензии в одном блоке без разграничения результатов и прав на них.
- Вознаграждение без измеримых метрик и без документов, подтверждающих объём использования и просрочку.
Что важно учитывать для защиты прав
Защита строится на заранее сформированной позиции правообладателя и доказательственной логике: кто является правообладателем (цепочка договоров с авторами, служебный режим, акты), что именно лицензируется (версия, модуль, исходный код или объектный, документация), в каком объёме и как фиксируется использование (акты, отчёты, логи, ключи, биллинг). Я рекомендую заранее предусмотреть процессуально «удобные» доказательства: обязательные отчёты лицензиата, право запросить подтверждающие документы, порядок уведомлений, электронный документооборот, а также договорные последствия нарушения (приостановка доступа, неустойка, расторжение, запрет дальнейшего использования). В случае спора важны аккуратные формулировки, исключающие двойное толкование, и разделение: лицензия отдельно, услуги отдельно, чтобы не спорить о том, «за что платили».
Практические рекомендации адвоката
- Сформулируйте цель сделки: продажи лицензии конечному пользователю, партнёрский канал (реселлинг), или корпоративная группа (аффилированные лица).
- Выберите вид лицензии и зафиксируйте это в преамбуле и предметe: «неисключительная лицензия» либо «исключительная лицензия» с ограничениями.
- Опишите объект: название ПО, версия, модули, окружение, документация; отдельно — обновления и новые релизы.
- Согласуйте объём: способы использования, территория использования, срок, количество пользователей/серверов, запреты на модификации/декомпиляцию.
- Настройте монетизацию и контроль: вознаграждение, отчётность, аудит, санкции, право приостановки, порядок расторжения и «выключения» доступа.
- Пропишите режим сублицензии (если нужен): только по шаблону, с реестром, лимитами и ответственностью партнёра.
- Проверьте правообладание до подписания: авторские договоры, служебные положения, наличие третьих компонентов и их лицензий.
Вывод
Выдать лицензию на софт и не потерять права возможно, если договор не оставляет «серых зон»: вид лицензии, объём и пределы использования, сублицензия, вознаграждение и доказательства контроля должны быть структурированы так, чтобы лицензия не превращалась в отчуждение и не позволяла неконтролируемое распространение.
В вашей сделке важнее всего контроль сублицензии и формулировки предмета — вы уже проверяли, нет ли в проекте договора фраз, которые читаются как отчуждение?
Информация актуальна по состоянию на июнь 2026.