Разработка софта является комплексным процессом, предполагающим, как правило, вовлечение нескольких команд и специалистов, возможность их ротации, а также значительные временные и денежные затраты.
Вместе с тем, разработка софта не ограничивается лишь его фактическим созданием и доработкой, но также требует правильного документального оформления и структурирования внутренних и внешних процессов, связанных с разработкой и апгрейдом софта.
На практике возникает стандартная ситуация, когда компании фокусируются на коде и устранении багов, но не уделяют внимания оформлению прав на него. Это может повлечь негативные последствия как при доказывании прав компании на софт, так и при последующем выводе софта на рынок или его «продаже». Подробнее об этом рассказал Егор Кравченко, юрист, IPR/Защита данных, Legaltax.
В этой статье мы остановимся на ключевых вопросах, на которые рекомендуем обращать внимание разработчикам софта при организации внутренних и внешних процессов, связанных с разработкой, доработкой и поддержкой софта.
Внутренние процессы
Внутренний контур предполагает анализ и оценку надлежащего оформления отношений с работниками, вовлеченными в процессы создания софта. По общему правилу, исключительные права принадлежат физическим лицам, которые являются авторами того или иного объекта (код, картинка, анимация и др.).
Но законодатель учел возможный конфликт интересов между работником и нанимателем, поэтому в силу механизма «служебного произведения» исключительные права на созданные работником объекты интеллектуальной собственности переходят к нанимателю с даты создания таких объектов работником.
Это своего рода упрощенный механизм, позволяющий обеспечить нанимателю исключительные права на создаваемые работниками продукты и компенсировать свои затраты, связанные с содержанием штата персонала.
Однако не все так просто: не любой созданный работником объект автоматически считается служебным произведением. Для того чтобы объект признавался служебным произведением, он должен создаваться работником по заданию нанимателя или в порядке выполнения обязанностей, обусловленных трудовым договором (то есть при выполнении работником своих трудовых обязанностей). К примеру, если HR увлекается разработкой и в свободное от работы время пишет код, то его наниматель не будет иметь никаких прав на создаваемый HRом код, так как написание кода не входит в его непосредственные трудовые обязанности в качестве HR.
На практике встречаются ситуации, когда кроме трудового договора с работником никакой другой документации не оформляется (например, нет должностных инструкций, служебных заданий, внутренние процессы не урегулированы). Не исключены и ситуации, когда фактический функционал работника отличается от должности, указанной в трудовом договоре. Все эти обстоятельства могут ставить под сомнение наличие у нанимателя исключительных прав на создаваемые работниками объекты.
Чек-лист для нанимателя, чтобы обезопасить свои служебные произведения:
1) Трудовой договор:
- оформлены ли трудовые договоры с работниками в письменной форме?
- содержат ли трудовые договоры все существенные условия?
- указана ли в трудовом договоре формулировка о переходе к нанимателю исключительных прав на создаваемые работником объекты интеллектуальной собственности?
2) Трудовая функция:
- указана ли в трудовом договоре должность работника исходя из его реального функционала?
- соответствуют ли указанные в должностной инструкции трудовые обязанности работника его фактическому функционалу?
В должностной инструкции следует перечислять обязанности и функции конкретного работника (в том числе, например, создание соответствующих объектов интеллектуальной собственности).
Должностные инструкции стоит адаптировать под реально выполняемые работниками задачи, так как часто «типовые» должностные инструкции не охватывают в полной мере фактический функционал работников или не отражают специфику внутренних процессов и распределения ролей в компании. Более того, работник должен быть обязательно под подпись ознакомлен с должностной инструкцией.
5) Организация внутренних процессов:
- каким образом оформляются служебные задания?
- как организована коммуникация, постановка задач и предоставление отчетов о проделанной работе?
Рекомендация: оформляйте служебные задания и акты/отчеты о проделанной работе, выполненных задачах и созданных объектах. Закон прямо не требует обязательного наличия письменной формы с подписью работника на указанных документах, но, если такая возможность есть, используйте ее.
Сегодня в большинстве случаев постановка задач и поручений (служебных заданий), оформление актов и отчетов, коммуникация по рабочим вопросам происходит в электронной форме (через, например, CRM-системы, сервисы по управлению проектами - Jira, Confluence, Trello и др). Законодательством, кстати, эта возможность прямо не исключена.
При использовании электронной коммуникации и управлении проектами рекомендуем, чтобы процессы были задокументированы. К примеру, можно разработать и принять локальный акт (с которым работники обязательно должны быть ознакомлены), отражающий:
- порядок постановки задач и использования систем управления проектами и программных средств;
- порядок конкретизации поручений, каналы официальной коммуникации;
- порядок предоставления сведений о выполнении поставленных задач (например, репорты или отметки в системе о закрытии задач);
- порядок предоставления работнику доступа к проекту и т.д.
Внешний контур
Разработка софта редко полностью замыкается исключительно на «внутренних» ресурсах компании. На практике возможны различные сценарии «внешнего» участия в разработке софта и каждый из них имеет свои особые точки контроля, которые необходимо учитывать.
Наиболее типичные сценарии для «внешнего» контура:
1) часть задач по разработке отдается на аутсорсинг внешним подрядчикам;
2) часть задач по разработке закрывается «сторонними» охраняемыми решениями и готовыми продуктами («Third-Party IP») (к примеру, стоковые объекты анимации и графики) или open-source решения;
3) этапы разработки или функции разделены между участниками группы компаний (для случаев, когда разработка софта осуществляется в рамках группы компаний).
Аутсорсинг
Аутсорсинг задач внешнему подрядчику оформляется гражданско-правовым договором, при этом подрядчиками могут выступать физ. лица, ИП и компании.
Важно помнить, что в отличие от трудовых отношений, при работе с подрядчиками на аутсорсе по гражданско-правовым договорам правила о служебных произведениях применяться не будут, так как служебные произведения возможны только в рамках трудовых отношений.
Среди примеров нередко встречающихся ошибок в отношении разработки софта с использованием аутсорсинга можно отметить:
1) Ненадлежащее оформление прав на софт (например, договор содержит только условия о выполняемой работе и не содержит условий о судьбе исключительных прав, либо условия о переходе прав сформулированы некорректно). Возможна ситуация, когда результат работ подрядчика может быть передан, но исключительные права на его использование останутся у подрядчика.
2) Неверное использование механизмов предоставления прав на результаты работ (например, когда компания хочет получить исключительное право на результаты работ подрядчика, но вместо уступки исключительного права подрядчик предлагает предоставить лицензию, оставаясь при этом владельцем исключительного права). В данном контексте каждая из сторон должна четко понимать, какой механизм предоставления прав на результаты работ ей действительно нужен, чтобы в дальнейшем не было ложных ожиданий.
3) Отсутствие должной конкретики в отношении характера выполняемых работ, требований к результату и порядку его передачи, а также организации процесса выполнения работ (например, отсутствуют технические задания либо согласованные механизмы организации рабочих процессов и коммуникации между заказчиком и подрядчиком, механизмы приемки результатов, отсутствуют договоренности об (не)использовании Third-Party IP или open-source решений, либо договор не отражается специфику выбранной методологии разработки и т.д.).
Структурирование в рамках группы компаний
В случае, если компания имеет несколько офисов, и над софтом работает несколько центров разработки, то в итоге важно обеспечить полную концентрацию прав на софт за конкретной компанией. Для этого среди группы компаний зачастую создается холдинговая компания, в которой сосредотачиваются исключительные права на софт. Параллельно имеется ряд отдельных центров разработки, между которыми могут быть разделены роли по разработке/доработке отдельных модулей, функционала и т.п.
В этой связи для группы компаний важно правильное внутригрупповое структурирование договорных отношений, чтобы обеспечить переход всех исключительных прав на софт в пользу холдинговой компании. Это важно, так как, к примеру, исключительные права на результаты работ работника белорусского офиса, созданные им в рамках служебного задания, возникают непосредственно у белорусского офиса (а не у холдинговой компании).
Third-Party IP и open-source решения
На практике при разработке софта для решения отдельных задач используются уже “готовые” решения третьих лиц (например, части кода, фото/видео/музыка со стоков и др.).
Вместе с тем, соответствующие готовые решения могут охраняться авторским правом, а соответствующие исключительные права могут принадлежать третьим лицам. Поэтому важно помнить, что произвольное использование «чужих» объектов не допускается и сама по себе простая “публикация” в интернете того или иного объекта (например, открытого исходного кода) не означает автоматически, что такое решение можно использовать свободно и без ограничений.
При намерении использовать Third-Party IP (например, стоковый материал) следует проверять условия лицензионных соглашений на предмет объема предоставляемых прав, сроков, возможности передачи прав третьим лицам, ограничений по использованию стоковых объектов и т.д. При работе со стоками возможны территориальные ограничения или ограничения по верхнему пределу бюджета проекта, в котором используются стоковые материалы. Поэтому всегда необходимо проверять, подходят ли условия лицензирования соответствующих Third-Party IP под потребности проекта (с учетом целей и планируемого способа, сроков и территории коммерциализации софта). Возможно, в конкретном случае подойдет расширенная подписка вместо стандартной либо в принципе не подойдет ни одна из стоковых подписок.
Порядок использования open-source решений имеет схожую логику. Применительно к ним также нужно внимательно проверять тип лицензий их распространения, так как от условий лицензии зависят права, обязанности и возможности использования и продвижения разрабатываемого софта. К примеру, некоторые лицензии могут требовать обязательное раскрытие исходного кода, либо ограничивать возможность коммерческого использования конечного продукта (в том числе запрещать включать open-source решения в проприетарное ПО), либо требовать документирования вносимых изменений или предоставлять текст лицензии вместе с проприетарным ПО и т.д.
Более того, различные лицензии могут иметь несколько версий со своими особенностями (например, не все лицензии являются «юридически» совместимыми с другими видами), поэтому в этом вопросе также достаточно много «подводных камней». Несовместимость может сильно усложнить разработку софта и потребовать дополнительных ресурсов на устранение выявленных «юридических» несовместимостей.
Общие рекомендации по использованию Third-Party IP и open-source решений:
1) Проверяйте совместимость лицензий с вашими планами по коммерциализации продукта.
2) При использовании в одном продукте объектов, распространяемых по разным лицензиям, проверяйте совместимость таких лицензий друг с другом.
3) Ведите учет используемых Third-Party IP и open-source решений (например, в форме реестра с указанием условий лицензий или их версий; также можно использовать сторонние программы, которые в автоматизированном режиме могут выявлять заимствованные open-source решения).
Горячие темы