Лицензионный договор на программное обеспечение: как защитить свой IT-продукт

Вы разработали программу, приложение или SaaS-сервис — и теперь хотите легально передать право на использование клиентам, партнёрам или дистрибьюторам? Без грамотного лицензионного договора на ПО каждая передача копии — это юридический риск: от несанкционированного копирования до полной потери контроля над продуктом. В этой статье разбираем, как составить лицензионный договор, который действительно защищает ваш IT-продукт.

Что такое лицензионный договор на ПО и зачем он нужен

Лицензионный договор (он же лицензия на программное обеспечение, или EULA — End User License Agreement) — это соглашение, по которому правообладатель (лицензиар) предоставляет пользователю (лицензиату) право использовать программу в определённых пределах.

Важно: без лицензионного договора любое использование вашей программы третьими лицами формально является нарушением авторских прав (ст. 1235 ГК РФ).

Что лицензия решает для правообладателя:

• Контроль над способами использования — вы определяете, что именно лицензиат может делать с вашей программой.
• Монетизация — фиксация стоимости, порядка оплаты, модели (подписка, разовый платёж, freemium).
• Защита от копирования и реверс-инжиниринга — прямой запрет в договоре + правовые основания для взыскания убытков.
• Ограничение ответственности — чёткие рамки гарантий и отказ от ответственности за косвенные убытки.

Виды лицензий на ПО: исключительная и неисключительная

Гражданский кодекс РФ выделяет два основных вида лицензий (ст. 1236 ГК РФ). Выбор между ними определяет всю коммерческую стратегию вашего продукта.

Неисключительная лицензия (простая)

Это самый распространённый вид лицензии для массового ПО.

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

Когда подходит:

• SaaS-сервисы и облачные платформы
• Мобильные приложения
• Коробочное ПО для массового рынка
• Корпоративные лицензии с множеством пользователей

Важная презумпция: если в договоре прямо не указано, что лицензия является исключительной, она считается неисключительной (п. 2 ст. 1236 ГК РФ).

Исключительная лицензия

Суть: лицензиар не вправе выдавать лицензии другим лицам в тех пределах, в которых право предоставлено лицензиату.

Когда подходит:

• Заказная разработка для конкретного клиента
• Стратегическое партнёрство с единственным дистрибьютором на определённой территории
• Передача прав на модуль или компонент для интеграции в продукт партнёра

Риск для правообладателя: выдав исключительную лицензию, вы сами теряете возможность использовать продукт в указанных пределах (если иное не установлено договором). Поэтому исключительные лицензии требуют особенно тщательной проработки.

Сравнительная таблица

Обязательные условия лицензионного договора на ПО

Гражданский кодекс устанавливает перечень условий, без которых лицензионный договор считается незаключённым (ст. 1235 ГК РФ). Однако для реальной защиты IT-продукта базового набора недостаточно — нужны дополнительные пункты, учитывающие специфику программного обеспечения.

Обязательные по закону (существенные условия)

1. Предмет договора — описание ПО

Программу необходимо идентифицировать так, чтобы не было двусмысленности:

• Наименование программы
• Версия и номер сборки
• Функциональное описание (или ссылка на документацию)
• Свидетельство о регистрации в Роспатент (если есть)

Пример формулировки: «Лицензиар предоставляет Лицензиату право использования программы для ЭВМ „ProjectFlow" (версия 3.2, свидетельство о государственной регистрации № 2024612345), описание функциональных характеристик которой приведено в Приложении № 1 к настоящему Договору.»

2. Способы использования

Необходимо прямо указать, какие именно способы использования разрешены (ст. 1270 ГК РФ):

• Воспроизведение (установка на устройство)
• Запуск и функциональное использование
• Распространение (если разрешается сублицензирование)
• Модификация (доработка, адаптация — обычно запрещена)

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

3. Размер вознаграждения (или указание на безвозмездность)

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

Дополнительные критически важные условия для ПО

4. Территория действия

Если территория не указана, лицензия действует на всей территории РФ. Для международных проектов территорию нужно определять явно.

5. Срок действия

Если срок не указан, договор считается заключённым на 5 лет (п. 4 ст. 1235 ГК РФ). Для подписочных моделей критически важно прописать точный срок и условия продления.

