Компьютеры

Экспертиза кодов от «А» до «Я»

Аннотация

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

Ключевые слова: экспертиза кодов, компьютерно-техническая экспертиза, исходный текст программы, программное обеспечение, заимствование кода, переработка программы, авторское право, исключительные права, техническое задание, ГОСТ Р 71489-2024, абстрактное синтаксическое дерево, метрический анализ, судебная экспертиза.

ВВЕДЕНИЕ

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

Актуальность исследования института экспертизы кодов обусловлена целым рядом факторов. Во-первых, в современном обществе неуклонно возрастает объём программного обеспечения, создаваемого и используемого как в коммерческом, так и в государственном секторе, что порождает необходимость объективного и научно обоснованного контроля за соблюдением исключительных прав на программные продукты. 💻 Во-вторых, увеличение числа дел о нарушении авторских прав на программное обеспечение делает востребованными специальные познания в области анализа исходных текстов программ для ЭВМ. ⚖️ В-третьих, особую остроту приобретают споры между заказчиками и подрядчиками по договорам разработки программного обеспечения, связанные с несоответствием фактически представленного кода условиям технического задания. 🔍 В-четвёртых, цифровая трансформация экономики и внедрение новых технологий разработки требуют постоянного развития методологии экспертной деятельности. 📊

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

Для достижения поставленной цели решаются следующие задачи:

определить понятие и сущность экспертизы кодов;
рассмотреть виды экспертизы кодов и их особенности;
проанализировать методологические основы экспертной деятельности;
исследовать организационно-правовые аспекты экспертизы кодов;
раскрыть методическое обеспечение экспертизы кодов;
рассмотреть методы исследования исходных текстов программ;
привести реестр типовых вопросов для экспертизы кодов;
проанализировать десять практических кейсов;
выявить проблемы и перспективы развития института экспертизы кодов.

Важное замечание. Экспертиза кодов может проводиться как в досудебном (независимом) порядке, так и по назначению суда. Досудебная экспертиза проводится по инициативе заинтересованного лица на договорной основе и позволяет выявить факты заимствования до начала судебного разбирательства. Судебная экспертиза назначается определением суда и обладает повышенной доказательственной силой. Выбор формы экспертизы зависит от конкретных обстоятельств спора, позиции сторон и стадии его рассмотрения. ⚖️

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ЭКСПЕРТИЗЫ КОДОВ

1.1. Понятие и сущность экспертизы кодов

Экспертиза кодов — это один из видов компьютерно-технической экспертизы, предметом которой является исследование исходных текстов программ для ЭВМ с целью установления фактов заимствования, переработки или самостоятельного создания программного продукта. 📋

Сущность экспертизы кодов раскрывается через несколько ключевых характеристик.

Во-первых, экспертиза всегда связана с применением специальных знаний. Эксперт-программист, обладающий глубокими профессиональными познаниями в области разработки программного обеспечения, анализа алгоритмов, архитектуры программных систем, использует их для разрешения вопросов, выходящих за пределы обыденного опыта и общих знаний. 🧠
Во-вторых, экспертиза проводится в строго определённой процессуальной форме. Законодательство устанавливает требования к порядку назначения экспертизы, правам и обязанностям эксперта, форме и содержанию экспертного заключения, срокам проведения исследования. 📜
В-третьих, результатом экспертизы является экспертное заключение — документ, содержащий мотивированные ответы на поставленные перед экспертом вопросы. Заключение эксперта имеет доказательственное значение в юридическом процессе и служит основой для принятия судебных решений. 📄
В-четвёртых, экспертиза кодов носит объективный и научно обоснованный характер. Экспертное исследование базируется на достижениях современной науки о программировании, использовании проверенных методов и методик, объективных данных. ✅
В-пятых, экспертиза кодов может проводиться как в досудебном порядке (по инициативе заинтересованного лица), так и по назначению суда. Это связано с тем, что заинтересованное лицо может самостоятельно обратиться к эксперту для проверки программного продукта, либо инициировать экспертизу в рамках судебного разбирательства, где суд может истребовать дополнительные материалы и обеспечить участие всех сторон. ⚖️

1.2. Когда возникает необходимость в экспертизе кодов

Наиболее часто экспертиза кодов востребована в рамках судебных споров о нарушении исключительных прав на программное обеспечение. Типичные сценарии: 🔍

бывший сотрудник или партнёр использует фрагменты кодовой базы для создания конкурирующего продукта; 👨‍💻
заказчик и подрядчик не могут согласовать объём и качество выполненной разработки; 🤝
правообладатель обнаруживает в сети программный продукт, подозрительно напоминающий его собственный. 🌐

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

1.3. Объекты экспертизы кодов

Объектами экспертизы кодов выступают исходные тексты программ для ЭВМ в различных форматах: 📁

файлы репозиториев систем контроля версий (Git, SVN); 📂
архивы проектов; 🗂️
документы, представленные для регистрации программ в Роспатенте. 📄

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

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

1.4. Место экспертизы кодов в системе правоприменения

Экспертиза кодов занимает особое место в системе правоприменения, выполняя ряд важнейших функций. ⚖️

Диагностическая функция — экспертное исследование позволяет установить наличие или отсутствие заимствования программного кода. 🔍

Оценочная функция — экспертиза даёт оценку соответствия представленного кода требованиям технического задания или договора. ✅

Разграничительная функция — экспертное исследование позволяет разграничить оригинальные и заимствованные фрагменты кода. 🧩

Причинно-следственная функция — экспертиза устанавливает наличие или отсутствие причинно-следственной связи между действиями ответчика и наступившими неблагоприятными последствиями для правообладателя. 🔗

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

ГЛАВА 2. МЕТОДИЧЕСКОЕ ОБЕСПЕЧЕНИЕ ЭКСПЕРТИЗЫ КОДОВ

