ღია წყაროების ლიცენზია და შეზღუდვები

1) რატომ OSS iGaming- ში და სად არის რისკები

OSS აჩქარებს პლატფორმის შემუშავებას (თამაშის ფრონტი/უკანა, გადახდის ინტეგრაცია, ანტიფროდი, ანალიტიკა), მაგრამ ლიცენზირების შეცდომები იწვევს დახურული კოდის გამჟღავნებას, გამოშვებების დაბლოკვას და პროვაიდერებთან დავებს. საჭიროა: მკაფიო პოლიტიკა, დამოკიდებულების რეესტრი (SBOM), აუდიტის პროცესები და ლიცენზიების სწორი არჩევანი.

2) ლიცენზიების რუკა: ტიპები და მნიშვნელობა

2. 1 Permissive (ნებართვები)

MIT, BSD-2/3-Clause, Apache-2. 0

მთავარი მოვალეობაა Apache-2- ში შეინარჩუნოს შეტყობინება/საავტორო უფლებები. 0 ასევე საპატენტო გრანტი + „დამცავი ტერმინაცია“.
შესაფერისია: UI ჩარჩოები, კომუნალური მომსახურება, SDK კლიენტები, ლოჯისტიკური ბიბლიოთეკები/NTTR.

2. 2 Weak copyleft (სუსტი კოპილეფი)

MPL-2. 0, LGPL-2. 1/3. 0

ისინი მოითხოვენ ცვლილებების გახსნას თავად ბიბლიოთეკაში/მოდულში, მაგრამ არა მთელ პროექტში.
LGPL- ით დინამიური LGPL ჩვეულებრივ დასაშვებია პირობების შესრულებისას (მომხმარებლის მიერ ვერსიის შეცვლის შესაძლებლობა, შეტყობინებები).

2. 3 Strong copyleft (ძლიერი ასო)

GPL-2. 0/3. 0, AGPL-3. 0

თქვენს კოდთან „შეერთებისას“ ჩნდება ვალდებულება წარმოებული პროდუქტის იმავე ლიცენზიის ქვეშ გამჟღავნების შესახებ (პირობები „tivoization“, „SaaS დახურვა“ ხურავს AGPL).
რისკი სათამაშო ბირთვის დახურული მოდულისთვის, ანტიფროდისთვის, გადახდის კარიბჭეებისთვის.

ცალკე: „ფსევდო-OSS“, როგორც SSPL: მოითხოვს მთელი მომსახურების დასტის გახსნას - განიხილეთ კომერციულად შეუთავსებელი საკუთრების კომპონენტებისთვის.

3) ლინკოვკა და „წარმოებული პროდუქტი“ (გამარტივებული)

სტატიკური საბრძოლო GPL- ით არის „ინფექციის“ მაღალი რისკი.
LGPL- ით დინამიური LGPL, როგორც წესი, დასაშვებია პირობების დაცვით (შეცვლა, შეტყობინებები).
IPC/REST/gRPC, ინდივიდუალური პროცესები ამცირებს წარმოების რისკს, მაგრამ არ აუქმებს ანალიზს (AGPL განმარტავს „ქსელის საშუალებით“, როგორც „კავშირი“).
პლაგინები/სკრიპტები შეფასებულია ფაქტობრივი ინტეგრაციით (API სტაბილურობა, მიზნობრივი სივრცეში დატვირთვა).

4) პატენტები და დათქმები

Apache-2. 0 იძლევა ავტორის პატენტების ლიცენზირებას და ამცირებს საპატენტო პრეტენზიების რისკს.
GPL-3. 0/AGPL-3. 0-ს აქვს ანტი-საპატენტო/ანტი-circumvention პოზიციები.
თუ თქვენი მოდული - პატენტურად მნიშვნელოვანი (RNG მათემატიკა, ანტიფროდიული ალგორითმები) - თავიდან აიცილეთ ლიცენზიები საპატენტო გრანტის გარეშე, ან დაამატეთ ინდივიდუალური საპატენტო შეთანხმებები კომერციულ ხელშეკრულებებში.

5) პასუხისმგებლობა OSS- სთვის: რა უნდა გააკეთოს

შეტყობინებების შენახვა/NOTICE (permisve).
გამოავლინეთ კოპილეფტის კომპონენტების მოდიფიკაციები (MPL/LGPL/GPL) და გადაკეთების მეთოდი.
წყაროების მიწოდება ბინების GPL/LGPL- ის ქვეშ (და ქსელის დაშვება AGPL- ის ქვეშ).
მიუთითეთ ლიცენზია ფანჯარაში „პროგრამის შესახებ „/გვერდზე „OSS კრედიტები “.
მესამე ნაწილის მიწოდების ლიცენზიის თვალყურის დევნება (თამაშების მოვაჭრეები/SDK/მობილური ბილეთები).

6) OSS პოლიტიკა პლატფორმისთვის (რეკომენდებულია მინიმალური)

