Open Source лицензии и ограничения

1) Зачем OSS в iGaming и где риски

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

2) Карта лицензий: типы и смысл

2.1 Permissive (разрешительные)

MIT, BSD-2/3-Clause, Apache-2.0

Основная обязанность — сохранить уведомление/копирайт, в Apache-2.0 еще и патентный грант + «defensive termination».
Подходит для: UI-фреймворков, утилит, SDK-клиентов, библиотек логирования/HTTP.

2.2 Weak copyleft (слабый копилефт)

MPL-2.0, LGPL-2.1/3.0

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

2.3 Strong copyleft (сильный копилефт)

GPL-2.0/3.0, AGPL-3.0

При «соединении» с вашим кодом возникает обязанность раскрытия производного произведения под той же лицензией (условия «tivoization», «SaaS-замыкание» закрывает AGPL).
Риск для закрытых модулей игрового ядра, антифрода, платежных шлюзов.

3) Линковка и «производное произведение» (упрощенно)

Статическая линковка с GPL → высокий риск «заражения».
Динамическая линковка с LGPL → обычно допустима при соблюдении условий (заменяемость, уведомления).
IPC/REST/gRPC, отдельные процессы → снижает риск производности, но не отменяет анализ (AGPL трактует «через сеть» как «соединение»).
Плагины/скрипты → оцениваются по фактической интеграции (API-стабильность, загрузка в адресное пространство).

4) Патенты и оговорки

Apache-2.0 дает лицензирование патентов автора → снижает риск патентных претензий.
GPL-3.0/AGPL-3.0 имеют анти-патентные/анти-circumvention положения.
Если ваш модуль — патентно значимый (RNG-математика, антифрод-алгоритмы) — избегайте лицензий без патентного гранта или добавляйте отдельные патентные ковенанты в коммерческие соглашения.

5) Обязанности по OSS: что именно делать

Сохранить уведомления/NOTICE (permisisve).
Раскрыть модификации копилефт-компонентов (MPL/LGPL/GPL) и способ пересборки.
Предоставить исходники при распространении бинарников под GPL/LGPL (и сетевой доступ под AGPL).
Указать лицензию в окошке «О программе»/странице «OSS Credits».
Отслеживать third-party лицензии в поставках (вендоры игр/SDK/мобильные билды).

6) Политика OSS для платформы (рекомендуемый минимум)

1. Классификация лицензий: зеленые (MIT/BSD/Apache/MPL), желтые (LGPL при условиях), красные (GPL/AGPL/SSPL для закрытых частей).
2. Процесс допуска компонента: запрос → юридическая и техоценка → запись в SBOM → периодический аудит.
3. Изоляция копилефта: отдельный процесс/микросервис, gRPC/HTTP граница, нет статической линковки.
4. SBOM по сборке: для каждого релиза prod/stage.
5. Уведомления и исходники: автоматическая генерация NOTICE/THIRD-PARTY и публикация исходников там, где нужно.
6. Вклады (upstream): CLA/DCO, проверка отсутствия секретов/патентов, согласование с Legal.
7. Security: скан уязвимостей, политика патчей, запрет «pin» уязвимых версий без waiver.

7) OSS в типичных зонах iGaming (best practice)

Игровая математика/RNG: избегать GPL/AGPL; предпочесть собственный код или permissive-библиотеки.
UI/клиент: React/Vue/бандлеры — permissive → ок, следить за лицензиями и шрифтами.
Платежи/KYC: SDK вендоров со строгими ToS; не смешивать с копилефтом.
Обсервабилити/DevOps: Prometheus/Grafana/Elastic — учитывать их лицензии (часть модулей не-OSS); читать «server side» условия.
Антифрод/скоринг: модель/правила — проприетарно; сторонние либы — permissive/MIT/Apache.

8) Таблица совместимости (вкратце)

9) Матрица рисков (RAG)

10) Чек-листы

