Договоры в сфере ИС

Контекст и зачем читать

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

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

Поэтому договоры в сфере ИС нужны не ради формальности, а ради ответа на ряд очень практических вопросов. Кому принадлежит результат? Что именно считается переданным? Какие права передаются полностью, какие — по лицензии, а какие вообще не передаются? Где лежат исходники? Как подтверждается сдача результата? Что считается доработкой, а что новым объектом? Можно ли подрядчику использовать работу в портфолио? Кто отвечает за стоковые элементы, шрифты, библиотеки, плагины, шаблоны и иные «чужие» компоненты? Как компания будет доказывать свои права через полгода, если отношения испортятся?

Эта страница нужна, чтобы перевести договорной слой ИС из режима «общих слов» в режим управляемой конструкции. Мы смотрим на договоры не как на отдельный текст, а как на связку: объект → правообладатель → модель передачи или лицензии → исходники и доступы → приёмка → версии и изменения → конфиденциальность → доказательства → контур защиты при споре. Такой подход особенно важен, если бизнес растёт, работает с несколькими подрядчиками, хочет быть готовым к due diligence, инвестору, продаже проекта, смене команды или конфликту с тем, кто вчера ещё был своим исполнителем.

Если вам нужна общая карта раздела, начните с Интеллектуальная собственность — раздел (партнёры). Если конфликт уже вероятен и нужен не только договор, но и стратегия следующего шага, рядом почти всегда нужна страница Стратегия защиты ИС и сопровождение спора (партнёры). Если вопрос касается в первую очередь контента, дизайна, фото, видео, интерфейсов, презентаций и иных произведений, полезно держать рядом Авторские права. Если спор или риск уже вышел в жёсткую фазу, следующим уровнем обычно становится Судебные споры (партнёры). Если же договорный слой связан с брендом, обозначениями или патентным активом, параллельно смотрят Товарный знак, Патент и при сделочном сценарии — Продажа/покупка патента.

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

Когда это обычно нужно и где чаще всего ломается процесс

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

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

• Исходники и доступы не регулируются отдельно. Бизнес считает, что если результат передан, то и исходники, облака, репозитории, пароли, CMS, рекламные кабинеты и хранилища тоже автоматически «на его стороне». Процесс ломается в день конфликта, увольнения или смены подрядчика. Это критично, потому что право на объект и фактический контроль над инфраструктурой — разные вещи.

• Договор не различает передачу права и лицензию. Для команды это кажется тонкой юридической разницей, но именно она определяет, кто остаётся владельцем результата, кто может перерабатывать, кто может выдавать права третьим лицам и насколько устойчиво чувствует себя бизнес в масштабировании. Это критично, потому что неправильно выбранная модель разрушает либо гибкость, либо контроль.

• Нет режима изменений и доработок. Результат редко живёт в той версии, в какой был впервые передан. Его правят, дорабатывают, режут на части, объединяют, перерабатывают, передают следующей команде. Процесс ломается, когда никто не знает, где граница между исходным объектом, его обновлением, новой редакцией и новым результатом. Это критично, потому что без регламента изменений легко потерять историю и спорить о правах на «новую версию».

• Конфиденциальность описана декларативно. В договоре может быть красивый блок про NDA, но он бесполезен, если неясно, что именно считается конфиденциальной информацией, кто имеет доступ, как данные передаются, где хранятся исходники, можно ли показывать проект в портфолио, можно ли использовать фрагменты в других проектах. Это критично, потому что утечки и повторное использование почти всегда происходят через неотрегулированные детали.

• Приёмка результата не привязана к проверяемым критериям. Формула «работы выполнены в полном объёме» почти ничего не даёт, если стороны не понимают, как проверяется качество, состав пакета, передача исходников, передача доступа, отсутствие скрытых ограничений, список сторонних компонентов и иные обязательные условия. Это критично, потому что в конфликте такой акт будет слабее, чем кажется.

• В проекте участвуют несколько исполнителей или несколько юрлиц. Один делает дизайн, другой код, третий тексты, четвёртый фото, пятый продаёт, шестой администрирует. Процесс ломается, когда договорная карта не собирает эти роли в единый контур. Это критично, потому что право в таких системах расползается быстрее, чем растёт проект.

• Компания думает о договоре только после конфликта. На старте всем не хочется «усложнять». Потом подрядчик пропадает, дизайнер заявляет права, маркетолог уходит вместе с файлами, агентство не отдаёт исходники, а репозиторий оформлен на сторонний аккаунт. Это критично, потому что договоры в сфере ИС особенно дороги именно тогда, когда их не было вовремя.

