EULA, SaaS Agreement и лицензия на программное обеспечение: какие права получает клиент

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

Такие споры возникают, когда договор ограничивается общей формулировкой о неисключительном праве использования. Она не отвечает на практические вопросы: кто может работать с продуктом, разрешен ли доступ аффилированным компаниям, можно ли подключать подрядчиков, устанавливать программу на несколько серверов или использовать ее при оказании услуг третьим лицам. Объем прав должен соответствовать способу поставки продукта. Для облачного SaaS, установленной на сервере клиента программы и white-label решения нужны разные договорные модели.

Чем SaaS отличается от лицензии на установленное ПО

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

В SaaS-модели программа остается в инфраструктуре поставщика. Клиент получает удаленный доступ к функциональности через браузер, приложение или API. Передача копии программного обеспечения для самостоятельной установки обычно не происходит.

Поэтому договор на SaaS часто сочетает несколько элементов: право доступа к сервису, оказание услуг, техническую поддержку, обработку данных и ограниченное разрешение использовать интерфейс и другие охраняемые элементы продукта. Название документа не меняет фактическую модель. Если соглашение называется лицензией, клиент не получает автоматически право скачать код, установить систему на собственный сервер или передать продукт другой компании.

Как выбрать договорную модель

Способ поставки определяет, какие права следует описать и какие ограничения будут иметь смысл.

Иногда одному продукту требуется несколько документов. B2B-клиент подписывает SaaS Agreement, его сотрудники принимают Terms of Use, а мобильная или desktop-версия дополнительно регулируется EULA. Условия этих документов не должны противоречить друг другу.

Какие права клиента нужно определить в договоре

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

Установить круг разрешенных пользователей

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

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

Для подрядчиков обычно разрешают доступ только при выполнении работ для клиента. Самостоятельное использование продукта в интересах других заказчиков в такую модель не входит.

Описать разрешенную цель использования

Формулировка для внутренних бизнес-целей подходит не каждому продукту. Она может запретить клиенту использовать систему при оказании услуг своим заказчикам, хотя именно для этого он приобретал решение.

Если продукт предназначен для агентств, консультантов, операторов платформ или managed service providers, договор должен разрешать обработку проектов конечных клиентов. При этом можно запретить перепродажу самого сервиса, создание конкурирующего продукта и предоставление самостоятельного доступа третьим лицам.

Зафиксировать технические ограничения

Объем лицензии можно рассчитывать по количеству пользователей, устройств, серверов, экземпляров, транзакций, проектов или API-запросов. Выбранный показатель должен быть измеримым и соответствовать ценообразованию. Нужно определить, считаются ли неактивные аккаунты, тестовые среды и резервные экземпляры. Если поставщик вправе проверять соблюдение лимитов, договор описывает источники данных, порядок уведомления и последствия превышения.

Определить срок и момент прекращения прав

Лицензия может действовать в течение подписки, согласованного периода или бессрочно. Слово perpetual не означает, что поставщик обязан бессрочно предоставлять поддержку, обновления и облачную инфраструктуру. Эти услуги регулируются отдельно.

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

Урегулировать передачу и сублицензирование

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

Право использования продукта конечными клиентами обычно требует разрешения на сублицензирование или иной договорной конструкции. Обычная корпоративная лицензия такого права не предоставляет. Для white-label и OEM-моделей также устанавливаются территория, каналы распространения и условия договоров с конечными пользователями.

Определить допустимые изменения и интеграции

Для on-premise продукта нужно указать, может ли клиент изменять настройки, создавать расширения и интегрировать систему с другим ПО. Доступ к API сам по себе не всегда разрешает копирование документации, массовое извлечение данных или создание конкурирующего интерфейса. Ограничения на декомпиляцию и обратную разработку должны учитывать применимое законодательство. В ЕС отдельные действия, необходимые для использования программы законным приобретателем или обеспечения совместимости, могут допускаться законом при выполнении установленных условий. Полный договорный запрет не всегда будет действительным.

Разделить права на продукт, данные и результаты

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

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

Какие ограничения можно установить

Поставщик может запретить копирование за пределами согласованного объема, передачу учетных данных, перепродажу сервиса, обход технических лимитов и использование продукта для создания конкурирующего решения. Ограничения должны быть конкретными и соответствовать архитектуре продукта.

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

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

Кто должен владеть правами на программное обеспечение

Поставщик вправе выдавать лицензию только в пределах принадлежащих ему прав. До запуска продаж нужно проверить договоры с основателями, штатными разработчиками и внешними подрядчиками. Оплата разработки сама по себе не всегда передает заказчику исключительные права. Отдельной проверки требуют open-source компоненты, коммерческие библиотеки, SDK, шрифты и сторонний контент. Их лицензии могут устанавливать правила распространения, указания авторства, передачи исходного кода или использования в коммерческом продукте.

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

Чем лицензионное соглашение отличается от EULA

EULA регулирует использование программы конечным пользователем. Такой документ обычно применяется к мобильным приложениям, desktop-программам, играм и другому ПО, которое пользователь скачивает или устанавливает.

B2B SaaS Agreement регулирует более широкий круг вопросов: доступ к облачному сервису, оплату, поддержку, доступность, обработку данных, ответственность и действия корпоративных пользователей. Замена такого договора короткой EULA оставляет без регулирования существенную часть отношений.

Если приложение распространяется через App Store или Google Play, EULA и условия использования нужно согласовать с правилами площадки. Платформа может устанавливать собственные положения об оплате, возвратах, подписках и стандартной лицензии конечного пользователя.

Типичные ошибки при лицензировании SaaS и ПО

Распространенная ошибка состоит в использовании одного шаблона для облачного и устанавливаемого продукта. В SaaS Agreement появляется право установить копию, хотя клиент не получает программу, а on-premise договор не определяет количество серверов и тестовых сред.

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

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

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

Что проверить перед подписанием договора

Поставщику нужно сопоставить лицензионные условия с архитектурой, тарифами и работой отдела продаж. Если продукт допускает несколько способов развертывания, для каждого из них следует определить отдельный объем прав.

Клиенту важно установить, охватывает ли договор все компании и людей, которые будут пользоваться системой, разрешена ли работа с данными конечных заказчиков и можно ли подключать подрядчиков. Для on-premise продукта дополнительно проверяются серверы, тестовые среды, резервные копии и право переноса при обновлении инфраструктуры.

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