Лицензионный договор на программы для ЭВМ: обязательные условия и права
Обычно всё начинается с невинной фразы: «Мы вам дадим доступ, просто подпишите лицензию». И вот уже в почте лежит лицензионный договор на двадцать страниц, где половина пунктов написана так, будто автор очень хотел, чтобы его не поняли. У разработчика горят сроки релиза, у заказчика горят нервы, а бухгалтер тихо спрашивает про НДС по лицензионному договору и смотрит так, словно вы сейчас вместе будете отвечать перед вселенной.
Я видела, как лицензионные договоры заключенные «на коленке» всплывают спустя полгода, когда команда меняется, проект растёт, и внезапно выясняется, что право использования по лицензионному договору было только на один сервер, а у вас теперь три окружения, тестовый контур и ещё облако. Или, наоборот, лицензиат «пожадничал» и решил, что раз заплатил, то исключительное право уже его, ну а что, логично же. А потом начинается переписка, где все одновременно правы и одновременно нет.
Зачем вам этот гайд и что вы сможете сделать после
После чтения у вас будет понятная схема: как собрать условия лицензионного договора так, чтобы он работал в реальной жизни, а не только в папке «Договоры_финал_самыйфинал». Я пройдусь по шагам: от предмета (какую именно программу вы лицензируете) до сроков, территории, вознаграждения по лицензионному договору и того, где нужна регистрация лицензионного договора, а где люди зря тратят время. По дороге зацепим права по лицензионному договору, передачу прав по лицензионному договору и типичные ловушки, когда договор превращается в мину с таймером.
Пошагово: как «собрать» рабочий лицензионный договор на ПО
Шаг 1. Называем программу по имени и фамилии, а не «софт»
Первое, что делаем: фиксируем предмет. Не «программное обеспечение», не «платформа», не «система», а конкретная программа для ЭВМ, версия, сборка, иногда даже хэш или номер релиза, если у вас строгая разработка. Зачем: предмет договора это то самое обязательное условие, без него лицензионный договор вобще трудно «приземлить» к реальному продукту. Типичная ошибка: указывают название маркетинговое, а в репозитории и актах оно другое, и потом спорят, что именно лицензировали. Проверка простая: откройте договор и спросите техлида, может ли он по тексту понять, что именно надо поставить и где это взять. Если техлид морщит лоб, значит предмет описан туманно.
Мини-кейс. У клиента был сервис для логистики, часть функций работала как отдельный модуль, а часть как веб-интерфейс. В договоре написали «передается лицензия по лицензионному договору на программу», без уточнений, и через два месяца заказчик потребовал «всё, что относится к системе», включая модуль, который вообще-то продавался отдельно. Потеряли неделю на переписку и правки, хотя можно было сразу обозначить, что лицензируется базовая версия, а модуль это отдельный предмет.
Шаг 2. Определяем: исключительный лицензионный договор или нет
Дальше решаем, какая именно лицензия: исключительная или простая (неисключительная). Исключительный лицензионный договор звучит красиво, но он про то, что право использования предоставляется так, что у лицензиара появляются ограничения на выдачу прав другим. И вот тут важная мысль: лицензионный договор исключительное право не передаёт, он даёт лицензию. Передача исключительного права это уже другой жанр, и люди путают эти вещи с упорством, достойным лучшего применения.
Зачем это делать на берегу: от типа лицензии зависят и права по лицензионному договору, и конфликтность в будущем. Типичная ошибка: пишут «исключительная лицензия», а потом добавляют, что лицензиар может выдавать права кому угодно, то есть сами себе противоречат. Как проверить, что всё работает: перечитайте раздел о правах лицензиара и лицензиата и задайте один вопрос, может ли лицензиар выдавать такие же права другим. Если ответ «да», у вас не исключительная конструкция, как бы она ни называлась в заголовке.
Шаг 3. Выписываем способы использования, иначе их «дорисуют» в споре
Самое скучное, но обязательными условиями являются не только предмет и деньги. В лицензии критично прописать способы использования: установка, воспроизведение, запуск на сервере, предоставление доступа пользователям, распространение, переработка, интеграции через API. Это и есть лицензионный договор на использование по, в нормальном, рабочем смысле: что конкретно можно делать. Зачем: если способ использования не указан, потом начинается творчество: «а мы думали, можно копировать на все ноутбуки отдела», «а мы думали, можно встраивать в свой продукт».
Типичная ошибка: берут шаблон, где перечислено «воспроизведение и распространение», хотя у вас SaaS и вообще нет распространения, есть доступ через браузер. Или наоборот, у вас дистрибутив для клиентов, а договор молчит про распространение, и формально право использования по лицензионному договору на этот способ не выдано. Проверка: сопоставьте реальные действия команды и пользователей с текстом. Если у вас облачная модель, в договоре должна быть логика доступа, аккаунтов, ограничений по пользователям или устройствам, иначе спор о «перерасходе лицензий» будет бесконечным.
Шаг 4. Территория и срок лицензионного договора: скучно, но спасает в конфликте
Территория использования звучит для IT смешно: интернет же. Но в лицензионном договоре территория это не про кабели, а про то, где разрешено использовать программу. Зачем: некоторые бизнесы привязаны к региону, у кого-то отдельные рынки, у кого-то экспорт, а у кого-то наоборот санкционные риски и внутренние ограничения. Часто думают, что если территорию не указать, «значит везде». Иногда так и живут, пока не появляется дистрибьютор в другой стране и не начинается: «а мы вам это не разрешали».
Срок лицензионного договора тоже лучше не оставлять «по умолчанию». Он может быть ограниченным или бессрочным, и это важно для планирования расходов, поддержки и, да, для того, чтобы нормально расстаться. Типичная ошибка: подписка на год, а в договоре внезапно бессрочное право использования, и лицензиар потом не может объяснить, за что берёт ежемесячный платёж. Проверка: откройте раздел «срок» и сопоставьте с вашей моделью монетизации. Если у вас подписка, срок и условия продления должны быть читаемыми, без квестов.
Шаг 5. Вознаграждение, НДС и документы: чтобы бухгалтер не плакал
Вознаграждение по лицензионному договору это ещё одно обязательное условие, и его нельзя прятать в переписку «в Телеге договорились». Фиксируйте сумму, валюту, порядок оплаты, что считается фактом предоставления лицензии: акт, доступ в личный кабинет, ключ, письмо с ссылкой. Зачем: споры чаще всего не про код, а про «нам не предоставили» или «мы не обязаны платить, потому что не подписали акт».
Типичная ошибка: договором предусмотрен акт, но по факту его никто не подписывает, потому что доступ выдали автоматически. А потом расторжение, долг, и стороны внезапно понимают, что доказательства слабые. Отдельно всплывает НДС по лицензионному договору: это вопрос налогообложения и формулировок, и его лучше согласовать с бухгалтером заранее, а не на этапе «срочно выставляем счёт». Проверка: смоделируйте ситуацию, где через два месяца вы идёте в суд или на претензионку и вам нужно доказать, что лицензия предоставлена и за что платили. Если доказать нечем, перепишите документооборот.
Мини-кейс. У небольшой студии на 12 человек был договор на доступ к системе аналитики для маркетплейса. Платили ежемесячно, доступ выдавался автоматически, актов не было. Когда клиент перестал платить, студия попыталась взыскать задолженность, а в договоре акт был обязательным. В итоге потратили время на восстановление доказательств через логи и переписку, и всё это выглядело неубедительно. Исправили просто: прописали, что факт предоставления лицензии подтверждается созданием аккаунта и доступом, а акт подписывается только по запросу.
Шаг 6. Права, запреты и «передача прав по лицензионному договору»
Теперь про то, что обычно прячут в середине: права и обязанности сторон. Тут важно честно указать права по лицензионному договору, а ещё ограничения: можно ли делать копии, можно ли давать доступ подрядчикам, можно ли сублицензировать. Запрет на сублицензирование часто ставят по умолчанию, но если у лицензиата есть интегратор или аутсорс, то запрет убивает проект на ровном месте. Зачем: вы предотвращаете ситуацию, когда лицензиат «раздаёт» программу партнёрам, а лицензиар потом ловит это по следам на форумах.
Типичная ошибка: путают передачу прав по лицензионному договору с уступкой исключительного права. В лицензии вы можете разрешить или запретить передавать право использования третьим лицам, но это не делает третье лицо владельцем исключительного права. Проверка: посмотрите, есть ли в договоре пункт о подрядчиках и аффилированных лицах. Если нет, а в проекте участвуют внешние команды, вы почти гарантированно получите нарушение «по формальным признакам», даже если все были добросовестны.
Шаг 7. Регистрация лицензионного договора: когда нужна, а когда это лишнее движение
В российской реальности регистрация лицензионного договора всплывает в разговорах постоянно, и тут важно не перепутать объекты. Для программ для ЭВМ чаще всего достаточно правильно оформленного договора и доказательств предоставления права использования. Но если вы параллельно выдаёте лицензионный договор на товарный знак, тогда тема регистрации становится практической: по товарным знакам лицензии обычно регистрируют в Роспатенте, иначе для третьих лиц договор может «не существовать» в нужном смысле. Товарный знак по лицензионному договору это отдельная головоломка, особенно если знак стоит на сайте и в интерфейсе программы.
Типичная ошибка: в одном документе смешивают лицензию на ПО и лицензионный договор на товарный знак, а потом не понимают, что часть условий надо тянуть в регистрацию, а часть нет. Как проверить: перечислите объекты в договоре. Если среди них есть зарегистрированный товарный знак и вы даёте право использования знака, продумайте регистрацию лицензионного договора и согласуйте это заранее, чтобы не тормозить запуск. Для брендов и интерфейсов это прям частая история.
Мини-кейс. Интернет-магазин запускал собственную программу для партнёров и разрешал использовать логотип в личных кабинетах и на наклейках для посылок. Программу лицензировали быстро, а на бренд махнули рукой. Через пару месяцев партнёр начал печатать логотип на рекламе без контроля качества, и это выглядело, мягко говоря, криво. Пришлось отдельно договариваться про лицензионный договор на товарный знак, контроль и ограничения, и да, доводить историю до регистрации.
Подводные камни: где чаще всего ломается даже хороший договор
Самая болезненная зона это расплывчатые условия лицензионного договора про обновления и поддержку. Люди пишут «обновления предоставляются», но не уточняют, какие, как часто, входят ли критические фиксы, что считается новой версией, а что просто патчем. Потом лицензиат ожидает вечную эволюцию продукта, а лицензиар имел в виду только исправление багов в рамках текущей версии. Проверяйте: если обновления важны, зафиксируйте порядок, сроки реакции и хотя бы рамки. Не надо превращать договор в SLA на сто страниц, но и «по возможности» это прям билет в спор.
Вторая зона это права на доработки и интеграции. В проектах, где ПО внедряют под себя, всегда появляются скрипты, коннекторы, отчёты, кастомные модули. Если не зафиксировать, кому принадлежат права на эти элементы и кто может их использовать дальше, конфликт неизбежен. Часто думают, что «раз мы оплатили, значит это наше», но исключительные права по лицензионному договору на доработки не возникают автоматически, и это надо оформлять отдельно или хотя бы проговаривать в тексте. Проверяйте: любой кусок кода, который пишется в рамках проекта, должен быть либо явно включён в режим лицензии, либо оформлен как отчуждение, либо как отдельная разработка с передачей прав.
Третья зона это смешанные объекты: программа плюс база данных, плюс контент, плюс бренд. В договор добавляют всё подряд, а потом стороны спорят, что именно было предоставлено «по лицензионному договору» и где чьё исключительное право. Я иногда предлагаю разделять: лицензия на программу отдельно, права на контент отдельно, товарный знак по лицензионному договору отдельно, даже если это один пакет услуг. Да, бумаг больше, зато меньше сюрпризов в момент, когда у вас уже конфликт и никто не хочет быть добрым.
Когда стоит подключать юристов и патентных специалистов, а не героически тащить самому
Если у вас простая подписка на типовой софт и вы покупатель, иногда достаточно внимательно прочитать и задать пару вопросов про срок лицензионного договора, ограничения и оплату. Но когда у вас свой продукт, партнёрская сеть, интеграторы, маркетплейсы, использование бренда в интерфейсе, тогда один кривой пункт может стоить месяцев. Особенно там, где рядом появляется лицензионный договор исключительное право, совместная разработка или спор про «кому что принадлежит».
Мне нравится формат, когда специалист не пишет «идеальный договор на все случаи жизни», а помогает собрать живую конструкцию: что реально делает пользователь, какие способы использования нужны, где узкие места, и нужна ли регистрация лицензионного договора для товарного знака. Если вы параллельно думаете про защиту бренда, полезно держать под рукой сервисы и практику по Регистрация товарного знака и истории про Монополия на бренд, а по комплексным вопросам иногда выручает Юридическая защита интеллектуальной собственности. И да, чтобы не пропускать новости и разборы кейсов, у нас есть Telegram-канал и отдельная ссылка, если удобнее так: Телеграмм канал Патентного бюро Лирейт».
FAQ
Вопрос: Какие условия обязательны в лицензии на программу для ЭВМ, чтобы договор не развалился?
Ответ: Обычно обязательное условие это предмет (какая программа и какая версия), способы использования, срок, территория и вознаграждение по лицензионному договору. Плюс стоит нормально прописать права и обязанности, иначе спор будет не про право, а про «кто что имел в виду».
Вопрос: Чем отличается исключительный лицензионный договор от передачи исключительного права?
Ответ: Исключительная лицензия даёт право использования с ограничениями для лицензиара на выдачу прав другим, но не делает лицензиата владельцем исключительного права. Передача исключительного права это отдельный договор, где право переходит к другому лицу целиком.
Вопрос: Нужно ли подписывать акт, если доступ к ПО выдаётся автоматически?
Ответ: Можно, но не всегда. Важно, чтобы договор описывал, что считается предоставлением лицензии по лицензионному договору: создание аккаунта, выдача ключа, открытие доступа. Если в договоре акт обязателен, а в жизни его никто не подписывает, это слабое место.
Вопрос: Что такое использование лицензионного договора «не по назначению» и чем это грозит?
Ответ: Это когда программа используется вне оговорённых способов: ставят на большее число устройств, дают доступ третьим лицам, распространяют дистрибутив, модифицируют без разрешения. Последствия зависят от договора: от расторжения до взысканий, а иногда ещё и блокировка доступа в самый неподходящий день.
Вопрос: Когда нужна регистрация лицензионного договора?
Ответ: Чаще всего вопрос регистрации всплывает, если в договор включён зарегистрированный объект вроде товарного знака и предоставляется право его использования. Тогда регистрация лицензионного договора в Роспатенте становится практичной процедурой. Для самой программы для ЭВМ обычно важнее корректный договор и доказательства предоставления прав.
Вопрос: Можно ли в одном документе оформить лицензию на ПО и лицензионный договор на товарный знак?
Ответ: Можно, но это рискованнее: разные режимы, разные требования, разные последствия. Если у вас товарный знак по лицензионному договору реально используется, лучше заранее продумать, как вы будете оформлять и при необходимости регистрировать эту часть, чтобы не тормозить проект позже.
Вопрос: Как понять, что права по лицензионному договору описаны достаточно конкретно?
Ответ: Возьмите реальный сценарий: кто ставит, где запускает, сколько пользователей, есть ли подрядчики, есть ли облако, есть ли распространение. Если всё это можно «прочитать» из договора и не додумывать, значит права и ограничения описаны нормально. Если половина сценариев остаётся в серой зоне, лучше переписать, пока все в нормальных отношениях.