Silver KnightБлог / Интеллектуальная собственность

Практическое руководство · Геймдев и IT

Кому принадлежит игра и как договориться с командой до релиза

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

Мария Полунина, основатель Silver Knight, патентный поверенный РФ № 2744, эксперт Организации развития видеоигровой индустрии

Около 25 минут чтения12 разделовПраво РФ и зарубежные примеры

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

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

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

Основная часть статьи — о российском праве. Зарубежные примеры отмечены отдельно: они помогают увидеть риски международного релиза, но не заменяют проверку права конкретной страны. Нормы и источники проверены 12 октября 2026 года.

Три кадра: разработчик радуется — «Игра готова!». Юрист спрашивает — «А права собраны?». Разработчик ищет контакт — «Сейчас найдём художника…».
Когда оформление прав отложили до релиза. Оригинальная иллюстрация создана с помощью ИИ.

1. Что в игре защищается авторским правом

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

Авторские права возникают в силу создания произведения. Платный релиз, значок © и регистрация для этого по общему правилу не нужны. Но при споре всё равно придётся доказывать, кто и что создал. Поэтому исходники, промежуточные версии и история работы полезны задолго до первого письма от юриста. Основа — статьи 1259 и 1261 ГК РФ [1].

Что вы используетеЧто может охранятьсяГде проходит граница
КодКонкретный исходный и объектный код, охраняемые подготовительные материалыИдея алгоритма и функциональность сами по себе не равны авторским правам на код
Графика и интерфейсРисунки, модели, текстуры, анимация, творческое оформлениеСтиль, жанр и техническая функция элемента сами по себе не монополизируются
Сценарий и персонажиТекст, диалоги, конкретный образ персонажа при наличии самостоятельного творческого характера«Воин спасает мир» или «саркастичный маг» — ещё не конкретное произведение
Музыка и озвучкаМузыкальное произведение, текст; отдельно могут действовать права исполнителя и изготовителя фонограммыРазрешение композитора не обязательно закрывает права на готовую запись
Название и логотипЛоготип; название, если оно само отвечает условиям авторско-правовой охраны; отдельно — товарный знакРегистрация названия как товарного знака не передаёт права на содержимое игры

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

Вдохновиться можно, скопировать чужое воплощение рискованно

Сделать свою игру о выживании в заброшенном городе — нормальная отправная точка. Взять из другой игры узнаваемые изображения, диалоги, музыку или код и слегка их переделать — уже другая история. Референс не становится свободным материалом только потому, что вы назвали его референсом.

Безопасного процента изменений не существует. Правила «перерисуем на 30 процентов» или «поменяем цвета и имя» не дают юридической гарантии. Оценивают конкретные заимствования и то, какие охраняемые элементы использованы. Указать автора полезно, но само по себе это не заменяет разрешение.

Показательный зарубежный пример — Tetris Holding против Xio Interactive. В решении от 30 мая 2012 года американский суд признал нарушение при создании игры Mino. Спор касался не монополии на идею падающих блоков, а копирования конкретного визуального воплощения Tetris. Даже отсутствие дословно скопированного исходного кода не решило проблему. Это решение суда США, но практический вопрос универсален: вы заимствуете идею или воспроизводите чужую творческую работу? [2]

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

2. Команда ещё не означает общее право на всю игру

Здесь важно различать автора и правообладателя. Автор — человек, который создал произведение своим творческим трудом. Правообладателем исключительного права может стать другой человек или компания: например, по договору или по правилам о служебных произведениях. Покупатель прав не становится автором вместо художника или программиста [1].

Несколько авторов и несколько результатов

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

Соавторство возникает, когда произведение создано совместным творческим трудом. Например, несколько людей вместе пишут сценарий или создают программу. Тогда нужно разбирать, что именно они создали совместно, какие части имеют самостоятельное значение и как договорились об использовании результата. Само присутствие в чате команды соавтором не делает. Это следует из статьи 1258 ГК РФ и пункта 83 постановления Пленума ВС РФ № 10 [1, 3].

Организатор и инвестор

Человек, который придумал бизнес-модель, собрал команду, оплатил работу и организовал релиз, не становится автором кода и графики только благодаря этим действиям. Организационная, техническая или материальная помощь сама по себе авторства не создаёт.