Перед добавлением библиотеки

• Лицензия библиотеки в «зеленом/желтом» списке.
• Проверена совместимость линковки (static/dynamic/IPC).
• Запись в SBOM + версия + источник.
• Сгенерированы уведомления (LICENSE/NOTICE).

Перед релизом

• SBOM на сборку сохранен (prod/stage).
• Скан уязвимостей пройден; критичное — закрыто или waiver.
• Требуемые исходники/патчи готовы к выдаче (если нужны).
• «OSS Credits»/About страница обновлена.

Для вкладов (contributions)

• CLA/DCO подписан.
• Review на отсутствие секретов/патентов.
• Авторские права/копирайт корректно проставлены.

11) Политика OSS (фрагменты)

11.1 Классификация

green:  [MIT, BSD-2, BSD-3, Apache-2. 0, MPL-2. 0]
amber:  [LGPL-2. 1, LGPL-3. 0] # speaker only/IPC + conditions red: [GPL-2. 0, GPL-3. 0, AGPL-3. 0, SSPL] # disallow for closed modules

11.2 Процесс допуска

request → legal+tech review → approve/deny → SBOM entry → periodic audit

11.3 Изоляция копилефта

Отдельный сервис, сетевой интерфейс, нет объединения бинарей, нет статической линковки.
Документация по сборке и обновлению библиотек (LGPL/MPL).

12) Реестры (YAML-шаблоны)

12.1 SBOM / third-party

yaml component: "rng-core-utils"
version: "1. 8. 2"
license: "Apache-2. 0"
source: "maven:com. example:rng-core:1. 8. 2"
linkage: "dynamic"
notices: ["apache-2. 0. txt"]
security:
cvEs: []
owner: "Engineering"
approved_by: ["Legal","Security"]
approved_at: "2025-11-05"

12.2 OSS-исходники к раскрытию

yaml package: "lgpl-math-lib"
our_version: "2. 3. 1-gamblehub"
license: "LGPL-3. 0"
modified_files: ["matrix. c","fft. c"]
public_src_url: "https://example. com/oss/lgpl-math-lib-2. 3. 1-src. zip"
build_instructions: "BUILD. md"

12.3 Реестр вкладов (upstream)

yaml project: "open-telemetry"
pr: 4521 author: "dev_a"
cla: true dco: true files: ["exporter. go"]
review_legal: "2025-10-28"
status: "merged"

13) Безопасность и соответствие

SCA/SAST в CI, автоскан новых зависимостей.
Политика патчей: P1 уязвимости — ≤72 ч, P2 — ≤14 дней.
Кэш артефактов: храните исходные LICENSE/NOTICE; проверяйте целостность (хэши).
Экспорт/санкции: не используйте компоненты/зеркала из запрещенных стран; логируйте проверки.

14) Плейбуки (операционные сценарии)

P-OSS-01: Обнаружен GPL в закрытом модуле

Инвентаризация связей → вариант изоляции/замены → юридическое заключение → релиз-фикс → ретро по процессу.

P-OSS-02: Требование исходников

Определить объем обязательств → подготовить архивы и NOTICE → передать в законный срок → обновить документацию.

P-OSS-03: Критическая уязвимость в зависимости

Бэкпорт/обновление → внеочередной релиз → уведомление заинтересованных → пост-морем и правила пиннинга.

15) Мини-FAQ

Можно ли использовать LGPL? Да, при динамической линковке/IPC и соблюдении условий (заменяемость, уведомления).
AGPL на сервере без распространения бинаря — безопасно? Нет: AGPL требует предоставить исходники пользователям, взаимодействующим с сервисом по сети.
Нужен ли патентный грант? Желателен для модулей c алгоритмическими новациями; Apache-2.0 предпочтительнее.
Достаточно указать OSS на сайте? Нет, выполните все требования: уведомления, исходники, инструкции.

16) Заключение

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