6. Техническая поддержка и обновления

Отдельно оговорите:

• Включена ли техподдержка в стоимость лицензии
• Обязан ли лицензиар предоставлять обновления
• На каких условиях предоставляются новые версии

7. Гарантии и ограничение ответственности

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

Ограничения использования: как установить «правила игры»

Раздел ограничений — это сердце защиты вашего IT-продукта. Именно здесь вы устанавливаете границы, за которые лицензиат не может выходить.

Типовые ограничения, которые стоит включить

Запрет на обратную разработку (реверс-инжиниринг)

Пример формулировки: «Лицензиату запрещается осуществлять декомпиляцию, дизассемблирование, обратную разработку Программы или иным образом пытаться получить исходный код Программы, за исключением случаев, прямо разрешённых применимым законодательством.»

Обратите внимание: ст. 1280 ГК РФ разрешает декомпиляцию исключительно для достижения совместимости с другими программами и только при определённых условиях. Полный запрет, противоречащий этой норме, будет ничтожным в соответствующей части.

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

Без прямого запрета лицензиат формально не может выдавать сублицензии (право на сублицензию должно быть прямо предусмотрено договором). Однако явный запрет на передачу доступа, учётных записей, копий программы — дополнительная страховка.

Ограничение количества пользователей / устройств

• Лимит на число одновременных пользователей
• Привязка к конкретным устройствам или серверам
• Различие между именованными пользователями и конкурентными лицензиями

Запрет на использование в определённых целях

• Использование только в коммерческих / только в некоммерческих целях
• Запрет на использование для создания конкурирующих продуктов
• Ограничения по отрасли или сфере применения

Запрет на модификацию и создание производных произведений

Пример: «Лицензиат не вправе модифицировать, адаптировать, переводить Программу, создавать на её основе производные произведения, а также включать Программу или её части в состав иного программного обеспечения без предварительного письменного согласия Лицензиара.»

Техническая защита как дополнение к юридической

Лицензионный договор работает значительно эффективнее в связке с техническими средствами защиты:

• Лицензионные ключи и активация — контроль количества установок
• DRM-системы — защита от копирования
• Облачная привязка — SaaS-модель исключает физическое копирование
• Аудит использования — право лицензиара проверять соблюдение условий

Правовой бонус: обход технических средств защиты авторских прав сам по себе является правонарушением (ст. 1299 ГК РФ), что даёт дополнительные основания для защиты.

Ответственность за нарушение лицензионного договора

Гражданско-правовая ответственность

Компенсация вместо убытков

Для правообладателя ПО предусмотрен удобный механизм — вместо доказывания конкретного размера убытков можно потребовать компенсацию (ст. 1301 ГК РФ):

• от 10 000 до 5 000 000 рублей — на усмотрение суда;
• в двукратном размере стоимости контрафактных экземпляров;
• в двукратном размере стоимости права использования, определяемой исходя из цены, которая обычно взимается за аналогичное использование.

Договорная неустойка

В лицензионный договор можно включить штрафные санкции за конкретные нарушения:

• Превышение количества пользователей
• Использование после истечения срока лицензии
• Передача доступа третьим лицам

Пример: «В случае превышения Лицензиатом допустимого количества пользователей Программы Лицензиат обязуется уплатить штраф в размере трёхкратной стоимости лицензии за каждого дополнительного пользователя.»

Уголовная ответственность

За использование контрафактного ПО в крупном размере предусмотрена уголовная ответственность по ст. 146 УК РФ:

• Крупный размер — свыше 100 000 рублей
• Особо крупный — свыше 1 000 000 рублей
• Наказание — штраф до 200 000 рублей или лишение свободы до 6 лет

Административная ответственность

Статья 7.12 КоАП РФ предусматривает штрафы за нарушение авторских прав:

• Для граждан — от 1 500 до 2 000 рублей
• Для должностных лиц — от 10 000 до 20 000 рублей
• Для юридических лиц — от 30 000 до 40 000 рублей

Досудебные механизмы

Практичный договор должен содержать:

• Право на одностороннее расторжение лицензии при нарушении условий (с указанием порядка уведомления)
• Право на блокировку доступа (для SaaS/облачных решений)
• Обязательный претензионный порядок (с указанием сроков рассмотрения)

