Исходный код, техническую документацию, дизайн интерфейса и базу данных может создавать одна команда, но права на эти элементы нередко распределены между работниками, подрядчиками и заказчиком. Если это не оформлено документально, компания может владеть сервером и доменом, но не иметь достаточных прав на доработку, передачу или коммерческое использование самого продукта.
В российском праве программа для ЭВМ охраняется как объект авторского права. Регистрация не нужна для возникновения охраны: право появляется с момента создания произведения. Однако одной ссылки на авторское право недостаточно. На практике значение имеют цепочка прав, договорный режим использования, сохранность доказательств, защита конфиденциальной информации и своевременная реакция на нарушения.
Что именно может защищаться в программном продукте
ПО редко бывает единым объектом. Оно состоит из нескольких элементов, для которых применяются разные правовые инструменты.
- Исходный и объектный код. Они охраняются авторским правом как программа для ЭВМ. Защита распространяется на форму выражения кода, но не даёт монополии на саму идею, алгоритмическую задачу или функциональный результат.
- Документация. Руководства пользователя, технические задания, архитектурные описания, справочные материалы и тексты сайта могут быть самостоятельными объектами авторского права.
- Интерфейс и графические элементы. Иконки, иллюстрации, отдельные экраны и другие творческие элементы могут охраняться авторским правом. Общие принципы навигации, типовые UX-элементы и функционально обусловленные решения обычно требуют отдельной оценки.
- Название, логотип, обозначение продукта. Для них подходит товарный знак. Авторское право на логотип и регистрация товарного знака решают разные задачи: первое возникает при создании, вторая закрепляет исключительное право на обозначение в заявленных классах товаров и услуг.
- База данных. В зависимости от характера и способа формирования она может охраняться как составное произведение, а в предусмотренных законом случаях — как объект смежных прав изготовителя базы данных.
- Технические решения. Если продукт использует новое техническое решение, иногда рассматривают патентование изобретения, полезной модели или промышленного образца. Сам по себе компьютерный алгоритм патентоспособен не всегда: оценка зависит от предмета решения и юрисдикции.
- Непубличные сведения. Архитектура, модели угроз, бизнес-логика, ключи доступа, планы развития, методы настройки и другие ценные сведения могут защищаться режимом коммерческой тайны, если он фактически введён, а не просто упомянут в договоре.
Распространённая ошибка — пытаться решить все вопросы одним документом. Для зрелого цифрового продукта обычно требуется сочетание авторско-правовой цепочки, договоров с разработчиками, клиентских лицензий, режима конфиденциальности, товарного знака и доказательств создания продукта.
Цепочка прав: основа, без которой защита слабеет
В споре недостаточно сказать, что «код написан для компании». Нужно подтвердить, на каком основании исключительное право перешло к ней или принадлежит ей изначально. Такую проверку лучше проводить до привлечения инвестиций, продажи бизнеса, запуска лицензирования или направления претензии.
Работники
Код, созданный сотрудником в рамках трудовых обязанностей или конкретного задания работодателя, может признаваться служебным произведением. Этот режим лучше подтверждать не общей формулировкой в трудовом договоре, а совокупностью документов: должностной инструкцией, локальными актами, постановкой задач, данными репозитория, актами и рабочей перепиской.
Важно отличать разработку в интересах работодателя от личного проекта сотрудника. Если обязанности программиста описаны расплывчато, задача не зафиксирована, а работа велась вне понятного производственного процесса, риск спора о правах возрастает. Неимущественное право авторства остаётся за физическим лицом и не передаётся, но компания может получить исключительное право либо необходимый объём прав на использование.
Подрядчики, фрилансеры и студии разработки
Сам по себе договор на разработку не означает автоматического перехода исключительного права. В документе нужно прямо определить правовую модель:
- отчуждение исключительного права после оплаты или подписания акта;
- лицензия с перечислением способов использования, территории, срока и возможности сублицензирования;
- смешанная конструкция, при которой права на новый код передаются заказчику, а права на ранее созданные модули подрядчика сохраняются за ним на условиях лицензии.
Отдельного внимания требуют зависимые компоненты: библиотеки, шаблоны, SDK, шрифты, иллюстрации, фотографии, аудио и код субподрядчиков. Исполнитель должен не только передать результат, но и подтвердить законность использования включённых материалов, раскрыть перечень сторонних компонентов и предоставить права, необходимые для эксплуатации продукта.
Соучредители и ранняя команда
Стартапы часто начинают разработку до учреждения юридического лица. В такой ситуации код может принадлежать конкретным физическим лицам, а не будущей компании. После регистрации бизнеса права следует оформить отдельными договорами с каждым автором или правообладателем. Устная договорённость о том, что продукт «общий», не подходит для due diligence, привлечения инвестиций и последующей сделки.
Договорные инструменты для продукта и его пользователей
Договорная модель зависит от того, как распространяется ПО. Продажа лицензий, корпоративное внедрение, мобильное приложение, поставка для установки на инфраструктуре клиента и сервис по подписке создают разные риски.
| Ситуация | Практический инструмент | Что закрепить |
|---|---|---|
| Разработка на заказ | Договор разработки, ТЗ, акты | Результат, порядок приёмки, права на код и документацию, гарантии исполнителя |
| Доступ к облачному продукту | Лицензионное соглашение или договор предоставления доступа | Функциональность, аккаунты, лимиты, плата, доступность, данные, прекращение доступа |
| Корпоративная установка | Лицензионный договор | Число пользователей или инсталляций, территория, срок, обновления, запрет передачи третьим лицам |
| Партнёрское распространение | Дистрибьюторский или партнёрский договор | Полномочия партнёра, маркетинг, использование бренда, отчётность, сублицензии |
| Доступ разработчиков к API | Условия API и технические правила | Допустимые сценарии, лимиты, безопасность ключей, запрет неправомерного извлечения данных |
Для массового продукта пользовательское соглашение или EULA должно быть доступно до начала использования, а действие пользователя — подтверждать принятие условий. В электронной среде особенно важны доказательства: версия документа, дата публикации, журналы акцепта, связь условий с учётной записью или заказом, а также порядок уведомления об изменениях.
Фразы «пользователь получает неисключительную лицензию» недостаточно. Лучше прямо указать разрешённые действия: запуск, установку, загрузку в память устройства, резервное копирование, использование определённым числом пользователей, доступ через браузер. Полезно также разграничить допустимую адаптацию для работы по назначению и запрещённые действия: декомпиляцию за пределами, допускаемыми законом, удаление уведомлений об авторстве, передачу доступа третьим лицам и обход технических ограничений.
Регистрация программы для ЭВМ: когда она помогает
В России программу для ЭВМ можно зарегистрировать в Роспатенте. Регистрация не создаёт авторское право и не заменяет договоры с авторами, но может служить дополнительным доказательством заявленного правообладателя и состава депонируемых материалов на дату регистрации.
Она может быть полезна, если компания планирует:
- привлекать инвестиции или готовиться к сделке с бизнесом;
- лицензировать продукт крупным корпоративным клиентам;
- участвовать в программах поддержки, где требуется документальное подтверждение прав;
- систематизировать портфель интеллектуальной собственности;
- усилить доказательственную позицию при вероятном конфликте.
При этом регистрация не проверяет оригинальность программы по существу и не исправляет недостатки в цепочке прав. Если разработчик не передал права заказчику, свидетельство, полученное без надлежащих оснований, не исключает претензий. До подачи заявления имеет смысл провести внутреннюю проверку договоров и состава кода.
Коммерческая тайна и конфиденциальность: режим должен работать
Часть ценности ПО может не отражаться в финальной сборке: алгоритмы настройки, параметры моделей, внутренние инструкции, данные для обучения, ключи, конфигурации, аналитика и дорожные карты. Для таких сведений важен режим коммерческой тайны. NDA полезно, но само по себе не всегда подтверждает, что компания ввела режим, требуемый законом.
Обычно необходимы перечень конфиденциальных сведений, ограничение доступа, маркировка носителей и документов, если она применима, учёт лиц с доступом, внутренние правила и договорные обязательства работников и контрагентов. Технические меры дополняют правовые: разграничение доступа к репозиториям, многофакторная аутентификация, журналирование, отзыв ключей при увольнении, разделение production- и test-сред.
Условия конфиденциальности стоит подстраивать под конкретный проект. Общий запрет на раскрытие «любой информации» применять сложнее, чем понятный перечень категорий, срок обязательства, допустимые случаи раскрытия, порядок возврата или уничтожения материалов и последствия нарушения. Практические ошибки при подготовке таких соглашений разобраны в материале о принудительном удалении нелегальной музыки из «ВКонтакте» лишь в части общей значимости фиксации нарушений в интернете; для защиты исходного кода нужна отдельная договорная и доказательственная стратегия.
Открытый исходный код: не «бесплатный», а лицензируемый
Использование open source не исключает коммерческого применения, но требует соблюдения условий конкретной лицензии. Одни лицензии в основном требуют сохранять уведомления и текст лицензии, другие могут устанавливать дополнительные обязанности при распространении производного произведения или предоставлении сетевого сервиса.
Компании стоит вести реестр компонентов: название, версия, источник, лицензия, способ использования, ответственный сотрудник и наличие модификаций. Он нужен не только для соблюдения лицензионных условий, но и для оперативной реакции на уязвимости, аудита перед сделкой и корректного формирования уведомлений для пользователей.
Как фиксировать нарушение прав на ПО
Нарушение может выражаться в копировании кода, публикации сборки без разрешения, использовании пиратской версии, незаконной передаче аккаунтов, удалении сведений об авторстве, распространении изменённого продукта или несоблюдении лицензионных ограничений. До направления претензии важно сохранить доказательства так, чтобы их можно было использовать в переговорах и, при необходимости, в суде.
Набор доказательств зависит от обстоятельств, но часто включает:
- скриншоты страниц, карточек приложений, объявлений и личных кабинетов с датой и адресом ресурса;
- видеозапись пользовательского пути: регистрация, оплата, загрузка, запуск, отображение спорной функциональности;
- файлы установки, контрольные суммы, логи, письма и ответы нарушителя;
- сведения из репозиториев и систем управления задачами, подтверждающие создание и передачу результата;
- договоры, акты, служебные задания, документы об оплате;
- при необходимости — нотариальное обеспечение доказательств и заключение специалиста.
Не следует получать материалы путём неправомерного доступа к чужим системам или обхода защитных механизмов. Даже при обоснованных подозрениях такие действия создают самостоятельные правовые риски и могут осложнить позицию правообладателя.
Претензия и дальнейшие меры
Претензия обычно содержит сведения о правообладателе, описание объекта, подтверждение прав, факты нарушения, конкретные требования и срок ответа. В зависимости от обстоятельств можно требовать прекратить использование, удалить материалы, выплатить компенсацию или возместить убытки, предоставить информацию о распространении либо урегулировать использование лицензией. При интернет-нарушениях могут применяться обращения к владельцу сайта, хостинг-провайдеру, маркетплейсу приложений или другой площадке по её процедуре.
Способ защиты зависит от применимого права, статуса сторон, характера объекта и имеющихся доказательств. Если контрагент находится в другой стране, отдельно анализируют договорную подсудность, применимое право, территорию лицензии и возможность фактического исполнения требований.
Минимальный правовой контур для команды разработки
Защиту лучше выстраивать до конфликта и включать в регулярные процессы. Рабочий порядок может быть таким:
- Составить инвентаризацию продукта: код, документация, дизайн, данные, домены, товарные знаки, сторонние компоненты.
- Определить автора и правообладателя каждого значимого элемента.
- Закрыть пробелы договорами с работниками, основателями, подрядчиками и субподрядчиками.
- Настроить репозитории и систему задач так, чтобы они фиксировали вклад, версии и историю передачи результатов.
- Сформировать реестр open source и проверять лицензии до включения компонента в релиз.
- Оформить лицензионные условия для клиентов, партнёров и пользователей API.
- Утвердить режим конфиденциальности и правила доступа к чувствительным материалам.
- Подготовить сценарий фиксации нарушений: ответственных лиц, перечень доказательств, шаблон претензии и порядок коммуникации.
Если продукт создаётся поэтапно, в каждом акте сдачи-приёмки полезно перечислять передаваемые материалы: указывать конкретный коммит или архив, документацию, дизайн-макеты, список зависимостей и сведения о лицензиях. Через год такая детализация позволит установить, что именно передавалось, кем создано и на каких условиях используется.
Материал носит информационный характер и не заменяет индивидуальную юридическую консультацию: содержание договоров и стратегия защиты должны оцениваться с учётом конкретного продукта, состава команды и применимого права.