Кому принадлежит код: как не потерять права при работе с подрядчиками

Почему оплата ещё не означает права на код

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

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

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

Штатные разработчики: режим служебного произведения

Для сотрудников по трудовому договору работает институт служебного произведения (ст. 1295 ГК РФ). Если код создан работником в пределах трудовых обязанностей, исключительные права на него по общему правилу принадлежат работодателю. За работником сохраняются личные неимущественные права — право авторства и право на имя.

Чтобы этот механизм действительно сработал, обычно нужно несколько вещей:

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

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

Подрядчики и фрилансеры: договор отчуждения или лицензия

С внешними исполнителями ситуация принципиально другая. Закон предусматривает два основных режима: договор о создании произведения по заказу (ст. 1296 ГК РФ) и договор подряда или НИОКР с элементами создания произведения (ст. 1297 ГК РФ). От правильно выбранной конструкции и точных формулировок зависит, кому в итоге достанется исключительное право.

Что обязательно проверить в договоре

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

Типичные ошибки

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

Особые ситуации, в которых легко потерять права

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

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

Что показывает due diligence

Когда компания выходит на инвестиционный раунд, готовится к сделке M&A или подаёт документы на продажу актива, юристы покупателя или инвестора в первую очередь смотрят на цепочку прав. Их интересует, может ли компания подтвердить, что владеет ключевыми объектами интеллектуальной собственности — от кода и дизайна до текстов и товарных знаков.

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

Как выстроить процесс системно

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

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