Регистрация ПО в Роспатент: нужно ли и что это даёт

Обязательна ли регистрация?

Нет. Авторское право на программу для ЭВМ возникает в момент создания и не требует регистрации (ст. 1259 ГК РФ). Однако добровольная регистрация даёт существенные практические преимущества.

Что даёт регистрация

Процедура регистрации

1. Подготовка заявки — заполнение формы Роспатента с указанием автора, правообладателя, названия, даты создания, языка программирования.
2. Депонирование исходного кода — предоставляется часть исходного кода (первые и последние 25 страниц или полный текст, если менее 50 страниц).
3. Оплата госпошлины — размер зависит от категории заявителя.
4. Рассмотрение заявки — Роспатент проводит формальную экспертизу (не проверяет новизну или оригинальность).
5. Получение свидетельства — срок рассмотрения составляет до 62 рабочих дней, на практике часто быстрее.

Стоит ли регистрировать лицензионный договор?

Регистрация предоставления права использования ПО по лицензионному договору не требуется (в отличие от патентов или товарных знаков). Договор вступает в силу с момента подписания сторонами.

Особенности EULA (лицензии для конечного пользователя)

Если вы распространяете ПО массово (мобильные приложения, десктопные программы, SaaS), заключение индивидуального лицензионного договора с каждым пользователем нецелесообразно. Для этого используется EULA — End User License Agreement, или лицензионное соглашение с конечным пользователем.

Правовая природа EULA в российском праве

EULA квалифицируется как договор присоединения (ст. 428 ГК РФ) — его условия определены одной стороной, а другая принимает их целиком, присоединяясь к договору.

Способы акцепта (принятия условий):

• Click-wrap — пользователь ставит галочку «Я согласен с условиями» или нажимает кнопку «Принять»
• Browse-wrap — условия размещены на сайте, использование сервиса считается согласием
• Shrink-wrap — вскрытие упаковки с ПО означает согласие с условиями (актуально для коробочного ПО)

Рекомендация: click-wrap обеспечивает наиболее надёжную фиксацию согласия пользователя.

Что обязательно включить в EULA

• Описание программы и предоставляемых прав
• Все ограничения использования
• Политику конфиденциальности (или ссылку на неё)
• Отказ от гарантий и ограничение ответственности
• Условия расторжения (в том числе автоматического)
• Применимое право и порядок разрешения споров
• Порядок изменения условий EULA

Шаблон лицензионного договора на ПО от BEJURE

Юристы BEJURE разработали профессиональный шаблон лицензионного договора на программное обеспечение, который учитывает все описанные в статье аспекты и соответствует актуальному российскому законодательству.

Что входит в шаблон:

✅ Основной договор — полный текст лицензионного договора с вариативными формулировками для исключительной и неисключительной лицензии

✅ Приложение «Описание ПО» — шаблон технической спецификации программы

✅ Приложение «Условия технической поддержки» — SLA (Service Level Agreement) с параметрами доступности и времени реакции

✅ Акт предоставления прав — документ, фиксирующий факт передачи лицензии

✅ Пояснительная записка — инструкция по заполнению с комментариями юристов

Для кого подходит:

• IT-компании, распространяющие ПО по лицензионной модели
• Стартапы, выводящие продукт на рынок
• Фрилансеры-разработчики, передающие права на свои программы
• Корпоративные заказчики, получающие ПО от подрядчиков

Как использовать:

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

Чек-лист: 10 пунктов для проверки вашего лицензионного договора на ПО

Прежде чем подписывать договор, убедитесь, что в нём есть:

• Чёткая идентификация ПО (название, версия, функционал)
• Вид лицензии (исключительная / неисключительная — прямо указано)
• Перечень разрешённых способов использования
• Ограничения (реверс-инжиниринг, передача, модификация, количество пользователей)
• Размер и порядок оплаты (или указание на безвозмездность)
• Срок действия и условия продления / прекращения
• Территория действия лицензии
• Ответственность за нарушение условий (неустойка, порядок расторжения)
• Гарантии и ограничение ответственности лицензиара
• Порядок разрешения споров (претензионный порядок, подсудность)

Заключение

