IP · Право · Лицензирование ПО · 2026

Лицензионное соглашение для сайта и ПО: как составить в 2026 году

Q: Нужна ли EULA для бесплатного open source продукта?

Да — open source лицензия (MIT, GPL) и есть лицензионное соглашение. Без явной лицензии авторское право «All rights reserved» применяется автоматически. Для монетизации рекомендуется dual-licensing: OSS-лицензия для community + коммерческая EULA для enterprise.

Q: Можно ли запретить в EULA reverse engineering полностью?

Нет — в части, прямо разрешённой законом. В РФ ст. 1280 ГК допускает декомпиляцию для интероперабельности. В ЕС директива о программах гарантирует это право. В США DMCA защищает DRM, но reverse engineering для interoperability и security research разрешены. Абсолютный запрет в EULA частично ничтожен.

Q: Что происходит с EULA при продаже компании?

Лицензии обычно не передаются без согласия лицензиара. При asset deal — каждую лицензию нужно переоформить. При share deal — договоры остаются с компанией, но EULA может содержать change of control clause, позволяющий лицензиару расторгнуть договор при смене контроля. IP due diligence проверяет это обязательно.

Q: Нужно ли регистрировать ПО перед выпуском EULA?

Не обязательно, но рекомендуется. В РФ регистрация в Роспатенте создаёт публичную презумпцию авторства. В США регистрация в Copyright Office открывает доступ к statutory damages ($750–$30K/нарушение). Без регистрации доказать убытки от нарушения EULA значительно сложнее.

Q: Может ли фрилансер без IP assignment заблокировать бизнес?

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

Q: Чем отличается EULA от Terms of Service для SaaS?

Для чистого SaaS разница минимальна. EULA явно включает grant of license — предоставление права использования ОИС. ToS регулирует условия сервиса без лицензионной конструкции. Для SaaS с мобильным приложением — EULA обязательна для части с установкой, ToS — для веб-доступа.

EULA без territorial scope, ToU вместо EULA для десктопного приложения, GPL-компоненты в закрытом продукте — три типичные ошибки, каждая из которых может стоить права на продукт. Разбираем структуру, виды лицензий, IP assignment и юрисдикционные ловушки.

EULA · Лицензия · IP
SaaS · Мобильные · Desktop
GPL · MIT · Open Source
РФ · ЕС · США · ОАЭ

1ToU vs EULA: когда нужно лицензионное соглашение
2Виды лицензий: исключительная, подписка, per-seat
3Обязательные разделы EULA
4EULA для SaaS: подписка, auto-renewal, SLA
5EULA для мобильных приложений
6IP assignment vs лицензия: ловушка разработчика
7Open Source: GPL, MIT, Apache — конфликты с EULA
8Юрисдикционные особенности: РФ, ЕС, США, ОАЭ
9Типичные ошибки
10Чек-лист: 10 пунктов
?FAQ

1ToU vs EULA: когда нужно лицензионное соглашение

Лицензионное соглашение (EULA — End User License Agreement) и пользовательское соглашение (ToU/ToS) часто путают или используют взаимозаменяемо. Это принципиальная ошибка: документы регулируют разные правовые отношения. ToU — договор о доступе к веб-сервису, он регулирует использование платформы. EULA — договор о передаче права использования интеллектуальной собственности: программного обеспечения, алгоритма, базы данных. В полной юридической упаковке IT-продукта эти документы дополняют друг друга.

Параметр	ToU / Terms of Service	EULA / Лицензионное соглашение
Правовая природа	Договор об условиях пользования сервисом	Договор о предоставлении права использования ОИС
Что регулирует	Правила поведения, ответственность, контент, аккаунты	Объём переданных прав, ограничения использования ПО
Объект	Доступ к веб-сервису, API, платформе	Программный код, алгоритм, БД, мобильное приложение
Когда применяется	SaaS, веб-сервис — нет локальной установки	Desktop, mobile app, встраиваемые SDK, on-premise
Права на ОИС	Обычно не передаются и не лицензируются явно	Явно определяются: что разрешено, что запрещено
Нужна ли регистрация ПО	Нет прямой связи	Желательна для защиты в суде (ст. 1262 ГК РФ, Copyright Office)
Нужны ли оба документа	Для SaaS обычно достаточно ToU. Для desktop/mobile + SaaS-бэкенда — оба документа.

