Раздел 1. Правовая природа и место экспертизы исходного кода в системе судебных экспертиз

Экспертиза исходного кода представляет собой специализированный вид исследования, находящийся на пересечении компьютерно-технической экспертизы и экспертизы объектов интеллектуальной собственности. В условиях стремительной цифровизации экономики и роста числа споров, связанных с программным обеспечением, значение данного вида экспертной деятельности возрастает многократно. Союз «Федерация судебных экспертов» располагает необходимым научно-методическим и кадровым потенциалом для производства таких исследований на высоком профессиональном уровне .

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

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

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

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

Раздел 2. Объекты и предмет экспертного исследования исходного кода

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

2.1. Классификация объектов исследования

Исходный код программы для ЭВМ может поступать на исследование в различных формах. Федерация судебных экспертов выделяет следующие основные категории:
• Текстовые файлы исходного кода в оригинальных форматах (расширения, соответствующие языку программирования: .c, .cpp, .cs, .java, .py, .js и другие).
• Архивы репозиториев систем контроля версий, содержащие полную историю изменений (коммиты, ветвления, теги).
• Проектные файлы и файлы конфигурации сборки, позволяющие воспроизвести среду компиляции.
• Документация разработчика, включая комментарии в коде, README-файлы и технические задания.
• Исполняемые файлы и промежуточные артефакты (байт-код, объектные файлы), используемые для верификации соответствия исходного текста и работающей программы .

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

2.2. Предмет исследования

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

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

Раздел 3. Методологические основы исследования исходного кода

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

3.1. Метод сравнения кодовых баз

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

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

3.2. Метод контрольной сборки

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

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

3.3. Динамический и статический анализ

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

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

Раздел 4. Установление признаков заимствования и самостоятельного творческого вклада

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

4.1. Проблема разграничения охраняемых и неохраняемых элементов

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

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

4.2. Критерии существенного сходства

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

Экспертиза исходного кода не может ограничиваться констатацией процента совпадения. Числовые метрики (например, «92% сходства») без качественного анализа способны ввести суд в заблуждение, поскольку не отражают, какие именно элементы совпали и являются ли они охраноспособными.

4.3. Установление авторства и соавторства

В спорах об авторстве экспертиза исходного кода решает задачи установления того, кто и в каком объёме создал конкретные фрагменты кода. Инструментами служат:
• Анализ истории системы контроля версий (git log), позволяющий проследить последовательность внесения изменений и их авторов.
• Сопоставление метаданных файлов (даты создания, атрибуты) с данными репозитория.
• Стилометрический анализ, выявляющий устойчивые индивидуальные особенности кодирования.
• Лингвистический анализ комментариев и идентификаторов на предмет соответствия языковым привычкам предполагаемого автора .

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

Раздел 5. Исследование качества и соответствия исходного кода требованиям

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

5.1. Соответствие функциональным требованиям

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

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

5.2. Выявление дефектов и уязвимостей

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

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

5.3. Наличие недокументированных возможностей

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

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

Раздел 6. Процессуальные аспекты назначения и производства экспертизы исходного кода

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

6.1. Судебная экспертиза

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

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

6.2. Внесудебное исследование

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

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

Раздел 7. Инструментальное обеспечение экспертизы исходного кода

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

7.1. Средства сравнения кода

Для выявления признаков заимствования применяются как специализированные коммерческие решения, так и открытые инструменты. К числу используемых средств относятся:
• MOSS (Measure Of Software Similarity) — система обнаружения сходства, разработанная для академических целей и широко применяемая в экспертной практике.
• JPlag — инструмент сравнения кода, поддерживающий множество языков программирования.
• BinDiff и Diaphora — средства сравнения бинарных файлов, полезные при отсутствии исходных текстов.
• Платформы статического анализа (SonarQube, Coverity), адаптированные для задач экспертного исследования.

Выбор конкретного инструмента фиксируется в заключении с указанием версии и настроек, поскольку результаты сравнения могут зависеть от параметров нормализации (учёт регистра, игнорирование комментариев и пробелов).

7.2. Среды сборки и виртуализации