Лицензионный договор на ПО — это не формальность, а основной юридический инструмент защиты вашего IT-продукта. Грамотно составленный договор позволяет контролировать использование программы, монетизировать её и эффективно пресекать нарушения.

Ключевые выводы:

• Без лицензионного договора любое использование вашего ПО третьими лицами — нарушение.
• Неисключительная лицензия подходит для массового распространения, исключительная — для эксклюзивных партнёрств.
• Раздел ограничений — самая важная часть договора для защиты правообладателя.
• Регистрация в Роспатент не обязательна, но существенно упрощает защиту в суде.
• Используйте проверенный шаблон лицензионного договора на ПО от BEJURE — это экономит время и снижает юридические риски.

Данная статья носит информационный характер и не является юридической консультацией. Для решения конкретных задач рекомендуем обращаться к квалифицированным юристам.

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

Классический лицензионный договор создавался в эпоху «коробочного» софта — когда пользователь получал физический носитель, устанавливал программу на свой компьютер и работал автономно. Современный рынок IT-продуктов устроен принципиально иначе. SaaS-платформы, облачные сервисы, мобильные приложения с подписочной моделью, микросервисные архитектуры — всё это требует адаптации лицензионного договора к реалиям, которые Гражданский кодекс РФ напрямую не регулирует. Ошибки на этом этапе приводят к спорам, потере дохода и невозможности защитить свой продукт в суде.

SaaS-модель: лицензия или услуга?

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

Аргументы в пользу квалификации как лицензии:

• Пользователь получает право использовать программу для ЭВМ (пусть и удалённо).
• Основная ценность — именно функциональность программного обеспечения, а не сам факт обработки данных на стороне провайдера.
• Для целей НДС лицензия на ПО, включённое в Реестр российского ПО, освобождена от налога (пп. 26 п. 2 ст. 149 НК РФ), что даёт ощутимую экономическую выгоду.

Аргументы в пользу квалификации как услуги:

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

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

Пример формулировки: «По настоящему Договору Лицензиар предоставляет Лицензиату неисключительное право использования программы для ЭВМ „CloudBase" (свидетельство о государственной регистрации № 2024619876) путём удалённого доступа через сеть Интернет (п. 1 Договора), а также оказывает Лицензиату услуги по обеспечению доступности Программы, хранению данных Лицензиата и технической поддержке на условиях, определённых Приложением № 2 к настоящему Договору (п. 2 Договора).»

Специфика предмета договора для облачных продуктов

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

Что необходимо зафиксировать дополнительно:

1. Модель предоставления доступа

Укажите, каким именно образом лицензиат получает доступ к программе:

• Через веб-интерфейс (браузер)
• Через мобильное приложение
• Через API (программный интерфейс)
• Через комбинацию способов

Для каждого канала доступа могут действовать разные ограничения — например, API-доступ может быть доступен только на тарифах «Бизнес» и выше.

2. Тарифные планы и функциональные модули

Современное ПО редко продаётся «целиком» — чаще предлагаются тарифы с разным набором функций. В лицензионном договоре необходимо:

• Описать тарифную сетку (или дать ссылку на актуальный прайс-лист на сайте)
• Определить порядок смены тарифа (апгрейд и даунгрейд)
• Установить, что происходит с данными пользователя при переходе на тариф с меньшим функционалом
• Зафиксировать, что считается «использованием» для каждого тарифа

3. Границы допустимой нагрузки

Для облачных продуктов критически важно определить количественные параметры использования:

• Объём хранилища данных
• Количество API-запросов в единицу времени
• Число обрабатываемых записей / транзакций
• Максимальное количество одновременных сессий

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

SLA (Service Level Agreement) как неотъемлемая часть лицензии

Для SaaS-продуктов и облачных сервисов SLA — это не факультативное дополнение, а критически важный элемент договора. Именно SLA определяет, что именно лицензиар обязуется обеспечить, и какие последствия наступают при невыполнении этих обязательств.

Ключевые параметры SLA:

Доступность сервиса (Uptime)

Стандартные уровни доступности и допустимое время простоя:

Важно: определите, что именно считается «простоем». Плановое техническое обслуживание, проведённое в ночные часы с предварительным уведомлением за 48 часов, обычно исключается из расчёта доступности.

