Продавец открыл доступ к репозиторию и передал архив с исходниками. Можно ли после оплаты развивать и продавать продукт? Пока рано делать вывод: вместе с копией программы исключительное право не переходит автоматически. Оно может остаться у продавца, а права на часть кода — у его подрядчика. До сделки нужно выяснить, что именно продают, кому принадлежат права и какие действия будут разрешены покупателю.
Сначала определите предмет покупки
За словами «купить код» могут стоять разные сделки: приобретение исключительного права на программу, лицензия на ее использование или покупка доли либо акций компании-правообладателя. В последнем случае правообладателем остается компания — со своими договорами и обязательствами. Проверять и оформлять эти варианты придется по-разному.
При отчуждении исключительного права покупатель рассчитывает стать правообладателем конкретной программы. При лицензировании правообладатель не меняется, а разрешенные способы использования определяет договор. Допустим, покупателю достаточно развивать продукт для собственных нужд. Если же он собирается открывать клиентам доступ к сервису, выдавать сублицензии или продавать производные решения, такие возможности нужно проверить и закрепить отдельно. Исходники сами по себе не расширяют лицензию.
Составьте перечень того, что входит в сделку: серверная и клиентская части, мобильные приложения, библиотеки, скрипты развертывания, документация, тесты, схемы баз данных. Укажите версии, ветки репозитория и дату, на которую фиксируется состав кода. Иначе стороны могут подписать договор о «платформе», подразумевая разные наборы файлов.
Проверьте цепочку прав продавца
Для сделки по российскому праву важно установить, на каком основании продавец получил исключительное право. Запрашивайте документы не только на готовый продукт, но и на существенные этапы разработки — особенно если программу годами дорабатывали разные команды или она переходила между компаниями группы.
Сотрудники и подрядчики
Если код писали сотрудники, изучите трудовые договоры, задания, документы о служебном характере результата и условия вознаграждения. Работа разработчика в штате еще не отвечает на вопрос, кому принадлежат права на конкретный модуль: нужно понять, входило ли его создание в обязанности или задания сотрудника. Для служебных произведений российское право предусматривает особенности реализации права работодателем и выплаты вознаграждения автору. Здесь имеют значение даты и обстоятельства разработки.
По подрядчикам запросите договоры, технические задания, акты и условия о правах. Оплаченный счет и подписанный акт сами по себе не подтверждают переход исключительного права заказчику в нужном объеме. Если привлекались субподрядчики, проследите цепочку до создателей соответствующих компонентов. Отдельно проверьте модули, написанные до договора с продавцом и позже включенные в продукт.
Сопоставьте документы с историей репозитория, списком участников проекта и данными системы учета задач. Коммит от корпоративной учетной записи не доказывает авторство конкретного человека. Зато расхождения между документами и историей разработки подскажут, по каким частям кода нужны пояснения.
Переданные и лицензированные компоненты
Если чужая библиотека входит в сборку, продавец от этого не получает права отчуждать ее покупателю. Составьте ведомость сторонних компонентов: название, версия, источник, лицензия, способ использования и место в продукте. Проверьте открытое ПО, коммерческие SDK, шрифты, иконки, платные плагины и фрагменты из других проектов подрядчика.
По каждому компоненту выясните, что покупатель получит после сделки: исключительное право, возможность использовать его по действующей лицензии или необходимость оформить отдельное разрешение. Для открытого ПО проверьте условия распространения, сохранения уведомлений об авторах, предоставления текстов лицензий и, когда это требуется, исходного кода. Все зависит от конкретной лицензии и способа использования. Пометки «open source» в ведомости недостаточно.
Отделите код от соседних активов
Даже бесспорное право на программу не дает покупателю автоматически все, что нужно для работы сервиса. У домена, товарного знака, дизайна интерфейса, текстов, фотографий, баз данных, технической документации и аккаунтов в облачных сервисах могут быть другие владельцы или отдельные договорные ограничения. Основания обработки и передачи пользовательских данных проверяйте самостоятельно: считать их приложением к исходникам нельзя.
Проверьте и инфраструктуру. Если система запускается только с ключами продавца или зависит от его договора с облачным провайдером, одних исходников для развертывания не хватит. Зафиксируйте перечень окружений, зависимостей, ключей и конфигураций. Секреты не стоит прикладывать к договору без оглядки на безопасность: предусмотрите контролируемую передачу и смену учетных данных после закрытия сделки.
Как оформить договор и приемку
Фраза «продавец передает все права на код» не определяет, на какой именно объект переходят права. При отчуждении исключительного права опишите программу так, чтобы ее можно было однозначно установить; если сделка возмездная, согласуйте вознаграждение или порядок его определения. В лицензии укажите способы использования, а также территорию и срок с учетом планов покупателя и применимых правил. Формулировки должны соответствовать реальной структуре продукта.
- Состав результата. Приложите перечень репозиториев, релизов и документации, список исключенных и сторонних компонентов.
- Момент перехода права. Разграничьте подписание договора, оплату, передачу материалов и момент, когда покупатель становится правообладателем. Если программа зарегистрирована, при необходимости учтите правила государственной регистрации перехода права.
- Заверения продавца. Зафиксируйте сведения о его правах, известных претензиях, лицензионных ограничениях и полномочиях на сделку; согласуйте последствия недостоверных заверений.
- Передача материалов. Укажите формат исходников, необходимость передачи истории репозитория, инструкции сборки, документацию, доступы и срок устранения выявленной неполноты.
- Содействие после сделки. Договоритесь, как команда продавца будет отвечать на вопросы по сборке и миграции, если без ее помощи продукт трудно поддерживать.
Акт приемки фиксирует передачу материалов, но не заменяет условия договора о правах. Проверяйте результат на практике: собирается ли программа из полученных файлов, совпадают ли зависимости с ведомостью, доступны ли тесты и документация. При крупной покупке оплату иногда делят на этапы: после проверки документов, передачи кода и успешной сборки. Это не устраняет правовые риски, зато помогает заметить техническую неполноту до окончательного расчета.
Что делать, если документов не хватает
Пробел в документах не всегда означает, что от сделки нужно отказаться. Но придется оценить риск и, возможно, изменить условия. До закрытия продавец может получить недостающие права у подрядчика, заменить спорный компонент или согласовать отдельную лицензию для покупателя. Если вопрос остается открытым, определите его границы: какой модуль затронут, используется ли он в коммерческой версии и можно ли заменить его без остановки продукта.
Не заменяйте такую проверку обещанием продавца «уладить претензии третьих лиц». Заверения и условия о возмещении потерь помогают распределить финансовые последствия, но не создают права, которого у продавца не было. Для выхода на иностранные рынки отдельно проверьте право, применимое к договорам с авторами и лицензиям компонентов: российский договор о передаче прав не отменяет условия их получения.
Перед подписанием договора заведите таблицу с тремя колонками: «компонент», «основание права продавца», «что получает покупатель». Не помечайте строку как проверенную, пока за ней не стоит конкретный договор, лицензия или другой проверяемый документ. Материал носит информационный характер и не заменяет индивидуальную юридическую консультацию.