Open source часто воспринимают как “бери и используй”.
❓На практике все сложнее: открытый код не означает отсутствие ограничений. У каждого open source компонента есть лицензия, и именно она определяет, что можно делать с ним в коммерческом проекте.
Если вы берете open-source код, плагин или библиотеку, важно проверить не только техническую совместимость, но и условия лицензии.
Open-source лицензии обычно делят на три группы.
1. Пермиссивные лицензии
*️⃣Например: MIT, BSD, Apache 2.0.
Обычно это самый удобный вариант для коммерческих проектов: код можно использовать, менять и включать в закрытый продукт. Но базовые требования все равно остаются: например, сохранить copyright notice, текст лицензии, иногда - уведомления об изменениях.
2. Слабый копилефт
*️⃣ Например: LGPL, MPL.
Такие лицензии обычно не требуют открывать весь код игры, но могут накладывать условия на сам open source компонент.
Например, если вы меняете этот компонент, изменения часто нужно раскрывать на тех же условиях. А для LGPL может быть важно, как именно библиотека подключена к проекту.
3. Сильный копилефт
*️⃣ Например: GPL, AGPL.
Здесь риски выше. Если такой компонент становится частью игры, при распространении продукта может возникнуть обязанность раскрыть исходный код под совместимой лицензией. Для коммерческого проекта это может затруднить продажу игры: придется либо соблюдать условия копилефта, либо срочно заменять компонент до релиза.
💻 Отдельный риск - реестр российского ПО
Если команда планирует включать продукт в реестр российского ПО, open source компоненты нужно проверять еще внимательнее. Их лицензии не должны мешать подтверждению прав на продукт и его коммерческому использованию.
Поэтому копилефтные лицензии лучше обнаруживать заранее, они могут создать дополнительные вопросы к правам на продукт и условиям его распространения.
На что смотреть перед использованием open source в игре?
- 🔢Какая именно лицензия у компонента?
Не достаточно, что проект “лежит на GitHub”. Важно понять, это MIT, Apache, GPL, LGPL или другая лицензия. В большинстве репозиториев есть секция с информацией о лицензии. - 🔢Какие лицензии у зависимостей?
Зависимости - это сторонние библиотеки и модули, которые нужны компоненту для работы. Даже если сам проект под пермиссивной лицензией, внутри могут быть компоненты с более жесткими условиями. - 🔢 Где окажется open source код?
Некоторые лицензии почти не создают дополнительных требований при внутреннем использовании ПО. Но если тот же компонент включается в продукт и передается пользователям, условия могут стать гораздо строже. - 🔢 Что попадет в релиз?
Перед выпуском важно понять, какие open-source компоненты уходят вместе с игрой, лаунчером или другими файлами. Пермиссивные лицензии могут требовать сохранить текст лицензии и указание автора, а копилефтные - повлечь обязанности по раскрытию кода и ограничения на дальнейшее распространение продукта.
🔍Почему это важно?
Лицензионные риски при использовании open source вполне реальны - вспомним историю со ScummVM, open source движком под GPL для запуска классических adventure-игр.
ScummVM обнаружили, что их код оказался в нескольких Wii-релизах игр Humongous Entertainment, но условия GPL при этом соблюдены не были. По версии проекта, Atari заказала портирование через Majesco Entertainment, а разработкой занималась Mistic Software.
До суда дело не дошло, но “без последствий” тоже не получилось: Mistic Software пришлось оплатить юридические издержки ScummVM и сделать пожертвование в пользу Free Software Foundation.
💡 Вывод простой: open source хорошо работает, когда команда понимает, что именно использует и на каких условиях. Проверка лицензий до релиза помогает избежать лишних расходов, срочных переделок и неожиданных претензий.
#iLegal_in_GameDev #Open_Source