Практический критерий выбора

Если пользователь скачивает и устанавливает что-либо на своё устройство (приложение, SDK, плагин, агент) — нужна EULA. Если пользователь только использует браузерный интерфейс без установки — достаточно ToU. Если есть и SaaS-интерфейс, и мобильное приложение — нужны оба документа, согласованные между собой.

2Виды лицензий: исключительная, подписка, per-seat

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

По исключительности

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

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

Пример: white-label SaaS для банка с запретом продавать тому же сегменту

По исключительности

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

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

Пример: любая подписка на SaaS — Slack, Notion, Figma

По сроку

Perpetual (бессрочная)

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

Пример: покупка Microsoft Office 2021 без подписки

По сроку

Subscription (подписочная)

Право действует пока активна подписка. При неоплате лицензия прекращается автоматически. Позволяет включать в цену обновления и поддержку. Требует чёткого auto-renewal clause.

Пример: Adobe Creative Cloud, большинство SaaS-продуктов

По объёму

Per-seat (по пользователям)

Лицензия ограничена числом именованных пользователей или concurrent users. Типична для B2B SaaS. Требует audit rights — право проверить фактическое использование.

Пример: Salesforce — оплата за каждого активного пользователя

По объёму

Per-instance / Site license

Лицензия на инсталляцию (сервер, домен, организацию) без ограничения числа пользователей. Удобна для enterprise с большими командами; для вендора — риск underpricing при росте клиента.

Пример: on-premise корпоративные системы

Freemium → Paid

EULA должна чётко разграничивать функции freemium и платных тиров. Что происходит с данными при переходе на Free после окончания триала? При downgrade — обязательно описать, какие функции отключаются, сохраняются ли данные и на какой срок. Неясность здесь = support tickets и churn.

Volume / Enterprise

Enterprise-соглашения обычно включают индивидуальный Order Form поверх стандартной EULA. Стандартная EULA — «рамочный» документ; Order Form уточняет: количество лицензий, SLA, ценообразование, кастомные условия. Конфликт между ними разрешается в пользу Order Form.

3Обязательные разделы EULA

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

1
Предмет лицензии. Точное описание лицензируемого объекта: наименование ПО, версия, тип объекта (программа для ЭВМ, база данных, алгоритм, мобильное приложение). Ссылка на реестровый номер, если ПО зарегистрировано в Роспатенте или Copyright Office. Без точного описания объекта лицензиат может оспорить, что именно было лицензировано — и распространить лицензию на смежные продукты вендора.
2
Объём передаваемых прав (Grant of License). Что именно разрешено: установка, запуск, копирование для резервных копей, использование в сети. Что запрещено явно: обратная разработка (reverse engineering), декомпиляция, модификация, создание производных произведений, sublicensing, transfer. Формулировка «разрешено всё, что не запрещено» — неприемлема для EULA. По законодательству ряда стран (директива ЕС о программах для ЭВМ) часть ограничений нельзя запретить договором — например, декомпиляцию для обеспечения интероперабельности.
3
Территория действия. Конкретный перечень стран или регионов. «По всему миру» — допустимо, но создаёт риски в юрисдикциях с ограничениями на иностранное ПО (РФ — реестр отечественного ПО, Китай — лицензирование иностранного ПО). Отсутствие territorial scope — ошибка №1 при аудите EULA. Без него объём лицензии неопределён.
4
Срок действия и расторжение. Срок лицензии, основания досрочного расторжения (нарушение условий, банкротство, неоплата), последствия расторжения (удаление ПО, судьба данных, порядок возврата средств). Автоматическое продление — отдельный пункт с условиями уведомления.
5
Вознаграждение и порядок оплаты. Стоимость, периодичность, способы оплаты, что происходит при просрочке (grace period, приостановка, расторжение). Для подписки — чёткий auto-renewal с уведомлением за N дней. Калифорнийский ARL (Automatic Renewal Law) требует явного уведомления за 3–30 дней до renewal для подписок свыше $5/month. Нарушение — штраф + право на cancellation без штрафа.
6
Ограничение ответственности (Limitation of Liability). Liability cap (обычно 12-месячный fee), исключение consequential damages (упущенная выгода, потеря данных, репутационный ущерб). Без этого раздела при инциденте вендор несёт неограниченную ответственность. В ряде юрисдикций (B2C в ЕС) limitation of liability имеет ограниченное применение — нельзя исключить ответственность за умысел и грубую небрежность.
7
Применимое право и форум. Какое право применяется (Delaware, Англия, Москва, DIFC). Где разрешаются споры (суд, арбитраж, DIFC Courts, ICC). Для B2C в ЕС — потребитель вправе обратиться в суд по месту жительства вне зависимости от choice of law.
8
Гарантии и их исключение (Warranty Disclaimer). «AS IS» — ПО предоставляется как есть, без гарантий пригодности для конкретной цели. Вендор не гарантирует отсутствие ошибок. Для enterprise-сегмента гарантии частично сохраняются (SLA, warranty period), для B2C — ограничены законом о защите прав потребителей.