При этом организатор вполне может собрать необходимые права у себя или у компании. Для сложных объектов, в том числе мультимедийных продуктов, закон предусматривает договорное приобретение прав на включаемые результаты. Но фраза «я продюсер, значит, всё принадлежит мне» эту работу не заменяет. Для конкретной игры проверяем состав объектов и применимость статьи 1240 ГК РФ [1].

Работа по дружбе

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

Безвозмездную передачу прав или лицензию можно оформить, если такая конструкция допустима для сторон. Безвозмездность нужно прямо согласовать. Отдельное ограничение: безвозмездное отчуждение исключительного права между коммерческими организациями запрещено; для некоторых безвозмездных исключительных лицензий между ними тоже есть запрет. Поэтому шаблон «друг подарил рисунок» нельзя механически переносить на отношения двух студий [1].

Работа за процент

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

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

Как собирается цепочка прав

У проекта могут одновременно быть собственные исключительные права и лицензии на чужие компоненты.

Авторы командыКод · персонажи · сценарий · музыка
Сторонние компонентыДвижок · библиотеки · стоковые ассеты
Договоры о правах
или служебный характер работы
Лицензии
с конкретными ограничениями
Права для проектаИсключительное право или достаточная лицензия — по выбранной модели
Разрешённое использованиеИсключительное право сохраняется у владельца компонента
Проверяем, что полученный объём позволяет следующую сделку
Договор с издателемТолько те права и способы использования, которыми проект вправе распоряжаться
Передача файлов, денег или доступа к репозиторию сама по себе эту цепочку не заменяет.

3. Зачем разбираться с правами до релиза

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

Если права не собраны, сделку могут отложить. Спорный ассет придётся заменить. Переговоры с ушедшим участником займут время, которого перед релизом уже нет. А иногда человека просто невозможно найти.

В практике Silver Knight были обращения, когда с правами приходили разбираться уже после того, как работа была сделана. Названия проектов и участников я не раскрываю: такие задачи ведутся под NDA. В подобных ситуациях многое зависит от сохранившихся договорённостей и готовности людей договариваться. Нельзя обещать, что любое отсутствие документов получится исправить одним актом задним числом.

Договор нужен и исполнителю. Он фиксирует, что именно нужно сделать, сколько правок входит в стоимость, когда заплатят, что можно оставить в собственном наборе инструментов и когда результат разрешено показать в портфолио.

4. Какой договор нужен с фрилансером

В первую очередь смотрим, что уже существует, что предстоит создать и кто будет создавать результат. Налоговый статус проверяем следующим шагом: он важен для расчётов, но сам по себе не определяет способ передачи прав.

СитуацияРабочая конструкцияЧто обязательно уточнить
Автор уже создал нужный код, рисунок или музыкуОтчуждение исключительного права либо лицензияКакой именно результат передаётся, объём прав, цена и момент перехода
Физическое лицо лично создаст произведение по вашему заданиюАвторский заказ с условием об отчуждении права либо лицензииЗадание, срок, результат, порядок сдачи и права заказчика
Автор работает как ИП или самозанятыйАвторский заказ также подходит, если результат лично создаёт этот авторДополнительно — статус, налоги, документы об оплате
Разработку делает студия с командойДоговор на создание произведения по заказу, при необходимости смешанныйПрава самой студии от работников и подрядчиков, передача заказчику
Результат создаёт сотрудникТрудовые документы и правила о служебных произведенияхТрудовая функция, связь результата с работой, передача работодателю, вознаграждение
Основатели вместе создают проектСоглашение о совместной работе плюс необходимые договоры о правахУправление, использование результатов, деньги и выход из проекта

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

Если результат уже готов

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

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

В лицензии проверяем способы использования, срок, территорию, исключительность, возможность переработки и выдачи сублицензии. Разрешение «использовать в игре» может не закрыть трейлер, отдельный саундтрек, мерч, сиквел или передачу прав издателю. В обычной лицензии без указанной территории по общему правилу действует территория России, а без срока — пять лет. Для включения произведения в сложный объект есть специальные правила статьи 1240: при отсутствии иных условий лицензия действует на весь срок исключительного права и на всю территорию его действия. Лучше согласовать нужный объём прямо, а не выяснять перед международным релизом, какое правило применимо [1].

Передать можно только те права, которые у передающего действительно есть. Покупка художником ассета в магазине обычно не даёт ему права отчуждать вам исключительное право на этот ассет.

