Ліцензування софту та API

1) Навіщо це важливо для iGaming

Платформа спирається на власний код, сторонні бібліотеки, SDK провайдерів ігор/платежів і публічні/приватні API. Помилки в ліцензіях призводять до претензій, блоків інтеграцій, витоків IP і регуляторних ризиків (privacy/санкції/експорт криптографії). Мета - вибудувати прозорий контур прав: що можна публікувати, інтегрувати, передавати партнерам і як захищати власні API.

2) Моделі ліцензування ПЗ (огляд)

Proprietary (закрита ліцензія): ексклюзивні права у вендора; для B2B (оператори, студії, PSP).

• Permissive: MIT, BSD, Apache-2. 0 (патентний грант).
• Copyleft: GPL/LGPL/AGPL - «заражаюча» сумісність; обережно в закритих модулях.
• Dual/Multi-licensing: безкоштовна OSS-гілка + комерційна ліцензія з розширеними правами/підтримкою.
• SaaS ліцензування: доступ як сервіс; код не передається, права - на використання.

Правила вибору: критичні сервіси (ігровий рушій, антифрод, розрахунки) - уникати copyleft; UI-бібліотеки - permissive; внутрішні тулзи - можливий GPL при ізоляції.

3) Права та обмеження: на що дивитися в ліцензіях

Обсяг прав (scope): території, термін, користувачі/інсталяції, середовища (prod/stage/dev).
Модифікації та похідні: чи можна форкати, змінювати, поширювати.
Субліцензування/передача: чи допустимо для афіліатів/white-label.
Патентний грант і defensive termination (Apache-2. 0, MPL): патентні ризики та крос-ліцензії.
Аудит та звітність: право вендора проводити ліцензійні перевірки.
Безпека/експорт: обмеження на криптографію, країни/санкції.
Індемніті і відповідальність: хто покриває претензії ІС/збиток.

4) Open Source: політика і контроль

Білий список: MIT/BSD/Apache-2. 0, MPL-2. 0.
Жовтий: LGPL-3. 0 (при динамічному лінку і дотриманні умов).
Червоний: AGPL/GPL-3. 0 в закритих сервісах, якщо немає ізоляції (сервіс-межі, network copyleft).
SBOM (Software Bill of Materials): обов'язковий список залежностей з версіями/ліцензіями.
Процедура внесення OSS: запит → юр/тех-оцінка сумісності → фіксація в реєстрі → періодичний аудит.
Внесок в OSS (upstream): CLA/DCO, перевірка розкриття IP, узгодження з Legal.

5) SDK і ліцензії провайдерів (ігри, платежі, KYC)

Типові вимоги: заборона зворотної розробки, заборона кешування поза умовами, контроль логотипів/брендингу, мінімальні версії, audit-право.
Дані: межі «операторські дані» vs «дані провайдера», хто володіє метриками і Derived Data.
Експортні/санкційні обмеження: гео-блоки, списки РЕР/санкцій - обов'язкова перевірка в ToS/ліцензії.
Підтримка/оновлення: SLA на патчі, breaking-changes, терміни міграцій.

6) API: юридичні умови надання доступу (для партнерів/афіліатів/В2В)

• Доступ та автентифікація: OAuth2/HMAC/мутуал-TLS; заборона передачі ключів третім особам.
• Rate limits і квоти: RPS/хвилини/на добу; «чесне використання»; політика burst.
• SLA та підтримка: доступність (напр., 99. 9%), вікна обслуговування, план інцидентів/комунікацій.
• Версіонування/депрекація: SemVer, терміни EOL (наприклад, ≥ 9-12 міс), розсилка повідомлень.

• Service-Generated Data (логи, метрики) - у власника API;
• Customer/Player Data - у клієнта/оператора;
• Derived Data - за договором (дозволено/обмежено, анонімізація).
• Кеш і зберігання: що і як можна кешувати (TTL, заборона зберігання персональних/чутливих полів).
• Privacy/AML/KYC: ролі (контролер/процесор), DPA/DSA, транскордонні передачі, DPIA для high-risk сценаріїв.
• Безпека: шифрування в транзиті/ат-рест, секрет-менеджмент, вимоги до SOC2/ISO 27001 (якщо застосовується).
• Заборони: зворотна інженерія, скрейпінг, вимірювання/бенчмаркінг без згоди, модифікація відповідей API.
• Аудит і логи: право на перевірку, вимоги до журналів запитів.
• Санкції та експорт: заборона використання в країнах/з користувачами зі списків, screening.
• Виключення гарантій і ліміт відповідальності: cap (наприклад, 12 × середньомісячний. платіж).
• Припинення доступу: негайне при загрозі безпеці/законі; план виведення даних.

7) Політика версіонування та сумісності