4EULA для SaaS: подписка, auto-renewal, SLA

Для SaaS-продуктов EULA (или ToU, в зависимости от наличия установки) приобретает специфические разделы, которых нет в классических software licenses. Подписочная модель, автоматическое продление, ограничения на объём использования и судьба данных при окончании подписки — всё это требует явного регулирования.

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

Укажите: период billing cycle, срок уведомления до auto-renewal (14–30 дней для B2C, 30–60 дней для enterprise), как отменить, что происходит с данными если не отменить вовремя.

Калифорнийский ARL: явное согласие + уведомление за 3–30 дней обязательно для потребителей. Нарушение = штраф + unilateral cancellation.

Fair Use Ограничения использования

API call limits, storage quotas, user counts, bandwidth caps — всё, что ограничивает использование, должно быть явно в EULA или ссылаться на Acceptable Use Policy. Размытые «fair use» ограничения без цифр — источник споров.

Практика: клиент превысил API limit в 100x. Без AUP с конкретными цифрами суд встал на сторону клиента.

Data Portability Данные при termination

Что происходит с данными клиента при окончании подписки: срок доступа к экспорту (30–90 дней), форматы экспорта, что удаляется и когда. Для EU — право на переносимость данных по GDPR Art. 20.

Enterprise-клиенты требуют минимум 90 дней на экспорт и формат JSON/CSV. Это должно быть в EULA, а не выясняться при offboarding.

Suspension Приостановка сервиса

Основания для приостановки (неоплата, нарушение AUP, угроза безопасности), срок уведомления до приостановки, процедура восстановления. Без этого раздела одностороннее отключение клиента = breach of contract.

Лучшая практика: уведомление за 10 дней при неоплате, немедленная приостановка при нарушении безопасности — с разными процедурами для каждого случая.

📊 Типичные SLA-параметры и их правовые последствия

99.9%

Uptime — стандарт. 8,7 часов downtime/год. Прописать метод измерения и исключения.

10×

Service Credit при нарушении SLA. Не возврат денег — кредит на следующий период.

24h

Срок уведомления об инциденте. Плановые работы — обычно 48–72 часа заранее.

100%

Service Credits — max компенсация. Нельзя требовать больше paid fees за период.

5EULA для мобильных приложений

Мобильные приложения — особый случай: вендор вынужден соблюдать одновременно свою EULA, стандартные EULA маркетплейса (Apple/Google) и применимое законодательство. При конфликте между ними — EULA маркетплейса приоритетна. App Store и Google Play оставляют за собой право удалить приложение, нарушающее их guidelines — без компенсации вендору.

🍎 Apple App Store

Стандартная EULA Apple применяется по умолчанию для всех приложений. Вендор вправе использовать собственную EULA, но обязан её зарегистрировать в App Store Connect и указать ссылку.
Apple EULA ограничивает: конечный пользователь получает личную, неисключительную, непередаваемую лицензию только для устройств Apple. Redistribution запрещён.
In-App Purchases — только через Apple IAP API. Прямые платежи в обход App Store (кроме B2B reader apps) = нарушение guidelines = удаление приложения. Комиссия Apple: 30% (15% для малого бизнеса).
Privacy Nutrition Labels — EULA должна соответствовать заявленным типам собираемых данных. Расхождение = rejection при ревью.
Age ratings — установлены вендором при публикации. Если приложение допускает контент 18+, EULA обязана содержать требование подтверждения возраста.

🤖 Google Play