2.1. Постановка проблемы

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

2.2. Нормативно-правовой уровень

Базовым документом, определяющим правовые рамки исследования, остаётся Федеральный закон от 31.05.2001 № 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации», устанавливающий общие требования к производству судебных экспертиз, включая принципы законности, независимости эксперта и объективности исследования. 📜

Применительно к объектам авторского права существенное значение имеют положения части четвёртой Гражданского кодекса РФ (ст. 1259, 1260, 1270, 1280), поскольку именно они задают юридические критерии, которые экспертное исследование должно операционализировать: оригинальность, творческий характер, воспроизведение в существенной части. ⚖️

Процессуальные основания назначения и производства экспертизы закреплены в АПК РФ (ст. 82–87), ГПК РФ (ст. 79–87), УПК РФ (ст. 195–207) и КАС РФ (ст. 77–79). Указанные нормы не содержат методических предписаний, однако формируют требования к структуре заключения, пределам компетенции эксперта и допустимости используемых методов. 📋

2.3. Общеметодический уровень

На общеметодическом уровне экспертиза кодов опирается на типовую методику производства компьютерно-технической экспертизы, разработанную в системе экспертных подразделений МВД России и в дальнейшем адаптированную для негосударственных экспертных организаций. В рамках этой методики определяются стадии экспертного исследования: подготовительная, аналитическая (раздельное и сравнительное исследование), синтезирующая и оценочная, — а также общие требования к фиксации хода и результатов исследования. 🔬

Значимый вклад в методическое обеспечение вносит ГОСТ Р 71489-2024 «Судебная компьютерно-техническая экспертиза. Термины и определения», вводящий унифицированный понятийный аппарат, в том числе применительно к исследованию программного обеспечения. 📊

Смежные положения содержатся в ГОСТ Р 7.0.97-2016 (требования к оформлению документов) и в национальных стандартах серии ГОСТ Р ИСО/МЭК 27000, регулирующих вопросы информационной безопасности и управления программными активами, что имеет значение при установлении происхождения кодовой базы. 📚

2.4. Частнометодический уровень

Собственно методики исследования кодов формируются по трём основным направлениям. 📋

Методика выявления заимствований (плагиата) в исходном коде. Наиболее разработанное направление, опирающееся на комбинацию лексического, синтаксического и семантического анализа. Лексический подход базируется на токенизации и сравнении последовательностей лексем с применением алгоритмов нечёткого сопоставления строк (Ratcliff/Obershelp, Levenshtein, Winnowing). Синтаксический подход предполагает построение абстрактных синтаксических деревьев (AST) и вычисление метрик структурного сходства. Семантический подход ориентирован на сопоставление алгоритмической логики и может применяться при кросс-языковом сравнении. Инструментальную основу составляют как специализированные пакеты (MOSS, JPlag, SIM, PMD CPD, SourcererCC), так и проприетарные решения, используемые экспертными учреждениями. 🔍

Методика установления факта переработки программы. Опирается на ст. 1270 ГК РФ и разъяснения, данные в постановлении Пленума Верховного Суда РФ от 23.04.2019 № 10, согласно которым переработка предполагает воспроизведение существенной части программы. Методика включает: установление объёма совпадающего кода в абсолютных и относительных показателях; оценку функциональной значимости совпадающих фрагментов; выявление признаков творческого вклада (уникальные архитектурные решения, нестандартные алгоритмы, характерные ошибки); исключение совпадений, обусловленных общеизвестными конструкциями, стандартными библиотеками и требованиями технического задания. ⚖️

Методика исследования программ по договорам разработки. Применяется при спорах о качестве и объёме исполнения. Предполагает сопоставление фактически представленного кода с техническим заданием, оценку полноты реализации функциональных требований, проверку соответствия заявленных характеристик фактическим. Методической основой служат положения ГОСТ 34.601-90 (стадии создания автоматизированных систем) и ГОСТ 19.201-78 (техническое задание). 📄

2.5. Проблема верифицируемости и стандартизации

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

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

ГЛАВА 3. МЕТОДЫ ИССЛЕДОВАНИЯ ИСХОДНЫХ ТЕКСТОВ ПРОГРАММ

3.1. Общенаучные методы

Методологическую основу экспертизы кодов составляют общенаучные и специальные методы познания. 🔬

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

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

Логические методы — анализ, синтез, индукция, дедукция, аналогия, обобщение, абстрагирование. 🧠

Статистические методы — сбор, обработка, анализ количественных данных. 📊

3.2. Специальные методы экспертизы кодов

Специальные методы экспертизы определяются конкретным видом экспертизы и решаемыми задачами. 📋

Синтаксический и структурный анализ предполагает сравнение архитектуры программ, организации модулей и библиотек, последовательности функций, а также именования переменных и классов. Особое внимание уделяется поиску уникальных, «опорных» участков кода, которые не могут совпадать случайно. 🏗️

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

Метрический анализ использует специализированное программное обеспечение для расчёта количественных показателей сходства: хеш-сумм, анализа последовательностей токенов, сравнения на уровне синтаксических деревьев. Это позволяет получить объективную оценку объёма совпадений. 📊

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

Построение абстрактных синтаксических деревьев (AST) — метод, предполагающий построение AST и вычисление метрик структурного сходства. 🌳

Анализ контрольного потока (CFG) — метод, основанный на сравнении графов потока управления. 🔄

Псевдокодный анализ — метод, предполагающий абстрагирование от конкретного синтаксиса и сравнение логики программ на уровне псевдокода. 📝

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

3.3. Экспертное исследование: этапы и содержание

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

Подготовительный этап:

изучение определения (постановления) о назначении экспертизы или договора на проведение экспертизы; 📋
проверка наличия и полноты материалов, представленных на экспертизу; 📁
определение достаточности материалов для решения поставленных вопросов; ❓
планирование экспертного исследования; 🎯
выбор методов и методик исследования. 🔬

