В феврале 2022г. РБК опубликовал результаты опроса сервиса SuperJob, согласно которому у 51% опрошенных компаний есть сотрудники, работающие удаленно. В Москве и Санкт-Петербурге этот показатель выше –  68% и 63% соответственно. При чём, чаще всего на дистанционную работу в переводят сотрудников из сферы информационных технологий.

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

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

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

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

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

Зачем вообще оформлять документы?

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

Подробнее

Документальное оформление прав на программное обеспечение в частности необходимо для:

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

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

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

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

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

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

Что будет, если этого не сделать?

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

Подробнее

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

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

• в отношении какого именно программного обеспечения у правообладателя есть исключительное право – название продукта не определяет само программное обеспечение, нужны документы, подтверждающие, что право на конкретный код принадлежит конкретному лицу (так, в случае с недвижимостью, в документе подтверждающим право собственности, указывается точный адрес и кадастровый номер объекта недвижимости);

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

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

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

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

Зачем нужны бумажные документы если есть CRM, task-manager, e-mail, среда разработки, из которых и так все понятно?

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

Подробнее

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

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

а) они не были изменены и именно в таком состоянии имели место в то или иное время;

б) были созданы конкретным лицом, что, к примеру, требует соотнесения цифрового ID «Ivan-Bogatyr» c физическим лицом Богатыревым Иваном Ивановичем (имя вымышленное) и неизбежно поставит вопрос об аутентификации и порядке присвоения логинов сотрудникам в конкретной организации, который опять же выясняется посредством изучения документов (локальных нормативных актов предприятия и договоров, заключенных между организацией и конкретным разработчиком).

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

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

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

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

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

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

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

Когда начинать оформлять документы?

Кратко: как только можете описать конечный результат (хотя бы примерно), который бы хотели получить от исполнителя.

Подробнее

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

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

Какие документы должны быть оформлены?

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

Подробнее

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

В случае трудовых правоотношений могут иметь место следующие документы:

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

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

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

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

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

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

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

б) момент принятия\ознакомления работника с таким служебным заданием (момент отправки задания работодателем, нажатие работником кнопки «принять» и т.д.);

в) момент выполнения работником порученного ему задания (например, проставление работником или руководителем рабочей группы статуса задачи «выполнено»);

в) порядок осуществления разработки и использования тех или иных корпоративных систем;

г) закрепление за каждым работником того иного цифрового ID, способов аутентификации (необходимо для соотнесения физического лица и его действий в корпоративных системах с тем цифровым ID, который за ним закреплен и отображается, к примеру, в среде разработки);

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

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

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

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

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

Как распределяются права на программное обеспечение?

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

Подробнее

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

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

Например, для трудовых правоотношений законом определена презумпция, что результаты интеллектуальной деятельности, созданные в рамках выполнения служебных заданий, по умолчанию принадлежат работодателю (ст.1295 ГК РФ).

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

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

Другой пример из гражданских правоотношений. Между заказчиком и исполнителем был заключен договор на создание программного обеспечения (ст.1296 ГК РФ). Исключительное право принадлежит заказчику. Но это вовсе не означает, что исполнитель не вправе использовать такое программное обеспечение для собственных нужд (при чем безвозмездно). «Свои нужды» - категория оценочная и то, что исполнитель считает своими нуждами, может не совпадать с тем, что вкладывает в это заказчик. Этот вопрос также должен быть специально оговорен в договоре.

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

• вопрос о допустимости осуществления переработки;

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

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

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

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

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

Что можно самому сделать прямо сейчас?

Проверка на «юридическую чистоту» процедура комплексная и непростая (отчасти похожая на разматывание клубка, а поэтому до конца не во всех случаях прогнозируемая). Тем не менее, как в отношении уже имеющихся объектов, так и еще только разрабатываемых, можно как минимум провести проверку по следующим топ-3 пунктам («ОКИ»):

1.    Объективизируй

• Объекта права (программного обеспечения и любого иного) не существует, пока он не выражен в какой-либо объективной форме.

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

2.    Конкретизируй

Из документов, оформляющих процесс создания того или иного результата должен следовать:

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

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

3.    Индивидуализируй

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

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

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

Рощупкин Николай Александрович

заместитель директора филиала юридической фирмы "Городисский и Партнеры" в Екатеринбурге