Developer Program Policy — обязательна для всех приложений. Собственная EULA размещается вендором; Google не предоставляет стандартную EULA в том же смысле, что Apple.
Google Play Billing обязателен для цифровых товаров и подписок. Исключения: физические товары, B2B-приложения. Комиссия: 30% (15% при выручке до $1M/год).
Data Safety Section — обязательное раскрытие: какие данные собираются, передаются ли третьим лицам, есть ли шифрование, можно ли удалить. Несоответствие EULA ≠ Data Safety = removal.
Subscription requirements — приложение обязано предоставить ссылку на управление подпиской и отмену прямо в интерфейсе. EULA должна это отражать.
Альтернативные сторы (на Android возможны) — если приложение распространяется не только через Google Play, EULA должна учитывать разные условия маркетплейсов.

⚠️ Ловушка In-App Purchases в EULA

EULA должна явно описывать: что покупается при IAP (consumable vs non-consumable vs subscription), refund policy (Apple и Google имеют собственные правила рефандов — их нельзя обойти EULA), что происходит с купленными items при удалении аккаунта или приложения. Отсутствие этих положений — типичная причина negative reviews и chargeback.

6IP assignment vs лицензия: ловушка разработчика

Это один из самых недооценённых рисков при найме разработчиков и работе с аутсорсом. По умолчанию (без явного договора) автор — владелец интеллектуальной собственности. Это значит: если разработчик написал код по заказу, но в договоре нет явной передачи прав (IP assignment), — права остаются у разработчика. Компания пользуется кодом без законного основания или с очень узкой лицензией.

📋 IP Assignment (передача прав)

Что происходит: Разработчик полностью передаёт исключительные права на результат работы заказчику. После assignment у разработчика нет права использовать код.
Когда применять: Штатные сотрудники (work-for-hire в США, служебное произведение в РФ ст. 1295 ГК), подрядчики, выполняющие ключевые IP-компоненты продукта.
Важно: В РФ у автора сохраняются личные неимущественные права (право авторства, имя) — их передать нельзя. Передаются только имущественные права.
Work-for-hire (США): Для подрядчиков (не сотрудников) work-for-hire должен быть явно прописан в договоре + работа должна относиться к одной из 9 категорий. Без этого — assignment.
Формула для договора: «Разработчик настоящим передаёт и уступает Компании все исключительные права на Результат работ, включая право на воспроизведение, распространение, модификацию...»

📝 Лицензия (без передачи прав)

Что происходит: Разработчик остаётся правообладателем, предоставляет компании право использовать код на оговорённых условиях. При расторжении лицензии — право использования прекращается.
Когда применять: Независимые ISV, white-label партнёры, платформенные интеграции, когда разработчик хочет сохранить право использовать код в других проектах.
Риски для компании: При конфликте с разработчиком лицензия может быть расторгнута. Продукт становится нелицензионным. M&A: покупатель бизнеса получает только права по лицензии.
Sublicensing: Если компания планирует продавать продукт клиентам — EULA с разработчиком должна явно разрешать sublicensing. Без этого продажа = нарушение.
При M&A: Due diligence проверит: все ли разработчики подписали IP assignment или лицензию? Отсутствие документов — блокер сделки или discount на цену.

⚠️

Реальная ситуация: фриланс без IP assignment

Компания наняла фрилансера для разработки ключевого модуля. Договор — только ТЗ и оплата, без mention прав. Фрилансер сделал работу, получил деньги. Через год при подготовке к инвестиционному раунду юристы инвестора нашли: права на модуль у фрилансера. Пришлось разыскивать его, платить ещё раз за assignment и откладывать раунд на 2 месяца. Стоимость договора с IP assignment в начале — 30 000 ₽. Цена отсутствия — несколько миллионов и потеря сделки.

7Open Source: GPL, MIT, Apache — конфликты с EULA

Большинство коммерческих продуктов используют open source компоненты. Это создаёт скрытый риск: лицензия зависимости может ограничивать коммерческое использование или обязывать раскрыть исходный код. Без аудита зависимостей (dependency audit) перед выпуском коммерческого EULA этот риск не виден — до первого юридического запроса.

