Доказывание по спорам о правах на программное обеспечение в Казахстане (Оралбаев Д., управляющий партнер ТОО «SOLIS Partners», магистр права)

03.08.2026

Доказывание по спорам о правах на программное обеспечение в Казахстане

Предмет доказывания, цифровые следы и пределы судебной экспертизы

Чингис Оралбаев,

управляющий партнер ТОО «SOLIS Partners»,

магистр права

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

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

Сначала нужно определить спорный объект.

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

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

Поэтому до оценки авторства и прав необходимо установить:

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

2. какая версия объекта заявлена как охраняемая;

3. совпадает ли она с версией, которую использует ответчик;

4. какие элементы созданы сторонами, а какие относятся к общедоступным библиотекам, стандартным решениям или автоматически сформированному коду;

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

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

Авторство и исключительное право — разные обстоятельства

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

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

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

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

Что доказывает служебный характер программы

По статье 14 Закона служебным признается произведение, созданное в порядке выполнения служебных обязанностей или служебного задания работодателя. Если договором не предусмотрено иное, исключительные имущественные права на такое произведение принадлежат работодателю. Аналогичный подход закреплен статьей 963 Гражданского кодекса Республики Казахстан.

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

Для подтверждения такой связи могут использоваться:

1. трудовой договор, должностная инструкция, приказы о переводе и документы, уточняющие трудовую функцию;

2. задания в корпоративной системе, планы подразделения, технические требования и деловая переписка;

3. документы о проверке, приемке и выпуске версий;

4. сведения о выплате заработной платы или иного вознаграждения;

5. данные об использовании оборудования, серверов, баз данных и учетных записей работодателя;

6. доказательства включения результата в коммерческий продукт компании.

Ни рабочее время, ни корпоративное оборудование, ни заработная плата не являются самостоятельным и безусловным основанием права. Их значение проявляется только в связи с содержанием трудовой функции и задания. Нормативное постановление Верховного Суда Республики Казахстан от 25 декабря 2007 года № 11 также ориентирует суды на выяснение того, создано ли произведение в порядке выполнения служебных обязанностей или служебного задания.

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

Как оценивать запись в государственном реестре.

Согласно статье 9 Закона авторское право возникает в силу факта создания произведения; регистрация или соблюдение иных формальностей для возникновения и осуществления права не требуются. Статья 9-1 предусматривает внесение сведений в Государственный реестр прав на объекты, охраняемые авторским правом.

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

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

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

Цифровые следы: относимость важнее объема.

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

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

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

1. объект и версия — исходный код, архив версии, описание выпуска;

2. авторство — история изменений, задания, переписка и творческий вклад;

3. служебный характер — трудовая функция, поручение и приемка;

4. принадлежность прав — закон, трудовой или авторский договор, акт передачи;

5. использование ответчиком — журналы работы системы, договоры, публикации и доступ пользователей;

6. размер требования — сопоставимые лицензионные условия или доказанные последствия нарушения.

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

Пределы нотариальной фиксации цифровых материалов.

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

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

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

Что может и чего не может установить эксперт.

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

Корректные вопросы эксперту могут касаться:

1. наличия совпадающих фрагментов и их значения для программы;

2. последовательности появления изменений;

3. использования одной версии как основы для другой;

4. наличия стандартных, сторонних или автоматически созданных элементов;

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

6. соответствия представленных файлов описанию зарегистрированного объекта.

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

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

Доказывание нарушения и размера компенсации.

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

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

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

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

Процессуальная модель такого спора.

Юридически устойчивую позицию удобно строить в следующей последовательности:

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

2. Установить физических авторов и содержание их творческого вклада.

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

4. Сопоставить запись в реестре с фактическими материалами разработки.

5. Обеспечить происхождение и целостность цифровых доказательств.

6. Поставить эксперту только технические вопросы.

7. Доказать конкретный способ использования и обосновать выбранный способ защиты.

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

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