SemVer: MAJOR (breaking), MINOR (features), PATCH (fix).
Контракти схем: JSON Schema/OpenAPI; contract-тести для клієнтів.
Deprecation-процедура: анонс → період сумісності (≥ 6 міс) → EOL → видалення; міграційний гайд.
Feature flags: для «м'яких» розкаток.

8) Експортний контроль, санкції, криптографія

Експорт криптографії: перевірка локальних правил; повідомлення/код ЕСС/бітові довжини.
Санкції: заборона обслуговувати/давати доступ резидентам підсанкційних юрисдикцій/осіб; періодичний рескринінг.
Відмовостійкість законодавства: клаузули про припинення сервісу при регуляторному ризику.

9) Матриця ризиків (RAG)

10) Чек-лист перед релізом/інтеграцією

• SBOM зібраний; ліцензії перевірені (несумісних немає).
• Вендор/SDK-ліцензії підписані; права на дані і бренд.
• DPA/DSA оформлені; ролі контролер/процесор визначені.
• API Terms/EULA оновлені; прописані rate limits/SLA/депрекація.
• Санкційний/експортний скринінг в процесах.
• Безпека: ключі, ротація, шифрування, журналювання.
• План інцидентів і відкликання доступу (killswitch) готовий.

11) Реєстри та артефакти (рекомендовані формати)

11. 1 SBOM/Реєстр ліцензій

yaml component: "payment-gateway-sdk"
version: "4. 2. 1"
license: "Apache-2. 0"
source: "maven"
usage: "runtime"
notes: "requires notice file"
dependencies:
- name: "okhttp"
version: "4. 12. 0"
license: "Apache-2. 0"
- name: "commons-io"
version: "2. 16. 1"
license: "Apache-2. 0"
owner: "Engineering"

11. 2 Реєстр API-клієнтів

yaml client_id: "aff-778"
app_name: "AffTrack"
scopes: ["reports:read","players:read_limited"]
rate_limit_rps: 5 quota_daily: 50_000 dpa_signed: true sanctions_screened_at: "2025-11-05"
status: "active"
owner: "API Ops"

11. 3 Registry SDK/вендорів

yaml vendor: "GameProviderX"
agreement: "SDK-License-2025-10"
audit_rights: true brand_rules: true data_rights:
provider_metrics: "vendor"
operator_metrics: "shared"
derived_data: "anonymized_allowed"
sla:
incidents: "P1:2h,P2:8h"
updates: "quarterly"

12) Шаблони (фрагменти)

12. 1 EULA (внутрішній фрагмент)

12. 2 API Terms (внутрішній фрагмент)

12. 3 Ліцензування приблизного коду/доків

13) Приватність і дані (API/SDK)

Мінімізація: не віддавайте зайві поля (PII), використовуйте «напівпрозорі» ідентифікатори.
TTL кешу: строго зафіксований; заборона локального копіювання повних дампів.
Права суб'єктів даних: маршрутизація запитів (access/erasure) через оператора; протоколювання.
Псевдонімізація/анонімізація: для аналітики/Derived Data - до публікації.

14) Плейбуки

P-LIC-01: Виявлено copyleft в прод-сервісі

Аудит SBOM → варіант міграції/ізоляції → юр-оцінка → план релізу → ретроспектива.

P-API-02: Витік ключа API

Відгук ключа → повідомлення клієнта → форензика → ротація секретів → апдейт політики.

P-SDK-03: Вендор ламає сумісність

Перехідний адаптер → тимчасова гілка API → переговори про продовження вікна → розсилка клієнтам.

P-XPORT-04: Санкційний прапор

Автоблок доступу → підтвердження матчів → юридична оцінка → документи для регулятора.

15) KPI/метрики

SBOM Coverage% і частка схвалених компонентів.
Час закриття ліцензійного інциденту (copyleft/несумісність).
Deprecation Compliance% (клієнти на актуальній версії).
Time-to-Revoke витеклого ключа і MTTR по API-інцидентам.
Частка клієнтів з підписаним DPA/DSA і пройденим санк-скринінгом.

16) Міні-FAQ

Чи можна вбудувати LGPL? Так, при динамічному лінку і дотриманні умов, фіксуємо в SBOM.
Хто володіє аналітикою по API? За замовчуванням - власник API (Service-Generated), клієнт - обмежена ліцензія.
Чи можна тренувати ML на API-даних? Тільки на анонімізованих/агрегованих і якщо це дозволено ToS/DPA.
Скільки тримати EOL? Рекомендуємо 9-12 місяців з міграційним гайдом.

17) Висновок

Ліцензування софту і API - це не «разово підписали», а постійний цикл: вибір сумісних ліцензій, ведення SBOM, чіткі API Terms (дані/квоти/SLA/депрекація), DPA/санкції, і операційні плейбуки. Стандартизуйте реєстри і шаблони - і ви знизите юридичні ризики, спростіть інтеграції і захистіть власний IP і дані гравців.