Вы запустили продукт, вложили в него месяцы работы и деньги. А потом обнаружили, что конкурент выпустил почти точную копию: тот же интерфейс, та же логика, иногда даже те же баги. Что делать?

Эта статья — практический алгоритм. Разберём, как зафиксировать нарушение, какие способы защиты существуют, чем отличается путь через суд от пути через ФАС РФ, сколько длится, какие дела уже прошли через суды и как не оказаться в роли нарушителя самому.

Что делать в первые 24 часа

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

1. Не пишите нарушителю сгоряча. Любое ваше сообщение его насторожит, и он начнёт чистить следы, поэтому сначала фиксация, потом контакт.

2. Сохраните страницы в веб‑архиве (web.archive.org). Это бесплатно и занимает минуту, зато позволяет зафиксировать даты.

3. Сделайте скриншоты и скринкаст с видимыми URL и датой: интерфейс, ключевые экраны, совпадающие элементы, идентичные баги.

4. Скачайте мобильное приложение нарушителя (APK/из стора) и сохраните дистрибутив — приложения обновляются, и через неделю спорной версии уже не будет.

5. Запишитесь к нотариусу на осмотр сайта/приложения.

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

Дальше действуйте спокойно по алгоритму.

Шаг 1. Зафиксируйте факт копирования

Первое и самое важное — собрать доказательства до того, как нарушитель что‑то изменит или удалит. Продукты обновляются быстро, и через неделю следов может не остаться.

Что фиксировать:

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

Скриншоты и видеозаписи. Зафиксируйте интерфейс, функционал, совпадающие элементы, идентичные баги. Желательно с отображением даты и URL. Совпадающий баг — недооценённое доказательство: случайно повторить чужую ошибку почти невозможно, и это сильный аргумент о копировании, а не о «независимой разработке».

Веб‑архив. Сохраните страницы через web.archive.org — это независимый источник с фиксацией даты.

Сравнительная таблица. Подготовьте наглядное сопоставление: ваш продукт и продукт нарушителя по элементам. Эту таблицу вы потом приложите и к претензии, и к иску, и к заявлению в ФАС.

Шаг 2. Определите, что именно скопировано

От этого зависит, какой инструмент защиты использовать. Это ключевой момент, который многие пропускают.

Скопирован исходный код — это нарушение исключительного права на программу для ЭВМ (ст. 1270 ГК РФ). Защищается авторским правом.

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

Скопирован функционал, логика, алгоритм. Авторское право не защищает идеи, концепции, принципы, методы и алгоритмы (п. 5 ст. 1259 ГК РФ). То есть если конкурент повторил саму бизнес‑логику и набор функций, но написал свой код и нарисовал свой интерфейс — формально нарушения авторского права нет. Это типичная причина проигрыша: истец считает, что у него украли «продукт», а защитить может только конкретную форму выражения — код и охраноспособный дизайн.

Скопировано название или фирменный стиль — тут речь о товарных знаках и иных средствах индивидуализации.

Скопирована база данных / данные спарсили — отдельный объект защиты: смежное право изготовителя базы данных (ст. 1334 ГК РФ). Об этом ниже отдельно — это самый частый спор последних лет.

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

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

Отдельно: парсинг, данные и API — самый частый спор сегодня

Сегодня «копируют» чаще не код целиком, а данные: парсят контент, выгружают через API, обучают на чужом массиве. Защищать тут нужно не код и не дизайн, а базу данных как объект смежного права (ст. 1334 ГК РФ).

Ключевой кейс — «ВКонтакте» против «Дабл Дата» (дело № А40-18827/2017). Соцсеть обвинила стартап в том, что тот автоматически собирал данные открытых профилей пользователей и формировал на их основе собственную базу для скоринга заёмщиков. Дело прошло несколько кругов, акты в итоге были отменены в связи с мировым соглашением, но правовые позиции остались — Президиум СИП включил их в Обзор практики по программам для ЭВМ и базам данных (постановление от 18.11.2021 № СП-21/26).

Что важно вынести из этого дела для практики:

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

• Право возникает и тогда, когда наполняют базу сами пользователи — аргумент «это не вы собрали данные, а ваши юзеры» защиту не снимает.

• Действует презумпция: база, содержащая 10 000+ самостоятельных элементов, считается результатом существенных вложений, пока ответчик не докажет обратное.

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

Шаг 3. Выберите трек защиты

В России есть два принципиально разных пути. Их можно использовать параллельно.

Трек 1: Суд

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

Что можно требовать:

• запрет на использование;

• компенсацию от 10 тысяч до 10 миллионов рублей (ст. 1301 ГК РФ в связке с новой базовой ст. 1252.1 ГК РФ) или в двукратном размере стоимости права;

• возмещение убытков;

• обеспечительные меры — на практике они часто важнее самой компенсации.

