Заимствование кода: как доказать заимствование программного кода в споре
Один из самых странных моментов в моей работе случается не на суде и не в переписке, а в голове клиента. Он приносит два архива, ставит на стол ноутбук и говорит: «Ну вы же видите, тут всё одинаковое. Значит, украли». И я правда вижу: одинаковые имена файлов, похожие функции, одинаковые комментарии с кривыми опечатками. Но дальше начинается взрослая часть разговора. Потому что «похоже» и «доказано» это две разные планеты, и на одной живут разработчики, а на другой юристы, эксперты и суд.
Вторая классика жанра: «Я же выкладывал на GitHub, там же всё с датами, это и есть доказательство». Иногда да, иногда нет. Публичный репозиторий может сыграть вам в плюс, а может внезапно стать сценой, где другая сторона покажет форк, переписанную историю и объяснит, что «вообще-то это их ветка». В споре про заимствование кода важно не только найти сходство, но и аккуратно собрать цепочку: от авторства и даты появления до объёма совпадений и отсутствия законного основания использовать ваш код.
Зачем вообще заморачиваться и что у вас останется в руках
После прочтения у вас будет рабочая схема: как подготовить доказательства так, чтобы они не рассыпались при первом вопросе «а откуда файл?», как фиксировать историю разработки, как подходить к анализу сходства, и где автоматизация реально экономит нервы. Плюс расскажу, где люди чаще всего сами себе устраивают пожар: забывают про лицензии, теряют исходники, путают «идею» и «код», и приходят слишком поздно. Если вам по дороге хочется держать руку на пульсе по интеллектуалке, подпишитесь на Telegram-канал и на Телеграмм канал Патентного бюро Лирейт», там часто обсуждаем такие сюжеты без занудства.
Пошаговый гайд: как собирать доказательства и не утонуть в папках
Шаг 1. Зафиксируйте, что именно вы считаете «своим кодом»
Сначала делаем скучную, но спасительную вещь: определяем границы. Какой проект, какая версия, какие модули. В споре про заимствование кода легко увязнуть, потому что продукт «живой»: вчера был один коммит, сегодня десять. Вам нужно заземлиться в конкретную точку времени и конкретный набор файлов. Зачем: чтобы эксперт и суд могли сравнивать «то» с «этим», а не ваши эмоции с чужими обещаниями. Типичная ошибка: приносить «весь репозиторий за три года», где половина библиотек чужая, а половина вообще не относится к спору. Проверка простая: вы можете за 2 минуты объяснить, какой именно кусок кода является объектом сравнения и почему он важен? Если нет, значит границы не поставлены.
Из практики: у клиента был небольшой B2B-сервис, и спор начался из-за двух модулей расчёта тарифов. Он хотел доказывать «украли всё приложение». Мы сели, вырезали ровно те директории, где у него была оригинальная логика, и перестали таскать за собой лишний балласт. Это не магия, просто дисциплина. И, да, иногда больно признавать, что «всё приложение» не ваше, потому что там половина зависимостей и типовой обвязки.
Шаг 2. Сохраните цепочку происхождения: версии, коммиты, даты
Дальше нужен след, по которому можно пройти. История коммитов, теги релизов, issue, пулл-реквесты, даже переписка команды, где обсуждали конкретные решения. Зачем: доказательство заимствования программного кода обычно упирается в три вопроса: вы это сделали раньше, у вас это было в таком виде, и это не появилось «само». Типичная ошибка: «у нас всё в Телеграме и на созвонах». Суду созвоны не покажешь, а Телеграм без привязки к файлам часто выглядит как разговоры о погоде. Проверка: по вашему набору материалов можно восстановить, когда появился конкретный файл и почему он стал таким? Если вы не можете, значит другая сторона сможет рассказать альтернативную историю.
Тут внезапно помогают не только GitHub/GitLab, но и автоматизация. Make.com (раньше Integromat) это платформа, которая позволяет без программирования связать сервисы и собрать рутину в одну цепочку. В кейсе с продуктовой командой на 6 человек мы настроили сценарий: при каждом релизном теге в GitLab автоматически сохранялся архив исходников в отдельное хранилище, а рядом создавалась карточка с датой, хешем коммита и ссылками на обсуждения. Не потому что «модно», а потому что в споре вы не хотите вручную собирать по крупицам, кто и что делал полгода назад. Проверка работоспособности простая: делаете тестовый тег, и через минуту у вас появляется полный «пакет» с фиксированной версией и метаданными.
Шаг 3. Аккуратно соберите «чужой» код и зафиксируйте источник
Теперь добываем то, с чем сравниваем. Это может быть открытый репозиторий, поставка клиенту, дистрибутив, или код на проде, к которому вы получили доступ законным способом. Зачем: без корректной фиксации источника любая находка превращается в «скриншотик из интернета». Типичная ошибка: «мы скачали zip, но не помним откуда», или «вот кусок кода из чата, нам скинул знакомый». Проверка: у вас должна быть понятная история получения, чтобы не прилетело обратное обвинение в неправомерном доступе или подлоге (и да, такие истории я тоже видела, неприятно).
Если речь про сайт/веб-приложение, часто хочется «вытащить» исходники прямо из браузера. Не надо. То, что доступно в клиенте, не равно исходникам сервера. Собирайте то, что реально можно собрать: публичные репозитории, официальные поставки, документы, где фигурируют куски кода, и любые законные артефакты. А если у вас есть бинарник, то вы уже на территории экспертизы по бинарному сходству, там свои правила и инструменты.
Шаг 4. Сравните код так, чтобы это было похоже на доказательство, а не на «мне кажется»
Вот тут начинается любимое: «я открыл два файла и вижу одинаковые строки». Это хороший старт, но плохой финал. Вам нужно показать характер совпадений: структура, уникальные фрагменты, повторяющиеся ошибки, одинаковые имена переменных в специфических местах, совпадающие комментарии, одинаковые нестандартные решения. Зачем: доказательство заимствования программного кода включает не только факт использования чужого кода, но и объём использования. Типичная ошибка: сравнивать только поверхностно и игнорировать, что типовые куски могут совпадать у сотни проектов. Проверка: если убрать общие места (инициализация, типовой CRUD, стандартные библиотеки), останется ли «ядро», которое всё равно совпадает?
Технически можно использовать инструменты статического анализа и поиска клонов кода. Тут я не буду называть «единственно правильный», потому что в разных языках и стэках работают разные штуки. Важно другое: сохраняйте отчёты, настройки сравнения, версии инструментов и входные файлы. Иначе вы приносите результат, который невозможно воспроизвести. Отдельная линия это бинарное сравнение, когда исходников нет. Есть исследования, где семантический анализ бинарного кода показывает высокую эффективность даже при обфускации, например, в работе про BinMatch (2018). В реальности это означает одно: иногда «они всё спрятали» не делает доказательство невозможным, но делает его дороже и более экспертозависимым.
Шаг 5. Разберите, было ли у них право использовать ваш код
Самый неловкий поворот в делах про заимствование кода случается, когда выясняется: код действительно ваш, но вы сами дали право на использование. Лицензия open source, договор с подрядчиком, условия фриланс-площадки, NDA с дырой размером с окно. Зачем: спор не про «кто первый написал», а про «было ли законное основание». Типичная ошибка: считать, что отсутствие договора автоматически на вашей стороне. Нет, иногда отсутствие договора бьёт по вам же, потому что права не оформлены или переданы не так, как вы думали. Проверка: вы можете показать документы и условия лицензирования на момент передачи/публикации, и они читаются однозначно?
Мини-кейс: у одного ИП был маркетплейс-плагин, который он заказывал у фрилансера «по дружбе». Оплата переводом, ТЗ в мессенджере, актов нет. Когда плагин всплыл у конкурента, началась паника. В итоге спор упёрся не только в сходство кода, но и в вопрос, кому принадлежат права на исходники. Мы вытащили переписку, подтверждения передачи, черновики, но времени на восстановление картины ушло больше, чем на сам анализ сходства. Вобще, это тот случай, когда «сэкономили на бумагах» превращается в дорогое хобби.
Шаг 6. Упакуйте доказательства так, чтобы их было удобно читать не программисту
Суд и юрист другой стороны не обязаны любить ваш стек. У них есть ограниченное время и ограниченное терпение. Поэтому ваша задача: сделать понятный пакет материалов, где есть исходные файлы, отчёты сравнения, пояснения простыми словами и привязка к датам. Зачем: даже сильные находки тонут, если их подать как кашу из скринов и архивов «final_final2.zip». Типичная ошибка: приносить материалы без объяснений, надеясь, что «там и так всё видно». Проверка: дайте пакет человеку, который не пишет на вашем языке, и спросите, может ли он понять, что произошло, за 15 минут. Если не может, значит нужно перепаковать.
Здесь автоматизация снова помогает. Make.com можно использовать как «конвейер папок»: складывать версии, отчёты, переписки и ссылки в одну структуру, чтобы ничего не потерялось. Я люблю такие решения не за красоту, а за то, что в момент стресса вы не перепутаете релиз, не забудете приложить отчёт и не отправите в суд не тот архив. И да, когда оппонент начинает заваливать вас письмами и «а пришлите ещё вот это», порядок в файлах экономит недели.
Шаг 7. Подготовьтесь к экспертизе и к тому, что вас будут «ловить на терминах»
Если спор заходит далеко, почти всегда всплывает тема экспертизы: что сравнивать, каким методом, какие вопросы ставить. Зачем: формулировка вопросов эксперту часто решает половину дела. Типичная ошибка: ставить вопросы уровня «украли или нет», на которые эксперт не может отвечать напрямую, или просить сравнить «весь код», что превращает экспертизу в бесконечный сериал. Проверка: ваши вопросы конкретны, измеримы и привязаны к спорным фрагментам, а не к общим ощущениям.
Ещё момент: другая сторона может утверждать, что это «правомерная модификация», а не плагиат, и тут границы действительно тонкие. В материалах GSL хорошо описано, что в таких спорах смотрят на факт использования чужого кода, объём и отсутствие законных оснований. Поэтому не зацикливайтесь только на проценте совпадений, важнее показать, что совпадает именно уникальная логика, а не стандартные конструкции. И заранее приготовьтесь, что вам зададут неприятный вопрос: «А вы сами ничего не заимствовали?» Лучше найти и обезвредить это у себя до того, как это сделает оппонент.
Подводные камни: где чаще всего всё ломается
Первое место, где люди теряют время, это попытка доказать «идею». «Они сделали такой же экран, такие же кнопки, такой же сценарий». Всё это может быть важно в общей картине, но спор про заимствование кода держится на коде и его происхождении. Если у вас нет исходников или хотя бы чётких артефактов разработки, вы будете биться головой о стену, сколько бы ни было похожих интерфейсов. И наоборот: иногда интерфейсы разные, а внутри почти тот же алгоритм с теми же странными переменными. Это обидно, но юридически часто сильнее.
Вторая ловушка это лицензии и «вроде бы открытый код». Некоторые берут кусок из Stack Overflow, кусок из GitHub, добавляют туда свой алгоритм и потом искренне считают весь файл «своим». В споре это выстреливает в обе стороны. Вам придётся отделить собственный вклад от чужих компонентов и не спорить с очевидным. И ещё: если вы публиковали код под открытой лицензией, не удивляйтесь, что им могли воспользоваться. Вопрос будет не «почему воспользовались», а «нарушили ли условия».
Третья боль это дисциплина фиксации. Репозиторий без нормальных коммит-месседжей, релизы без тегов, доступы уволившихся сотрудников, переписка на личных аккаунтах. Пока всё хорошо, это никого не волнует. Когда случается конфликт, внезапно выясняется, что самый важный кусок истории уехал вместе с ноутбуком разработчика в другой город. Если вы сейчас читаете это и думаете «у нас так и есть», не пугайтесь, просто начните наводить порядок сегодня, а не после претензии.
Когда имеет смысл подключать юристов по интеллектуалке и оформлять права заранее
Есть ситуации, где оформление интеллектуальной собственности и правильные договоры экономят не «возможную прибыль», а обычные человеческие недели. Это продукты, которые вы отдаёте клиентам, разработки с подрядчиками, совместные проекты с долями, и всё, что живёт в команде больше пары месяцев. Если у вас код пишут разные люди и у каждого свой взгляд на «кому принадлежит», лучше зафиксировать это на берегу. В работе часто ценнее не громкие письма, а спокойная обратная связь: что хранить, как фиксировать версии, какие формулировки включить в договор с разработчиком, чтобы потом не краснеть.
Если параллельно вы строите бренд и хотите не только отбиваться в спорах, но и закрывать вопросы системно, посмотрите, что подходит по задачам: Регистрация товарного знака, история про Монополия на бренд, и более широкий контур Юридическая защита интеллектуальной собственности. Я люблю, когда всё это не превращается в «юридический ремонт на кухне», а делается как часть нормальной инженерной гигиены. И да, в Телеграмм канал Патентного бюро Лирейт» иногда разбираем кейсы, где один пункт в договоре сэкономил людям месяцы переписки.
FAQ
Вопрос: Чем отличается «похоже» от «доказано» в споре про заимствование кода?
Ответ: «Похоже» это ваше впечатление от совпадений. «Доказано» это когда у вас есть фиксированная версия вашего кода, корректно полученный набор материалов другой стороны, воспроизводимый анализ сходства и понятная история, почему у них не было законного основания использовать эти фрагменты.
Вопрос: Если код был в открытом репозитории, это облегчает доказательство заимствования программного кода?
Ответ: Может облегчить фиксацию дат и авторства, но одновременно поднимает вопрос лицензии. Если вы сами разрешили использование на определённых условиях, спор будет крутиться вокруг соблюдения этих условий, а не вокруг факта копирования.
Вопрос: Можно ли использовать Make.com для подготовки материалов по спору?
Ответ: Да, как инструмент организации. Make.com это платформа автоматизации без программирования: она помогает связать GitHub/GitLab, хранилища и таблицы, чтобы автоматически сохранять архивы версий, метаданные коммитов и ссылки на обсуждения. Это не «доказывает» само по себе, но сильно снижает риск потерять важные куски.
Вопрос: А если у меня только бинарник, без исходников?
Ответ: Тогда обычно речь идёт о сравнении бинарного кода и экспертизе. Существуют подходы на основе семантического анализа, и исследования показывали эффективность таких методов (например, BinMatch, 2018) даже при обфускации. На практике это означает, что задача решаема, но почти всегда требует экспертного уровня и аккуратной фиксации материалов.
Вопрос: Какие ошибки чаще всего убивают дело про заимствование кода?
Ответ: Отсутствие фиксации версий и дат, «сбор доказательств» через сомнительные каналы, смешивание своего кода с чужими библиотеками без разбора, и игнорирование лицензий. Ещё часто люди пытаются доказать сходство по интерфейсу вместо кода, и теряют время.
Вопрос: Нужно ли сразу идти в суд, если нашёл совпадения?
Ответ: Обычно сначала стоит навести порядок в доказательствах и понять юридическую конструкцию: что именно заимствовано, в каком объёме, и почему это неправомерно. Иногда достаточно грамотной претензии, иногда без экспертизы и суда не обойтись, но прыгать в процесс без базы это дорогая лотерея.
Вопрос: Комментарии и одинаковые опечатки в коде это серьёзный аргумент?
Ответ: Это может быть сильным косвенным признаком, особенно если совпадают редкие формулировки, ошибки и структура, а не только общие конструкции. Но лучше, когда это подкреплено анализом уникальной логики и привязано к датам появления этих фрагментов у вас.