Licencjonowanie oprogramowania i API

1) Dlaczego ma znaczenie dla iGaming

Platforma opiera się na zastrzeżonym kodzie, bibliotekach osób trzecich, dostawcy gier/płatności SDK oraz publicznych/prywatnych interfejsach API. Błędy licencyjne prowadzą do roszczeń, bloków integracji, wycieków IP i ryzyka regulacyjnego (prywatność/sankcje/eksport krypto). Celem jest zbudowanie przejrzystego zarysu praw: co można opublikować, zintegrować, przekazać partnerom i jak chronić własne interfejsy API.

2) Modele licencjonowania oprogramowania (przegląd)

Zastrzeżone (licencja zamknięta): prawa wyłączne od sprzedawcy; dla B2B (operatorzy, studia, PSP).

• Permissive: MIT, BSD, Apache-2. 0 (przyznanie patentu).
• Copyleft: GPL/LGPL/AGPL - kompatybilność „infekcyjna”; ostrożnie w zamkniętych modułach.
• Dual/Multi-Licensing: bezpłatny oddział OSS + licencja komercyjna z rozszerzonymi prawami/wsparciem.
• Licencja SaaS: dostęp jako usługa; kod nie jest przekazywany, prawa - do użytku.

Zasady wyboru: usługi krytyczne (silnik gier, przeciwdziałanie oszustwom, obliczenia) - unikać copyleft; Biblioteki interfejsu użytkownika - pobłażliwe; narzędzia wewnętrzne - GPL jest możliwe podczas izolacji.

3) Prawa i ograniczenia: co zobaczyć w licencjach

Zakres: terytoria, daty, użytkownicy/instalacje, środowiska (prod/stage/dev).
Modyfikacje i pochodne: czy możliwe jest widelec, zmiana, dystrybucja.
Sublicencja/transfer: jest dozwolony dla podmiotów stowarzyszonych/białej etykiety.
Udzielenie patentu i rozwiązanie umowy obronnej (Apache-2. 0, MPL): ryzyko patentowe i wzajemne licencje.
Audyt i sprawozdawczość: prawo sprzedawcy do przeprowadzania audytów licencyjnych.
Bezpieczeństwo/eksport: ograniczenia kryptograficzne, kraje/sankcje.
Odszkodowanie i odpowiedzialność: kto pokrywa roszczenia IP/odszkodowania.

4) Open Source: Polityka i kontrola

Biała lista: MIT/BSD/Apache-2. 0, MPL-2. 0.
Żółty: LGPL-3. 0 (jeżeli spełnione są dynamiczne ogniwo i warunki).
Czerwony: AGPL/GPL-3. 0 w usługach zamkniętych, jeśli nie ma izolacji (granice usług, copyleft sieciowy).
Oprogramowanie Bill of Materials (SBOM) - Zapytana lista zależności z wersjami/licencjami.
Procedura OSS: wniosek → prawna/tech-ocena zgodności → rejestracja w rejestrze → audyt okresowy.
Wkład do OSS (w górę rzeki): CLA/DCO, przegląd ujawniania informacji o IP, jednoczesność z Legal.

5) Licencje SDK i dostawcy (gry, płatności, KYC)

Typowe wymagania: zakaz inżynierii odwrotnej, zakaz buforowania poza warunkami, kontrola logo/marki, minimalne wersje, prawo audytu.
Dane: granice „danych operatora” vs „danych dostawcy”, który jest właścicielem mierników i danych pochodnych.
Ograniczenia eksportu/sankcji: bloki geograficzne, wykazy PEP/sankcje - obowiązkowa weryfikacja w ToS/licencjach.
Wsparcie/aktualizacje: SLA dla łatek, przełamywanie zmian, terminy migracji.

6) API: prawne warunki dostępu (dla partners/affiliates/B2B)

• Dostęp i uwierzytelnianie: OAuth2/HMAC/mutual-TLS; zakaz przekazywania kluczy osobom trzecim.
• Limity stawek i kwoty: RPS/minuty/dziennie; „uczciwe użytkowanie”; Polityka pęknięcia.
• SLA i wsparcie: dostępność (np. 99. 9%), okna konserwacji, plan incydentu/komunikacji.
• Wersioning/depletion: SemVer, daty EOL (na przykład, ≥ 9-12 miesięcy), wysyłanie powiadomień.

• Dane generowane przez usługę (dzienniki, mierniki) - właściciel API;
• Dane klienta/gracza - u klienta/operatora;
• Dane pochodne - według umowy (dozwolone/ograniczone, anonimizacja).
• Pamięć podręczna i przechowywanie: co i jak można przechowywać (TTL, zakaz przechowywania pól osobistych/wrażliwych).
• Prywatność/AML/KYC: role (kontroler/procesor), DPA/DSA, transmisje transgraniczne, DPIA dla scenariuszy wysokiego ryzyka.
• Bezpieczeństwo: szyfrowanie tranzytu/odpoczynku, tajne zarządzanie, wymagania SOC2/ISO 27001 (w stosownych przypadkach).
• Zakazy: inżynieria odwrotna, skrobanie, pomiar/benchmarking bez zgody, modyfikacja odpowiedzi API.
• Audyt i dzienniki: prawo do sprawdzania, wymagania dotyczące dzienników żądania.
• Sankcje i eksport: zakaz stosowania w krajach/z użytkownikami z list, kontrola bezpieczeństwa.
• Wyłączenie gwarancji i limit odpowiedzialności: pułap (na przykład 12 × średnia waga. płatność).
• Wygaśnięcie dostępu: natychmiastowe w przypadku zagrożenia bezpieczeństwa/prawa; plan wyjściowy.