Реалистично о деньгах и сроках. С 4 января 2026 года верхний предел компенсации в твёрдой сумме повышен с 5 до 10 миллионов рублей (Федеральный закон от 07.07.2025 № 214-ФЗ, которым введена и общая ст. 1252.1 ГК РФ). Важная оговорка: новый потолок применяется только к нарушениям, совершённым после 04.01.2026, к более ранним действует прежний лимит 5 млн. Сам по себе диапазон вводит в заблуждение оптимизмом: суды почти никогда не присуждают по верхней планке: размер компенсации суд определяет с учётом характера нарушения, и заявленную сумму регулярно снижают. Чтобы получить больше нижней границы, сумму нужно обосновывать: стоимостью лицензии, объёмом использования, длительностью. Срок: дело с экспертизой кода — это, как правило, больше года; рассмотрение дела в ФАС РФ обычно идёт быстрее.

Главная сложность в спорах о коде — доказывание. Основной инструмент судов — сравнение исходных кодов через экспертизу. Если у вас нет кода ответчика, а он отказывается его предоставить — придётся опираться на косвенные доказательства и юридическую фикцию по ч. 3 ст. 79 ГПК РФ (суд вправе считать факт установленным, если сторона уклоняется от экспертизы). Это отдельная большая тема, разбирала её в другой статье.

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

Где смотреть актуальные позиции по интернет‑нарушениям: ориентируйтесь на Обзор судебной практики по делам, связанным с нарушением авторских и смежных прав в сети «Интернет», утверждённый Президиумом ВС РФ 29.05.2024. В нём собраны свежие подходы судов к доказыванию и ответственности за неправомерное использование контента и ПО в сети — полезно и для подготовки иска, и для оценки своих шансов.

Трек 2: ФАС РФ — недобросовестная конкуренция

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

Закон о защите конкуренции (135-ФЗ) прямо запрещает несколько видов недобросовестной конкуренции, связанных с копированием:

• Статья 14.5 — недобросовестная конкуренция, связанная с незаконным использованием результатов интеллектуальной деятельности.

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

Признаки, которые нужно доказать по ст. 14.6, разъяснены в постановлении Пленума ВС РФ от 04.03.2021 № 2 и некогда были детализированы в письме ФАС от 30.06.2017 № АК/44651/17: нужно установить наличие конкурентных отношений, факт копирования или имитации, вероятность смешения, различительную способность внешнего вида вашего продукта и причинение или возможность причинения вреда. Ключевой акцент ПП ВС: смешение оценивается не по отдельным деталям, а по общему впечатлению, которое продукт производит на потребителя.

Преимущества пути через ФАС:

• не нужно платить госпошлину как в суде;

• ФАС РФ сама проводит расследование и запрашивает доказательства, в том числе у нарушителя, что снимает с вас часть бремени доказывания;

• решение ФАС РФ можно затем использовать в суде для взыскания убытков;

• иногда достаточно самой угрозы обращения, чтобы нарушитель остановился.

Когда ФАС РФ особенно полезна: когда скопирован не код, а общее впечатление от продукта (дизайн, стиль, подача) и пользователи путают ваш продукт с продуктом конкурента. Именно тот случай, где авторское право бессильно (форма не охраняется), а смешение налицо.

Это работает и для цифровых продуктов. Показательное дело «ЛиБренд» против «БизБренд» (№ А65-7164/2020): Татарстанское УФАС признало недобросовестной конкуренцией по п. 2 ст. 14.6 то, что оформление сайта «ЛиБренд» было сходно до степени смешения с сайтом конкурента «БизБренд», работающего на том же рынке.

Шаг 3*. Обеспечительные меры или как остановить нарушение сразу

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

Что стоит знать на практике:

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

• Суды осторожны: заблокировать сайт конкурента по одному заявлению не дадут — нужна весомая доказательная база (та самая нотариальная фиксация со Шага 1).

• Для отдельных категорий (например, нарушение прав на контент в интернете) предусмотрены предварительные обеспечительные меры через Мосгорсуд, но это специфический механизм с жёсткими сроками, и подходит он не для всякого спора об IT‑продукте.

Обсуждайте обеспечительные меры с юристом на старте, а не после подачи иска, поданное «вдогонку» ходатайство почти не работает.

Шаг 4. Досудебная претензия

До суда и до ФАС РФ имеет смысл направить нарушителю претензию. Иногда этого достаточно: нарушитель не хочет публичного спора и устраняет нарушение.

Для ряда споров досудебный порядок обязателен, без него суд вернёт иск.

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

Минимальный скелет претензии:

1. Кто вы и какие права имеете — точно укажите объект (код, товарный знак №…, дизайн, база данных) и основание прав (договор отчуждения, свидетельство, git‑история).

2. В чём нарушение — конкретно: что, где и с какой даты использует нарушитель. Сошлитесь на приложенную сравнительную таблицу.

3. Доказательства — перечень приложений (нотариальный протокол, скриншоты, ссылки на веб‑архив).

4. Требования — прекратить использование, удалить, выплатить компенсацию (с суммой и обоснованием).

5. Срок на ответ — разумный, обычно 10–30 дней.

6. Предупреждение — что при отказе вы обращаетесь в суд и/или ФАС и относите на нарушителя расходы.

Отправляйте так, чтобы остался след доставки (заказное с описью, плюс на e‑mail из реквизитов).

Шаг 5. Иск или заявление в ФАС