Время реакции на инциденты

Установите категории инцидентов и максимальное время реакции для каждой:

• Критический (сервис полностью недоступен) — реакция в течение 30 минут, устранение в течение 4 часов
• Высокий (существенная деградация функциональности) — реакция в течение 2 часов, устранение в течение 8 часов
• Средний (отдельные функции работают некорректно) — реакция в течение 8 часов, устранение в течение 3 рабочих дней
• Низкий (косметические дефекты, пожелания) — реакция в течение 2 рабочих дней

Компенсации за нарушение SLA

Наиболее распространённый механизм — сервисные кредиты: при нарушении показателей доступности лицензиат получает скидку на следующий период оплаты пропорционально времени простоя. Альтернатива — продление срока действия лицензии на период, равный длительности простоя.

Пример формулировки: «В случае если уровень доступности Программы за календарный месяц составил менее 99,5%, Лицензиат вправе потребовать предоставления сервисного кредита в размере 5% от ежемесячной стоимости лицензии за каждые полные 0,1% ниже гарантированного уровня доступности, но не более 30% от ежемесячной стоимости лицензии.»

Мобильные приложения: трёхсторонние отношения

Распространение ПО через магазины приложений (App Store, Google Play, RuStore) создаёт дополнительный уровень сложности — появляется третья сторона со своими правилами.

Ключевые особенности:

1. Двойной слой условий

Пользователь одновременно подчиняется:

• Условиям платформы (App Store Terms of Service, Google Play Terms of Service)
• Вашему EULA / лицензионному соглашению

Эти документы могут конфликтовать. Например, Apple требует, чтобы EULA предоставляло пользователю определённый минимум прав, который нельзя ограничить. Прежде чем финализировать текст лицензии, убедитесь, что он не противоречит правилам платформы.

2. Обработка платежей

Платёж за лицензию проходит через платформу, которая удерживает комиссию (обычно 15–30%). С юридической точки зрения это означает, что:

• Лицензионный договор заключается между вами и пользователем
• Но денежные отношения опосредованы агентским договором с платформой
• Возврат средств (refund) осуществляется по правилам платформы, а не по условиям вашего EULA

Рекомендуется прямо указать в EULA: «Порядок оплаты и возврата денежных средств при приобретении лицензии через магазин приложений определяется правилами соответствующего магазина приложений.»

3. Автоматическое продление подписки

Платформы предъявляют жёсткие требования к прозрачности подписочной модели:

• Пользователь должен быть уведомлён о стоимости и периодичности списаний до оформления подписки
• Должна быть доступна простая процедура отмены
• Автопродление должно быть явно обозначено

Включите в EULA подробное описание подписочной модели с указанием:

• Стоимости каждого периода подписки
• Даты списания средств
• Порядка отмены подписки
• Последствий отмены (сохраняется ли доступ до конца оплаченного периода)

Персональные данные и конфиденциальность

Для SaaS и мобильных приложений обработка персональных данных — не побочный, а центральный аспект деятельности. Лицензионный договор должен быть согласован с политикой конфиденциальности и политикой обработки персональных данных.

Что необходимо урегулировать:

Роли сторон в обработке данных

• Если лицензиат загружает в SaaS-сервис данные своих клиентов (например, CRM-система), то лицензиат является оператором персональных данных, а лицензиар — лицом, обрабатывающим данные по поручению оператора.
• Это требует заключения поручения на обработку персональных данных (ч. 3 ст. 6 Федерального закона № 152-ФЗ «О персональных данных»).

Локализация данных

Для российских пользователей персональные данные граждан РФ должны храниться на серверах, расположенных на территории РФ (ч. 5 ст. 18 ФЗ-152). Если ваш SaaS-сервис использует зарубежную инфраструктуру, это необходимо учитывать и при необходимости обеспечить локализацию.

Порядок действий при прекращении лицензии

Критически важный вопрос: что происходит с данными лицензиата после окончания срока действия договора?

Рекомендуемая формулировка: «В течение 30 (тридцати) календарных дней после прекращения действия настоящего Договора Лицензиар обеспечивает Лицензиату возможность выгрузить свои данные из Программы в машиночитаемом формате. По истечении указанного срока Лицензиар вправе безвозвратно удалить данные Лицензиата.»

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