• Бизнес не готов к due diligence, инвестору или продаже проекта. Пока проект живёт внутри команды, кажется, что всё под контролем. Но внешняя проверка быстро показывает: где акты, где перечни объектов, где права на шаблоны, где лицензии на библиотеки, где режим доступа, где реестр исходников, где право использовать материалы в новых продуктах. Это критично, потому что ценность актива в глазах инвестора зависит не только от качества результата, но и от чистоты его договорного контура.

Алгоритм действий

1. Определить объект и модель работы. Сначала нужно зафиксировать, о чём вообще договор: контент, дизайн, сайт, ПО, интерфейсы, фото/видео, документация, курс, шаблоны, база материалов, брендовые визуалы, смешанный продукт. Одновременно нужно понять, что именно требуется бизнесу — полная передача прав, лицензия, ограниченная лицензия, временное использование, совместное использование или staged-модель. Фиксация: карта объекта и цели договора. Артефакт: рамка сделки. Типичная ошибка: сразу брать шаблон договора, не определив, какой объект и какая модель управления правом нужны реально.

2. Собрать перечень результата. Нужно превратить общую формулу «разработка сайта» или «пакет дизайна» в список конкретных объектов: страницы, макеты, файлы, экраны, тексты, карточки, API-описания, модули, репозитории, фото, ролики, анимации, шаблоны, иконки, презентации, таблицы, документы, инструкции. Фиксация: приложение с перечнем объектов. Артефакт: опись результата. Типичная ошибка: ограничиться общим названием услуги без предметной конкретизации.

3. Определить правообладателя и основание прав. Нужно понять, кто создаёт объект, на каком основании, кому и как переходят права, что остаётся у исполнителя, какие ограничения действуют по исходным компонентам. Фиксация: карта «объект → создатель → основание → получатель прав». Артефакт: матрица правообладания. Типичная ошибка: подменять правообладание фактом оплаты.

4. Выбрать модель передачи или лицензии. Это ключевой разворот. Полная передача прав нужна не всегда. Иногда бизнесу важнее лицензия с правом переработки, иногда — исключительная модель, иногда — ограниченная лицензия без права сублицензии, иногда — комбинированный режим. Фиксация: таблица допустимых способов использования и ограничений. Артефакт: выбранная правовая конструкция. Типичная ошибка: тянуть все проекты в универсальную формулу «передать всё навсегда», не понимая, чем это бьёт по исполнимости и переговорам.

5. Прописать исходники, доступы и инфраструктуру. Нужно отдельно зафиксировать, что передаётся в виде файлов, что — в виде доступа, кто администратор, какие хранилища используются, где живёт репозиторий, где хранятся мастер-файлы, что считается полной передачей исходников, в каком формате и в какой срок она происходит. Фиксация: опись хранилищ, файлов и доступов. Артефакт: акт передачи исходников и доступа. Типичная ошибка: считать это технической мелочью, которую можно решить «по звонку потом».

6. Настроить приёмку результата. Нужны критерии: что именно считается сданным, как проверяется полнота, какие замечания допустимы, в какие сроки принимаются правки, как подтверждается передача файлов и доступов, как закрывается этап. Фиксация: регламент приёмки и чек-лист. Артефакт: акт/протокол приёмки с понятной логикой. Типичная ошибка: подписывать акты без проверки состава результата.

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

8. Закрепить конфиденциальность и правила публичного использования. Важно определить, что можно показывать в портфолио, что нельзя раскрывать, кто может использовать фрагменты, как хранится чувствительная информация, что происходит после окончания проекта. Фиксация: список конфиденциальных блоков, портфолио-ограничений и правил доступа. Артефакт: рабочий контур конфиденциальности. Типичная ошибка: вставить шаблонный NDA-блок, который красиво выглядит, но не регулирует реальное поведение сторон.

9. Собрать пакет доказательств исполнения. Для каждого этапа полезно заранее понимать, какие документы потом будут доказывать правовую чистоту: ТЗ, бриф, договор, приложение, акт, опись файлов, переписка, ссылки на публикации, журнал версий, доказательства лицензий на сторонние элементы. Фиксация: реестр доказательств по проекту. Артефакт: due diligence-ready папка. Типичная ошибка: вспоминать о доказательствах только после конфликта или перед инвестором.

