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: осалдықтарды сканерлеу, тегістеу саясаты, waiver-сіз «pin» осал нұсқаларына тыйым салу.

7) iGaming типтік аймақтарында OSS (best practice)

Ойын математикасы/RNG: GPL/AGPL болдырмау; жеке кодты немесе permissive-кітапхананы таңдау.
UI/клиент: React/Vue/бандлерлер - permissive → ok, лицензиялар мен қаріптерді қадағалаңыз.
Төлемдер/АКҚ: 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 »/Туралы бет жаңартылды.

Салымдар үшін (contributions)

• CLA/DCO қол қойды.
• Құпиялардың/патенттердің жоқтығына шолу.
• Авторлық құқық/көшірме дұрыс қойылған.

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 modules

11. 2 Рұқсат беру процесі

request → legal+tech review → approve/deny → SBOM entry → periodic audit

11. 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. Осы бапқа сүйене отырып, сіз әзірлеу жылдамдығын сақтап, «желілік копилефтен» бастап патенттік талаптарға дейін заңды тұзақтарды болдырмайсыз.