Аналитический этап:

раздельное исследование каждого объекта (изучение структуры, архитектуры, функциональности); 📄
сравнительное исследование (сопоставление кодов, выявление совпадений); 🔍
анализ применённых алгоритмов и структур данных; 🧠
выявление уникальных и стандартных фрагментов. 🧩

Исследовательский этап:

проведение метрического анализа; 📊
построение AST и CFG; 🌳
оценка функциональной значимости совпадающих фрагментов; ⚖️
исключение совпадений, обусловленных стандартными библиотеками и требованиями ТЗ; ✅
фиксация результатов исследований. 📸

Синтетический этап:

обобщение результатов исследования; 📚
установление причинно-следственных связей; 🧠
формулирование промежуточных выводов; 📝
проверка выводов на соответствие принципам логики и научной обоснованности. ✅

Заключительный этап:

формулирование ответов на поставленные вопросы; 📋
составление экспертного заключения; 📄
оформление иллюстративного материала (таблицы совпадений, схемы); 📊
подписание заключения, удостоверение его печатью. 🖊️

ГЛАВА 4. РЕЕСТР ВОПРОСОВ ДЛЯ ЭКСПЕРТИЗЫ КОДОВ

4.1. Введение в проблематику формулирования вопросов

Правильная постановка вопросов перед экспертом-программистом — залог получения качественного и доказательственно значимого экспертного заключения. От того, насколько точно и корректно сформулированы вопросы, напрямую зависит полнота и объективность экспертного исследования. ❓

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

4.2. Общие требования к формулированию вопросов

Вопросы должны быть в пределах компетенции эксперта. Эксперт-программист не вправе давать юридическую оценку действиям сторон. ⚖️

Некорректный вопрос: «Является ли заимствование кода нарушением авторских прав?»

Корректный вопрос: «Имеются ли в представленных программах совпадения программного кода, и каков характер этих совпадений?»

Вопросы должны быть конкретными и однозначными. ❓

Некорректный вопрос: «Правильно ли написана программа?»

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

Вопросы должны быть основаны на материалах дела. 📁

Некорректный вопрос: «Какова рыночная стоимость аналогичных программ?»

Корректный вопрос: «Является ли исходный код одной программы переработкой или воспроизведением кода другой программы?»

Вопросы должны быть сформулированы в логической последовательности. 📊

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

Является ли представленный код оригинальным?
Имеются ли совпадения с кодом другой программы?
Каков характер и объём этих совпадений?
Свидетельствуют ли совпадения о заимствовании?

4.3. Вопросы о принадлежности прав и оригинальности

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

Обладает ли представленный исходный код признаками творческого характера, позволяющими признать его объектом авторского права (оригинальность алгоритмических решений, структур данных, архитектуры)? 🧠
Имеются ли в представленном исходном коде уникальные элементы, свидетельствующие об авторстве (специфические ошибки, служебные комментарии, тестовые данные, стиль именования)? 🔍
Является ли представленный код результатом самостоятельной творческой деятельности? ✅

Методика исследования данной категории вопросов опирается на анализ нефункциональных характеристик кода. Эксперту необходимо выявить те индивидуализирующие признаки, которые не могут возникнуть случайно при независимой разработке: специфические习惯 именования методов, опечатки, избыточное проектирование и иные особенности. 🧩

4.4. Вопросы о сходстве и заимствовании кода

Это наиболее востребованная категория вопросов, связанная со сравнительным анализом двух или более массивов программного кода. 🔍

Является ли исходный код одной программы переработкой или воспроизведением кода другой программы? 📋
Имеются ли в представленных программах совпадения программного кода, и каков характер этих совпадений? 📊
Свидетельствуют ли обнаруженные совпадения о заимствовании логики работы программы? 🧠
Является ли программа ответчика переработкой (заимствованием) программы истца? Для проведения экспертизы должны быть представлены исходные коды обеих программ. ⚖️
Имеются ли в сравниваемых программах идентичные или сходные до степени смешения фрагменты исходного кода? Если да, каковы их качественные и количественные характеристики? 📊
Могут ли обнаруженные совпадения быть обусловлены независимым созданием, использованием открытого исходного кода, стандартных библиотек или реализацией общеизвестных алгоритмов? 🔄
Какова доля совпадений исходного кода программ в процентном соотношении? Обусловлена ли такая доля исключительно функциональным назначением сравниваемых программ? 📈

Важное замечание. Процентное соотношение совпадений само по себе не предопределяет вывод о переработке. Суд в деле № 09АП-91383/23 (2024) признал, что даже при совпадении исходного кода в 2,53% и 2,8% такие совпадения не образуют переработки, если они «полностью обусловлены функциональным назначением сравниваемых программ во взаимодействии с криптовалютными биржами». ⚖️

Методика исследования данной категории вопросов предполагает использование лексического сравнения, сравнения абстрактных синтаксических деревьев (AST), сравнения графов потока управления (CFG). 📊

4.5. Вопросы о соответствии программы условиям договора

Данная категория вопросов возникает в спорах между заказчиком и разработчиком и касается соответствия фактически представленного программного продукта условиям технического задания. 📄

Работоспособна ли программа в соответствии с условиями заключённого договора? ✅
Обладает ли программа потребительской ценностью? 💰
Какова степень завершённости программы? Имеются ли недостатки и ошибки, препятствующие нормальной работе и использованию продукта потребителем? ⚠️
Соответствует ли программа обычно применяемым требованиям к此类产品? 📋
Если экспертиза установит неработоспособность программы, обусловлена ли такая неработоспособность отсутствием обновлений программы или вмешательством третьих лиц в программное обеспечение? 🔄