10. Сразу заложить маршрут на случай конфликта. Договор по ИС не должен быть написан как будто спор невозможен. Нужно заранее определить, что делать при отказе передавать исходники, при нарушении портфолио-ограничения, при копировании, при споре о составе результата, при несанкционированном использовании третьими лицами. Фиксация: карта триггеров и допустимых сценариев. Артефакт: спороустойчивая договорная модель. Типичная ошибка: оставлять спорный контур на «будем решать по ситуации».

Документы и доказательства

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

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

• Техническое задание, бриф или иной документ постановки задачи.

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

• Приложение со способами использования и ограничениями.

• Акты приёмки результата по этапам.

• Акты передачи исходников, доступов, логинов, паролей, репозиториев, CMS, облаков и иных инфраструктурных компонентов.

• Реестр хранилищ и администраторов: где лежат мастер-файлы, кто управляет доступом, кто отвечает за резервирование.

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

• Переписка по правкам, замечаниям, согласованию финалов и передаче результата.

• Подтверждения лицензий на стоки, шрифты, шаблоны, плагины, библиотеки, музыку, фото и иные сторонние компоненты.

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

• Таймлайн проекта: заказ, этапы, передача, публикация, изменения, закрытие проекта, передача следующему подрядчику.

• Реестр доказательств исполнения и доказательств права по объектам.

• Шаблоны претензий, запросов на передачу, запретов на портфолио-использование, требований об удалении и иных рабочих документов на случай конфликта.

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

Как мы работаем: действие → фиксация → артефакт

• Микро-сценарий 1. Постановка задачи. Что делаем: определяем объект, модель права, ставку и чувствительные зоны проекта. Что фиксируем: карту объекта и сценарий использования. Что выдаём: рамку договора. Зачем это нужно: чтобы договор начинался не с шаблона, а с логики бизнеса.

• Микро-сценарий 2. Сбор предмета. Что делаем: раскладываем результат на конкретные единицы. Что фиксируем: перечень объектов и файлов. Что выдаём: приложение с реестром результата. Зачем это нужно: чтобы спорить можно было о конкретике, а не об абстракции.

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

• Микро-сценарий 4. Исходники и доступы. Что делаем: отдельно описываем инфраструктурную часть проекта. Что фиксируем: репозитории, облака, логины, CMS, мастер-файлы, исходники, роли администраторов. Что выдаём: акт передачи исходников и доступа. Зачем это нужно: чтобы компания не зависела от одного исполнителя после завершения проекта.

• Микро-сценарий 5. Приёмка и контроль качества. Что делаем: строим проверяемую процедуру сдачи этапов. Что фиксируем: чек-лист, замечания, сроки на исправление, подтверждение состава результата. Что выдаём: исполнимый акт/протокол приёмки. Зачем это нужно: чтобы спор о «сдали/не сдали» не был голословным.

• Микро-сценарий 6. Версии и изменения. Что делаем: определяем, как жить с правками, новыми редакциями и передачей проекта следующему подрядчику. Что фиксируем: журнал изменений и порядок оформления новых версий. Что выдаём: регламент изменения результата. Зачем это нужно: чтобы через полгода можно было точно назвать актуальную редакцию и её правовой статус.

• Микро-сценарий 7. Конфиденциальность и внешний контур. Что делаем: задаём правила доступа, запреты на разглашение, режим портфолио и повторного использования. Что фиксируем: перечень чувствительных блоков и допустимых публикаций. Что выдаём: рабочий контур конфиденциальности. Зачем это нужно: чтобы защита результата не разрушалась через повседневную небрежность.

• Микро-сценарий 8. Пакет доказательств. Что делаем: собираем договорную и операционную историю проекта в единую папку. Что фиксируем: договор, приложения, акты, переписку, лицензии, версии, публикации. Что выдаём: due diligence-ready пакет. Зачем это нужно: чтобы спор, проверка партнёра или инвестора не заставляли срочно собирать всё заново.

• Микро-сценарий 9. Конфликтный маршрут. Что делаем: заранее строим коридор действий на случай отказа передавать исходники, нарушения лицензии, копирования, неправильной публикации или удержания доступа. Что фиксируем: триггеры, дедлайны, доказательства, шаблоны. Что выдаём: спороустойчивая договорная модель. Зачем это нужно: чтобы договор не был наивным и беспомощным в момент напряжения.

Типовые ошибки