Контрольная сборка требует воспроизведения оригинальной среды разработки. Экспертиза исходного кода предполагает использование:
• Виртуальных машин и контейнеров для изоляции исследуемого кода.
• Менеджеров версий компиляторов и зависимостей.
• Систем фиксации состояния среды (снимки, хеш-суммы компонентов).

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

7.3. Средства анализа метаданных и репозиториев

При работе с системами контроля версий используются:
• Штатные средства git (log, blame, diff) для восстановления хронологии.
• Скрипты анализа метаданных коммитов (автор, дата, хеш).
• Инструменты визуализации истории изменений.

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

Раздел 8. Кейсы из экспертной практики

Кейс 1. Спор о заимствовании в системе управления складом

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

На исследование были представлены исходные тексты обеих программ, архивы репозиториев и исполняемые файлы. Объём кодовых баз составлял 87 000 и 91 000 строк соответственно. Экспертиза исходного кода началась с построения деревьев абстрактного синтаксиса и их сопоставления. Предварительный лексический анализ показал низкий процент прямых текстуальных совпадений, что могло объясняться переименованием идентификаторов.

На следующем этапе был применён анализ графов потока управления для ключевых модулей. Результаты оказались показательными: 92% функций модуля комплектации заказов имели идентичную топологию графов, включая порядок ветвлений и циклов. Дальнейшее исследование выявило в одной из функций уникальную константу 0x4C4F4749 (ASCII-последовательность «LOGI»), не несущую функциональной нагрузки. Эта же константа присутствовала в коде истца и отсутствовала в открытых библиотеках.

Стилометрический анализ подтвердил совпадение индивидуальных особенностей кодирования: характер отступов, способ именования локальных переменных (использование префикса «tmp_» для временных значений), типичные опечатки в строковых литералах сообщений об ошибках. Экспертиза исходного кода завершилась выводом о том, что программа ответчика является переработанной копией системы истца с переименованием идентификаторов и изменением структуры файлов, но без изменения алгоритмической сущности. Суд взыскал компенсацию в размере 43 миллионов рублей.

Кейс 2. Установление авторства в споре о служебном произведении

Гражданин К. обратился в суд с требованием признать его автором программного обеспечения, созданного, по его утверждению, в период работы в организации «ТехноСистемс». Организация настаивала на том, что код создан коллективом сотрудников, а вклад К. ограничивался администрированием репозитория.

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

Анализ истории git показал, что первые коммиты в корпоративном репозитории датированы мартом 2021 года. Однако метаданные файлов на ноутбуке К. содержали даты создания, предшествующие этой дате на четыре месяца. Был проведён сравнительный анализ содержимого: фрагменты, датированные на ноутбуке более ранним периодом, совпадали с более поздними коммитами в корпоративном репозитории с точностью до идентификаторов и комментариев. Это указывало на то, что код существовал до его формального внесения в организационный репозиторий.

Стилометрический анализ 34 файлов исходного кода выявил устойчивые индивидуальные маркеры, совпадающие с образцами, предоставленными К. (его личные проекты на GitHub). Характерной особенностью было использование цикла for с предусловием в стиле, не typical для остальных участников проекта, а также специфический способ обработки исключений с логированием в самодельную функцию _log_it.

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

Кейс 3. Спор о соответствии техническому заданию

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

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

Исследование началось с формального сопоставления пунктов технического задания с модулями кода. Экспертом был составлен перечень функций, подлежащих проверке. Для каждой функции производился поиск реализации по ключевым идентификаторам и последующий анализ логики. Было установлено, что функции экспорта отчётов в формате, предусмотренном пунктом 4.2 ТЗ, в коде отсутствовали. Попытка обнаружения соответствующих библиотек или вызовов не дала результатов.

Далее был проведён статический анализ на предмет уязвимостей. В модуле аутентификации обнаружено хранение паролей в открытом виде в базе данных (функция save_user с прямой вставкой пароля в SQL-запрос без хеширования). Кроме того, выявлена возможность SQL-инъекции в обработчике формы поиска по причине конкатенации пользовательского ввода с текстом запроса.

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

Кейс 4. Исследование недокументированных возможностей

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

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

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

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