Особенность данной категории вопросов состоит в том, что эксперт должен не только провести статический анализ исходного кода, но и развернуть программу в тестовой среде и проверить её фактическую функциональность. 🧪

4.6. Вопросы об отдельных функциональных модулях

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

Использовался ли исходный код программы истца в программном модуле, предназначенном для подключения к криптовалютным биржам? 📊

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

4.7. Вопросы о сбоях в работе программы и техническом вмешательстве

Данная категория вопросов связана с техническим установлением причин сбоев в работе программного обеспечения. ⚠️

Обусловлен ли сбой в работе программы техническими недостатками самой программы или вмешательством третьих лиц в программное обеспечение? 🔄
Является ли сбой в работе программы воспроизводимым? Если да, каков его технический механизм? 🧪

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

4.8. Методологические требования к формулированию вопросов

Обобщая изложенное, можно сформулировать следующие методологические требования к постановке вопросов на экспертизу кодов. 📚

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

Второе. Техническая проверяемость вопроса. Вопрос должен допускать однозначный технический ответ с использованием существующих методов. Юридически значимый вопрос о том, является ли программа переработкой, должен быть преобразован в технические вопросы о наличии заимствования на уровне исходного кода и о характере и объёме совпадений. 🔬

Третье. Связь вопроса с предметом спора. При определении вопросов суд должен учитывать, соответствуют ли они предмету иска и имеют ли значение для разрешения дела. Вопросы, выходящие за рамки предмета спора, не только влекут неоправданные процессуальные издержки, но и могут лишить заключение доказательственной силы. ⚖️

Четвёртое. Учёт доступности материалов экспертизы. При формулировании вопросов необходимо учитывать фактический объём материалов, доступных эксперту. Если в распоряжении эксперта имеется только объектный код, прямое сравнение исходного кода невозможно, и вопросы должны быть адаптированы к методам декомпиляции или анализа поведения. 📂

ГЛАВА 5. ДЕСЯТЬ ПРАКТИЧЕСКИХ КЕЙСОВ ЭКСПЕРТИЗЫ КОДОВ

5.1. Кейс № 1: Beijing Meishe Network Technology Co., Ltd. против TikTok Inc. (Федеральный окружной суд Северного округа Калифорнии, США, 2025 год)

Фабула дела. Китайская компания Meishe предъявила иск к TikTok, утверждая, что бывший сотрудник Се, уволившись, взял с собой пять версий исходного кода приложения «Дуньхуан» и использовал этот код в приложении TikTok. Meishe путём декомпиляции объектного кода ответчика и сравнения его с собственным исходным кодом обнаружила значительное сходство в функциях редактирования видео и аудио, включая совпадение имён методов и опечаток. 📱

Метод экспертизы. В данном деле истец применил метод декомпиляции объектного кода и перекрёстного сравнения с исходным кодом. Сходство включало не только функциональные совпадения, но и нефункциональные признаки — специфические习惯 именования методов и опечатки, которые крайне индивидуализированы и не могут возникнуть случайно при независимой разработке. 🔍

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

5.2. Кейс № 2: PQ Systems против Jeff Aughton (Высокий суд Англии, патентное отделение, 2023 год)

Фабула дела. Ответчик Aughton ранее работал в компании истца и участвовал в разработке программного обеспечения ProSPC. После увольнения он создал две новые программы InSPC v1 и InSPC v2. Истец утверждал, что при написании последующих программ ответчик скопировал код ProSPC. 💻

Сложности экспертизы. Оригинальный исходный код ProSPC и InSPC v1 был удалён ответчиком, что сделало прямое сравнение невозможным. Кроме того, InSPC v2 написан на C#, тогда как ProSPC и InSPC v1 — на VB.NET, что исключало прямой текстовый анализ. 🔄

Метод экспертизы. Стратегия истца основывалась на сравнении декомпилированного кода и косвенных доказательствах. Эксперты получили декомпилированный объектный код ProSPC и InSPC v1 и сравнили его с декомпилированным кодом InSPC v2. Из-за значительных различий между декомпилированным и оригинальным кодом выводы в большей степени опирались на структурное сходство, а не на построчное соответствие. Суд также учёл признания ответчика на дисциплинарных слушаниях и его противоречивые объяснения в суде. ⚖️

5.3. Кейс № 3: Admar Computers Pty Ltd против Ezy Systems Pty Ltd (Федеральный суд Австралии, 1997 год)

Фабула дела. Истец Admar разработал систему управления для винодельческой отрасли. Четвёртый ответчик ранее был программистом истца, третий ответчик работал консультантом. После увольнения они основали конкурирующую компанию и разработали систему Ezy Wine Management System. Истец обвинил их в копировании исходного кода и использовании конфиденциальной информации. 🍷

Метод экспертизы — анализ псевдокода. Ключевой вклад данного дела — признание анализа псевдокода в качестве допустимого метода экспертизы программного обеспечения. Эксперт истца профессор Willis не проводил построчное сравнение исходного кода (объём каждой системы превышал 90 000 строк), а использовал метод абстрагирования — преобразование исходного кода в псевдокод, отвлекаясь от конкретных синтаксических деталей и фокусируясь на логике программы, структуре модулей, соглашениях об именовании и стиле кодирования. 🧠

Ограничения выводов. Willis отметил, что «система Ezy в целом не выглядит как построчная конвертация системы Admar», и только в отношении одной программы просмотра экранных отчётов признал «наиболее вероятное прямое копирование (с незначительными изменениями)». 📊

5.4. Кейс № 4: Дело о программном обеспечении «Тунмусинь» (Шанхайский народный суд района Цзинъань, 2024 год)