• Ошибка: писать «передаются все права», не объясняя какие именно. Почему возникает: хочется упростить текст. Последствия: договор красиво звучит, но плохо работает в конкретных вопросах использования, переработки и передачи третьим лицам. Как предотвратить: описывать способы использования, ограничения и состав результата. Что проверить сейчас: можно ли по договору понять, что именно разрешено и запрещено без дополнительных разговоров.

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

• Ошибка: забывать про исходники. Почему возникает: заказчик думает о финале, а не о системе дальнейшего управления. Последствия: зависимость от подрядчика, проблемы при доработке, миграции, споре или смене команды. Как предотвратить: отдельно описывать исходники, формат передачи и сроки. Что проверить сейчас: знаете ли вы, что именно считается полным комплектом исходников по вашему проекту.

• Ошибка: не регулировать доступы и администрирование. Почему возникает: доступы воспринимаются как «технический вопрос». Последствия: компания юридически права, но фактически не контролирует систему. Как предотвратить: оформлять акт передачи доступа и карту администраторов. Что проверить сейчас: кто конечный владелец домена, CMS, репозитория, облака и рекламных кабинетов.

• Ошибка: использовать стоковые и сторонние элементы без документальной чистоты. Почему возникает: продакшн работает быстрее юристов. Последствия: проект нельзя чисто передать или продавать как полностью собственный актив. Как предотвратить: вести реестр лицензий и ограничений по сторонним компонентам. Что проверить сейчас: можно ли по каждому чужому элементу показать основание его использования.

• Ошибка: нет приёмки по существу. Почему возникает: акт подписывают, потому что «надо закрыть этап». Последствия: спустя время невозможно доказать, что именно было принято и в каком составе. Как предотвратить: вводить чек-лист приёмки. Что проверить сейчас: были ли перед подписанием акта проверены исходники, доступы и перечень результата.

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

• Ошибка: шаблонный NDA без операционного смысла. Почему возникает: confidentiality-блок копируют без адаптации. Последствия: он не покрывает реальные точки утечки: портфолио, подрядчики второго контура, облака, доступы, экспорт файлов. Как предотвратить: привязывать конфиденциальность к конкретным объектам и каналам. Что проверить сейчас: перечислены ли реальные чувствительные блоки проекта, а не только абстрактная «информация».

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

• Ошибка: использовать один и тот же шаблон договора для контента, дизайна, сайта и ПО. Почему возникает: хочется скорости и единообразия. Последствия: договор получается слишком общий и не попадает в специфику объекта. Как предотвратить: адаптировать ядро шаблона под тип результата. Что проверить сейчас: не слишком ли общая модель используется для вашего конкретного объекта.

• Ошибка: вспоминать о договорном контуре только на стадии спора. Почему возникает: на старте кажется, что задача срочная и «бумаги потом». Последствия: после конфликта приходится латать систему задним числом. Как предотвратить: строить договорный слой одновременно с запуском проекта. Что проверить сейчас: есть ли у текущего проекта хотя бы минимально безопасная версия договора и приложений.

• Ошибка: не разводить контентный и брендовый слой. Почему возникает: дизайн и бренд часто визуально переплетены. Последствия: спор путается между объектами и режимами ИС. Как предотвратить: отдельно квалифицировать спор по авторскому праву и по бренду. Что проверить сейчас: спор действительно о результате творчества или о знаке/обозначении. При необходимости — свериться со страницей Товарный знак.

• Ошибка: не превращать разовый проект в повторяемую систему. Почему возникает: после закрытия этапа команда сразу переключается на следующие задачи. Последствия: те же ошибки повторяются с новым подрядчиком и новым объектом. Как предотвратить: сохранять шаблоны, чек-листы и регламент. Что проверить сейчас: остался ли после прошлого проекта повторяемый пакет, а не только папка с файлами.

Триггеры и ранние признаки

• Признак: подрядчик говорит «исходники потом». Что это обычно означает: риск удержания контроля после оплаты. Первый безопасный шаг: письменно зафиксировать состав исходников и дедлайн передачи.

• Признак: в договоре нет приложения с перечнем результата. Что это обычно означает: высокий риск спора о составе. Первый безопасный шаг: собрать и утвердить реестр объектов до подписания акта.

• Признак: доступы к CMS, репозиторию, облаку и домену оформлены на исполнителя. Что это обычно означает: компания уязвима операционно. Первый безопасный шаг: провести инвентаризацию владельцев доступа и изменить модель администрирования.