Кейс 5. Сравнение мобильного приложения и серверной части

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

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

Серверная часть истца была реализована на Python, ответчика — на Node.js. Прямое текстуальное сравнение было невозможно из-за различия языков. Эксперт применил метод сравнения алгоритмических структур: были построены блок-схемы ключевых функций обработки заказа в обеих реализациях. Анализ выявил совпадение последовательности операций в 47 из 52 проверенных сценариев, включая нестандартную последовательность проверок скидок и округления, не имеющую очевидного обоснования.

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

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

Кейс 6. Определение хронологии создания кода

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

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

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

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

Кейс 7. Экспертиза кода после смены разработчика

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

Экспертиза исходного кода была назначена по требованию исполнителя А, утверждавшего, что его код используется без разрешения. Исследованию подлежали архивы, переданные А, и финальная версия продукта, созданная Б.

Сравнение показало, что архитектура приложения в финальной версии сохранила структуру, заложенную А: те же имена модулей, та же схема базы данных, та же последовательность вызовов API. Однако реализация методов была переписана. Эксперт квалифицировал это как переработку: сохранилась творческая основа (архитектурные решения), но конкретное выражение было изменено.

Экспертиза исходного кода разграничила элементы, созданные А (архитектура, схема данных, интерфейсы), и элементы, добавленные Б (реализация методов, оптимизации, новый функционал). Вывод эксперта позволил суду определить объём правомерного использования и размер компенсации.

Кейс 8. Исследование кода встроенной системы

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

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

Эксперт проанализировал алгоритмы управления приводами, реализованные в обеих системах. Были выявлены совпадения в структуре ПИД-регулятора с нестандартной последовательностью обновления коэффициентов, а также в обработке аварийных ситуаций: обе системы использовали одинаковую, не описанную в отраслевых стандартах, последовательность отключения питания при перегреве. Экспертиза исходного кода с применением методов дизассемблирования и структурного сравнения позволила установить признаки заимствования. Суд принял заключение в качестве доказательства.

Кейс 9. Оценка качества кода при приемке

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

Экспертиза исходного кода была назначена для оценки соответствия общепринятым стандартам качества. В отсутствие явных договорных критериев эксперт руководствовался положениями ГОСТ и отраслевыми методиками.

Анализ выявил: средняя цикломатическая сложность функций превышала 25 (при рекомендуемом пороге 10), 34% функций не имели комментариев, дублирование кода составляло 18%. В коде присутствовали «магические числа» без пояснений и функции длиной более 500 строк. Экспертиза исходного кода concluded, что качество сопровождения кода существенно ниже отраслевых стандартов, что делает его поддержку силами заказчика затруднительной без дополнительной документации. Суд признал отказ заказчика от приёмки частично обоснованным.

Кейс 10. Рецензирование заключения другой экспертной организации

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

Рецензирование включало проверку методической корректности и полноты исследования. Экспертиза исходного кода, подвергнутая рецензии, ограничилась подсчётом процента совпадений с использованием одного инструмента (MOSS) без качественного анализа совпавших фрагментов. Рецензент установил, что вывод о плагиате был сделан на основании 41% совпадения, при этом не было проверено, относятся ли совпавшие фрагменты к стандартным библиотекам или сгенерированному коду. Кроме того, в заключении отсутствовало описание процедуры нормализации (учёт комментариев, пробелов, переименований), что делает результат невоспроизводимым.

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

Раздел 9. Организационные аспекты взаимодействия с экспертной организацией

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

9.1. Подготовка материалов

При обращении в Союз «Федерация судебных экспертов» для производства экспертизы исходного кода заказчику рекомендуется подготовить:
• Полные архивы репозиториев с сохранением истории изменений (не только снимок последней версии).
• Файлы конфигурации сборки и инструкции по развёртыванию, если они сохранились.
• Техническое задание и договорную документацию, если спор касается соответствия.
• Исполняемые файлы, соответствующие исследуемому исходному коду, для проведения контрольной сборки.
• Документацию разработчика: проектные решения, спецификации, переписку по ключевым техническим вопросам.

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

9.2. Сроки и стоимость

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

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

Раздел 10. Заключительные положения

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

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

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

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