{"id":14274,"url":"\/distributions\/14274\/click?bit=1&hash=fadd1ae2f2e07e0dfe00a9cff0f1f56eecf48fb8ab0df0b0bfa4004b70b3f9e6","title":"\u0427\u0435\u043c \u043c\u0443\u0440\u0430\u0432\u044c\u0438\u043d\u044b\u0435 \u0434\u043e\u0440\u043e\u0436\u043a\u0438 \u043f\u043e\u043c\u043e\u0433\u0430\u044e\u0442 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430\u043c?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"6fbf3884-3bcf-55d2-978b-295966d75ee2"}

Юридический due diligence в отношении компьютерных программ. Часть II

Иван Галкин, Консультант, Дарья Носова, Партнер O2 Consulting

O2 Consulting

Часть II. Основные зоны риска, связанные с исключительным правом

Продолжая цикл публикаций, посвященных юридическому due diligence в отношении компьютерных программ (с вводной Частью I. "Общие вопросы" можно ознакомиться по ссылке), мы затронем один из наиболее значимых с коммерческой точки зрения аспектов проверки – проверку принадлежности исключительного права на программу (в терминологии гражданского законодательства – программа для ЭВМ).

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

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

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

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

1. Переход исключительных прав на программу от её авторов – разработчиков

При проведении юридического due diligence в отношении компьютерной программы важно проанализировать аспект отчуждения исключительного права авторами - создателями её кода, что применимо как к Собственным, так и к Приобретенным разработкам.

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

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

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

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

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

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

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

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

2. Переход исключительного права на Приобретенную разработку

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

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

На основании нашего опыта проведения проверок, мы отмечаем, что при заключении и исполнении указанных договоров часто допускаются различные юридические и фактические ошибки, такие как:

- несогласование существенных условий договора,

- неосуществление государственной регистрации перехода исключительного права (когда такая регистрация требуется),

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

- неоформление сопутствующих документов доказательственного характера (актов приема-передачи).

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

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

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

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

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

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

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

0
2 комментария
Evgenii Tarasevich

Не могли бы Вы привести реальный пример, каким образом на практике сотрудники компании-разработчика  применяют метод оформления актов сдачи-приемки, о которых Вы сообщаете. Это ежедневная или ежемесячная сдача кода или как? И еще вопрос — если таких актов не делается, а это обычная практика разработчиков (а не теоретиков-юристов), то организция не имеет по Вашему мнению исключительного права на разработанный код? Или это все относится к неоперившимся стартапам, которым непременно нужно проконсультироваться у юристов?
 Пожалуйста  приведите новеллы ГК или "актуальной судебной практики" для иллюстрации Ваших мыслеизъявлений.

Ответить
Развернуть ветку
O2 Consulting
Автор

Спасибо за внимательное прочтение и вопросы!

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

В качестве примера реального судебного дела можем привести N А40-202764/2018 – в нем довольно классическая ситуация: по мнению истца (организация А), сотрудники разработали компьютерную программу, работая в организации А, а после увольнения учредили организацию Б и передали ей права на эту программу. Организация А обратилась в суд за защитой своих прав, утверждая, что программа была создана сотрудниками в рамках исполнения служебных обязанностей при работе на организацию А, однако, суды отказали в удовлетворении исковых требований за недостаточностью доказательств. Судами указано, что для установления служебного характера произведения недостаточно наличия трудовых отношений, необходимо предоставление дополнительных документов доказательственного характера (среди которых отмечен акт приема-передачи).

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

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

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда