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

По российскому праву автором программы для ЭВМ признаётся тот, кто внёс в неё личный творческий вклад (ст. 1228 ГК РФ). Звучит просто, но на практике — это десятки судебных споров о том, что считать творческим вкладом, а что нет.

Разберём каждую роль в команде разработки.

Что вообще считается творческим вкладом

Закон устанавливает чёткую границу: не являются авторами те, кто оказывал техническое, консультационное, организационное или материальное содействие (ст. 1228 ГК РФ). Также не признаются авторами те, кто лишь осуществлял контроль за выполнением работ.

При этом авторские права не распространяются на идеи, концепции, принципы, методы, алгоритмы и языки программирования (п. 5 ст. 1259 ГК РФ) — только на форму их выражения.

Пленум Верховного суда в Постановлении № 10 от 23.04.2019 добавил важное уточнение: само по себе отсутствие новизны, уникальности и оригинальности результата не свидетельствует о том, что он создан не творческим трудом. То есть даже неоригинальная по меркам отрасли работа может быть признана творческой.

С этим базисом разберём роли.

Разработчик кода

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

В ходе компьютерно-технической экспертизы анализируются стиль именования переменных, классов и функций, использование разделительных знаков, предпочтение определённых синтаксических конструкций, совпадение программных платформ и ключевых участков кода (Решение Дзержинского районного суда г. Новосибирска от 30.09.2013 по делу № 2-3/2013).

Статус-кво: автор.

Архитектор программного обеспечения

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

При этом архитектор исходного кода не пишет. И здесь возникает коллизия с законом.

Авторское право охраняет форму выражения, но не идеи, концепции, принципы и алгоритмы (п. 5 ст. 1259 ГК РФ). Архитектура программы — это система решений о том, как программа будет устроена. Без исходного кода суду не на что опереться, и российские суды прямо подтверждают: лица, которые не участвовали в создании кодовой базы, — в том числе архитекторы — не могут признаваться авторами.

В деле № А46-13578/2019 двое разработчиков договорились о равном вкладе: один — архитектура и алгоритмы, второй — код, 50 на 50. Но юридически эти вклады неравнозначны. Вклад автора кода — охраняемый элемент программы, измеримый и доказуемый. Вклад архитектора формально остаётся в категории идей и концепций, которые авторским правом не охраняются. Даже взаимное соглашение авторов не меняет правовой квалификации.

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

Статья 1261 ГК РФ прямо включает подготовительные материалы в состав программы для ЭВМ. Исследователи В.С. Витко и А.Ю. Чурилов называют описание архитектуры программы в числе таких материалов. Если архитектурная документация создавалась в процессе разработки и непосредственно определила структуру конечного продукта — есть основания квалифицировать её как охраняемый подготовительный материал и признать творческий вклад архитектора юридически значимым.

Практика начинает двигаться в этом направлении. В деле № 2-2899/2025 (решение Зюзинского районного суда г. Москвы от 16.12.2025) в числе десяти признанных соавторов программы «Атом.Око: Базовый релиз» фигурировал «Архитектор по разработке сервисов» с творческим вкладом «Разработка алгоритмов и архитектуры». Суд утвердил этот список и не поставил под сомнение включение архитектора.

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

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

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

Дизайнер графического интерфейса

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

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

Дизайн GUI — визуальное решение, созданное дизайнером. Охраняется авторским правом как самостоятельное произведение.

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

В современной доктрине оба эти понятия нередко смешивают, что порождает ошибочные выводы об авторстве. Разграничение между дизайном GUI как самостоятельным охраняемым объектом и GUI как аудиовизуальным отображением программы обосновано в ряде недавних научных работ (Моргунова Е.А. Дизайн графического интерфейса как объект авторских прав // Юрист. 2025. № 6; Смирнов Д.А. Проблемные аспекты определения программы для ЭВМ // ИС. Авторское право и смежные права. 2025. № 4).

Суд ЕС в деле C-393/09 (2010) прямо указал: графический пользовательский интерфейс не является формой выражения компьютерной программы, а лишь элементом, через который пользователь взаимодействует с её функционалом. Российский суд в деле № А40-181017/2018 подтвердил: дизайн программы не является самостоятельным произведением и не может быть предметом спора об определении правообладателя программы.

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

Итог: дизайнер является автором своего дизайна как самостоятельного произведения — при наличии творческого вклада. Соавтором программы для ЭВМ он, как правило, не становится: его вклад относится к другому объекту авторских прав.

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

Тестировщик

Тестировщик планирует и выполняет тест-кейсы, фиксирует баги, проверяет соответствие требованиям. Полезная и нужная работа, но творческая ли?

В деле № 02-3146/2023 суд был однозначен: «целью тестирования является подтверждение того, что программное обеспечение выполняет требования в целевой среде». Заявки на доработку функционала также не были признаны творческим вкладом — суд квалифицировал их как запросы от пользователей программы, а не от её создателей.

Тестировщики помогают программе работать правильно, но не создают её. Это техническое содействие в понимании ст. 1228 ГК РФ.

Статус-кво: не автор. Моя позиция: не автор.

Создатель технического задания

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

В деле № СИП-136/2015 Суд по интеллектуальным правам признал соавтором гражданина, который участвовал в разработке технического задания, в котором впервые были выражены требования к создаваемому объекту и его исполнению, включая интерфейс. Кода он не писал.

В деле № 02-5299/2023 работник разработал техническое задание, в котором был изложен алгоритм в форме совокупности данных и команд, предназначенных для функционирования ЭВМ — суд признал его автором произведения. То есть по содержанию ТЗ фактически описывало саму программу.

Это важное уточнение: стандартный список пожеланий заказчика авторством не станет. Суды смотрят на то, насколько ТЗ определяет конечный результат.

Статус-кво: как правило, автор. Моя позиция: автор при соблюдении условий.

Руководитель и менеджер

Формирование бизнес-модели, организация процессов, планирование выхода на рынок — всё это важно, но не является творческим вкладом в программу.

В решении Фрунзенского районного суда г. Санкт-Петербурга от 18.09.2018 по делу № 2-3145/2018 суд прямо указал: «формирование бизнес-модели, организация бизнес-процессов, продумывание стратегии выхода на рынок... не свидетельствуют о творческом вкладе в программу».

Роспатент в своём Руководстве (Приказ № 129 от 25.07.2018) также подчёркивает: руководство разработкой не свидетельствует о творческом участии в ней.

Пленум ВС РФ в Постановлении № 10: «Соавторами не признаются лица, осуществлявшие лишь руководство деятельностью автора».

Статус-кво: не авторы. Моя позиция: не авторы.

Итоговая таблица

Что это значит на практике

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

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

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

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

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

Есть вопросы по конкретной ситуации — пишите в комментариях или в личку.

Проголосовали 2 пользователя. Воздержался 1 пользователь.