Фабула дела. Обвиняемый Чжун Моуфэн, предоставив программу trade.dll, позволил программе trading-agent компании «Сюньмоу» несанкционированно подключиться к системе биржевой торговли ценными бумагами «Тунмусинь». В ходе предварительного расследования была проведена экспертиза, которая установила, что ключевые торговые файлы tc-dump1.dll и tc-dump2.dll программы trading-agent имеют существенное сходство с ключевым торговым файлом tc.dll программы «Тунмусинь». 📈

Метод экспертизы. Экспертиза носила комплексный характер. Сначала из облачного сервера была извлечена программа trading-agent, из неё выделена программа trade.dll, затем с помощью загрузочного анализа и декомпиляции проведено сравнение кода, выявившее существенное сходство ключевых торговых файлов. 🔍

От «сходства» к «нарушению». Экспертиза не ограничилась установлением сходства кода. Прокуратура с помощью технического специалиста провела имитационный эксперимент и установила, что программа «Тунмусинь» использует двойную защиту — проверку целостности клиентских файлов на сервере и упаковку ключевых файлов с помощью VMProtect. Вывод экспертизы указывал на то, что программа компании «Сюньмоу» обошла технические меры защиты для несанкционированного подключения, а не на простое копирование кода. ⚖️

5.5. Кейс № 5: Американская компания против Уханьской компании (Верховный суд КНР, 2021 год)

Фабула дела. Американская компания утверждала, что Уханьская компания без разрешения скопировала и использовала её программное обеспечение для автоматизации проектирования электроники «Design Compiler». Суд с помощью предварительного обеспечения доказательств и метода «командного исследования» зафиксировал состояние компьютеров и серверов Уханьской компании и обнаружил в них информацию, идентичную программному обеспечению американской компании по названию, структуре каталогов и сообщениям об ошибках. 💻

Особенность экспертизы — отказ от сравнения исходного кода. Суд чётко указал: «сравнение исходного кода не может быть единственным критерием для установления тождества или существенного сходства программного обеспечения». Если правообладатель доказал высокое сходство интерфейсов, наличие одинаковой информации об управлении правами, конструктивных недостатков, избыточного проектирования и иных уникальных признаков, бремя доказывания переходит на ответчика. ⚖️

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

5.6. Кейс № 6: AML Software, Inc. против Athena Bitcoin, Inc. (Федеральный окружной суд Южного округа Флориды, США, 2026 год)

Фабула дела. Компания AML разработала проприетарный исходный код для биткойн-банкоматов. Её бывший президент и основной разработчик, как утверждалось, «передал» программное обеспечение через консалтинговое соглашение на 2 миллиона долларов компании PSBC, которая затем за 5,5 миллиона долларов разработала для Athena платформу биткойн-банкоматов. AML утверждала, что сделка по сути была переупаковкой её существующего программного обеспечения под видом новой разработки. 💰

Косвенные доказательства сходства. В данном деле доказательства сходства кода основывались на аномалиях сроков контракта и цикла разработки. Одно соглашение требовало «разработки платформы биткойн-банкоматов всего за девять дней», другое предусматривало поставку программного обеспечения до даты вступления в силу. Суд признал, что эти обстоятельства «разумно свидетельствуют о попытке передачи программного обеспечения AML и связанных с ним прав интеллектуальной собственности». 📅

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

5.7. Кейс № 7: Cincom Systems Inc. против LabWare, Inc. (Апелляционный суд шестого округа США, 2025 год)

Фабула дела. Cincom подала иск к LabWare за нарушение лицензионного соглашения на программное обеспечение и присвоение коммерческой тайны. LabWare приобрела исходный код VSE компании Cincom у Seagull/Rocket, но сама продажа нарушала права Cincom. Cincom утверждала, что LabWare несанкционированно использовала её исходный код. ⚖️

Переплетение экспертизы кода и сроков исковой давности. В центре внимания данного дела была не техническая идентификация сходства кода, а применение правила обнаружения к присвоению коммерческой тайны. Руководитель Cincom Bish видел в интернете множество упоминаний об использовании LabWare её программного обеспечения, читал блог, указывающий на возможную работу его бывшего сотрудника в LabWare над VSE, и знал, что владелец исходного кода Seagull нарушил права Cincom, продав этот код. 🔍

Значение для экспертизы кода. Суд разграничил «последующие подозрения в отношении одного и того же продолжающегося деяния» и «новое самостоятельное деяние по присвоению». Подозрения Cincom в 2014 и 2019 годах касались одного и того же продолжающегося деяния (LabWare с 2006 года непрерывно использовала незаконно полученный исходный код), поэтому срок исковой давности не начал течь заново из-за последующих подозрений. Данный прецедент показывает, что временные рамки экспертизы кода тесно связаны с установлением непрерывности или прерывности нарушения, и выводы экспертизы могут потребовать технической оценки временного периода использования кода. 📅

5.8. Кейс № 8: RELX Inc. против Informatica Corp. (Федеральный окружной суд Южного округа Нью-Йорка, США, 2018 год)

Фабула дела. Дело касалось спора об интеллектуальной собственности в процессе обновления программного обеспечения Informatica до версии 9.6.1. Свидетельские показания в суде revealed, что эксперт истца в некоторых делах имел доступ к исходному коду обеих сторон и мог проводить прямое сравнение исходного кода. 📄

Доказательственный аспект метода экспертизы. Свидетельские показания выявили важную практическую проблему — доступность материалов экспертизы напрямую влияет на выбор метода. Свидетель чётко заявил: «В данном деле, насколько мне известно, RELX никогда не имела доступа к исходному коду Informatica, и я его не изучал», поэтому сравнение на уровне исходного кода было невозможно. Свидетель также разграничил объекты экспертизы в разных делах: в делах Mary Kay и Chapel of Flowers объектом был исходный код, а в данном деле — «только исполняемый код». 💻

