Licencje i ograniczenia Open Source
1) Dlaczego OSS w iGaming i gdzie są zagrożenia
OSS przyspiesza rozwój platformy (front/back gry, integracja płatności, zwalczanie nadużyć finansowych, analityka), ale błędy licencyjne prowadzą do ujawnienia zamkniętego kodu, blokowania zwolnień i sporów z dostawcami. Potrzebujemy: jasnej polityki, rejestru zależności (SBOM), procesów audytu i prawidłowego wyboru licencji.
2) Mapa licencyjna: rodzaje i znaczenie
2. 1 Pobłażliwy
MIT, BSD-2/3-Clause, Apache-2. 0
Głównym obowiązkiem jest zachowanie Apache-2 zawiadomienia/praw autorskich. 0 również grant patentowy + „wypowiedzenie obronne”.
Nadaje się do: ram interfejsu użytkownika, narzędzi, klientów SDK, bibliotek logowania/HTTP.
2. 2 Słabe copyleft
MPL-2. 0, LGPL-2. 1/3. 0
Wymagaj zmian otwarcia w samej bibliotece/module, ale nie w całym projekcie.
Dynamiczne połączenie z LGPL jest zwykle dozwolone, jeśli spełnione są warunki (wymiana użytkownika, powiadomienia).
2. 3 Mocny copyleft
GPL-2. 0/3. 0, AGPL-3. 0
Przy „łączeniu” z Twoim kodem powstaje obowiązek ujawnienia utworu pochodnego na tej samej licencji (warunki „tivoization”, „closure SaaS” zamknij AGPL).
Ryzyko dla zamkniętych modułów rdzenia gry, przeciwdziałanie oszustwom, bramy płatności.
3) Powiązanie i „produkt pochodny” (uproszczony)
Statyczne powiązanie z GPL → wysokie ryzyko „zakażenia”.
Dynamiczne połączenie z LGPL → jest zwykle dozwolone z zastrzeżeniem warunków (wymiana, powiadomienia).
IPC/REST/gRPC, indywidualne procesy → zmniejszyć ryzyko wydajności, ale nie anulować analizy (AGPL traktuje „przez sieć” jako „połączenie”).
Wtyczki/skrypty są → oceniane przez rzeczywistą integrację (stabilność API, ładowanie do przestrzeni adresowej).
4) Patenty i zastrzeżenia
Apache-2. 0 daje licencjonowanie patentów autora → zmniejsza ryzyko roszczeń patentowych.
GPL-3. 0/AGPL-3. 0 posiadają pozycje anty-patentowe/anty-obejście środków.
Jeśli Twój moduł ma znaczenie patentowe (matematyka RNG, algorytmy zwalczania nadużyć finansowych), unikaj licencji bez przyznania patentu lub dodaj oddzielne porozumienia patentowe do umów handlowych.
5) Obowiązki OSS: co dokładnie zrobić
Zapisz powiadomienia/ZAWIADOMIENIE (dopuszczalne).
Ujawnić modyfikacje komponentów copyleft (MPL/LGPL/GPL) oraz metodę reasekuracji.
Zapewnij źródła podczas dystrybucji binariów dla GPL/LGPL (oraz dostępu do sieci dla AGPL).
Określ licencję na stronie O polu/Kredyty OSS.
Śledź licencje firm trzecich w przesyłkach (sprzedawcy gier/SDK/mobilne buduje).
6) Polityka platformy OSS (zalecane minimum)
1. Klasyfikacja licencji: zielony (MIT/BSD/Apache/MPL), żółty (LGPL w warunkach), czerwony (GPL/AGPL/SSPL dla części zamkniętych).
2. Proces przyjmowania komponentów: wniosek → ocena prawna i techniczna → rekord w SBOM → audyt okresowy.
3. Izolacja Copyleft: oddzielny proces/mikroservice, granica gRPC/HTTP, brak połączenia statycznego.
4. Budowa SBOM: dla każdego wydania prod/stage.
5. Powiadomienia i źródła: automatyczna generacja POWIADOMIENIA/STRONY TRZECIEJ oraz publikacja źródeł w razie potrzeby.
6. Wkłady (w górę rzeki): CLA/DCO, brak tajemnic/patentów, koordynacja z Legal.
7. Bezpieczeństwo: skanowanie luk, zasady łata, zakazanie „pin” wrażliwych wersji bez rezygnacji.
7) OSS w typowych strefach iGaming (najlepsza praktyka)
Matematyka/RNG: Unikaj GPL/AGPL; wolisz własny kod lub permisywne biblioteki.
Interfejs użytkownika/klient: React/Vue/bundlers - permissive → ok, monitorowanie licencji i czcionek.
Płatności/CCM: SDK sprzedawców z ścisłym ToS; nie mieszać z copyleft.
Obserwowalność/DevOp: Prometheus/Grafana/Elastic - uwzględnienie ich licencji (część modułów innych niż OSS); odczytać warunki „po stronie serwera”.
Antyfraud/punktacja: model/zasady - zastrzeżone; third-party libs - permissive/MIT/Apache.
8) Matryca kompatybilności (w skrócie)
9) Macierz ryzyka (RAG)
10) Listy kontrolne
Przed dodaniem biblioteki
- Licencja biblioteczna na zieloną/żółtą listę.
- Zweryfikowana kompatybilność łącza (statyczna/dynamiczna/IPC).
- SBOM + wersja + źródło.
- Wygenerowane powiadomienia (LICENCJA/ZAWIADOMIENIE).
Przed zwolnieniem
- SBOM na zaoszczędzony montaż (prod/etap).
- Przeszedł skan podatności na zagrożenia; krytyczne - zamknięte lub zwolnienie.
- Wymagane źródło/łatki są gotowe do wydania (w razie potrzeby).
- „OSS Credits „/O aktualizacji strony.
W przypadku składek
- Podpisano CLA/DCO.
- Przegląd pod kątem braku tajemnic/patentów.
- Prawa autorskie/prawa autorskie są prawidłowe.
11) Polityka OSS (snippets)
11. 1 Klasyfikacja
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 Proces przyjmowania
request → legal+tech review → approve/deny → SBOM entry → periodic audit11. 3 Izolacja kopyleftów
Oddzielna usługa, interfejs sieciowy, brak kombinacji binariów, brak statycznego połączenia.
Library Build and Upgrade Documentation (LGPL/MPL).
12) Rejestry (szablony YAML)
12. 1 SBOM/strona trzecia
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 źródła OSS do ujawnienia
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 Rejestr depozytów (w górę strumienia)
yaml project: "open-telemetry"
pr: 4521 author: "dev_a"
cla: true dco: true files: ["exporter. go"]
review_legal: "2025-10-28"
status: "merged"13) Bezpieczeństwo i zgodność
SCA/SAST w CI, autoskan nowych zależności.
Zasady plastra: luki P1 - ≤ 72 godziny, P2 - ≤ 14 dni.
Artifact Cache: Zachowaj oryginał LICENCJI/ZAWIADOMIENIA; sprawdź integralność (hashes).
Eksport/sankcja: Nie stosować komponentów/luster z krajów objętych zakazem; sprawdzenie dziennika.
14) Playbooks (scenariusze operacyjne)
P-OSS-01: GPL wykryte w zamkniętym module
Link inventory → opcja izolacji/wymiany → opinia prawna → zwolnienie fix → retro na proces.
P-OSS-02: Wymóg źródłowy
Określić zakres obowiązków → przygotowanie archiwów i OGŁOSZENIA → transfer na czas → aktualizacja dokumentacji.
P-OSS-03: Krytyczna wrażliwość w zależności
Backport/update → nadzwyczajne wydanie → powiadomienie zainteresowanych → zasady po morzu i szpilki.
15) Mini-FAQ
Czy mogę użyć LGPL? Tak, z dynamicznym połączeniem/IPC i zgodności z warunkami (wymienność, powiadomienia).
AGPL na serwerze bez dystrybucji binarnej - czy to bezpieczne? Nie: AGPL wymaga podania kodu źródłowego użytkownikom interakcji z usługą przez sieć.
Czy potrzebuję dotacji patentowej? pożądane dla modułów z innowacjami algorytmicznymi; Apache-2. 0 jest korzystne.
Czy wystarczy określić OSS na stronie? Nie, wykonaj wszystkie wymagania: powiadomienia, źródła, instrukcje.
16) Wniosek
Praca z OSS to proces, a nie jednorazowa kontrola: standardy wstępu, izolacja copyleft, zautomatyzowane powiadomienia i pełny SBOM na montaż. Wykonując ten artykuł, będziesz utrzymywać szybkość rozwoju i unikać pułapek prawnych - od „copyleft sieciowy” do roszczeń patentowych.