05/11/2019

Кому принадлежит ваша игра?

Итак, вы сделали это! Вашей команде удалось создать что-то по-настоящему крутое и многообещающее, теперь вы готовы опубликовать игру и встать на путь неминуемой монетизации. А вы уверены, что ваша игра (или, говоря сухим слогом юриста, игровой программный продукт) действительно ваша, и у Компании есть права ее опубликовать и уж тем более беспрепятственно зарабатывать?

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

Для начала ответим на вопрос – кто создал игру? МЫ! – первое, что срывается с языка при ответе. Но "мы" — это команда экспертов, каждый из которых отвечает за соответствующий "участок". Именно из таких "участков" позднее и будет создан игровой программный продукт.

Чтобы разместить игру на платформе, Компания должна подтвердить, что не нарушает прав третьих лиц при размещении игры. Для этого нужно указать на каком основании размещается игра: (i) на основании купленной лицензии (тут все просто — присутствует лицензионный договор, дающий право размещать чужую игру); или (ii) Компания сама является собственником игры, являясь ее разработчиком.

В последнем случае как раз и могут скрываться подводные камни. Утверждать, что компания является собственником можно в случае, если все "участки" игрового программного продукта принадлежат Компании и, как следствие, вся игра целиком. Зафиксировать это можно несколькими способами в зависимости от вашего "производственного процесса":

1. Игра полностью создана силами сотрудников Компании (ключевое слово тут – сотрудник, то есть лицо, работающее на основании трудового договора).

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

Казалось бы, очень просто, но на практике часто должностные обязанности сотрудников описаны очень скупо и не позволяют сделать однозначный вывод о том, что созданное сотрудником произведение (арт, код) создано именно в рамках выполнения им своих обязанностей, а не в свободное от работы время в порядке саморазвития.

Решить это можно либо посредством регулярного мониторинга и апдейта должностных инструкций членов вашей команды, либо посредством формирования так называемых служебных заданий. Служебное задание — это что-то вроде внутреннего "договора" с сотрудником. В нем вы описываете желаемый результат (ТЗ) и вручаете сотруднику его под роспись, а по истечение срока для выполнения служебного задания получаете результат работ, сданный вам по акту. Как раз акт приема передачи результатов и представляет собой документ, оформляющий полную передачу прав на созданное от сотрудника к Компании. На практике, такие служебные задания и соответствующие акты могут быть привязаны либо ко временным периодам (например, раз в квартал), либо к периодам завершения определенного существенного этапа проекта.   

2. Игра создана с привлечением сторонних разработчиков (которые предпочли сотрудничать с вашей Компанией как фрилансеры или через свое ИП/ООО).

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

Таким образом, внимание к документам на этапе сборки игры позволит избежать спора в отношении прав на отдельные элементы игры (например, art, механики). Неопределенность в правах на игру (и/или ее составные элементы) может привести к требованиям по возмещению части получаемого дохода от такой игры.   

* * *

Этот материал был бы неполным без упоминания соглашения о конфиденциальности — NDA или же соглашение о неразглашении. 

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

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

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

Успешность защиты прав напрямую зависит от способности доказать (проще говоря — рассчитать), какой убыток был понесен ввиду такого разглашения. На практике проблемы как раз возникают на моменте расчетов сумм убытков и установлению связи этих убытков с разглашением. Тем не менее, NDA как минимум играет роль "джентльменского соглашения", фиксирующего реальные намерения сторон сохранить в тайне свое сотрудничество и предмет договора. Лучше позаботиться о его наличии.

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

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

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

Звучит фантастически только на первый взгляд. В действительности же такому разработчику для начала спора достаточно иметь свидетельства сотрудничества с вами (трудовой договор, к примеру) и созданные им в этот период материалы (часть кода, арт), а также указать на отсутствие передачи прав, равно как и на отсутствие согласия на размещение игры. Требованием в данном случае может быть компенсация за размещение с нарушением прав, равно как и запрет на дальнейшее размещение без согласия соавтора. 

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

Помните об указанных рисках и не омрачайте свой долгожданный успех! Удачи! 

Recent Posts

Терпение, труд и Backbone

07/11/2019
О Backbone не слышал только ленивый. Детективная игра с элементами стелса в сеттинге антиутопичного Ванкувера. Рассказываем, как пиксельная игра в оболочке Unreal Engine шагает к успеху.

Разработка мультиплеера на Blueprints. Часть 2

28/10/2019
Продолжаем разговор — типы серверов, game mode, инструменты, классы, разработка фич, репликация виджетов, сетевая оптимизация.

Разработка мультиплеера на Blueprints. Часть 1

28/10/2019
Разработчик проекта Greed делится не только выработанными приемами, но и ошибками, которые совершил во время работы с сетью.