Если результат ещё создаётся

Когда вы заказываете произведение непосредственно его автору, базовая конструкция — авторский заказ по статье 1288 ГК РФ. Сразу включаем условие о передаче исключительного права или о лицензии. Одна обязанность «разработать и передать файлы» не заменяет условия о правах.

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

У заказа студии другая логика. По статье 1296 ГК РФ право на специально создаваемое по заказу произведение по общему правилу принадлежит заказчику, если договором не установлено иное. Но эта статья прямо не применяется, когда исполнителем выступает сам автор. А если создание произведения вообще не было предметом договора, может работать другая конструкция — статья 1297. Поэтому полагаться на правило «я заплатил, закон всё передал мне» опасно [1].

На практике удобен один договор на длительное сотрудничество, а конкретные задачи и этапы оформляются предусмотренным в нём способом. Каждый раз переподписывать все общие условия не требуется.

Что меняет статус исполнителя

С обычным физлицом российской компании или ИП нужно проверить обязанности по НДФЛ и страховым взносам с учётом вида выплаты. Одной фразы «исполнитель платит все налоги сам» для снятия обязанностей заказчика недостаточно.

С самозанятым проверяем статус на дату расчёта, допустимость НПД для конкретного дохода и получаем чек. Чек подтверждает расчёт, но не заменяет договор о правах. Доход от работ или услуг для нынешнего работодателя либо бывшего работодателя, с увольнения от которого прошло менее двух лет, под НПД не подпадает. Это не общий запрет работать вместе, а ограничение налогового режима [4].

С ИП уточняем, действует ли он в рамках предпринимательской деятельности, как оформляются расчёты и применяется ли НДС. При работе со студией дополнительно проверяем, как она получила права от людей, которые фактически создают результат.

И ещё: если человек фактически работает как штатный сотрудник, одно название «фрилансер» или статус НПД не устраняют риск признания отношений трудовыми [4].

5. О чём договориться до первой задачи

Вот минимальные вопросы, на которые должен отвечать договор с учётом конкретного проекта.

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

Что входит в передачу. Сборка, исходный код, редактируемые макеты, модели, текстуры, документация, ключи доступа в необходимом объёме. Получить исходники и получить права — две отдельные задачи, обе нужно закрыть.

Какие права и когда получает заказчик. При создании, передаче результата, приёмке или полной оплате — момент выбирают осознанно. Если переход привязан к оплате, заранее определите, на каком основании команда тестирует и интегрирует результат до неё. Для зарегистрированной в Роспатенте программы переход исключительного права требует государственной регистрации [1].

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

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

Можно ли привлекать других людей. Если да, кто оформляет с ними права и какие подтверждения предоставляет. Гарантия студии полезна, но при значимом проекте разумно проверить и саму цепочку договоров.

Какие чужие компоненты допустимы. Для кода — зависимости и лицензии, для графики и музыки — источник покупки и ограничения. Open source не означает «можно без условий»: могут требоваться уведомления, указание авторства или предоставление исходного кода в предусмотренных лицензией случаях. Проверяем конкретную лицензию и способ использования.

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

Как указывают автора и меняют произведение. Право авторства и право на имя не продаются вместе с исключительным правом. Согласуйте титры, псевдоним или использование без указания имени, допустимые изменения и переработки в пределах закона. Формулировка «автор отказывается от всех личных прав» не работает [1].

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

6. Как договориться с соавторами и основателями

Если вы вместе строите проект, одного распределения задач мало. Обсудите, кто будет заключать договор с издателем, получать выручку и управлять правами. Пока «команда» не оформлена как юридическое лицо, само это слово не обозначает отдельного правообладателя.

Возможны разные модели: права собираются у компании; у одного участника с обязательствами перед остальными; либо остаются у нескольких правообладателей с согласованным порядком использования. Последний вариант требует особенно внимательного регулирования: использование произведения и распоряжение исключительным правом — не одно и то же.

Например, соавторы по общему правилу используют совместное произведение вместе, если не договорились иначе. А когда исключительное право принадлежит нескольким лицам, распоряжаться им — например, передавать его издателю или выдавать лицензию — по общему правилу нужно совместно. Поэтому один участник не всегда может подписать такую сделку за весь проект.

Практически стоит договориться о следующем:

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

