პროგრამული ლიცენზირება და API
1) რატომ არის ეს მნიშვნელოვანი iGaming- ისთვის
პლატფორმა ეყრდნობა საკუთარ კოდს, მესამე მხარის ბიბლიოთეკებს, თამაშების/გადახდის პროვაიდერების SDK და საზოგადოებრივ/კერძო API. ლიცენზიების შეცდომები იწვევს პრეტენზიებს, ინტეგრაციის ბლოკებს, IP გაჟონვას და მარეგულირებელ რისკებს (კერძო/სანქციები/კრიპტოგრაფიის ექსპორტი). მიზანია უფლებების გამჭვირვალე წრის შექმნა: რისი გამოქვეყნება, ინტეგრაცია, პარტნიორების გადაცემა და როგორ დავიცვათ საკუთარი API.
2) პროგრამული უზრუნველყოფის ლიცენზირების მოდელები (მიმოხილვა)
დახურული ლიცენზია: გამყიდველის ექსკლუზიური უფლებები; B2B- სთვის (ოპერატორები, სტუდიები, PSP).
Open Source (OSS):- Permissive: MIT, BSD, Apache-2. 0 (საპატენტო გრანტი).
- კოპილეფტი: GPL/LGPL/AGPL - „ინფიცირების“ თავსებადობა; ფრთხილად დახურული მოდულებით.
- Dual/Multi-licensing: უფასო OSS ფილიალი + კომერციული ლიცენზია გაფართოებული უფლებებით/მხარდაჭერით.
- SaaS ლიცენზირება: წვდომა, როგორც მომსახურება; კოდი არ გადადის, უფლებები გამოიყენება.
არჩევანის წესები: კრიტიკული მომსახურება (თამაშის ძრავა, ანტიფროდი, გამოთვლები) - თავიდან აიცილოთ კოპილეფტი; UI ბიბლიოთეკა - სრულყოფილი; შიდა ტულზები - GPL შესაძლებელია იზოლირებისას.
3) უფლებები და შეზღუდვები: რას უყურებთ ლიცენზიებში
უფლებების მოცულობა (სკოპი): ტერიტორიები, ვადა, მომხმარებლები/ინსტალაცია, გარემო (scope/stage/dev).
მოდიფიკაციები და წარმოებულები: შესაძლებელია თუ არა ჩაქრობა, შეცვლა, გავრცელება.
სუბლიცენზია/გადაცემა: მისაღებია თუ არა affiliats/white-label.
საპატენტო გრანტი და დამცავი ტერმინაცია (Apache-2. 0, MPL): საპატენტო რისკები და ჯვარედინი ლიცენზია.
აუდიტი და ანგარიშგება: მოვაჭრის უფლება განახორციელოს ლიცენზირებული შემოწმებები.
უსაფრთხოება/ექსპორტი: შეზღუდვები კრიპტოგრაფიაზე, ქვეყნებზე/სანქციებზე.
დამოუკიდებელი და პასუხისმგებლობა: ვინ ფარავს IS/ზიანის პრეტენზიებს.
4) ღია წყარო: პოლიტიკა და კონტროლი
თეთრი სია: MIT/BSD/Apache-2. 0, MPL-2. 0.
ყვითელი: LGPL-3. 0 (დინამიური ჩამოსხმის და პირობების დაცვით).
წითელი: AGPL/GPL-3. 0 დახურულ სერვისებში, თუ არ არსებობს იზოლაცია (მომსახურების საზღვრები, ქსელის კოპილეფტი).
SBOM (Software Bill of Materials): დამოკიდებულების სავალდებულო სია ვერსიით/ლიცენზიით.
OSS- ის წარდგენის პროცედურა: მოთხოვნა, იური/თავსებადობის შეფასება, რეესტრში დაფიქსირება პერიოდული აუდიტისთვის.
წვლილი OSS (upstream) - ში: CLA/DCO, IP გამჟღავნების შემოწმება, ლეგალის კოორდინაცია.
5) SDK და პროვაიდერების ლიცენზია (თამაშები, გადახდები, KYC)
ტიპიური მოთხოვნები: საპირისპირო განვითარების აკრძალვა, ქეშირების აკრძალვა, ლოგოების/ბრენდინგის კონტროლი, მინიმალური ვერსიები, აუდიტის კანონი.
მონაცემები: „კამერის მონაცემების“ საზღვრები „პროვაიდერის მონაცემები“, რომელიც ფლობს მეტრიკებს და Derived Data.
ექსპორტის/სანქციების შეზღუდვები: გეო-ბლოკები, REP/სანქციების სიები - სავალდებულო შემოწმება ToS/ლიცენზიაში.
მხარდაჭერა/განახლება: SLA patchi, breaking-changes, მიგრაციის დრო.
6) API: იურიდიული პირობები წვდომის უზრუნველსაყოფად (პარტნიორებისთვის/აფილიატებისთვის/B2V)
API Terms- ის ძირითადი მონაკვეთები:- წვდომა და ავთენტიფიკაცია: OAuth2/HMAC/mutual-TLS; მესამე პირებზე გასაღებების გადაცემის აკრძალვა.
- Rate limits და კვოტები: RPS/წუთი/დღეში; „გულწრფელი გამოყენება“; პოლიტიკა burst.
- SLA და მხარდაჭერა: წვდომა (მაგ., 99. 9%), მომსახურების ფანჯრები, ინციდენტების/კომუნიკაციების გეგმა.
- ვერსია/გადაკეთება: SemVer, EOL დრო (მაგალითად, 9-12 თვე), შეტყობინებების გაგზავნა.
- Service-Generated Data (logs, მეტრიკა) - API- ს მფლობელთან;
- Customer/Player Data - კლიენტთან/ოპერატორთან;
- Derived Data - ხელშეკრულების თანახმად (ნებადართულია/შეზღუდული, ანონიმიზაცია).
- ქეში და შენახვა: რა და როგორ შეიძლება ქეშირება (TTL, პირადი/მგრძნობიარე ველების შენახვის აკრძალვა).
- Privacy/AML/KYC: როლები (მაკონტროლებელი/პროცესორი), DPA/DSA, ტრანსსასაზღვრო გადაცემები, DPIA მაღალი დონის სცენარებისთვის.
- უსაფრთხოება: დაშიფვრა ტრანზიტში/at-rest, საიდუმლო მენეჯმენტი, მოთხოვნები SOC2/ISO 27001 (თუ გამოიყენება).
- აკრძალვები: საპირისპირო ინჟინერია, სკრიპინგი, გაზომვა/ბენჩმარკინგი თანხმობის გარეშე, API პასუხების შეცვლა.
- აუდიტი და ლოგიკა: აუდიტის უფლება, მოთხოვნის ჟურნალების მოთხოვნები.
- სანქციები და ექსპორტი: აკრძალვა ქვეყანაში/მომხმარებლების მიერ სიიდან გამოყენების აკრძალვა, ეკრანიზაცია.
- გარანტიების გამორიცხვა და პასუხისმგებლობის ზღვარი: cap (მაგალითად, 12 × საშუალო. გადახდა).
- დაშვების შეწყვეტა: დაუყოვნებლივი უსაფრთხოების/კანონის საფრთხის ქვეშ; მონაცემთა გამომავალი გეგმა.
7) ვერსიისა და თავსებადობის პოლიტიკა
SemVer: MAJOR (breaking), MINOR (features), PATCH (fix).
სქემების კონტრაქტები: JSON Schema/OpenAPI; contract ტესტები მომხმარებლებისთვის.
Deprecation პროცედურა: გამოცხადება თავსებადობის პერიოდის შესახებ (6 თვე), EOL - მოცილება; მიგრაციის ჰაიდი.
Feature flags: „რბილი“ დარტყმებისთვის.
8) ექსპორტის კონტროლი, სანქციები, კრიპტოგრაფია
კრიპტოგრაფიის ექსპორტი: ადგილობრივი წესების შემოწმება; შეტყობინებები/ESS კოდი/bit სიგრძე.
სანქციები: აკრძალვა ემსახურება/წვდომა სანქცირებული იურისდიქციების/პირების მაცხოვრებლებზე; პერიოდული გადახრა.
კანონის წინააღმდეგობა: კლაუზულები მარეგულირებელი რისკის ქვეშ მომსახურების შეჩერების შესახებ.
9) რისკის მატრიცა (RAG)
10) ჩეკის სია გამოშვებამდე/ინტეგრაციამდე
- შეიკრიბა SBOM; შემოწმებულია ლიცენზიები (არ არსებობს შეუთავსებელი).
- გაფორმებულია Wendor/SDK ლიცენზიები; უფლებები მონაცემებსა და ბრენდზე.
- DPA/DSA გაფორმებულია; განისაზღვრება მაკონტროლებელი/პროცესორის როლები.
- API Terms/EULA განახლებულია; რეგისტრირებულია rate limits/SLA/debrecation.
- სანქციების/ექსპორტის სკრინინგი პროცესებში.
უსაფრთხოება: გასაღებები, როტაცია, დაშიფვრა, ჟურნალები.
- ინციდენტების გეგმა და წვდომის მიმოხილვა (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 ქეში: მკაცრად დაფიქსირებული; სრული ნაგვის ადგილობრივი კოპირების აკრძალვა.
მონაცემთა სუბიექტების უფლებები: მოთხოვნის მარშრუტიზაცია (წვდომა/გაფართოება) ოპერატორის მეშვეობით; პროტოკოლი.
ფსევდონიმიზაცია/ანონიმიზაცია: ანალიტიკისთვის/Derived Data - გამოქვეყნებამდე.
14) პლეიბუკი
P-LIC-01: იპოვნეს კოპილეფტი სარეკლამო მომსახურებაში
SBOM აუდიტი - მიგრაციის/იზოლაციის ვარიანტი - იურიდიული შეფასება - გამოშვების გეგმა - რეტროსპექტივა.
P-API-02: API გასაღების გაჟონვა
გასაღების გადახედვა - კლიენტის შეტყობინებას, რომელიც მიზნად ისახავს საიდუმლოებების როტაციას და პოლიტიკის გაფართოებას.
P-SDK-03: Wendor არღვევს თავსებადობას
გარდამავალი ადაპტერი - API დროებითი ფილიალი - მოლაპარაკებები ფანჯრის გახანგრძლივებისა და მომხმარებლების გაგზავნის შესახებ.
P-XPORT-04: სანქციების დროშა
დაშვების ავტობუსი - მატჩების დადასტურება - მარეგულირებლის იურიდიული შეფასება და დოკუმენტები.
15) KPI/მეტრიკა
SBOM Coverage% და დამტკიცებული კომპონენტების წილი.
ლიცენზირებული ინციდენტის დახურვის დრო (copyleft/შეუთავსებლობა).
Deprecation Compliance% (მომხმარებლები მიმდინარე ვერსიით).
გაჟღენთილი გასაღების დრო და MTTR API ინციდენტებისთვის.
DPA/DSA- ს მიერ ხელმოწერილი მომხმარებლების წილი და გაიარა სლაიდების სკრინინგი.
16) მინი-FAQ
შესაძლებელია LGPL- ის ინტეგრირება? დიახ, დინამიური ჩამოსხმის და პირობების დაცვით, ჩვენ ვადგენთ SBOM- ს.
ვინ ფლობს API- ს ანალიტიკას? ნაგულისხმევი - API- ს (სამსახურის გენერალი) მფლობელი, კლიენტი - შეზღუდული ლიცენზია.
შეგიძლიათ ML- ს მომზადება API მონაცემებზე? მხოლოდ ანონიმური/საერთო და თუ ეს ნებადართულია ToS/DPA.
რამდენი უნდა შეინახოთ EOL? რეკომენდებულია 9-12 თვის განმავლობაში მიგრაციის ჰაერით.
17) დასკვნა
პროგრამული უზრუნველყოფის და API- ს ლიცენზირება არ არის „ერთჯერადი“, არამედ მუდმივი ციკლი: თავსებადი ლიცენზიების არჩევანი, SBOM, მკაფიო API Terms (მონაცემები/კვოტები/SLA/დეპრესია), DPA/სანქციები და ოპერაციული ფლეიბუქები. სტანდარტიზდება რეესტრები და შაბლონები - და შეამცირებთ იურიდიულ რისკებს, გაამარტივებთ ინტეგრაციას და დაიცავთ საკუთარ IP და მოთამაშეთა მონაცემებს.