Ограничения исполняемого кода как объекта экспертизы. Когда для сравнения доступен только объектный код (исполняемый код), экспертиза обычно полагается на декомпиляцию или анализ поведения, точность и убедительность которых ниже, чем при сравнении на уровне исходного кода. Свидетельские показания показали, что недоступность исходного кода может вынудить экспертизу перейти к сравнению внешнего поведения программного обеспечения (функции, интерфейс, вывод), что создаёт непреодолимые трудности при доказывании копирования на уровне «выражения». ⚠️

5.9. Кейс № 9: InDyne, Inc. против Abacus Technology Corp. (Федеральный суд по искам к США, 2012 год)

Фабула дела. InDyne разработала программное обеспечение PIMS для контракта KICS с NASA. В переходный период сотрудник InDyne, как утверждалось, предоставил «непроприетарный исходный код» компании Abacus, сменившей подрядчика, чтобы «быстро развернуть» веб-сайт. Впоследствии InDyne подала иск против Abacus за нарушение авторских прав. 🚀

Катастрофа управления версиями кода. Ключевая проблема экспертизы — определение объекта прав. InDyne никогда не регистрировала PIMS V.1 и «не сохранила копию PIMS V.1». При регистрации PIMS V.2 в 2008 году единственная доступная версия была продуктом многолетней кастомизации в рамках государственных контрактов, «без чёткой дорожной карты, позволяющей понять, какие части кем оплачены и какие изменения кем внесены». 📂

Основа для выводов экспертизы. В ходе раскрытия доказательств InDyne предоставила файлы кода PIMS V.2, из которых 36% файлов имели дату «последнего изменения» позже заявленной даты публикации, а код содержал более 95 ссылок на «KICS» — контракт, который ещё не начался на заявленную дату публикации (29 августа 2003 года). Эти противоречия во временных метках и содержании не позволили экспертам установить чёткую генеалогию версий кода, что серьёзно подорвало доказательственную силу иска. 📅

5.10. Кейс № 10: Австралийское дело Sony PlayStation (Kabushi Kaisha Sony Entertainment Inc против Stevens, Федеральный суд Австралии, полный состав)

Фабула дела. Дело касалось применения определения «материальная форма» в австралийском Законе об авторском праве к хранению компьютерной программы в оперативной памяти (RAM). Спорный вопрос: когда игровая консоль PlayStation 2 запускает игру, программа загружается в RAM — является ли это «копированием» в смысле авторского права? 🎮

Глубокое методологическое значение. Хотя данное дело не является типичной экспертизой «сходства кода», его технические выводы напрямую касаются того, что составляет «копирование» кода. Судья Sackville J отметил, что хотя из RAM консоли PlayStation 2 можно извлечь объектный код, это невозможно сделать «обычной операцией». Судья Lindgren J в апелляции дополнительно пояснил, что толкование определения «может быть скопирован» настолько широко, чтобы охватывать случаи «если изготовить и подключить дополнительное устройство, не входящее в комплект консоли и ещё не доступное, можно скопировать», является «нереалистичным и натянутым». 🧠

Значение для экспертизы кода. Техническая экспертиза в данном деле касалась криминалистического анализа состояния памяти во время выполнения. Когда правовые требования касаются временного копирования программного обеспечения во время работы (например, загрузки в RAM), экспертиза должна разграничивать «состояние памяти, наблюдаемое при обычной работе» и «состояние памяти, для извлечения которого требуются специальные инструменты». Это разграничение имеет методологическое значение во многих технических спорах, касающихся способов работы программного обеспечения. 🔍

ГЛАВА 6. ОБОБЩЕНИЕ ПРАКТИЧЕСКИХ ВЫВОДОВ

6.1. Спектр методов экспертизы кода

Из анализа десяти приведённых кейсов можно выделить несколько устойчивых закономерностей. 🔬

Практикуемые методы экспертизы кода образуют своего рода непрерывный спектр — от наиболее доказательных к менее доказательным: прямое сравнение исходного кода с исходным кодом (дела Mary Kay и Chapel of Flowers, упомянутые в деле RELX) → сравнение декомпилированного объектного кода (дела Meishe, PQ Systems) → абстрактный анализ псевдокода (дело Admar) → сравнение внешних признаков, не относящихся к коду (метод «командного исследования» в деле против Уханьской компании). Ограниченность доступных материалов экспертизы нередко вынуждает эксперта смещаться к менее доказательному концу этого спектра. 📊

6.2. Ключевое значение управления версиями

Дела InDyne и Cincom с разных сторон показывают, что отсутствие или ненадлежащее управление версиями исходного кода может подорвать саму возможность проведения экспертизы. Когда «временной срез» объекта прав не может быть зафиксирован, сравнение исходного кода лишается надёжной точки отсчёта. 📅

6.3. Бремя доказывания: от «сходства» к «нарушению»

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

6.4. Процессуальный аспект методов экспертизы

Признание в деле Meishe того, что распространение объектного кода составляет публикацию исходного кода, а также правило о переходе бремени доказывания в деле против Уханьской компании, свидетельствуют о том, что экспертиза кода является не только технической, но и процессуальной проблемой. Допустимость и доказательственная сила её результатов в значительной степени определяются рамками процессуального закона. 📜

I. ВОПРОСЫ О ПРИНАДЛЕЖНОСТИ ПРАВ И ОРИГИНАЛЬНОСТИ КОДА

Обладает ли представленный исходный код признаками творческого характера, позволяющими признать его объектом авторского права (оригинальность алгоритмических решений, структур данных, архитектуры)? 🧠
Имеются ли в представленном исходном коде уникальные элементы, свидетельствующие об авторстве (специфические ошибки, служебные комментарии, тестовые данные, стиль именования переменных и методов)? 🔍
Является ли представленный код результатом самостоятельной творческой деятельности или он воспроизводит (полностью либо в существенной части) иной программный продукт? ✅
Имеются ли в представленном исходном коде признаки, характерные для определённой среды разработки, стиля программирования или конкретного автора? 🧩