Особенно полезно убрать неопределённость вокруг ухода. Если права уже надлежащим образом переданы, выход из команды сам по себе не возвращает их автору. Но основания прекращения договора, судьбу неоплаченных этапов и будущих выплат нужно проверить отдельно. Договор не должен обещать абсолютную неотменяемость там, где закон допускает защиту нарушенных прав автора.

Если вы создаёте ООО, корпоративный договор может помочь договориться об управлении и долях. Но он сам по себе не заменит передачу компании кода, который основатель написал до её регистрации.

7. Если разработчики в штате

По общему правилу исключительное право на служебное произведение принадлежит работодателю, если договором не предусмотрено иное. Ключевое слово — служебное: произведение должно быть создано в пределах установленных трудовых обязанностей работника [1, 3].

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

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

Отдельно урегулируйте авторское вознаграждение в случаях, предусмотренных статьёй 1295 ГК РФ. Зарплата за труд и такое вознаграждение имеют разные основания. Условия можно согласовать в трудовом или другом договоре с работником, но нельзя просто предположить, что любая зарплата автоматически закрыла этот вопрос.

Есть и правило трёх лет: если в течение трёх лет со дня, когда произведение было предоставлено в распоряжение работодателя, он не начнёт его использовать, не передаст исключительное право другому лицу и не сообщит автору о сохранении произведения в тайне, исключительное право возвращается автору. Это не означает, что обязательно нужно успеть выпустить игру: использование произведения не ограничивается коммерческим релизом. Важно фиксировать не только создание, но и дальнейшую судьбу результата [1].

8. Можно ли обойтись без акта на каждый коммит

Да, можно организовать работу разумнее. Закон не устанавливает общего требования подписывать отдельное бумажное служебное задание и акт на каждый рисунок, коммит или спринт.

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

Задания в трекере

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

У задачи сохраняют описание результата, исполнителя, сроки и историю изменений. Сдачу привязывают к файлам и версии: например, к конкретному pull request, коммиту или архиву. Если исполнителей несколько, важно видеть их вклад.

Приёмка и электронные подписи

С подрядчиком можно согласовать электронный акт, отчёт по этапу или понятную процедуру приёмки в системе. Если используете приёмку по истечении срока без замечаний, нужно определить способ доставки результата, срок проверки и порядок мотивированного отказа. Сам по себе статус Done ещё не доказывает юридическую приёмку.

Для гражданско-правовых договоров доступны электронный документооборот и электронные подписи, включая простую подпись при соблюдении требований закона и соглашения сторон. Важно установить, чьё сообщение считается подписанным документом, как проверяется отправитель и как защищаются средства подписи. Скриншот переписки может быть доказательством, но это не универсальная замена правильно оформленной письменной сделке [5].

У сотрудников есть отдельные правила кадрового электронного документооборота, а у дистанционных работников — специальные нормы взаимодействия. Положение о задачах в трекере не превращает его автоматически в систему КЭДО и не отменяет требования к обязательным трудовым документам. Требования к бухгалтерским первичным документам тоже нужно выполнять [6].

Простой вариант для небольшой команды

Один договор на сотрудничество, задачи в согласованной системе, а раз в месяц или по этапу — один электронный документ с перечнем результатов и версиями. К нему прикладывается реестр сторонних компонентов и использования ИИ. Момент перехода прав заранее определён в договоре.

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

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

Оформление в ритме разработки

Договор задаёт правила, а обычные рабочие действия сохраняют доказательства.

До стартаДоговориться

Права, деньги, исходники, выход из команды. Разрешённые инструменты ИИ и сторонние материалы.

Каждый этапЗафиксировать

Задачи, авторов, версии и приёмку. Проверить условия перехода прав и сохранить документы.

Перед релизомПроверить цепочку

Договоры, лицензии и платежи. Условия издателя, заявления площадкам и сведения об ИИ.

Если участник уходитОтдельное событие

Определить судьбу незавершённых результатов, прав и выплат. Сохранить файлы и историю работы под контролем проекта.

Уход участника может произойти на любом этапе и требует отдельной проверки.

9. Что меняется, если команда использует нейросети

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

Оплаченная подписка не гарантирует исключительных прав

По российскому праву автором признаётся человек, создавший результат творческим трудом. Поэтому авторская работа с ИИ как вспомогательным инструментом и почти нетронутая машинная генерация — разные ситуации. Для результата с ИИ нужно отдельно оценивать человеческий творческий вклад [1].

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

