При передаче игры внешней студии заказчик обычно раскрывает намного больше информации, чем обычному подрядчику. Это исходный код, незапущенные механики, дизайн-документация, концепты, финансовые планы, roadmap и иногда данные о будущих релизах.
Поэтому NDA в геймдеве — не формальность перед началом работы. Он определяет, что подрядчик может делать с полученной информацией, кому её разрешено показывать и что происходит после окончания проекта.
Но одного NDA недостаточно.
Отдельно в основном договоре нужно разобраться с правами на результат: кому принадлежит написанный код, 2D- и 3D-графика, дизайн, музыка, документация и другие материалы.
Именно здесь возникает большинство неприятных сюрпризов. Заказчик может оплатить производство игры и только после завершения проекта обнаружить, что получил право пользоваться частью материалов, но не получил исключительные права или исходники.
Почему NDA и договор нужно разделять
NDA защищает информацию, которую стороны раскрывают друг другу.
Например, заказчик передаёт ещё не опубликованный build, исходный код и информацию о будущей игре. Подрядчик обязуется не разглашать эти данные и использовать их только для выполнения проекта.
Основной договор решает другую задачу. Он определяет, что именно должна сделать команда, как принимается работа, сколько она стоит и кому принадлежат результаты.
Поэтому фраза «у нас подписан NDA, значит с правами всё нормально» неверна.
Конфиденциальность и интеллектуальная собственность — разные блоки отношений.
На сайте NoPanic Studio эти этапы также разделены: после инспекции, оценки и согласования плана подписываются NDA и договор, при этом отдельно указано, что права на результат закрепляются за заказчиком.
Что должно быть понятно из NDA
Хороший NDA должен отвечать прежде всего на вопрос: что именно считается конфиденциальной информацией.
Если формулировка слишком узкая, часть материалов может формально оказаться за её пределами. Если слишком широкая — договор становится неудобным в реальной работе.
Для игрового проекта обычно имеет смысл охватить исходный код, билды, документацию, концепты, модели, финансовую и коммерческую информацию, данные о пользователях, roadmap и материалы будущих релизов.
Также нужно понимать, кому подрядчик может передавать эти данные внутри своей команды. Если над проектом работают разработчики, художники и QA, у них должен быть законный доступ к необходимой информации, но обязательства конфиденциальности при этом должны распространяться и на них.
Отдельно фиксируется срок действия обязательств. Он не обязательно должен совпадать со сроком самого production: чувствительность информации может сохраняться и после завершения разработки.
Что происходит при нарушении конфиденциальности
В договоре можно предусмотреть ответственность за нарушение NDA, в том числе договорную неустойку. По статье 330 ГК РФ неустойка может устанавливаться соглашением сторон за неисполнение или ненадлежащее исполнение обязательства.
Но пункт «штраф 10 миллионов за всё» сам по себе не превращает NDA в хорошую защиту.
Не менее важно определить, что является нарушением, как сторона должна уведомить об утечке и что происходит с конфиденциальными материалами после окончания сотрудничества.
Если компания хочет использовать именно режим коммерческой тайны в смысле российского законодательства, одного NDA может быть недостаточно. Закон предусматривает дополнительные меры: определение перечня защищаемой информации, ограничение и учёт доступа, регулирование отношений с сотрудниками и контрагентами и другие действия.
Для конкретного проекта этот блок лучше согласовать с юристом.
Кому принадлежит код игры
Для заказчика это один из главных вопросов.
В российском праве для произведений, создаваемых по договору заказа, действует важное правило: если предметом договора является создание произведения, исключительное право по общему правилу принадлежит заказчику, если стороны не предусмотрели иное. Это правило распространяется в том числе на программы для ЭВМ.
Но полагаться только на правило «по закону вроде должно быть нашим» не стоит.
В договоре лучше прямо написать, какие результаты создаются и кому принадлежат исключительные права на них.
Это особенно важно для игры, где одновременно появляется множество объектов: source code, editor tools, shaders, UI, тексты, 3D-модели, анимации, концепты и документация.
Если используется отдельный договор об отчуждении исключительного права, он должен быть заключён письменно. ГК РФ также позволяет сторонам определить момент, когда право переходит к приобретателю.
Например, стороны могут связать переход прав с полной оплатой определённого этапа.
Не путайте исключительные права с исходными файлами
Это разные вещи.
Договор может передавать заказчику права на модель персонажа, но из этого ещё не всегда следует понятный технический порядок передачи рабочего .blend, .ma, Substance-файлов и всех связанных материалов.
То же самое с программированием.
Получить права на написанный код и получить актуальный repository со всей историей, документацией и средствами сборки — не одно и то же с практической точки зрения.
Поэтому в договоре или приложении желательно отдельно перечислить, что физически передаётся заказчику.
Для кода это может быть репозиторий, документация и необходимые scripts. Для Game Art — исходные сцены, текстуры и согласованные рабочие файлы. Для синематика — master и исходники production в том объёме, который предусмотрен сделкой.
Что проверить по 2D- и 3D-графике
С art production есть отдельный риск: часть результата может создавать не сама компания как единый «автор», а конкретные художники.
По российскому праву авторство остаётся за физическим лицом. Право авторства и право автора на имя являются неотчуждаемыми, даже если исключительное право на произведение передано другому лицу.
Для заказчика это означает, что подрядчик должен сам иметь достаточные права на работы своих сотрудников и привлечённых исполнителей, чтобы затем корректно передать имущественные права заказчику.
Если произведение создано работником в пределах его трудовых обязанностей, исключительное право по общему правилу принадлежит работодателю, если договором не предусмотрено иное.
При работе с фрилансерами и физическими лицами схема может отличаться, поэтому подрядчику важно иметь корректно оформленную цепочку прав.
Музыка, шрифты, плагины и Asset Store — отдельная зона риска
Далеко не всё, что находится внутри финальной игры, создаётся подрядчиком специально для заказчика.
В проекте могут использоваться:
- движок;
- plugins;
- шрифты;
- stock music;
- звуковые библиотеки;
- marketplace assets;
- сторонние SDK;
- open-source библиотеки.
На такие материалы подрядчик физически не может передать заказчику исключительное право, если сам им не владеет.
Здесь действует лицензия правообладателя.
Поэтому договор должен отличать созданные специально для проекта результаты от сторонних компонентов.
Для последних полезно вести список лицензий и условий использования.
Особенно внимательно стоит смотреть на ограничения по коммерческому использованию, количеству пользователей, platforms, sublicensing и распространению исходных файлов.
Если право использования предоставляется именно по лицензионной модели, договор должен определять разрешённые способы использования. Право, прямо не предусмотренное лицензионным договором, по общему правилу не считается предоставленным.
Как проверить договор перед подписанием
Не нужно начинать с размера штрафов.
Сначала стоит проверить сам предмет договора.
Понятно ли, что именно создаёт подрядчик? Есть ли связь между техническим заданием, этапами и актами приёмки?
После этого — права.
В договоре должно быть однозначно понятно, кому принадлежит исключительное право на созданный результат и в какой момент оно переходит.
Дальше имеет смысл посмотреть на исходники и инфраструктуру. Кто контролирует repository? Что происходит с ним после окончания проекта? Передаётся ли документация? Что будет с рабочими файлами art-команды?
И только затем — ответственность, NDA, сроки и порядок расторжения.
Хороший тест прост: если сотрудничество неожиданно прекратится через полгода, сможет ли другая команда взять полученные материалы и продолжить разработку?
Если ответ неочевиден, договор стоит уточнить.
Типичный риск: подрядчик использовал то, на что у него не было прав
Для заказчика опасна не только ситуация, когда подрядчик отказывается передавать права.
Есть менее заметный вариант: подрядчик обещал их передать, но сам не получил необходимые права от автора.
Например, 3D-модель сделал привлечённый freelancer, а договор с ним не содержал нужной передачи прав.
Или в трейлер попала музыка с лицензией, которая не покрывает коммерческую рекламу.
Поэтому для большого проекта разумно добавить заверение подрядчика о том, что он вправе передавать согласованные результаты и что использование известных ему сторонних материалов будет оформлено в соответствии с их лицензиями.
Типичный риск: право есть, а дорабатывать результат нельзя без спора
В играх практически любой материал меняется.
Код рефакторят, модель дорабатывают, интерфейс адаптируют, изображение режут под store assets.
При этом у автора существуют личные неимущественные права, включая право на неприкосновенность произведения; российское право отдельно регулирует внесение изменений в произведение.
Поэтому юридическая конструкция для production должна учитывать, что результат предполагается изменять, адаптировать и включать в состав сложного игрового продукта.
Конкретные формулировки этого блока лучше готовить с IP-юристом, особенно для крупных проектов.
Как NoPanic Studio работает с NDA и передачей прав
Процесс NoPanic Studio начинается с изучения проекта и определения реального scope.
Сначала команда смотрит билд, репозиторий и pipeline, затем оценивает состав, сроки и смету. После согласования плана стороны переходят к договорной части.
На основном сайте NoPanic прямо указано: «Подписываем NDA и договор. Права на результат закреплены за вами». Также форма обращения позволяет сразу прикрепить собственный NDA.
Подробно процесс подключения описан на сайте студии: /.
Для заказчика такой формат важен именно предсказуемостью: конфиденциальность обсуждается до передачи чувствительных материалов, а права на создаваемый результат фиксируются в договоре, а не остаются устной договорённостью.
Чек-лист: что проверить в договоре перед стартом
Перед подписанием я бы проверил следующие пункты:
Понятно ли определено, что именно должен создать подрядчик.
Указано ли, кому принадлежат исключительные права на код, art, UI, тексты, документацию и другие результаты.
Зафиксирован ли момент перехода прав.
Понятно ли, какие исходники и рабочие файлы передаются заказчику.
Отделены ли собственные результаты подрядчика от сторонних assets, plugins, библиотек и музыки.
Есть ли порядок работы с confidential information и NDA.
Распространяются ли обязательства подрядчика на людей, которым он даёт доступ к проекту.
Понятно ли, где находится repository и как заказчик получает к нему доступ.
Определено ли, что происходит с материалами после расторжения договора.
Есть ли понятная процедура приёмки результата и исправления недостатков.
Установлена ли ответственность сторон за существенные нарушения.
Не противоречат ли друг другу договор, техническое задание и приложения по интеллектуальной собственности.
Для крупной разработки этот чек-лист не заменяет полноценную юридическую проверку, но хорошо помогает быстро найти зоны, которые нужно обсудить до подписания.
Что прислать для обсуждения условий
Если у заказчика уже есть собственный NDA, его можно отправить до передачи билда или исходного кода.
Для обсуждения основного договора полезно сразу понимать формат проекта: новая разработка, отдельный art-production, co-development, LiveOps или подключение команды к существующему продукту.
Также желательно обозначить, какие материалы особенно чувствительны и какие результаты должны передаваться вместе с исходниками.
Если проект содержит сторонние технологии или assets с отдельными лицензиями, это лучше сообщить заранее.
NoPanic позволяет приложить NDA или бриф непосредственно при первом обращении.
Итоги
В геймдев-аутсорсе юридическая безопасность строится из двух отдельных частей.
Первая — конфиденциальность. NDA определяет, как подрядчик работает с кодом, билдами, документацией и другой непубличной информацией.
Вторая — права на результат.
Заказчик должен понимать, кому принадлежит созданный код, art, дизайн и другие материалы, когда переходят права и какие исходники он получит после завершения работы.
Отдельно нужно проверить сторонние компоненты. Marketplace assets, SDK, музыка и библиотеки могут использоваться по лицензии, поэтому «передать права на всю игру» буквально возможно не всегда.
Чем раньше эти вопросы зафиксированы в договоре, тем меньше риск обнаружить юридическую проблему уже после релиза или при смене подрядчика.
Материал носит информационный характер и не является юридической консультацией. Условия конкретного договора и применимое право лучше проверять с профильным юристом.