II. ВОПРОСЫ О СХОДСТВЕ И ЗАИМСТВОВАНИИ КОДА

Является ли исходный код одной программы переработкой или воспроизведением кода другой программы? 📋
Имеются ли в представленных программах совпадения программного кода, и каков характер этих совпадений? 📊
Свидетельствуют ли обнаруженные совпадения о заимствовании логики работы программы? 🧠
Является ли программа ответчика переработкой (заимствованием) программы истца? Для проведения экспертизы должны быть представлены исходные коды обеих программ. ⚖️
Имеются ли в сравниваемых программах идентичные или сходные до степени смешения фрагменты исходного кода? Если да, каковы их качественные и количественные характеристики? 📊
Могут ли обнаруженные совпадения быть обусловлены независимым созданием, использованием открытого исходного кода, стандартных библиотек или реализацией общеизвестных алгоритмов? 🔄
Какова доля совпадений исходного кода программ в процентном соотношении? Обусловлена ли такая доля исключительно функциональным назначением сравниваемых программ? 📈
Имеются ли в сравниваемых программах совпадения на уровне архитектуры, структуры модулей, последовательности функций, именования переменных и классов? 🏗️
Свидетельствуют ли выявленные совпадения о переносе кода с одного языка программирования на другой (кросс-языковое заимствование)? 🔄

III. ВОПРОСЫ О СООТВЕТСТВИИ ПРОГРАММЫ УСЛОВИЯМ ДОГОВОРА

Работоспособна ли программа в соответствии с условиями заключённого договора? ✅
Обладает ли программа потребительской ценностью? 💰
Какова степень завершённости программы? Имеются ли недостатки и ошибки, препятствующие нормальной работе и использованию продукта потребителем? ⚠️
Соответствует ли программа обычно применяемым требованиям к программным продуктам данного класса? 📋
Соответствует ли предоставленный исходный код условиям технического задания (функциональным, техническим, эксплуатационным требованиям)? 📊
Реализованы ли в представленном коде все функциональные требования, предусмотренные техническим заданием? Если нет, какие именно требования не реализованы? 🔍
Если экспертиза установит неработоспособность программы, обусловлена ли такая неработоспособность отсутствием обновлений программы или вмешательством третьих лиц в программное обеспечение? 🔄
Имеются ли в программе критические дефекты, препятствующие её использованию по назначению? Каковы причины этих дефектов? ⚠️

IV. ВОПРОСЫ ОБ ОТДЕЛЬНЫХ ФУНКЦИОНАЛЬНЫХ МОДУЛЯХ

Использовался ли исходный код программы истца в программном модуле, предназначенном для подключения к криптовалютным биржам? 📊
Содержит ли конкретный модуль программы (с указанием наименования и версии) фрагменты исходного кода, заимствованные из другой программы? 🔍
Является ли конкретный функциональный блок программы результатом самостоятельной разработки или он воспроизводит логику иного программного продукта? 🧠

V. ВОПРОСЫ О СБОЯХ В РАБОТЕ ПРОГРАММЫ И ТЕХНИЧЕСКОМ ВМЕШАТЕЛЬСТВЕ

Обусловлен ли сбой в работе программы техническими недостатками самой программы или вмешательством третьих лиц в программное обеспечение? 🔄
Является ли сбой в работе программы воспроизводимым? Если да, каков его технический механизм? 🧪
Имеются ли в программе следы несанкционированного вмешательства (изменения кода, подмена модулей, внедрение сторонних библиотек)? 🔍
Соответствуют ли файлы журналов и трассировок работы программы данным, представленным сторонами? 📋

VI. ВОПРОСЫ ОБ ИСПОЛЬЗОВАНИИ ОТКРЫТОГО КОДА И СТОРОННИХ БИБЛИОТЕК

Данная категория вопросов приобретает всё большую актуальность в связи с широким распространением открытого программного обеспечения. 📚

Содержит ли представленный исходный код фрагменты, заимствованные из открытых источников (GitHub, GitLab и иные репозитории)? 🔍
Соблюдены ли условия лицензий на открытое программное обеспечение, фрагменты которого использованы в представленном коде? 📜
Являются ли выявленные совпадения следствием использования стандартных библиотек и общеизвестных алгоритмов, не охраняемых авторским правом? ✅
Имеются ли в представленном коде фрагменты, тождественные коду сторонних библиотек, и если да, каков объём и функциональное назначение этих фрагментов? 📊

VII. ВОПРОСЫ О ВРЕМЕНИ СОЗДАНИЯ КОДА И ПОСЛЕДОВАТЕЛЬНОСТИ РАЗРАБОТКИ

Данная категория вопросов имеет значение при определении момента возникновения прав и при проверке версий разработки. 📅

Соответствуют ли временные метки файлов исходного кода заявленным срокам разработки? 📆
Имеются ли в представленных файлах признаки, указывающие на более позднее внесение изменений по сравнению с заявленной датой создания? 🔍
Возможно ли установить последовательность создания фрагментов кода на основании анализа истории изменений (при наличии репозитория системы контроля версий)? 📊
Являются ли представленные версии программы последовательными этапами разработки одного продукта или они относятся к различным программным продуктам? 🔄

VIII. ВОПРОСЫ О СООТВЕТСТВИИ ПРОГРАММЫ ТРЕБОВАНИЯМ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Данная категория вопросов возникает в делах, связанных с защитой информации, а также с оценкой качества программных продуктов. 🛡️

Содержит ли программа уязвимости, позволяющие получить несанкционированный доступ к данным или функциям программы? ⚠️
Соответствует ли программа требованиям информационной безопасности, предъявляемым к программным продуктам данного класса? ✅
Имеются ли в программе механизмы защиты от несанкционированного копирования, и были ли они обойдены? 🔒