Лицензия	Тип	Коммерческое использование	Раскрытие исходного кода	Ограничения для EULA
MIT	Permissive	✅ Разрешено	Не обязательно	Только attribution. Совместима с любой EULA.
Apache 2.0	Permissive	✅ Разрешено	Не обязательно	Attribution + NOTICE файл. Патентный grant и отзыв. Совместима с EULA.
BSD (2/3-clause)	Permissive	✅ Разрешено	Не обязательно	Attribution. 3-clause BSD — запрет использования имени автора в рекламе.
LGPL v2/v3	Слабый copyleft	✅ Разрешено при динамической линковке	Только сама библиотека (не ваш код) при статической линковке	При статической линковке — раскрытие библиотеки + возможность замены. EULA может быть закрытой для вашего кода.
GPL v2 / v3	Сильный copyleft	⚠️ Ограничено	Обязательно — весь «combined work» должен быть под GPL	Нельзя запрещать redistribution. EULA не может ограничивать права GPL. Критически несовместима с закрытым коммерческим продуктом.
AGPL v3	Сетевой copyleft	⚠️ Очень ограничено	Обязательно при использовании в SaaS — доступ по сети = distribution	Использование AGPL-зависимости в SaaS обязывает раскрыть весь код сервиса. Несовместима с закрытым SaaS.
SSPL	Коммерческий copyleft	❌ Фактически запрещено без коммерческой лицензии	Весь стек, включая инфраструктуру	MongoDB, Elasticsearch используют SSPL. Любое коммерческое SaaS-использование требует отдельной коммерческой лицензии от вендора.

🔍 Dependency audit перед выпуском EULA

Инструменты: FOSSA, Black Duck, Snyk License Compliance, OSS Review Toolkit. Сканируют все транзитивные зависимости (не только прямые) и выявляют конфликты с вашей EULA. Обязательны перед: выпуском первой коммерческой версии, M&A due diligence, публикацией в корпоративные реестры ПО. Транзитивные зависимости — наиболее опасны: прямая зависимость на MIT-пакет, который внутри использует GPL — и весь GPL-конфликт скрыт на два уровня.

8Юрисдикционные особенности: РФ, ЕС, США, ОАЭ

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

🇷🇺 Россия — ГК РФ Часть IV

Ст. 1235–1238 ГК РФ — лицензионный договор на программы для ЭВМ. Исключительная лицензия подлежит госрегистрации при регистрации ПО (рекомендована ст. 1262).
Реестр российского ПО — включение обязательно для госзаказа. EULA для реестрового ПО должна соответствовать требованиям Минцифры.
Служебные произведения (ст. 1295) — ПО, созданное в рамках трудовых обязанностей, принадлежит работодателю с момента создания. Отдельный IP assignment не нужен, но письменная фиксация задания рекомендована.
Запрет обратной разработки можно включить в EULA, но ст. 1280 ГК допускает декомпиляцию для обеспечения совместимости — этот запрет будет ничтожным в этой части.
Вознаграждение обязательно в лицензионном договоре. Безвозмездная лицензия в B2B между коммерческими организациями запрещена (ст. 1 ГК + ст. 575 ГК об ограничении дарения).

🇪🇺 ЕС — Директива о программах для ЭВМ

Directive 2009/24/EC — устанавливает минимальные права пользователя, которые нельзя ограничить EULA: право на резервную копию, право на декомпиляцию для интероперабельности, право на исправление ошибок при законном использовании.
Exhaustion of rights (исчерпание прав) — при продаже копии ПО правообладатель теряет право контролировать её перепродажу (CJEU: UsedSoft v. Oracle). Для SaaS не применяется — нет «продажи копии».
GDPR + data portability при termination — обязательно для SaaS с EU-пользователями. Ссылка на GDPR Art. 20 в EULA.
Consumer protection — B2C EULA в EU не может исключать statutory warranty (2 года). Limitation of liability ограничена: нельзя исключить ответственность за умысел и грубую небрежность.
Digital Markets Act (2023) — для крупных платформ (gatekeepers) запрет определённых ограничений в EULA, в т.ч. запрета interoperability.

🇺🇸 США — DMCA, First Sale, UCITA