Договор может ограничить повторное использование материала исполнителем и установить конфиденциальность. Но такие условия сами по себе не дадут исключительного права против всех остальных: если конкретная генерация не охраняется авторским правом, запретить её копирование третьими лицами только на основании этого договора не получится.

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

Для международного релиза это тоже существенно. В отчёте Copyright Office США от 29 января 2025 года разграничены человеческое творчество с помощью ИИ и полностью машинная генерация. Охраняться может вклад человека; одних запросов к существующим системам, по позиции ведомства, обычно недостаточно. Это американский подход, который нельзя автоматически переносить на все страны [7].

Что включить в договор и правила команды

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

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

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

Проверка результата. Нужны проверка заметных заимствований и лицензий, обычное тестирование кода и проверка безопасности. Обещание «это придумала нейросеть» не освобождает от ответственности за использование чужого материала. При этом договор не должен требовать заведомо невозможного — например, доказать состав всей обучающей выборки сторонней модели.

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

Замена проблемного материала. Заранее определите порядок уведомления, доработки или замены, сроки, распределение расходов и помощи при претензии. Для сотрудника и независимого подрядчика ответственность оформляется по разным правилам.

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

Отдельно проверьте синтез голоса и внешности реального человека. Разрешение использовать существующую запись не стоит автоматически считать разрешением обучать модель и генерировать новые реплики от имени актёра.

Как ИИ влияет на релиз в Steam

Действующая анкета Steam выделяет ИИ-контент, который входит в игру и воспринимается игроками: графику, звук, сюжетный текст, локализацию. Для контента, который генерируется во время игры, дополнительно нужно описывать меры против появления незаконного контента. Это не равнозначно требованию раскрыть вообще любое использование помощника для повышения эффективности разработки [8].

Практический вывод: сведения от исполнителей нужны до заполнения анкеты. Если руководитель проекта не знает происхождения материалов, он не может уверенно давать платформе или издателю заявления о них. Правила площадок проверяют повторно перед релизом: они меняются.

10. Реальные споры о правах на разработки

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

Medsenger и недоказанные права работодателя

ООО «Амедико» требовало защиты прав на программу Medsenger и взыскания 5 млн рублей с ООО «ТелеПат». Компания ссылалась на трудовые отношения с участниками разработки. Но суды не сочли доказанным, что спорная программа создана в рамках их трудовых обязанностей и права на неё принадлежат истцу. Суд по интеллектуальным правам оставил отказ в силе.

Это не правило «сотруднику принадлежит весь написанный им код». Вывод уже: работодателю нужно доказать служебный характер именно спорной разработки. Одного факта трудоустройства и использования ресурсов компании недостаточно.

Постановление СИП от 01.08.2019 № С01-446/2019, дело № А40-202764/2018 [9].

TeamJet и доказательства работы команды

В споре ООО «Тимджет» с компанией Teamatix FZ-LLC из ОАЭ стороны предъявили друг другу требования о правах на программный продукт. Российская компания представила документы об организации разработки и трудовых обязанностях; исследовались исходники и история репозиториев, проводилась экспертиза.

Девятый арбитражный апелляционный суд 11 октября 2024 года оставил в силе решение в пользу «Тимджет» и отказ по встречному иску. Для команды здесь полезна связка: документы об отношениях плюс доказательства фактического создания результата. Речь не о том, что любой репозиторий сам доказывает права, и не о том, что похожая функциональность автоматически означает копирование.

Постановление № 09АП-55254/2024, дело № А40-144779/2022. Здесь описан результат рассмотрения именно в указанной апелляционной инстанции [10].

Star Control и разные права внутри одной франшизы

В споре Stardock с создателями Star Control Полом Райком и Фредом Фордом выяснялись границы прав на известную серию. Исходный договор разделял авторские права создателя и права издателя на название и товарные знаки. Покупка Stardock соответствующих активов не устранила разногласия о содержимом игр.

В акте американского суда от 27 декабря 2018 года зафиксировано удаление спорных промоматериалов с площадок Valve и GOG после DMCA-уведомлений. Суд отказался заранее запретить новые уведомления. Это был вопрос обеспечительной меры, а не окончательное решение о принадлежности всего спорного контента. В июне 2019 года стороны объявили об урегулировании конфликта [11, 12].