• Признак: подрядчик хочет использовать работу в портфолио без ясных правил. Что это обычно означает: позже возникнет спор о допустимой публичности. Первый безопасный шаг: отдельно согласовать режим портфолио и запреты.

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

• Признак: используются шрифты, плагины, шаблоны и стоковые элементы без архива лицензий. Что это обычно означает: проект не готов к чистой передаче или due diligence. Первый безопасный шаг: собрать реестр сторонних компонентов и их правовой статус.

• Признак: акт подписан, но никто не проверял полноту передачи файлов и доступов. Что это обычно означает: формальная приёмка слабее фактической реальности. Первый безопасный шаг: делать post-acceptance dry-run по чек-листу состава передачи.

• Признак: у компании нет единой папки с договором, приложениями, актами и перепиской. Что это обычно означает: при споре восстановление картины будет медленным и неполным. Первый безопасный шаг: собрать due diligence-ready архив по проекту.

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

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

Мини-кейсы

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

• Кейс 2. Дизайн-система распалась между агентствами. Один подрядчик рисовал брендовые материалы, другой адаптировал их под рекламу, третий делал презентации и карточки. Пока всё развивалось быстро, никто не собирал единый перечень объектов и режим прав. В момент due diligence выяснилось, что брендовый актив существует, но договорная карта по нему дырявая. Разворачивать такую историю надо через сводный реестр и переразметку прав, а не через попытку найти «главного виноватого».

• Кейс 3. Подрядчик передал PDF, но не передал мастер-файл. Снаружи это выглядело как завершённый этап. Но как только заказчик захотел адаптировать материал под новый продукт, стало ясно: без мастер-файла и прав на переработку ценность передачи ограничена. Эта история типична для презентаций, дизайна, макетов, сложной полиграфии и motion-материалов. Разница между «финалом» и «управляемым активом» оказалась критичной.

• Кейс 4. Портфолио разрушило конфиденциальность. Исполнитель считал, что имеет право показать проект у себя на сайте как кейс. Заказчик был уверен, что всё под NDA. В договоре было общее слово «конфиденциально», но не было правил публикации, сроков, исключений и режима портфолио. Конфликт здесь возник не из злого умысла, а из плохой конкретизации. Решение — всегда отдельно регулировать публичное использование результата.

• Кейс 5. Внедрили стоковые элементы и сорвали чистую передачу прав. Команда быстро собрала визуальную упаковку из готовых библиотек, шаблонов и платных ассетов. До сделки с партнёром это никого не беспокоило. Но как только потребовалось «передать всё как собственный актив», выяснилось, что часть элементов передавать нельзя в том режиме, на который рассчитывал покупатель. Ранняя проверка лицензий могла бы сэкономить месяцы переделок.

• Кейс 6. Репозиторий и домен оказались сильнее договора. Формально компания считала себя владельцем продукта. Фактически домен и репозиторий были зарегистрированы на частные аккаунты исполнителей. Когда отношения испортились, спор быстро вышел из уровня «кому принадлежат права» на уровень «кто может в один клик сломать бизнес». Это пример того, что договоры по ИС всегда нужно связывать с реальным контролем над технической инфраструктурой.

• Кейс 7. После трёх итераций проекта никто не понимал, какая версия правовая. Доработки шли быстро, менялись исполнители, акты подписывались по общим формулировкам. В итоге финальная версия жила в боевом контуре, а договорно зафиксирована была старая конфигурация. Типичный вывод: если нет журнала изменений и правил оформления новых версий, проект почти неизбежно уходит в правовой разрыв.

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

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

• Нужно ли всегда передавать права полностью? Нет. Иногда бизнесу достаточно лицензии, иногда нужна полная передача, иногда — смешанная модель. Важен не максимализм, а соответствие модели реальной цели проекта.

• Что важнее: договор или акт? Они работают вместе. Договор задаёт модель отношений, акт подтверждает передачу конкретного результата. Без одного из них конструкция часто слабеет.

• Обязательно ли делать перечень объектов? Для управляемой сделки — практически да. Иначе в конфликте или проверке слишком много остаётся в зоне предположений.

• Нужно ли отдельно передавать исходники? Если бизнесу нужен реальный контроль над результатом, доработкой и сменой исполнителя — да, обязательно нужно отдельно описывать и передавать исходники или эквивалентный технический пакет.

