Кому принадлежат права на код и как оформить их на компанию

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

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

Короткий ответ: одного платежа недостаточно для проверки прав

Нельзя определить правообладателя только по факту оплаты. Имеют значение условия договора и обстоятельства создания программы. Для служебной разработки, заказа подрядчику и договора непосредственно с автором применяются разные правила. Авторство при этом нельзя передать компании как исключительное право. Правовая основа — статьи 1228, 1295–1297, а для договора с автором также 1288 части четвёртой ГК РФ.

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

Если код написал сотрудник

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

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

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

Если код написали фрилансер или студия

Сначала проверьте предмет договора и распределение прав. Договор непосредственно с автором нельзя автоматически приравнивать к любому договору с подрядчиком. Формулировка «техническая поддержка» тоже может не отражать фактическую разработку нового модуля.

При согласовании задания и договора разберите следующие вопросы:

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

Если исполнителем выступает студия, её обещание передать права стоит сопоставить с документами от фактических авторов. Договор на верхнем уровне не устраняет автоматически пробелы внутри команды подрядчика.

Почему NDA и корпоративный репозиторий не заменяют договор

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

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

Проверьте владельцев аккаунтов, резервных администраторов, восстановление доступа и резервные копии. Храните секреты в подходящем защищённом хранилище. При увольнении меняйте доступы по согласованному плану, сохраняя историю и доказательства, а не удаляя аккаунты и переписку в спешке.

Что делать с Open Source и сторонними компонентами

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

Далее проверьте требования конкретных лицензий: уведомления, тексты лицензий, условия распространения и, где применимо, предоставление исходного кода. Нельзя утверждать, что любая GPL-библиотека автоматически обязывает открыть весь SaaS: вывод зависит от лицензии и технической схемы. При необходимости правовую проверку проводят вместе с разработчиком.

Такой же отдельной оценки требуют SDK, API и материалы, права на которые компания получила по подписке или иной лицензии.

Чек-лист перед инвестициями или продажей продукта

Соберите в одном закрытом каталоге:

1. Список авторов и исполнителей по ключевым частям продукта.
2. Договоры, задания и дополнительные соглашения.
3. Документы о передаче результатов и оплате.
4. Перечень прежних наработок и сторонних компонентов.
5. Сведения о владельцах технических аккаунтов и резервном доступе.
6. Список пробелов с ответственными и порядком исправления.

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

Частые вопросы

Если подрядчик получил деньги, вопрос закрыт?

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

Разработчик уходит и угрожает удалить репозиторий. Что делать первым?

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

Что показать IT-юристу для первичной оценки?

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

Нужно привести права на продукт в порядок?

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

Обсудить права на код

Материал носит общий информационный характер. Правовой режим конкретной программы зависит от документов и обстоятельств её создания.