IX. ВОПРОСЫ ОБ ОБХОДЕ ТЕХНИЧЕСКИХ МЕР ЗАЩИТЫ

Данная категория вопросов характерна для дел о неправомерном доступе к компьютерной информации и о нарушении исключительных прав. ⚖️

Использует ли программа ответчика технические средства обхода защиты программы истца? 🔍
Имеются ли в программе ответчика признаки модификации или эмуляции защитных механизмов программы истца? 🔄
Позволяет ли программа ответчика осуществлять доступ к функциональности программы истца без санкции правообладателя? ⚠️

X. МЕТОДОЛОГИЧЕСКИЕ ТРЕБОВАНИЯ К ФОРМУЛИРОВАНИЮ ВОПРОСОВ

Пятое. Недопустимость выхода за пределы компетенции эксперта. Вопросы не должны требовать юридической оценки (например, «является ли заимствование нарушением авторских прав»). Эксперт устанавливает технические факты, а правовая квалификация относится к компетенции суда. 🚫

XI. ТИПИЧНЫЕ ОШИБКИ ПРИ ФОРМУЛИРОВАНИИ ВОПРОСОВ

Выход за пределы компетенции эксперта. Некорректный вопрос: «Является ли заимствование кода нарушением авторских прав?» Как исправить: «Имеются ли в представленных программах совпадения программного кода, и каков характер этих совпадений?» ⚖️

Неконкретность формулировок. Некорректный вопрос: «Правильно ли написана программа?» Как исправить: «Соответствует ли предоставленный исходный код условиям технического задания?» ❓

Выход за пределы материалов дела. Некорректный вопрос: «Какова рыночная стоимость аналогичных программ?» Как исправить: «Является ли исходный код одной программы переработкой или воспроизведением кода другой программы?» 📁

Постановка избыточных вопросов. Некорректный вопрос: «Какова численность сотрудников разработчика?» Как исправить: «Является ли представленный код результатом самостоятельной творческой деятельности?» 🚫

Постановка взаимоисключающих вопросов. Некорректный вопрос: «Правильно ли написана программа? Если нет, то какова сумма ущерба?» Как исправить: «Соответствует ли программа условиям технического задания? Имеются ли в программе критические дефекты?» 🔄

XII. ПРАКТИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ФОРМУЛИРОВАНИЮ ВОПРОСОВ

Для судей:

формулировать вопросы в пределах компетенции эксперта-программиста; 🎓
избегать вопросов, требующих юридической оценки; ⚖️
формулировать вопросы конкретно и однозначно; ❓
группировать вопросы по видам исследования (оригинальность, сходство, соответствие ТЗ); 📊
указывать конкретные версии программ и модулей, подлежащих исследованию; 📌
указывать конкретные документы, которые должны быть исследованы. 📋

Для адвокатов и представителей:

готовить вопросы заранее, на основе анализа материалов дела; 📚
формулировать вопросы таким образом, чтобы они были понятны эксперту; 🧠
избегать вопросов, ответы на которые не имеют значения для дела; 🚫
предлагать вопросы, которые позволяют установить все обстоятельства дела; 🔍
учитывать, что эксперт не вправе давать юридическую оценку. ⚖️

Для заказчиков:

формулировать вопросы на основе договора и технического задания; 📄
указывать конкретные функциональные требования, по которым имеются сомнения; 💰
не формулировать вопросы, требующие юридической оценки; ⚖️
обращаться за помощью к квалифицированному адвокату. 👨‍⚖️

Для подрядчиков:

формулировать вопросы, направленные на подтверждение самостоятельности разработки; 📊
предоставлять полный пакет документов для исследования (репозитории, историю изменений); 📁
не формулировать вопросы, выходящие за пределы компетенции эксперта; 🚫
учитывать, что эксперт не вправе давать юридическую оценку; ⚖️
обращаться за помощью к квалифицированному адвокату. 👨‍⚖️

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

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

ИСТОЧНИКИ

Федеральный закон от 31.05.2001 № 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации». 📜
Гражданский кодекс РФ, часть четвёртая (ст. 1259, 1260, 1270, 1280). ⚖️
Арбитражный процессуальный кодекс РФ (ст. 82–87). 📋
Гражданский процессуальный кодекс РФ (ст. 79–87). 📋
Уголовно-процессуальный кодекс РФ (ст. 195–207). 📋
Кодекс административного судопроизводства РФ (ст. 77–79). 📋
Постановление Пленума Верховного Суда РФ от 23.04.2019 № 10. ⚖️
ГОСТ Р 71489-2024 «Судебная компьютерно-техническая экспертиза. Термины и определения». 📊
ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания». 📚
ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению». 📚
Методические материалы ЭКЦ МВД России. 📋
Постановление Девятого арбитражного апелляционного суда от 28.03.2024 № 09АП-91383/23 по делу № А40-224872/2022. ⚖️
Постановление от 01.12.2023 по делу № А40-90889/2021. ⚖️
АНО «Судебный Эксперт». Экспертиза № 165315. 2025. 📄
Высшая школа судебных экспертиз. Экспертиза программного обеспечения: исследование кода и работы информационных систем. 2026. 📚
Федерация судебных экспертов. Судебная экспертиза компьютерных программ в юрисдикции Москвы и Московской области. 2026. 📊

Экспертиза кодов: когда нужна, как проводится, сколько стоит. Минимальные цены начинаются от 20 000 рублей за досудебную проверку исходного кода. Судебная экспертиза — от 40 000 рублей. Комплексная экспертиза (код, работоспособность, соответствие техническому заданию) — от 80 000 рублей. Срок проведения — от 3 до 30 рабочих дней.

Полезная информация?

Задать вопрос экспертам

Title*