Лицензирование софта и 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.
Экспортные/санкционные ограничения: гео-блоки, списки PEP/санкций — обязательна проверка в ToS/лицензии.
Поддержка/обновления: SLA на патчи, breaking-changes, сроки миграций.

6) API: юридические условия предоставления доступа (для партнеров/аффилиатов/B2B)

• Доступ и аутентификация: 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) Экспортный контроль, санкции, криптография

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

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 и данные игроков.