Покупка программы, подписка на облачный сервис или получение исходного кода от подрядчика сами по себе не означают переход исключительного права на ПО. Как правило, компания получает разрешение использовать продукт в определенных договором пределах. Передача доступа аффилированной компании, установка на большее число рабочих мест или доработка закрытого продукта за пределами согласованных условий могут нарушать права правообладателя.
В российском праве программа для ЭВМ охраняется как объект авторского права. Исключительное право обычно остается у разработчика или другого правообладателя, а пользователь получает простую (неисключительную) либо исключительную лицензию. Значение имеет не название договора, а конкретные способы использования, которые стороны в нем согласовали.
Что именно лицензируется
В коммерческом смысле ПО редко представляет собой единый объект. В состав цифрового продукта могут входить исполняемый код, библиотеки, интерфейс, документация, базы данных, шрифты, графика, API, модули сторонних поставщиков и компоненты с открытым исходным кодом. Для каждого элемента могут действовать свои права и лицензионные условия.
Формулировка «лицензия на программу» без идентификации продукта оставляет почву для спора. В договоре или приложении стоит закрепить:
- наименование, версию, редакцию и состав модулей;
- способ поставки: дистрибутив, личный кабинет, репозиторий или облачный доступ;
- территорию использования, если она ограничена;
- допустимое число пользователей, устройств, серверов, инсталляций или другие метрики;
- цель использования: внутренние нужды, коммерческая эксплуатация, встраивание в продукт, предоставление клиентам;
- разрешение или запрет на модификацию, декомпиляцию, интеграцию и создание производных решений;
- права на обновления, техническую поддержку и документацию.
Особого внимания требуют SaaS-модели. Пользователь нередко не получает копию программы, а работает с ее функциональностью через интернет. При этом нужно определить объем разрешенного использования: кто может работать в аккаунте, допустимо ли предоставлять доступ клиентам, как выгружаются данные после прекращения подписки и что происходит с резервными копиями.
Простая и исключительная лицензия: различие, которое влияет на бизнес
Простая лицензия позволяет лицензиату использовать ПО, при этом правообладатель сохраняет возможность пользоваться продуктом сам и предоставлять права другим лицам. Это стандартная модель для коробочных программ, корпоративных подписок, маркетплейсов и облачных сервисов.
Исключительная лицензия может предоставить лицензиату право использования в согласованных пределах с исключением других лиц. Но исключительность нельзя предполагать по умолчанию. В договоре нужно прямо указать способы использования, территорию и срок, право самого правообладателя продолжать эксплуатацию продукта, а также возможность выдачи сублицензий.
Если договор прямо не устанавливает исключительный характер лицензии, по российскому законодательству она предполагается простой. Это важно для инвестора или заказчика разработки: высокая цена не превращает неисключительное разрешение в передачу исключительного права.
Лицензионный договор и договор разработки нельзя смешивать
При заказной разработке компании часто считают, что оплата работ автоматически дает все права на результат. Это не так. Распределение исключительного права зависит от условий договора, статуса разработчика и обстоятельств создания продукта. Исполнитель может передать исключительное право, предоставить лицензию или сохранить права за собой, разрешив заказчику использовать результат в ограниченном объеме.
Если бизнес планирует развивать продукт другой командой, продавать его клиентам или привлекать инвестора, лучше заранее согласовать:
- кому принадлежат права на созданный код, дизайн, документацию и материалы;
- переходят ли права по мере приемки этапов или после полной оплаты;
- какие права подрядчик сохраняет на ранее созданные наработки;
- включены ли в результат сторонние компоненты и на каких условиях они используются;
- обязан ли исполнитель передать исходный код, ключи, инструкции по развертыванию и доступы;
- какие гарантии предоставляются в отношении прав третьих лиц.
Похожий вопрос возникает и в отношениях с работниками. Сам по себе трудовой договор с программистом не заменяет оформление служебных результатов. Чтобы снизить риски, нужны должностные обязанности, задания, порядок передачи результатов и документы, подтверждающие создание кода в рамках трудовой функции.
Ограничения использования: где возникают нарушения
Лицензионные ограничения должны быть измеримыми. Условие «только для внутренних нужд» может не покрывать использование программы при оказании услуг клиентам. Формулировка «до 100 пользователей» требует уточнения: учитываются ли временные аккаунты, подрядчики, администраторы и сотрудники дочерних обществ.
Передача доступа внутри группы компаний
Компании одной группы не становятся единым лицензиатом только из-за общего собственника. Если лицензию приобрела головная компания, использование продукта дочерним обществом, филиалом иностранной структуры или внешним подрядчиком может потребовать отдельного разрешения. Это можно предусмотреть перечнем разрешенных аффилированных лиц и понятным порядком их присоединения к условиям лицензии.
Доработка и интеграция
Право пользоваться программой не всегда включает право изменять исходный код, устранять ошибки силами третьего лица или встраивать продукт в собственную платформу. Отдельно проверьте условия о модификации, создании производных произведений, обратной разработке в пределах, допускаемых законом, и использовании API. Для критически важного корпоративного продукта стороны иногда согласуют передачу исходников или escrow-механизм.
| Условие | Что проверить |
|---|---|
| Срок лицензии | Дата начала, автопродление, последствия прекращения доступа |
| Территория | Использование сотрудниками и серверами за пределами указанной страны |
| Метрика оплаты | Пользователи, устройства, процессоры, выручка, запросы к API или иная единица |
| Сублицензия | Можно ли передавать права клиентам, партнерам и компаниям группы |
| Поддержка | Срок реакции, каналы связи, обновления, исключения из SLA |
Открытый код не означает отсутствие условий
Компоненты с открытым исходным кодом можно использовать только на условиях соответствующих лицензий. Одни лицензии требуют сохранять уведомления об авторстве, другие — раскрывать исходный код модификаций или производного продукта при распространении, третьи устанавливают специальные правила для сетевого взаимодействия. Риск обычно связан не с самим open source, а с отсутствием учета происхождения компонентов и лицензионных обязанностей.
Для коммерческого продукта полезно вести реестр компонентов: название, версия, источник, лицензия, назначение в продукте, ответственный сотрудник и обязательные уведомления. Такой реестр пригодится при аудите перед сделкой, выпуске новой версии или передаче решения крупному клиенту.
Как подтвердить предоставление и использование прав
В споре имеют значение не только условия договора, но и доказательства исполнения. Для лицензиара это могут быть акты, письма о предоставлении ключей, логи активации, счета и сведения из личного кабинета. Лицензиату пригодятся договор, приложения, платежные документы, подтверждение получения дистрибутива, переписка о разрешенном объеме использования и версии продукта.
При электронном заключении договора важно определить, какое действие считается акцептом: оплата счета, нажатие кнопки, ввод ключа или регистрация в сервисе. Условия, действовавшие на дату акцепта, стоит сохранять в неизменяемой редакции. Если правила размещены только на сайте и могут меняться без фиксации версий, доказать согласованный объем прав будет сложнее.
Практический порядок проверки перед подписанием
- Определите сценарий использования продукта на весь планируемый срок: сотрудники, клиенты, подрядчики, компании группы, зарубежные подразделения.
- Сопоставьте этот сценарий с конкретными способами использования в договоре, а не только с коммерческим предложением.
- Проверьте цепочку прав лицензиара, если приобретаются кастомное решение, исходный код или право перепродажи.
- Выделите сторонние и open source-компоненты, оцените совместимость их условий с моделью распространения вашего продукта.
- Зафиксируйте порядок приемки, обновлений, поддержки, прекращения доступа и выгрузки данных.
- Назначьте внутри компании ответственного за учет лицензий и контроль согласованных метрик.
Например, лицензия может разрешать работу только 50 именованным пользователям. Перед продлением проверьте не только число активных сотрудников: сопоставьте выгрузку учетных записей с тестовыми профилями, доступами подрядчиков и аккаунтами уволенных работников. Это позволит вовремя закрыть лишние доступы или согласовать расширение лицензии.
Материал носит информационный характер и не заменяет индивидуальную юридическую консультацию. Применимое право, условия договора и фактическая модель использования могут существенно повлиять на правовую оценку.