Найти в Дзене

Авторы программы для ЭВМ. Кого к ним можно отнести

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

Как говорится, и швец, и жнец, и на дуде игрец. И во всем молодец.

Получая свое первое образование на факультете ВМиК МГУ, я, собственно, так и представляла себе работу программиста.

Времена поменялись, функции, которые выполнял программист, расщепили.

В итоге, появилась целая команда игроков, у каждого из которого своя роль при разработке ПрЭВМ. Да и программы уже совсем другие.

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

Если продукт посложнее, к делу включаются сценаристы.

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

Это я уже буду делать как юрист.

🔷Художники, дизайнеры

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

Подробности в моем Телеграм-канале "IP-IT право с нуля"

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

Это, в том числе графический пользовательский интерфейс программы (его отображение).

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

А чтобы было что заложить, нужно сначала над этим поработать.

И работают над этой частью специально обученные лица – художники, дизайнеры, композиторы и другие специалисты. Те же сценаристы.

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

Кстати, про изображения, тексты, формируемые ИИ (искусственным интеллектом), сейчас не говорю.

Насчет ИИ можно почитать в моей статье «Искусственный интеллект оставили без прав? Или революция отменяется».

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

🔷Бизнес-аналитики

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

Их роль носит, скорее, консультационный и организационный характер. Оказание материальной помощи. Но вот в силу ст. 1228 ГК РФ такая работа не приводит к авторству.

🔷Системные аналитики

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

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

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

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

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

Этот код можно назвать псевдокодом.

Про псевдокод можно подробнее прочитать в моем Телеграм-канале "IP-IT право с нуля"

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

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

В пользу того, что системные аналитики – это не кто иные, как авторы, внесшие творческий вклад в создание ПрЭВМ, хочу привести любопытное дело.

Дело (Определение МГС от 20.02.2023 г. по делу №33 - 7022/2023)

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

Вознаграждение работодатель не пожелал ей выплачивать, более того, стал оспаривать ее авторство.

Аргумент – в обязанности сотрудницы разработка программ не входила. Она была руководителем отдела, который к созданию программ мало имел отношения.

Однако судами было установлено, что сотрудница составляла ТЗ в виде алгоритма. Алгоритм представлял собой совокупность данных и команд, предназначенных для функционирования ЭВМ, необходимый для получения конкретного результата (смотрим определение ПрЭВМ из ст. 1261 ГК РФ).

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

Подробнее детали дела изложены в одном из постов Телеграм – канала «IP – IT право с нуля»

Таким образом, системные аналитики явно несправедливо отстранены от соавторства.

🔷Непосредственно программисты

Программисты работают по ТЗ, переводят процессы на язык программирования.

То есть, программисты - авторы исходного кода.

К ним вопросов, пожалуй, нет.

Хотя. Если на то пошло. Как бы при работе по договору авторского заказа не пришлось программисту отбиваться от того, что созданный им исходный код является, по сути, переработкой (переводом) псевдокода на язык программирования.

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

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

🔷Тестировщик

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

Тестировщик должен постараться сымитировать все возможные действия пользователя (сценарии).

Тестировщику нужно иметь большое воображение, чтобы просчитать возможные варианты событий (работы программы).

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

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

Так же, как, например, системного аналитика.

🔷Технический писатель

Специалист готовит документацию к ПрЭВМ.

Например, инструкцию по эксплуатации (установка и обслуживание), руководство пользователей.

Как он работает?

В работе техпис руководствуется гостами, в частности ГОСТ 19.101-77(единая система программной документации, виды программ и программных документов), ГОСТ 2.105-2019 (общие требования к текстовым документам), иными документами, в том числе утвержденными в организации.

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

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

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

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

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

Пример (Дело № А43-34415/2017)

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

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

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

В суде ответчик упирал на то, что спорная инструкция не является объектом авторского права, а описывает процесс эксплуатации и установки полимерных труб.

Похоже на ситуацию с документами для ПрЭВМ. Можно привести такие же аргументы.

Однако суд встал на сторону истца (работодателя сотрудников).

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

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

Про составные произведения см. на канале «IP – IT право с нуля»

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

Да, авторские права не распространяются на идеи, концепции, принципы, методы, процессы, системы, способы, решения технических, организационных или иных задач, открытия, факты (п. 5 ст. 1259 ГК РФ).

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

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

🔷Почему важно понимать, кто автор ПрЭВМ?

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

Ситуация 1. ПрЭВМ создается не в рамках трудовых отношений.

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

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

Ситуация 2. ПрЭВМ писали работники

Проблем ничуть не меньше.

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

С другой стороны, если работник был привлечен к разработке, а его трудовые обязанности не предполагали создание ПрЭВМ, в части вклада этого работника служебного произведения не будет.

Про служебные произведения см. подробнее на канале "IP - IT право с нуля"

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

А работодатель уже мог успешно (читай «неуспешно») передать исключительное право третьему лицу или предоставить лицензию. И это третье лицо может оказаться нарушителем (как в деле, которое рассматривал ВС РФ (определение от 27.06.2023 г. № 5-КГ23-51-К2).

И уламывай потом работника, договаривайся.

Приятного мало.

Я писала, что современные ПрЭВМ, в большинстве своем, можно отнести к сложным объектаммультимедийным продуктам.

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

Но пока все равно остается пробел в части того, кто же автор именно ПрЭВМ.

Ведь нарушение и личных неимущественных прав автора также наказуемо.

Хотелось бы для сложных ПрЭВМ такого же подробного регулирования, как и для аудиовизуальных произведений.

Подробнее в моей статье «Программа для ЭВМ как сложный объект. Быть или не быть?»

Надеюсь, в ближайшее время либо законодатели, либо Верховный Суд РФ с этим разберутся.

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

Детально разрабатываем договор авторского заказа. Определяем состав авторов. Кто, что делает.

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

Возникнут вопросы, обращайтесь.

Возможна связь через телеграм @NataBeres (в том числе по наставничеству).

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

«Использование Хеш-суммы в качестве доказательства тождественности файлов (РИДы, закупки и др.)»

«Защита сайта через защиту его дизайна. Сначала проверим, внесена ли творческая компонента»

«SaaS – услуга или лицензия на ПО»,

«БАЗА ДАННЫХ- объект авторских и смежных прав. Проблемы защиты и решения»,

«Искусственный интеллект оставили без прав? Или революция отменяется»

а также статьями из подборок:

подборка «Программы для ЭВМ и базы данных»,

подборка "Товарные знаки, изображения, фотографии и др. Как не нарушить права на них",

подборка "Налогообложение в сфере IP/IT".

Приглашаю в свой Телеграм-канал «IP – IT право с нуля».

Канал полезен как юристам в сфере IP-IT права, так и предпринимателям для понимания азов интеллектуального права

©Береснева Н.В. 03.10.2024