Интеллектуальная собственность в договоре технологического партнёрства: права и объекты
Один из самых нервных моментов в технологическом партнёрстве наступает не тогда, когда вы не сошлись во вкусах на стек технологий. И даже не тогда, когда интеграция «внезапно» занимает не две недели, а два месяца. Самое интересное начинается, когда продукт уже почти готов, демо показали, инвестор кивнул, а кто-то тихо спрашивает: «А права на всё это чьи?». И вот тут в комнате обычно становится слышно, как у юриста щёлкает ручка, а у руководителя проекта в голове открывается вкладка «пожар».
Я, Эльвира Габдрахманова, видела это много раз: люди реально дружат, вместе пилят прототип по ночам, шлют друг другу мемы в рабочем чате, а потом в один день выясняется, что «право интеллектуальной собственности является» не абстрактной философией, а конкретным правом запретить выпуск, отключить доступ к коду или внезапно уйти с базой данных. Технологическое партнёрство отлично работает, пока вы заранее договорились, что такое ваша интеллектуальная собственность, какие у неё объекты интеллектуальной собственности, и кто чем может пользоваться. Без этого договор превращается в лотерею, а защита интеллектуальной собственности сводится к спору «я же придумал» против «я же оплатил».
Зачем вообще так заморачиваться и что у вас будет на руках
После чтения у вас появится понятный маршрут: как описать объекты права интеллектуальной собственности в договоре, как закрепить право на результат интеллектуальной собственности, где поставить ограничения, где наоборот дать свободу, и как не потерять контроль над тем, что создаётся на стыке команд. Я не буду строить из себя учебник по ГК РФ, но покажу, как это выглядит в реальных переговорах и почему интеллектуальная собственность правовая штука упрямая: она не любит «договорились устно» и «ну мы же партнёры».
Пошаговый гайд: как прописать ИС в договоре технологического партнёрства
Шаг 1. Составьте карту: что вы приносите в партнёрство, а что создаёте внутри
Первое, что делаем, это делим всё на «внесённое» и «создаваемое». Внесённое это ваш прежний код, дизайн-система, библиотека, ТЗ, бренд, домен, документация, методики, иногда даже интерфейсные тексты. Создаваемое это то, что появится в рамках проекта: новая программа для ЭВМ, база данных, алгоритм, новое техническое решение (потенциально изобретение или полезная модель), промобразец для корпуса устройства, а иногда и товарный знак под новую линейку. Это и есть те самые объекты интеллектуальной собственности, которые потом превращаются в деньги, запреты и суды, если их не разложить по полкам.
Зачем так подробно: чтобы потом не перепутать, кому принадлежит исключительное право интеллектуальной собственности на то, что было раньше. Типичная ошибка: написать «стороны совместно разрабатывают продукт», а про исходники и наработки умолчать. Проверка простая: откройте карту и спросите себя, может ли любая сторона завтра забрать внесённое обратно без разрушения проекта. Если нет, значит вы уже смешали активы, и защита прав интеллектуальной собственности у вас на честном слове.
Шаг 2. Зафиксируйте, кому принадлежат права на создаваемое: совместно или раздельно
Дальше выбираем модель владения правами на результат интеллектуальной собственности. Вариант «всё совместное» звучит по-товарищески, но в жизни это часто тормоз. Совместное право значит, что любая лицензия, продажа, sublicensing третьим лицам, иногда даже публикация кейса превращается в согласования, и никто не хочет быть тем, кто «не дал добро». Вариант «каждому своё» проще: например, один получает исключительное право на программу для ЭВМ, другой на товарный знак и маркетинг-материалы, а доступ друг другу оформляют лицензиями. Есть и гибрид: совместное владение ядром, а модули принадлежат разработчикам.
Типичная ошибка тут смешная и грустная: стороны пишут «права принадлежат заказчику», но заказчик не платит как заказчик, а приносит, скажем, инфраструктуру и продажи. Потом исполнитель доказывает, что это партнёрство, а не подряд, и начинается спорт по переписке. Как проверить, что всё работает: возьмите один объект (например, исходный код), и смоделируйте ситуацию «расходимся через полгода». Кто может продолжать выпуск? Кто может запретить? Кто может передать права инвестору? Если ответы неочевидны, договор недописан.
Шаг 3. Пропишите условия использования: лицензии, территории, сроки, ограничения
Когда собственник определён, важно не забыть про использование. Технологические партнёры обычно не хотят быть «собственниками» всего подряд, им нужно право пользоваться. Вот тут и появляются лицензии: простые или исключительные, на территорию РФ или шире, на срок проекта или бессрочно, с возможностью переработки или строго «как есть». Если ваш проект выходит в онлайн, территория всё равно важна, потому что «интеллектуальная собственность РФ» живёт в российской юрисдикции, а внешние рынки могут потребовать другой структуры прав, иначе вы просто не сможете нормально подписать контракт с зарубежным контрагентом.
Кейс из практики: у клиента был небольшой SaaS для бухгалтерии, партнёр отвечал за модуль интеграции с маркетплейсами. За три месяца они автоматизировали выгрузку заказов и возвратов, и продукт пошёл в продажи через аккаунты в VK и Telegram. Но лицензии не было, только «взаимное разрешение». Когда партнёр ушёл, он потребовал отключить модуль, потому что это его объект права интеллектуальной собственности. Проверка: в договоре должна быть фраза не про дружбу, а про конкретное право использования, с объёмом и границами, иначе защита интеллектуальной собственности превращается в просьбу.
Шаг 4. Закройте конфиденциальность так, чтобы она реально работала, а не лежала мёртвым текстом
Конфиденциальность в ИС это не «не рассказывать никому». Это режим доступа к исходникам, датасетам, техническим решениям, макетам, коммерческим условиям. Если вы обсуждаете технологию в общем чате, пересылаете архивы в личку, а пароль от репозитория «qwerty123», то потом очень сложно убедительно говорить про защиту интеллектуальной собственности. В договоре обычно фиксируют, что считать конфиденциальным, как долго хранить режим, кому можно раскрывать (например, аудитору или юристу), и что делать при утечке.
Типичная ошибка: запретили разглашать всё подряд, но не прописали, как стороны обмениваются информацией и кто отвечает за доступы. Проверка: у вас должен быть понятный канал обмена (корпоративная почта, защищённый репозиторий, конкретные рабочие пространства), и список ролей, кто имеет доступ. Иногда я прошу команду просто показать, где лежит финальная версия ТЗ. Если ответ «ну у нас в переписке где-то», то интеллектуальная собственность какое право бы ни давала, утечки будут делом времени.
Шаг 5. Решите, что и как регистрируем: патент, товарный знак, программа, дизайн
Не всё нужно регистрировать, но кое-что без регистрации защищать тяжело. Товарный знак почти всегда лучше приводить в порядок заранее, особенно если партнёрство выводит продукт на рынок. По патентам сложнее: изобретение или полезная модель требуют новизны, и болтать о решении на конференции до подачи заявки рискованно. По программам для ЭВМ регистрация в РФ добровольная, но иногда помогает в спорах и при сделках. По промобразцам тоже часто вспоминают слишком поздно, когда изделие уже в фотках на маркетплейсах.
Кейс: команда делала устройство для мониторинга температуры в логистике, железо и софт. Они показали прототип на выставке, а потом пришли с вопросом: «федеральное интеллектуальной собственности это кто, туда идти?». Я сначала подумала, нет, лучше вот так: объяснила, что по практике ориентируются на материалы ФИПС и подают через Роспатент, но важнее другое, успеть до публичного раскрытия и договором закрепить, кто заявитель. Типичная ошибка: оплатили разработку, но заявку подал «кто быстрее успел». Проверка: в договоре должно быть расписано, кто подаёт, кто оплачивает, кто подписывает и кому принадлежит право собственности на интеллектуальную деятельность, созданную в проекте.
Шаг 6. Пропишите, что происходит с улучшениями, форками и «побочками» разработки
В реальной разработке всегда появляются улучшения: ускорили алгоритм, переписали модуль, добавили новый датасет, сделали новый интерфейсный паттерн. И тут внезапно всплывают объекты права интеллектуальной собственности, которые никто не планировал. В договоре стоит заранее определить: улучшения входят в общий результат или остаются за автором улучшения, но лицензируются партнёру. Это особенно важно, если одна сторона ведёт продуктовую часть, а другая лабораторию или R&D.
Типичная ошибка: считать, что улучшения «автоматически» принадлежат тому, кто платит. Иногда да, но партнёрство не всегда про оплату, и суды смотрят на фактические отношения и документы. Проверка: возьмите пример «мы сделали форк репозитория и добавили ML-модуль», и попробуйте понять, есть ли у второй стороны право его использовать без новых согласований. Если нет, через год вы упрётесь в блокировку релизов и будете решать вопросы интеллектуальной собственности уже на повышенных тонах.
Шаг 7. Встройте механизм споров и «развода» так, чтобы он не выглядел как предательство
Этот шаг обычно эмоционально тяжёлый: никто не хочет обсуждать расставание в день знакомства. Но технологические партнёрства часто заканчиваются банально, без драмы: смена стратегии, сокращение бюджета, усталость команды. И если вы не прописали, кто и как продолжает использовать объекты интеллектуальной собственности, спор будет не про технологию, а про власть. В договоре удобно заранее определить досудебный порядок, сроки ответа, экспертизу кода, а также санкции за нарушение и порядок прекращения лицензий.
Кейс: у одного ИП и студии разработки был совместный проект, сроком на 6 месяцев, работали через таск-трекер и Git. Через четыре месяца ИП захотел продать продукт крупному игроку, а студия сказала: «исключительное право наше, мы только дали доступ». Спор решали через юристов, потеряли время, сделку отложили. Проверка: у вас должен быть сценарий «выходим из партнёрства», где понятно, что остаётся каждой стороне, а что подлежит выкупу, передаче или прекращению. Это и есть нормальная защита прав интеллектуальной собственности, без романтики.
Подводные камни: где чаще всего всё ломается
Первый ломатель нервов это путаница между авторством и правом. Автор мог написать код, дизайнер мог нарисовать интерфейс, но исключительное право интеллектуальной собственности может принадлежать компании, если отношения оформлены правильно. И наоборот: компания может быть уверена, что «всё наше», но договоры с исполнителями на самом деле не передали права, или передали криво. Я часто вижу, как в партнёрстве аккуратно прописали раздел между компаниями, но забыли про физлиц, фрилансеров, подрядчиков. Потом появляется человек с ноутбуком и спокойным голосом говорит: «право на результат интеллектуальной собственности моё», и у всех портится день.
Второй момент это цифровизация и следы. Проект в онлайне оставляет логи, коммиты, переписки, куски кода в чатах. Это одновременно спасение и ловушка. Спасение, потому что можно доказать вклад, ловушка, потому что при споре вы внезапно понимаете, что сами же нарушали режим конфиденциальности. Если вы хотите, чтобы интеллектуальная собственность правовая часть не выглядела театром, заведите минимальную дисциплину: где храним исходники, где обсуждаем ТЗ, кто имеет доступ, кто подписывает релизы. Это скучно, да, но дешевле нервов.
Третий подводный камень это «мы зарегистрируем потом». Потом часто оказывается, что домен уже занят, знак похож на чужой, новизну по патенту вы убили презентацией, а база данных уже расползлась по подрядчикам. И тут начинаются вопросы уровня «федеральное интеллектуальной собственности где посмотреть, что уже занято?», «интеллектуальная собственность ответы кто даст срочно?». Смотрите материалы ФИПС, проверяйте заранее, и не стесняйтесь задавать право интеллектуальной собственности вопросы юристу до запуска, а не после претензии.
Где помогает поддержка и кому это реально экономит время
Если у вас технологическое партнёрство и продукт хотя бы близко к рынку, регистрация и нормальное оформление ИС обычно окупаются не деньгами, а тишиной в голове. Особенно если вы собираетесь на маркетплейсы, в корпоративные продажи или в переговоры с инвестором. Товарный знак, структура прав на софт, режим коммерческой тайны, правильные лицензии между партнёрами это не «бумажки», а способ не потерять проект на стадии, когда он наконец-то стал похож на бизнес.
Иногда достаточно одной консультации, чтобы разложить по местам объекты интеллектуальной собственности и понять, где у вас дырка. Если вам ближе практика, чем лекции, можно начать с полезных материалов и новостей: Хотите защитить свою интеллектуальную собственность, быть в курсе всех новостей? Подпишитесь на наш Telegram-канал. Я там часто вижу вопросы в духе «право интеллектуальной собственности ответы где найти», и приятно, когда люди приходят заранее, а не после того, как партнёр уже сменил пароли. И да, ссылка на Телеграмм канал Патентного бюро Лирейт» тоже пусть будет у вас под рукой, вдруг пригодится в самый неподходящий вечер.
Если нужна прикладная помощь по бренду, вот страницы, которые обычно сохраняют в закладки: Регистрация товарного знака и Монополия на бренд. А когда речь про конфликты и претензии, полезно смотреть, как устроена Юридическая защита интеллектуальной собственности, потому что «защита» в реальности это не лозунг, а работа с доказательствами, договорами и тем самым исключительным правом.
FAQ
Вопрос: Что считать объектами интеллектуальной собственности в технологическом партнёрстве?
Ответ: Обычно это программа для ЭВМ, исходный код и документация, база данных, дизайн интерфейса, товарный знак и элементы бренда, а также технические решения, которые могут тянуть на изобретение, полезную модель или промобразец. Важно не угадывать, а прямо перечислить объекты права интеллектуальной собственности в договоре и приложениях.
Вопрос: Исключительное право интеллектуальной собственности можно поделить «пополам»?
Ответ: Можно оформить совместное владение, но оно часто создаёт пробки на решениях: любое использование или передача прав требует согласования. На практике удобнее, когда исключительное право у одной стороны, а у другой лицензия с понятным объёмом, сроком и правом на доработки.
Вопрос: Интеллектуальная собственность какое право даёт партнёру, который инвестировал, но не писал код?
Ответ: По умолчанию инвестиции сами по себе не превращаются в право собственности на интеллектуальную деятельность. Право возникает из договора: уступка, лицензия, доля в совместном праве, и так далее. Поэтому право интеллектуальной собственности является тем местом, где «мы договорились» нужно фиксировать буквами.
Вопрос: Как связаны «федеральное интеллектуальной собственности» и ФИПС, и где смотреть информацию?
Ответ: В российской системе по промышленной собственности обычно ориентируются на Роспатент и ФИПС как на источник материалов, реестров и разъяснений. Если вы проверяете знак или думаете о патентовании, начинать разумно с открытых данных и инструкций, а дальше уже решать, нужна ли подача заявки.
Вопрос: Что делать, если партнёрство развалилось, а права на продукт не прописаны?
Ответ: Придётся поднимать переписку, коммиты, акты, платежи, договоры с подрядчиками и пытаться восстановить картину, кому что принадлежит. Это долго и дорого, и именно поэтому защита интеллектуальной собственности начинается с договора, а не с претензии.
Вопрос: Можно ли выкладывать разработки в портфолио, если это совместный проект?
Ответ: Только если в договоре есть разрешение на публикацию и понятно, что именно можно показывать без раскрытия конфиденциальной информации. Иначе вы рискуете нарушить режим секретности и получить конфликт по защите прав интеллектуальной собственности, хотя хотели просто похвастаться работой.
Вопрос: Где искать право интеллектуальной собственности ответы на частые вопросы по РФ, если нужно быстро?
Ответ: Для базовой ориентации полезны материалы ФИПС и практика по типовым договорам, а для конкретной ситуации лучше короткая консультация с разбором именно вашего проекта. Вопросы интеллектуальной собственности почти всегда завязаны на детали: кто делал, где лежит код, что подписано, кто платил и что обещали друг другу в переписке.