DMCA (17 U.S.C. §1201) — запрет обхода технических средств защиты (DRM). EULA с anti-circumvention clause подкреплена федеральным законом. Исключения: security research, interoperability.
First Sale Doctrine — при продаже физической копии ПО покупатель вправе её перепродать. Для «лицензии» (не продажи) — доктрина не применяется. EULA должна явно устанавливать, что это лицензия, а не продажа.
Shrink-wrap / click-wrap — суды США в целом признают click-wrap EULA валидной. Browse-wrap — риски, особенно без явного уведомления.
Калифорнийский ARL — auto-renewal требует explicit consent + уведомление до renewal + cancellation mechanism. Нарушение = штраф + право на cancellation.
Copyright registration — без регистрации в Copyright Office нельзя получить statutory damages ($750–$30K/нарушение) при infringement. Только actual damages.

🇦🇪 ОАЭ — Federal Copyright Law

Federal Decree-Law No. 38/2021 — новый закон об авторских правах. Защита ПО как литературного произведения. Срок защиты — 50 лет с момента создания.
DIFC / ADGM — для B2B лицензионных договоров с иностранными компаниями рекомендуется регистрация в DIFC (английское право) или ADGM (английское право). Эти юрисдикции дают предсказуемость enforcement.
Обязательная регистрация для получения максимальной защиты — регистрация ПО в Министерстве экономики ОАЭ. Нерегистрированный объект защищается, но доказательная база слабее.
Reverse engineering прямо запрещён без разрешения правообладателя. Суды ОАЭ поддерживают соответствующие EULA-ограничения.
Arabic language requirements — контракты с государственными структурами должны иметь версию на арабском. Для B2B с частными компаниями — английский приемлем в DIFC/ADGM.

9Типичные ошибки

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

Ошибка #1

Нет territorial scope

EULA не содержит указания на территорию действия лицензии. Лицензиат трактует это как «весь мир». Вендор ожидал ограничить RU-рынком. При конфликте суд встаёт на сторону расширительного толкования.

Ошибка #2

Нет version control

EULA обновляется без версионирования и changelog. Клиент ссылается на версию при подписании — доказать её содержание невозможно. Особенно критично при enterprise-сделках, где EULA согласовывалась индивидуально.

Ошибка #3

Конфликт с Open Source

EULA запрещает redistribution и modification — но продукт включает GPL-зависимости, которые разрешают именно это. Суд признаёт EULA-запрет недействительным в части GPL-кода. Вся коммерческая модель под угрозой.

Ошибка #4

Нет termination clause

Что происходит при расторжении — не описано. Данные клиента? Доступ к экспорту? Возврат предоплаты? При конфликте суд применит default rules юрисдикции — почти всегда невыгодные для вендора.

Ошибка #5

«Все права защищены. Любое использование без разрешения запрещено» — и больше ничего о том, что разрешено пользователю. EULA без grant of license вообще не является лицензионным соглашением — это запрет на использование.

Ошибка #6

ToU вместо EULA для desktop

Разработчик опубликовал ToU для десктопного приложения. ToU не содержит grant of license — пользователь технически использует ПО без правового основания. При спорах о reverse engineering или redistribution ToU не защищает.

10Чек-лист: 10 пунктов для проверки EULA

Используйте перед выпуском новой версии ПО, выходом на новый рынок или инвестиционным due diligence.

1
Предмет лицензии определён точно. Наименование ПО, версия, тип объекта, реестровый номер (если есть). Нет размытых «и связанные продукты».
2
Grant of License содержит полный перечень разрешённых и запрещённых действий. Нет формулировки «разрешено всё, что не запрещено». Явно перечислены: reverse engineering, sublicensing, modification, redistribution — и что из этого запрещено.
3
Territorial scope указан. Конкретные страны, регионы или «по всему миру» — явно, не по умолчанию. При ограниченной территории — механизм geo-restriction в продукте.
4
Срок и основания расторжения описаны. Для подписки — условия auto-renewal и уведомление. Для perpetual — основания досрочного расторжения. Последствия расторжения: данные, доступ, возврат средств.
5
IP assignment получен от всех разработчиков. Штатные сотрудники — служебные произведения подтверждены. Фрилансеры/подрядчики — подписали IP assignment. Без пробелов.
6
Open Source аудит проведён. Все зависимости (прямые и транзитивные) проверены на совместимость с EULA. GPL/AGPL-компоненты заменены или лицензированы коммерчески. Attribution выполнен.
7
Limitation of Liability соответствует юрисдикции. Liability cap установлен. Consequential damages исключены. Для B2C в EU — statutory warranty и императивные нормы защиты потребителей соблюдены.
8
Мобильный маркетплейс — требования соблюдены. Для App Store: custom EULA зарегистрирована, IAP через Apple API, privacy labels соответствуют. Для Google Play: Data Safety Section актуальна, subscription cancellation в UI.
9
Версионирование EULA настроено. Каждая версия имеет дату и номер. История версий хранится. Пользователи уведомляются при изменениях. Enterprise-клиенты имеют право на negotiated terms в Order Form.
10
Применимое право и форум соответствуют бизнес-модели. Choice of law не конфликтует с императивными нормами рынков сбыта. Арбитражная оговорка (если есть) совместима с B2C-законодательством целевых юрисдикций.