Модель подписки: юридические нюансы

Подписочная модель (monthly/annual subscription) стала доминирующей для SaaS-продуктов. Однако с точки зрения лицензионного договора она создаёт ряд вопросов, которые необходимо урегулировать заранее.

Автоматическое продление

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

Пример: «Лицензия предоставляется сроком на 1 (один) месяц и автоматически продлевается на аналогичный срок, если ни одна из Сторон не уведомит другую Сторону о нежелании продлевать действие Договора не менее чем за 10 (десять) календарных дней до окончания текущего срока.»

Изменение стоимости

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

• Уведомление не менее чем за 30 дней до вступления новой цены в силу
• Новая цена применяется со следующего периода оплаты, а не с момента уведомления
• Лицензиат вправе отказаться от продления по новой цене

Изменение функциональности

Ещё один болезненный вопрос — может ли лицензиар в одностороннем порядке изменить функциональность продукта? С одной стороны, непрерывное развитие — суть SaaS. С другой стороны, удаление функций, за которые клиент платит, может квалифицироваться как ненадлежащее исполнение договора.

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

Open-source компоненты в составе вашего продукта

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

Основные риски:

• Копилефт-лицензии (GPL, AGPL) могут требовать открытия исходного кода вашего продукта, если open-source компонент интегрирован определённым образом.
• Разрешительные лицензии (MIT, Apache 2.0, BSD) обычно требуют лишь сохранения уведомления об авторских правах, но и это обязательство необходимо выполнять.
• Несовместимость лицензий — некоторые open-source лицензии несовместимы друг с другом или с вашей проприетарной лицензией.

Что включить в лицензионный договор:

• Перечень используемых open-source компонентов и их лицензий (в приложении или по ссылке)
• Указание на то, что соответствующие компоненты используются на условиях их оригинальных лицензий
• Оговорку о том, что ничто в лицензионном договоре не ограничивает права лицензиата, предусмотренные open-source лицензиями

Пример: «Программа содержит компоненты с открытым исходным кодом, перечень которых приведён в Приложении № 3. Указанные компоненты используются на условиях соответствующих лицензий свободного/открытого программного обеспечения. В случае противоречия между условиями настоящего Договора и условиями лицензий на компоненты с открытым исходным кодом в отношении таких компонентов применяются условия соответствующих открытых лицензий.»

Практические рекомендации при составлении лицензии для облачного продукта

Подводя итоги данного раздела, приведём сводный перечень рекомендаций:

1. Определите правовую природу отношений — разграничьте лицензионную и сервисную составляющие в одном договоре.
2. Детализируйте предмет — опишите не только саму программу, но и модель доступа, тарифные планы, количественные лимиты.
3. Включите SLA — зафиксируйте параметры доступности, время реакции и механизм компенсаций.
4. Урегулируйте вопросы данных — определите роли сторон при обработке персональных данных, локализацию, порядок выгрузки и удаления.
5. Пропишите механику подписки — автопродление, изменение цен, изменение функциональности, порядок отмены.
6. Учтите требования платформ — при распространении через магазины приложений согласуйте EULA с правилами App Store, Google Play, RuStore.
7. Раскройте open-source — перечислите сторонние компоненты и их лицензии, установите приоритет открытых лицензий в части соответствующих компонентов.
8. Предусмотрите переносимость данных — возможность экспорта данных в открытых форматах снижает риск блокировки лицензиата (vendor lock-in) и одновременно повышает доверие к вашему продукту.
9. Не забудьте про форс-мажор — облачные сервисы зависят от инфраструктуры третьих лиц (хостинг-провайдеры, каналы связи, DNS-сервисы), и масштабные сбои на стороне инфраструктурных партнёров должны быть учтены в разделе обстоятельств непреодолимой силы.
10. Регулярно обновляйте договор — облачные продукты меняются быстрее, чем любые другие виды ПО. Убедитесь, что процедура внесения изменений в EULA позволяет оперативно актуализировать условия.

Грамотная проработка всех этих аспектов на этапе подготовки лицензионного договора позволяет избежать большинства типичных споров между правообладателем SaaS-сервиса и его клиентами — и обеспечивает надёжную правовую базу для масштабирования бизнеса.