1. ლიცენზიების კლასიფიკაცია: მწვანე (MIT/BSD/Apache/MPL), ყვითელი (LGPL პირობებში), წითელი (GPL/AGPL/SSPL დახურული ნაწილებისთვის).
2. კომპონენტის დაშვების პროცესი: მოთხოვნა - იურიდიული და ტექნოლოგია - ჩაწერა SBOM- ში - პერიოდული აუდიტი.
3. კოპილეფტის იზოლაცია: ცალკეული პროცესი/მიკროსერვისი, gRPC/HTTP საზღვარი, არ არსებობს სტატიკური საბრძოლო.
4. SBOM ასამბლეის შესახებ: თითოეული გამოშვებისთვის scream/stage.
5. შეტყობინებები და წყაროები: NOTICE/THIRD-PARTY ავტომატური წარმოება და წყაროების გამოქვეყნება, სადაც საჭიროა.
6. ანაბრები (upstream): CLA/DCO, საიდუმლოებების/პატენტების არარსებობის შემოწმება, ლეგალის კოორდინაცია.
7. უსაფრთხოება: დაუცველების სკანირება, პატჩების პოლიტიკა, „პინის“ დაუცველი ვერსიების აკრძალვა waiver- ის გარეშე.

7) OSS ტიპიურ ზონებში iGaming (საუკეთესო პრემია)

თამაშის მათემატიკა/RNG: თავიდან აიცილოთ GPL/AGPL; უპირატესობა მიანიჭეთ საკუთარ კოდს ან პირმშოს ბიბლიოთეკებს.
UI/კლიენტი: React/Vue/Bandlers - permissive, აკონტროლეთ ლიცენზიები და შრიფტები.
გადახდა/KUS: SDK გამყიდველები მკაცრი ToS; ნუ შეურიეთ კოპილეფტს.
Observability/DevOps: Prometheus/Grafana/Elastic - გაითვალისწინეთ მათი ლიცენზია (მოდულის ნაწილი არა-OSS); „server side“ - ის წაკითხვის პირობები.
ანტიფროდი/მორიელი: მოდელი/წესები - საკუთრება; მესამე მხარის ლიბიელები - permissive/MIT/Apache.

8) თავსებადობის ცხრილი (მოკლედ)

9) რისკის მატრიცა (RAG)

10) ჩეკის ფურცლები

ბიბლიოთეკის დამატებამდე

• ბიბლიოთეკის ლიცენზია მწვანე/ყვითელ სიაში.
• შემოწმებულია ლინკების თავსებადობა (static/dynamic/IPC).
• ჩანაწერი SBOM + ვერსიაში + წყარო.
• წარმოიქმნება შეტყობინებები (LICENSE/NOTICE).

გამოსვლამდე

• SBOM შეკრებისთვის არის შენახული (stage/stage).
• დაუცველების სკანი დასრულდა; კრიტიკული - დახურულია ან waiver.
• საჭირო წყაროები/პატჩი მზად არიან ექსტრადიციისთვის (საჭიროების შემთხვევაში).
• „OSS კრედიტები “/About გვერდი განახლებულია.

დეპოზიტებისთვის

• 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) Playbooks (ოპერაციული სცენარები)

P-OSS-01: აღმოაჩინა GPL დახურულ მოდულში

ობლიგაციების ინვენტარიზაცია - იზოლაციის/ჩანაცვლების ვარიანტი - იურიდიული დასკვნა - გამოშვება - რეტრო პროცესი.

P-OSS-02: წყაროების მოთხოვნა

ვალდებულებების ოდენობის დადგენა, არქივებისა და NOTICE- ების მომზადება, კანონიერ ვადაში გადაცემა და დოკუმენტაციის განახლება.

P-OSS-03: კრიტიკული დაუცველობა დამოკიდებულია

Backport/განახლება - რიგგარეშე გამოშვება - შეტყობინება, რომელიც დაინტერესებულია პოსტ-ზღვით და პინინგის წესებით.

15) მინი-FAQ

შესაძლებელია LGPL- ის გამოყენება? დიახ, დინამიური საბრძოლო/IPC და პირობების დაცვით (შეცვლა, შეტყობინებები).
AGPL სერვერზე, ბინარული განაწილების გარეშე - უსაფრთხოა? არა: AGPL მოითხოვს წყაროების მიწოდებას ქსელის მომსახურებასთან ურთიერთქმედების მომხმარებლებისთვის.
საჭიროა საპატენტო გრანტი? სასურველია ალგორითმული ინოვაციების მოდულებისთვის; Apache-2. სასურველია 0.
საკმარისია საიტზე მიუთითოთ OSS? არა, დააკვირდით ყველა მოთხოვნას: შეტყობინებები, წყაროები, ინსტრუქციები.

16) დასკვნა

OSS- სთან მუშაობა პროცესია და არა ერთჯერადი შემოწმება: დაშვების სტანდარტები, ასლის იზოლაცია, ავტომატური შეტყობინებები და სრული SBOM თითოეული შეკრებისთვის. ამ სტატიის შემდეგ, თქვენ შეინარჩუნებთ განვითარების სიჩქარეს და თავიდან აიცილებთ იურიდიულ ხაფანგებს - „ქსელის კოპილეფტიდან“ საპატენტო პრეტენზიებამდე.