Аннотация

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объектами экспертизы программного кода могут выступать различные материальные и нематериальные носители информации о программе. К числу наиболее распространенных объектов относятся:

• исходные тексты программы на языках программирования (C, C++, Java, Python, PHP, JavaScript, C# и другие), представленные на электронных носителях или в распечатанном виде;

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

• алгоритмы и блок-схемы, описывающие логику работы программы;

• проектная и техническая документация: технические задания, спецификации, руководства пользователя, описания архитектуры;

• файлы проектов, содержащие метаданные о разработке (история изменений, сведения об авторах, комментарии);

• данные, генерируемые программой в процессе работы: журналы, дампы памяти, снимки состояния;

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

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

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

• имело ли место воспроизводство компьютерной программы одного правообладателя в компьютерной программе другого лица;

• является ли представленная программа полным или частичным воспроизведением другой программы;

• чем обусловлена оригинальность данной программы, какие элементы являются уникальными, а какие — заимствованными или стандартными;

• являются ли исходные тексты представленной программы переработкой исходного кода другой программы;

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

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

• соответствует ли созданная программа требованиям технического задания;

• какие функции, предусмотренные техническим заданием, реализованы не полностью или реализованы с отклонениями;

• какова причина сбоя или неработоспособности программы;

• содержит ли программа недокументированные возможности (так называемые «закладки»), не предусмотренные договором.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первым индикатором авторства является стиль программирования. Подобно тому, как литературный стиль писателя позволяет идентифицировать автора даже при отсутствии подписи, стиль программиста проявляется в ряде характеристик: способах именования переменных и функций (camelCase, snake_case, венгерская нотация), структуре отступов,习惯 использования комментариев, предпочтении определенных конструкций языка, способах обработки ошибок. Опытный эксперт, проанализировав достаточно большой фрагмент кода, может составить представление о стиле его автора и сравнить его со стилем других программ.

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

Третьим индикатором является история разработки, зафиксированная в метаданных файлов, системах контроля версий, журналах изменений. Если программа разрабатывалась с использованием системы контроля версий (Git, SVN и другие), история коммитов может содержать ценную информацию: кто и когда вносил изменения, какие файлы редактировались, какие комментарии сопровождали изменения. Эта информация может быть использована для подтверждения или опровержения доводов о самостоятельном характере разработки.

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

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

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

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

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

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

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

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

• реализованы ли в программе все функции, предусмотренные техническим заданием;

• соответствует ли поведение программы описанию, содержащемуся в документации;

• имеются ли в программе ошибки, приводящие к сбоям или некорректной работе, и какова их причина;

• является ли выявленный дефект производственным (связанным с ошибкой разработчика) или эксплуатационным (связанным с неправильными действиями пользователя);

• соответствует ли программа заявленным системным требованиям (совместимость с операционными системами, аппаратными конфигурациями);

• содержит ли программа недокументированные возможности, не предусмотренные техническим заданием.

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

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

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

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

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

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

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

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

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

Важным процессуальным требованием является предупреждение эксперта об уголовной ответственности за дачу заведомо ложного заключения. Эксперт дает подписку о том, что он предупрежден об ответственности, предусмотренной статьей 307 Уголовного кодекса Российской Федерации. Это требование распространяется на всех экспертов, как государственных, так и негосударственных. Нарушение этого требования может повлечь признание заключения недопустимым доказательством.

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

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

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

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

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

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

Раздел 7. Экспертиза программного кода в делах о нарушении авторских прав: практические аспекты

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

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

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

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

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

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

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

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

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

Раздел 8. Экспертиза недокументированных возможностей и вредоносного кода

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

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

• содержит ли программа функции, не описанные в документации;

• какова функциональность этих функций, какие действия они выполняют;

• осуществляется ли передача информации третьим лицам без ведома пользователя;

• имеются ли в программе механизмы удаленного управления или обновления, не предусмотренные договором;

• содержит ли программа код, который может быть квалифицирован как вредоносный (вирус, троян, шпионское ПО);

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

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

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

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

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

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

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

Раздел 9. Экспертиза причин сбоев и инцидентов в работе программного обеспечения

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

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

• какова непосредственная причина сбоя программы;

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

• мог ли разработчик предотвратить сбой при должном уровне качества разработки;

• соответствует ли поведение программы при сбое требованиям надежности и безопасности;

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

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

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

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

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

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

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

Раздел 10. Практические кейсы экспертизы программного кода

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

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

В арбитражный суд обратилась компания «Альфа» с иском к компании «Бета» о нарушении исключительных прав на программу для ЭВМ — систему управления базами данных, разработанную «Альфой» для внутренних нужд и впоследствии коммерциализированную. Истец утверждал, что ответчик, бывший партнер «Альфы», получил доступ к исходному коду и использовал его при создании собственного продукта, который впоследствии был выведен на рынок под другим названием. В подтверждение своих доводов истец представил заключение специалиста, согласно которому сходство между программами составляет 85%. Ответчик возражал, утверждая, что его продукт является самостоятельной разработкой, а совпадения объясняются использованием общих алгоритмов и стандартных библиотек.

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

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

На следующем этапе эксперт применил метод сравнения на основе отпечатков (хеш-функций) для функций и методов. Было выявлено, что 47% функций имеют полностью идентичные отпечатки, еще 22% функций имеют частичные совпадения. Однако при более детальном анализе выяснилось, что значительная часть совпадающих функций относится к работе с базами данных через стандартный JDBC-драйвер и к обработке JSON, то есть к типовым задачам, решение которых неизбежно приводит к схожему коду.

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

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

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

Кейс 2. Спор о качестве программного обеспечения для медицинского учреждения

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

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

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

Для проверки гипотезы о причинах сбоев эксперт развернул систему в тестовой среде, имитирующей конфигурацию заказчика, и провел нагрузочное тестирование. При 50 одновременных пользователях время отклика превышало 5 секунд, при 100 пользователях система становилась неработоспособной. Анализ журналов показал, что при формировании отчетов возникали ошибки из-за нехватки памяти (OutOfMemoryError), вызванные загрузкой всех записей в память без постраничной обработки. Также были выявлены ошибки в логике расчета некоторых показателей, приводившие к некорректным результатам.

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

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

Кейс 3. Дело о недокументированной функции сбора данных в мобильном приложении

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

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

Эксперт получил дистрибутив приложения (APK-файл для Android) и провел его декомпиляцию с использованием инструментов apktool и jadx. Анализ манифеста приложения выявил наличие разрешений на доступ к контактам, геолокации (включая фоновый режим), календарю, микрофону. При этом в пользовательском соглашении упоминались только геолокация (без указания на фоновый режим) и контакты (для функции «найти друзей»). Разрешения на доступ к календарю и микрофону не были описаны.

Динамический анализ проводился на изолированном устройстве с перехватом сетевого трафика. Эксперт запустил приложение, предоставил запрашиваемые разрешения и наблюдал за его активностью. Было установлено, что приложение периодически (каждые 30 минут) отправляет на сервер разработчика следующие данные: список контактов (включая имена, телефоны, email), координаты геолокации (даже когда приложение не используется активно), содержимое буфера обмена (при копировании пользователем любых данных), а также информацию о запущенных приложениях. Передача осуществлялась на IP-адреса, не указанные в политике конфиденциальности и принадлежащие третьим лицам (не разработчику).

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

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

Кейс 4. Дело о сбое в системе управления производственным оборудованием

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

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

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

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

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

Кейс 5. Спор о самостоятельности разработки программного обеспечения для веб-хостинга

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

Эксперт получил исходные коды обеих панелей (на PHP и JavaScript). Первичный анализ показал, что обе панели используют фреймворк Laravel и библиотеку jQuery, что объясняло значительную часть совпадений. Однако при более глубоком анализе были выявлены совпадения в файлах, не относящихся к фреймворкам: в модулях аутентификации, управления доменами, биллинга.

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

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

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

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

Кейс 6. Дело о сбое в банковской системе обработки платежей

Кредитная организация столкнулась с инцидентом: в течение нескольких часов система обработки платежей обрабатывала транзакции с задержкой, а часть транзакций была отклонена без объяснения причин. Банк понес репутационные и финансовые потери. Разработчик системы утверждал, что причиной стал резкий рост нагрузки, вызванный действиями злоумышленников (DDoS-атака), и что система работала в пределах проектных параметров.

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

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

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

Кейс 7. Спор о переработке программы для ЭВМ при смене языка программирования

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

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

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

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

Кейс 8. Дело о сбое в системе онлайн-бронирования в результате ошибки обновления

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

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

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

Кейс 9. Дело о заимствовании алгоритма сжатия данных

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

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

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

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

Кейс 10. Спор о соответствии программного обеспечения требованиям информационной безопасности

Банк приобрел программное обеспечение для управления взаимоотношениями с клиентами (CRM) и впоследствии подвергся аудиту информационной безопасности, в ходе которого были выявлены уязвимости: возможность SQL-инъекций в формах ввода, отсутствие шифрования персональных данных при передаче, слабое хеширование паролей. Банк потребовал от разработчика устранения недостатков за свой счет, ссылаясь на то, что договор предусматривал соответствие требованиям безопасности. Разработчик возражал, утверждая, что требования не были конкретизированы.

Эксперт проанализировал договор и техническое задание. В договоре содержалось общее требование «соответствия общепринятым стандартам информационной безопасности», без указания конкретных стандартов (например, OWASP Top 10, ГОСТ Р ИСО/МЭК 27001). Техническое задание также не содержало детальных требований к защите.

Эксперт провел тестирование на проникновение (penetration testing) и подтвердил наличие уязвимостей. Было установлено, что SQL-инъекции возможны в нескольких формах, включая форму поиска клиентов и форму добавления комментариев. Пароли хранились в базе данных в виде MD5-хешей без соли, что не соответствует современным представлениям о безопасности (MD5 считается криптографически слабым и не рекомендуется для хранения паролей). Передача данных между клиентом и сервером осуществлялась по HTTP, без шифрования.

Эксперт пришел к выводу, что выявленные уязвимости являются существенными и свидетельствуют о низком качестве разработки с точки зрения безопасности. Хотя техническое задание не содержало детальных требований, «общепринятые стандарты» в области веб-разработки на момент создания программы уже включали защиту от SQL-инъекций и использование надежных алгоритмов хеширования. Разработчик, обладая необходимой квалификацией, должен был реализовать эти меры без дополнительных указаний. Суд обязал разработчика устранить уязвимости за свой счет. Стоимость экспертизы составила 140 000 рублей, срок — 30 рабочих дней.

Заключение

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

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

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

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