Геймдев и open source: на что обратить внимание

С использованием открытого ПО (распространяемого на условиях открытой лицензии; open source) процесс разработки становится значительно проще и дешевле.

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

Главное - не забывать соблюдать описанные в тексте открытой лицензии требования.

И если правообладатель желает, чтобы его угостили пивом при встрече (Beerware license), нет повода не выполнить это условие лицензии:

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

Копилефтные: обязывают распространять производное ПО (в основе которого ПО на условиях открытой лицензии) на тех же условиях, которые предполагают сами копилефтные лицензии (здесь имеет место т.н. «вирусный эффект»). Такие лицензии могут накладывать на лицо, использующее открытое ПО, обязанность раскрывать исходный код производного ПО, например, Mozilla Public License, MPL; General Public License, GPL.

Разрешительные (пермиссивные): предоставляют лицензиату значительные права, в том числе право создавать производное ПО и распространять его на коммерческих условиях без какого-либо раскрытия исходного кода продукта. А также позволяют самостоятельно определять условия лицензирования. Взамен такие лицензии накладывают незначительные ограничения на лицензиата, например, обязанность указывать авторов открытого ПО. Примеры: Apache, Berkeley Software Distribution license, Massachusetts Institute of Technology license.

Если плюсы использования открытого ПО достаточно очевидны и к использованию этой волшебной палочки, порой превращающейся в костыли, не прибегал разве что только полностью отрезанный от Интернета разработчик, то как обстоят дела с минусами?

А самое главное, какие юридические риски несет использование ПО с открытым исходным кодом в своих игровых продуктах?

РИСК ПЕРВЫЙ: претензии правообладателей в связи с нарушением условий открытых лицензий, и аналогичные претензии (запреты) других участников игрового рынка

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

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

Разберём два относительно свежих кейса*, которые иллюстрируют такие последствия.

Спор ChessBase GmbH и Stockfish

Stockfish – шахматный движок, который распространяется по копилефтной лицензии GPL 3.0. Разработчиками Stockfish было обнаружено, что немецкая компания ChessBase GmbH включила код шахматного движка Stockfish в свои коммерческие игровые продукты Fat Fritz 2 и Houdini 6.

Нарушив условия открытой лицензии, компания ChessBase GmbH не раскрыла исходный код своего продукта и не проинформировала пользователей об использовании кода под лицензией GPL 3.0.

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

1. был признан факт нарушения лицензии со стороны ChessBase;
2. в течение года после заключения соглашения ChessBase не имела права распространять или делать публично доступными программы, в которых использован движок Stockfish. По истечении года компания получила возможность использовать движок и распространять свои производные игровые продукты строго на условиях GPL 3.0. Если бы запрет был нарушен, ChessBase выплатила бы штраф в пользу Европейского фонда свободного программного обеспечения;
3. ChessBase обязана разместить на своём сайте информацию о распространении Fat Fritz 2 и Houdini 6 на условиях GPL 3.0.

Информация о соглашении опубликована на сайте Stockfish.

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

Исключение игры Only Up! из перечня доступных на игровой платформе

В прошлом году обсуждался кейс об удалении игры Only Up! (разработчик – SCKR Games) из Steam в связи с нарушением разработчиком условий открытой лицензии (Creative Commons) на 3D-модель девушки, созданной и опубликованной на Sketchfab пользователем Aboulicious.

Aboulicious одобрил только некоммерческое использование 3D-модели, но SCKR Games включила её в коммерческий проект.

Такое нарушение стало причиной удаления Only Up! из Steam. Однако через непродолжительное время страница игры вернулась обратно. Подробнее об этом можно почитать здесь.

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

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

РИСК ВТОРОЙ: правомерное использование опенсорса (как ни странно)

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