Если претензия не сработала — переходите к формальной процедуре. По интеллектуальным правам — иск в суд (первой инстанцией обычно будет арбитражный суд). По недобросовестной конкуренции — заявление в территориальное управление ФАС или в центральный аппарат (в зависимости от территориального охвата нарушения).

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

Если нарушитель иностранная компания

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

• давление на инфраструктуру: жалобы хостеру, в магазины приложений (App Store, Google Play), платёжным провайдерам — у них свои процедуры по жалобам на нарушение прав;

• блокировка для российской аудитории, если нарушение касается российского рынка;

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

Если ваш рынок международный — регистрируйте права (прежде всего товарный знак) в ключевых странах заранее.

Как защитить свой продукт заранее (превентивные меры)

Лучший спор — тот, который вы выигрываете ещё до его начала, за счёт правильной подготовки.

Фиксируйте авторство на код. Ведите историю разработки в git с датами и авторами коммитов — это ваша основная и самая убедительная точка отсчёта. Депонирование в Роспатенте/у нотариуса полезно как дополнение, но честно понимайте его пределы: депонирование не подтверждает авторство и не создаёт презумпцию правообладания — оно лишь фиксирует, что на определённую дату у вас был такой файл. Ценность есть только в связке с git‑историей и договорами.

Оформите права на код от всех участников. Договоры с разработчиками, фрилансерами, подрядчиками с явным отчуждением исключительных прав. Без этого вы не сможете защищать то, что формально вам не принадлежит. Нюанс, если ваш продукт строился на чужой основе (чужие библиотеки, форк, доработка готового решения): доработка чужого сама по себе не лишает вас прав на ваш собственный результат — это подтвердил Конституционный Суд РФ в деле Мамичева (постановление от 16.06.2022 № 25-П по п. 3 ст. 1260 ГК). Однако чтобы не доказывать это годами в судах, лучше заранее закрыть вопрос с правами всех, кто прикасался к коду.

Зарегистрируйте товарный знак. Это закрывает трек защиты через средства индивидуализации и через ст. 14.6 о смешении и защищает от патентных троллей.

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

Фиксируйте инвестиции в данные. Если ценность в базе данных — сохраняйте подтверждения вложений в её сбор и структурирование. Это ваш аргумент в возможном споре о парсинге.

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

Как самому не стать нарушителем

Обратная сторона — не попасть под иск, копируя чужое. Особенно актуально для стартапов, которые «вдохновляются» лидерами рынка.

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

Проверяйте open source лицензии. GPL и AGPL имеют копилефт‑эффект и могут повлечь обязанность раскрыть исходный код производного/связанного решения при распространении, а AGPL — ещё и при сетевом использовании; объём зависит от архитектуры и способа интеграции. MIT, Apache 2.0, BSD копилефта не создают, но это не значит, что можно делать, что хочется: они требуют соблюдения условий атрибуции (сохранения уведомлений об авторстве и текста лицензии), а Apache 2.0 содержит ещё и патентные положения и требование к файлу NOTICE. Нарушение атрибуции — это тоже нарушение лицензии. Проведите аудит зависимостей до релиза.

Не копируйте фирменный стиль конкурента. Можно вдохновляться отраслевыми стандартами, но прямое копирование цветовой гаммы, расположения элементов и подачи — риск попасть под ст. 14.6 о смешении.

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

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

Частые ошибки из практики

Несколько ситуаций, с которыми клиенты приходят слишком поздно:

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

• «У нас украли идею». Скопировали логику и набор функций, но написали свой код и нарисовали свой интерфейс. Идея и алгоритм не охраняются (п. 5 ст. 1259 ГК) — защищать в этом случае нечего, остаётся только трек ФАС, если есть смешение.

• «Мы им сначала написали». Предприниматель в гневе отправил нарушителю гневное письмо и тот быстро переписал спорные экраны и почистил репозиторий. Доказательств не осталось, поэтому сначала фиксация, потом контакт.

• «Задепонировали, значит, защищены». Клиент уверен, что раз код задепонирован, вопрос с защитой закрыт. Однако депонирование лишь фиксирует, что на определённую дату у него был такой файл, оно не доказывает ни авторство, ни то, что права принадлежат компании. А git‑истории, которая показала бы, кто и когда писал код, нет; договоров с разработчиками об отчуждении прав — тоже нет. В итоге в споре одно депонирование почти ничего не даёт.

Итог

Если скопировали ваш продукт — действуйте по алгоритму: в первые сутки зафиксируйте нарушение (веб‑архив, скриншоты, запись к нотариусу), определите, что именно скопировано (код, дизайн, данные или общее впечатление), выберите трек (суд, ФАС или оба параллельно), направьте претензию, при необходимости заявите обеспечительные меры и переходите к формальной процедуре.

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

А чтобы не оказаться нарушителем самому — проверяйте лицензии (включая условия атрибуции в MIT/Apache/BSD), не копируйте чужой код и фирменный стиль, оформляйте права от подрядчиков.

Есть вопрос по конкретной ситуации — пишите в комментариях или в личку.

Проголосовали 10 пользователей. Воздержались 3 пользователя.