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-клієнтів, бібліотек логування/НТТР.
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 → ок, стежити за ліцензіями і шрифтами.
Платежі/КУС: 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 modules11. 2 Процес допуску
request → legal+tech review → approve/deny → SBOM entry → periodic audit11. 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 вимагає надати вихідні дані користувачам, які взаємодіють з сервісом по мережі.
Чи потрібен патентний грант? Бажаний для модулів з алгоритмічними новаціями; Apache-2. 0 краще.
Достатньо вказати OSS на сайті? Ні, виконайте всі вимоги: повідомлення, вихідні, інструкції.
16) Висновок
Робота з OSS - це процес, а не одноразова перевірка: стандарти допуску, ізоляція копілефту, автоматизовані повідомлення і повний SBOM на кожну збірку. Дотримуючись цієї статті, ви збережете швидкість розробки і уникнете юридичних пасток - від «мережевого копілефта» до патентних претензій.