• Можно ли использовать один шаблон договора для всех проектов? Базовое ядро — да, но объект и приложения почти всегда требуют адаптации. Контент, дизайн, сайт, ПО и фото/видео по-разному чувствительны к деталям.

• Что делать, если конфликт уже начался? Остановить хаос, собрать факты, версии, переписку, перечни объектов, доступы и текущее состояние результата. После этого выбирать режим: претензия, переговоры, подготовка к спору. Для такого маршрута полезна страница Стратегия защиты ИС и сопровождение спора (партнёры).

• Что выдают на выходе кроме договора? Обычно это пакет артефактов: реестр объектов, акты передачи, опись хранилищ, регламент изменений, чек-листы приёмки, реестр доказательств и карта рисков.

• Когда рядом нужна страница про авторские права? Когда спор или работа крутятся вокруг текстов, дизайна, фото, видео, интерфейсов, презентаций и иных произведений. Здесь опорная связка — Авторские права.

• Когда договорный спор уже близок к суду? Когда стороны спорят не о правке условий, а о праве, составе передачи, удержании исходников, доступах, нарушении запретов и последствиях уже состоявшихся действий. Тогда маршрутом становится Судебные споры (партнёры).

• Что делать, если бизнес уже живёт на старых слабых договорах? Начинать с ревизии: выделить критичные активы, собрать перечень объектов, проверить правообладателей, собрать пробелы и поэтапно переупаковывать контур с минимальным риском для текущих отношений.

Куда обратиться и что подготовить

Если задача общая и сначала нужно понять, как договорный слой встроен в остальной контур ИС, начните с Интеллектуальная собственность — раздел (партнёры). Если конфликт уже вероятен, отношения с подрядчиком нестабильны или вы боитесь сделать неправильный первый шаг, рядом полезно держать Стратегию защиты ИС и сопровождение спора (партнёры). Если ядро вопроса — контент, дизайн, код, презентации, фото/видео и иные произведения, сильная связка будет со страницей Авторские права. Если ситуация уже вошла в плотный спор, следующим этапом обычно становится Судебные споры (партнёры).

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

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

Артефакты на выходе и критерии готовности

• Артефакт 1. Карта объекта и цели договора по проекту.

• Артефакт 2. Приложение с перечнем объектов результата.

• Артефакт 3. Матрица правообладания и оснований прав.

• Артефакт 4. Договор/лицензия с исполнимой моделью прав и ограничений.

• Артефакт 5. Акт передачи результата.

• Артефакт 6. Акт передачи исходников, доступов и инфраструктурных компонентов.

• Артефакт 7. Опись хранилищ, администраторов и ключевых доступов.

• Артефакт 8. Регламент приёмки и чек-лист состава результата.

• Артефакт 9. Регламент изменений и журнал версий.

• Артефакт 10. Реестр сторонних компонентов и их лицензий.

• Артефакт 11. Реестр доказательств исполнения и права.

• Артефакт 12. Пакет на случай конфликта: шаблоны требований, список триггеров, маршрут первого шага.

• Артефакт 13. Due diligence-ready папка по активу.

• Артефакт 14. Набор шаблонов и чек-листов для повторяемой работы по следующим проектам.

• Критерий готовности 1. Предмет договора описан не общими словами, а конкретным составом результата.

• Критерий готовности 2. Понятно, кто правообладатель по ключевым объектам и на каком основании.

• Критерий готовности 3. Выбранная модель прав соответствует бизнес-цели, а не просто привычному шаблону.

• Критерий готовности 4. Исходники и доступы передаются по описанной и проверяемой процедуре.

• Критерий готовности 5. Приёмка результата основана на чек-листе, а не на общей формуле «всё ок».

• Критерий готовности 6. Есть режим новых версий, доработок и передачи проекта другому исполнителю.

• Критерий готовности 7. Конфиденциальность и портфолио-ограничения описаны в привязке к реальным объектам и каналам.

• Критерий готовности 8. Сторонние компоненты учтены и их правовой статус подтверждён.

• Критерий готовности 9. Папка проекта позволяет пережить спор, due diligence и смену исполнителя без потери логики.

• Критерий готовности 10. У компании остаётся повторяемый контур, а не только один подписанный договор.

Смотрите также

• Интеллектуальная собственность — раздел (партнёры)

• Авторские права

• Стратегия защиты ИС и сопровождение спора (партнёры)

• Судебные споры (партнёры)

• Товарный знак

• Патент

• Продажа/покупка патента

Получить консультацию

Мы можем предложить Вам следующие услуги: