Права в IT-продукте: где команда теряет контроль
Как проверить цепочку прав на код, интерфейс, бренд и сторонние компоненты до инвестиций, лицензирования или спора.
IT-продукт может выглядеть готовым для рынка, но юридически состоять из разных слоев: код сотрудников, модули подрядчиков, компоненты с открытым исходным кодом, дизайн студии, домен основателя, тексты маркетинга и бренд, который еще не проверяли. Для инвестора, покупателя или крупного клиента важен не только работающий продукт, а подтвержденная цепочка прав.
Проверьте, кто создал каждый слой
Разделите продукт на кодовую базу, интерфейс и пользовательский сценарий, контент, базы данных, бренд, домены, аккаунты и документацию. Затем по каждому слою ответьте: кто автор, на каком основании результат передан компании, где хранится подтверждение, есть ли ограничения на использование или передачу.
Особое внимание нужно уделить ранним подрядчикам и сооснователям. Если вклад был сделан до регистрации компании или без договора, права могут остаться у автора либо быть спорными. Это не всегда блокирует продукт, но влияет на юридическую проверку и переговоры.
Не смешивайте доступ и право
Доступ к репозиторию, макету, домену или облачному аккаунту не означает переход исключительных прав. Для юридической проверки важен документ: трудовой договор, служебное задание, договор разработки, акт, уступка прав, лицензия или другой механизм передачи.
Если подрядчик использовал свои библиотеки, шаблоны или предыдущие наработки, договор должен отделять переданные результаты от ранее созданных материалов и прав. Иначе компания может получить продукт, который нельзя свободно отчуждать, лицензировать или включать в сделку.
Отдельно проверьте открытый исходный код
Список компонентов с открытым исходным кодом нужен не только технической команде. Лицензии могут влиять на распространение, публикацию производных работ, уведомления, указание авторства и коммерческое использование. Риск зависит от конкретной лицензии, архитектуры продукта и способа доставки.
Лучше фиксировать не только название пакета, но и версию, лицензию, место использования и ответственного за обновления. Это помогает не спорить с нуля, если клиент или инвестор запросит перечень программных компонентов.
Бренд и интерфейс требуют доказательств
Название продукта, логотип, домен и визуальная система должны быть отделены от кода. Проверьте, кто владеет доменом, кто подавал или будет подавать товарный знак, какие классы нужны, кто создавал дизайн и есть ли акт передачи.
По интерфейсу сохраните исходники, версии, переписку по заданиям и договоры с авторами. В споре или сделке важна не только финальная картинка, но и доказательство, что компания контролирует результат.
Когда нужен отдельный IP-аудит
- перед инвестиционным раундом или M&A;
- перед лицензированием продукта крупному клиенту;
- при конфликте с подрядчиком, бывшим сотрудником или сооснователем;
- при выходе на новый рынок под тем же брендом;
- при обнаружении спорной зависимости с открытым исходным кодом.
Аудит прав не обещает, что претензий не будет. Он показывает, где права подтверждены, где нужен документ, а где решение зависит от фактов создания, условий договора и юрисдикции.