Описанная ситуация чуть не произошла с известной игрой Dungeons & Dragons^®. Исторически, игра распространяется под открытой лицензией Open Gaming License (OGL), которая допускает создание сторонних игр на основе оригинальной D&D, но взамен требует распространять такие игры под той же OGL (стандартный принцип копилефта).

Однако в конце прошлого года правообладатель игры Wizards of the Coast предпринял попытку внести существенные изменения в текст лицензии, которые давали бы ему больший контроль над сторонними играми и материалами на основе D&D. В частности, планировалось начать взимать роялти в размере 25% с создателей материалов в случае, если их годовая прибыль превышает 750 тысяч долларов. Предполагалось осуществить принудительный переход на новую лицензию путём прекращения поддержки предыдущей версии.

В ответ последовала масштабная критика со стороны поклонников игры. Под таким давлением Wizards of the Coast принял решение не пересматривать существующую лицензию.

РИСК ТРЕТИЙ: невозможность включить свой игровой продукт в реестр российского ПО

Если говорить только о российских реалиях, то здесь помимо вышеописанных рисков возникает вопрос о допустимости использования открытого ПО в игровых продуктах, которые заявлены на включение в Единый реестр российских программ для ЭВМ и баз данных (реестр российского ПО).

Для игрового продукта включение в реестр ПО даёт право на получение налоговой льготы в виде освобождения от НДС при предоставлении лицензии (лицензия, SaaS и т.д.) на игровой продукт на территории РФ или при отчуждении прав на игровой продукт.

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

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

1. копилефтные открытые лицензии (компоненты, которые распространяются под пермиссивными открытыми лицензиями, включать в игровой продукт допустимо);
2. проприетарные лицензии (как минимум, те лицензии, которые запрещают включение компонента в состав вашего (производного) ПО);
3. любые лицензии, которые запрещают использование компонента на отдельных территориях (например, на территории Республики Крым и г. Севастополя).

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

По статистике Минцифры, несоответствие указанным требованиям является самой частой причиной отказа во включении ПО в реестр.

А что с санкциями?

Обойти стороной известную всем (но, возможно, не в контексте открытого ПО) тему санкций было бы нерационально. С одной стороны, санкции – тоже риск, с другой – реальность, с которой приходится мириться.

Ограничениями в использовании российскими компаниями открытого ПО в связи с иностранными санкциями (в первую очередь со стороны США) могут быть:

1. запреты использования на территории РФ, предусмотренные условиями открытых лицензий;
2. блокировки, которые могут быть применены внутренними средствами самого ПО, например, ограничения использования ПО с российских аккаунтов, недоступность обновлений ПО;
3. запрет на доступ российских компаний к иностранным репозитариям открытого ПО.

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

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

Известным случаем стала блокировка в 2022 г. со стороны GitHub аккаунтов российских разработчиков открытого ПО, включая попавших под санкции аккаунты Сбербанка и Альфа-Банка. В отрасли были обсуждения полной блокировки использования функционала GitHub российскими пользователями.

Чтобы подстраховаться от вероятного отключения российских разработчиков от иностранных репозиториев и в качестве альтернативы GitHub, Минцифры анонсировало создание Национального репозитария открытого кода – 10 октября 2022 г. было принято соответствующее Постановление Правительства. Предполагается, что «российский GitHub» будет создан до 30 апреля 2024 года.

Другими способами «подстраховки» стало создание АНО «Открытый код» (учредители – Вконтакте, Ростелеком и другие крупные игроки рынка). Его цель – «создание, поддержание и развитие экосистемы разработчиков и пользователей системного и прикладного программного обеспечения с использованием принципов открытого исходного кода», а также создание государственной открытой лицензии (с текстом лицензии можно ознакомиться тут). Лицензия не требует распространять производное ПО на условиях аналогичных условиях (не является копилефтной).

* * *

Ещё раз сформулируем основной момент, на который хотелось бы обратить особое внимание: открытое ПО – это благо, но использовать его нужно осознанно и осторожно.

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

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