Для разработчика вывод вполне прикладной: права на бренд, код, персонажей, музыку и отдельные части серии нужно проверять отдельно. Формулировка «мы купили франшизу» сама по себе не объясняет объём приобретения.

11. Если компания или часть команды за рубежом

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

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

Не стоит рассчитывать на универсальную фразу work made for hire. Её значение и условия применения зависят от юрисдикции, статуса исполнителя и вида работы. Там, где она не подходит, может потребоваться отдельная передача прав. Перевод российского шаблона на английский этих различий не устраняет.

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

12. Что делать, если игра уже готова, а документов нет

Шаг 1. Составить карту результатов. Кто написал код, нарисовал персонажей, сделал музыку и озвучку. Что куплено на стоках, взято из открытых библиотек или создано с помощью ИИ. Включить бывших участников и ранние версии, если их материалы остались в проекте.

Шаг 2. Собрать доказательства. Договоры, задания, платежи, переписку, исходники, историю репозитория, условия лицензий. Сохранить копии под контролем проекта. Регистрация программы полезна, но не заменяет действительной цепочки прав.

Шаг 3. Проверить, какие права уже есть. Не каждый пробел означает полное отсутствие прав. Например, может действовать правило о служебном произведении или заказе студии. Но вывод нужно делать по документам и фактическим отношениям, а не по ощущению «все же понимали».

Шаг 4. Оформить недостающее текущей датой. Для готовых результатов согласовать отчуждение или достаточную лицензию, точно перечислить объекты, урегулировать оплату и прошлое использование. Не подделывать даты: сегодняшняя подпись не доказывает, что письменный договор существовал год назад, и не всегда устраняет последствия прежнего использования.

Шаг 5. Решить судьбу спорных компонентов. Если договориться не получается или правообладатель неизвестен, оценить замену, исключение материала либо специальную правовую стратегию. Исчезновение автора не делает его работу свободной. Для ключевого кода сначала стоит оценить доказательства и варианты, а уже потом переписывать всё с нуля.

Шаг 6. Проверить договор с издателем и заявления платформам. Не обещать больше прав, чем действительно получено. Оставшиеся ограничения нужно устранить или корректно учесть в сделке.

Проверка перед релизом

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

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

Нормы и материалы для проверки

  1. Гражданский кодекс РФ, часть четвёртая: статьи 1228–1229, 1234–1236, 1238, 1240, 1258–1262, 1265–1266, 1270, 1288–1290, 1295–1297. Статья 1228 об авторстве и статья 1288 об авторском заказе.
  2. Tetris Holding, LLC v. Xio Interactive, Inc., дело № 09-6115, решение от 30.05.2012. Судебный акт, опубликованный Justia.
  3. Постановление Пленума ВС РФ от 23.04.2019 № 10, в частности пункты 83, 95, 104.
  4. ФНС о доходах от нынешнего и бывшего работодателя, ФНС о риске подмены трудовых отношений. Основа ограничения НПД — пункт 8 части 2 статьи 6 Федерального закона № 422-ФЗ; проверяется именно налоговый режим выплаты.
  5. Статьи 160 и 434 ГК РФ, часть первая; статьи 6 и 9 Федерального закона от 06.04.2011 № 63-ФЗ «Об электронной подписи».
  6. Статьи 22.1–22.3 ТК РФ, в том числе правила подписания электронных трудовых документов, и статья 312.3 ТК РФ о дистанционной работе; статья 9 Федерального закона от 06.12.2011 № 402-ФЗ «О бухгалтерском учёте».
  7. US Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability, 29.01.2025.
  8. Steamworks, Content Survey, раздел об ИИ. Проверено 12.10.2026.
  9. Постановление СИП от 01.08.2019 № С01-446/2019 по делу № А40-202764/2018. Полный текст судебного акта в системе ГАРАНТ.
  10. Постановление 9 ААС от 11.10.2024 № 09АП-55254/2024 по делу № А40-144779/2022. Полный текст судебного акта на СудАкт.
  11. Stardock Systems, Inc. v. Reiche and Ford, № C 17-07025 SBA, Document 102, 27.12.2018. Копия судебного акта об отказе в обеспечительной мере, страницы 1–3 и 20.
  12. Сообщение Stardock об урегулировании спора, 11.06.2019.
Silver Knight · Юридическая практика для IT и креативных проектовК началу ↑