?Частые вопросы

Нужна ли EULA для бесплатного open source продукта?

Да — open source лицензия (MIT, GPL и т.д.) и есть лицензионное соглашение. Без явной лицензии пользователи не имеют права использовать, модифицировать или распространять код — авторское право автоматически «All rights reserved». Выбор конкретной OSS-лицензии определяет, что разрешено пользователям. Если продукт планирует монетизацию — рекомендуется dual-licensing: open source для community + коммерческая EULA для enterprise.

Можно ли запретить в EULA reverse engineering полностью?

В РФ — частично: ст. 1280 ГК допускает декомпиляцию для обеспечения совместимости с другими программами. Запрет в EULA этой части будет ничтожным. В ЕС — аналогично, директива о программах для ЭВМ гарантирует это право. В США — DMCA запрещает обход DRM, но reverse engineering для interoperability и security research разрешены. Абсолютный запрет в EULA — декларативен и не имеет силы в части, прямо разрешённой законом.

Что происходит с EULA при продаже компании (M&A)?

Лицензионные договоры, как правило, не передаются без согласия лицензиара (если нет прямой разрешительной оговорки в EULA). При asset deal — каждую лицензию нужно переоформить или получить согласие правообладателя. При share deal — договоры остаются с компанией, но некоторые содержат «change of control» clause, позволяющий лицензиару расторгнуть договор при смене контроля. Проверка EULA на change of control provisions — обязательный элемент IP due diligence.

Нужно ли регистрировать ПО перед выпуском EULA?

Не обязательно, но рекомендуется. В РФ (ст. 1262 ГК) регистрация ПО в Роспатенте создаёт публичную презумпцию авторства и даты создания — это упрощает доказательство прав при нарушении EULA. В США регистрация в Copyright Office открывает доступ к statutory damages ($750–$30K/нарушение) вместо actual damages. Без регистрации доказать убытки от нарушения EULA значительно сложнее.

Может ли один разработчик-фрилансер удержать права на код и заблокировать бизнес?

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

Чем отличается EULA от Terms of Service для SaaS?

Для чистого SaaS (только браузерный доступ, без установки) разница минимальна — оба документа регулируют доступ к сервису. Ключевое отличие: EULA явно включает «grant of license» — предоставление права использования ОИС. ToS обычно регулирует условия сервиса без лицензионной конструкции. Для SaaS с мобильным приложением или desktop-клиентом — EULA обязательна для части с установкой, ToS — для веб-доступа.

⚖️ ToU ≠ EULA

Для продуктов с установкой ToU недостаточно. EULA нужна для desktop-приложений, SDK, мобильных клиентов — всего, что устанавливается на устройство.

📋 IP assignment — до начала работ

Отсутствие IP assignment у фрилансеров — скрытый риск, который блокирует M&A и создаёт рычаг давления. Стоимость исправления после — в десятки раз выше, чем сделать сразу.

🔍 Open Source аудит

GPL-зависимость в закрытом продукте — не формальность, а реальная угроза. Dependency audit перед выпуском коммерческой EULA — обязательный шаг.

Заказать разработку лицензионного соглашения

Разработаем EULA под ваш продукт и рынки: SaaS, desktop, мобильные приложения. С учётом модели лицензирования, Open Source аудита, IP assignment для команды и требований App Store.

📋Разработка EULA — под тип продукта, модель и юрисдикции

🔍Аудит существующей EULA — 10-пунктный чек-лист с заключением

📝IP assignment пакет — для сотрудников и подрядчиков

🌍Мультиюрисдикционная EULA — РФ + ЕС + США + ОАЭ

Заказать разработку EULA → IP · Право → Юридическая упаковка →