7) Polityka weryfikacji i zgodności

SemVer: MAJOR (breaking), MINOR (funkcje), PATCH (fix).
Umowy schematyczne: JSON Schema/OpenAPI; testy kontraktowe dla klientów.
Procedura odchylenia: ogłoszenie → okres zgodności (≥ 6 miesięcy) → EOL → usunięcie; przewodnik migracji.
Flagi funkcyjne: do „miękkiego” walcowania.

8) Kontrola eksportu, sankcje, kryptografia

Eksport kryptografii: sprawdzanie lokalnych zasad; powiadomienia/kod ECC/długości bitów.
Sankcje: zakaz służenia rezydentom jurysdykcji/osobom podlegającym subkarnacji/dostępu do nich; okresowa rekonwalescencja.
Odporność ustawodawstwa: klauzule dotyczące zawieszenia służby na ryzyko regulacyjne.

9) Macierz ryzyka (RAG)

10) Lista kontrolna przed zwolnieniem/integracja

• SBOM zmontowane; sprawdzone licencje (nie są niezgodne).
• Licencje sprzedawcy/SDK są podpisane; prawa do danych i marki.
• DPA/DSA wydane; zdefiniowano role nadzorcy/przetwórcy.
• Warunki/uaktualnione interfejsy API EULA; określono limity szybkości/SLA/wyczerpanie.
• Kontrola sankcji/eksportu w procesach.
• Bezpieczeństwo: klucze, obrót, szyfrowanie, rejestrowanie.
• Plan incydentu i dostęp Recall (killswitch) gotowy.

11) Rejestry i artefakty (zalecane formaty)

11. 1 SBOM/rejestr licencji

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 Rejestr klienta 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 Rejestr SDK/Sprzedawcy

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) Szablony (fragmenty)

12. 1 EULA (fragment wewnętrzny)

12. 2 Warunki API (fragment wewnętrzny)

12. 3 Kod próbki/licencjonowanie doku

13) Prywatność i dane (API/SDK)

Minimalizacja: nie podawać dodatkowych pól (PII), używać „półprzezroczystych” identyfikatorów.
Cache TTL: ściśle stałe; Zabronić kopiowania pełnych porzuconych.
Prawa osób, których dane dotyczą: routing wniosków (dostęp/usunięcie) za pośrednictwem operatora; rejestrowanie.
Pseudonimizacja/anonimizacja: dla danych analitycznych/pochodnych - przed publikacją.

14) Playbooks

P-LIC-01: Copyleft wykryty w serwisie produkcyjnym

SBOM audyt → migracja/izolacja opcja → JUR → plan wydania → retrospektywny.

P-API-02: Wyciek klucza API

Odwołanie klucza → powiadomienie klienta → kryminalistyka → tajna rotacja → aktualizacja polityki.

P-SDK-03: Sprzedawca łamie kompatybilność

Adapter przejściowy → tymczasowy oddział API → negocjacje w celu rozszerzenia okna → dystrybucja do klientów.

P-XPORT-04: flagi sankcji

Autoblock dostęp → potwierdzenie meczu → ocena prawna → dokumenty dla regulatora.

15) KPI/Metryki

SBOM Pokrycie% i procent zatwierdzonych komponentów.
Czas zamknięcia incydentu licencyjnego (copyleft/niezgodność).
Odrzucenie zgodności% (klienci w aktualnej wersji).
Czas do odwołania wyciek klucza i MTTR dla incydentów API.
Przeszedł odsetek klientów z podpisanym DPA/DSA i przesiewem schodów.

16) Mini-FAQ

Czy mogę osadzić LGPL? Tak, dzięki dynamicznemu połączeniu i zgodności z warunkami, naprawiamy go w SBOM.
Kto jest właścicielem API analytics? Domyślnie - właściciel API (Service-Generated), klient - ograniczona licencja.
Czy mogę trenować ML na danych API? Tylko na anonimizowanych/zagregowanych i jeśli dozwolone przez ToS/DPA.
Ile trzymać EOL? Zalecane 9-12 miesięcy z przewodnikiem migracji.

17) Wniosek

Licencjonowanie oprogramowania i API nie jest „jednorazowym podpisem”, ale stałym cyklem: wybór zgodnych licencji, konserwacja SBOM, jasne warunki API (dane/kwoty/SLA/wyczerpanie), DPA/sankcje, i operacyjne playbooks. Standaryzuj rostery i szablony - a zmniejszysz ryzyko prawne, uprościsz integrację i chronisz własne IP i dane graczy.