GH GambleHub

პროგრამული ლიცენზირება და 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)

ზონაR (კრიტიკულად)A (უნდა მართოთ)G (დაახლ)
OSS თავსებადობაAGPL/GPL დახურულ მომსახურებაშიLGPL პირობების გარეშეPermissive/იზოლირებული
API მონაცემებიშეინახეთ PII უფლებების გარეშე/TTLნაწილობრივი ანონიმიზაციამკაფიო უფლებები, TTL, DPA
პატენტებიარ არსებობს გრანტი/დამცავი კლაუსიარასრული ტექსტიApache-2. 0/პერსონალი. გრანტი
სანქციები/ექსპორტიარა სკრინინგიერთჯერადი სკრინინგიპოლიტიკა + პროცედურები
ვერსიახელშეკრულებები ვადების გარეშევადები <6 თვეSemVer + EOL - 9-12 თვე
ლიცენზიის აუდიტიარ არსებობს SBOM/რეესტრიარასრულისრული SBOM + კვარტი. აუდიტი

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 (შიდა ფრაგმენტი)

💡 ლიცენზია იღებს დაუსაბუთებელ, დაუსაბუთებელ ლიცენზიას პროდუქტის გამოყენებისთვის ტერიტორიასა და ვადაში, საბოლოო მომხმარებლებისთვის მომსახურების მიწოდების მიზნით. აკრძალულია: (i) საპირისპირო ინჟინერია, დეკომპილაცია; (ii) ტექნიკური ზომების გვერდის ავლით; (III) უფლებების გადაცემა მესამე პირებზე წერილობითი თანხმობის გარეშე. პროდუქტი მოცემულია „როგორც არის“; სალიცენზიო პასუხისმგებლობა შემოიფარგლება ღონისძიების წინა 12 თვის გადახდის ოდენობით.

12. 2 API Terms (შიდა ფრაგმენტი)

💡 კლიენტი თანახმაა დაიცვას წვდომის გასაღები მითითებული კვოტები და სიჩქარის შეზღუდვები. პასუხების მიღება ნებადართულია არაუმეტეს [N საათის] განმავლობაში, პირადი მონაცემების გარდა. ყველა სერვისის გენერირებული მონაცემი ეკუთვნის API მომწოდებელს; კლიენტი იღებს შეზღუდული შიდა გამოყენების ლიცენზიას. მიმწოდებელს უფლება აქვს შეცვალოს ან შეაჩეროს ნებისმიერი Endpoint, მიაწოდოს შეტყობინება EOL- ს მინიმუმ [9 თვის].

12. 3 სავარაუდო კოდის/დოქტის ლიცენზირება

💡 სავარაუდო კოდი და snippets ქვეყნდება MIT- ის ქვეშ; ტექსტური დოკუმენტაცია - CC BY-4. 0 (თუ სხვა რამ არ არის მითითებული). ბრენდის აქტივები - ბრენდის ცალკეული პოლიტიკის შესაბამისად.

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 და მოთამაშეთა მონაცემებს.

Contact

დაგვიკავშირდით

დაგვიკავშირდით ნებისმიერი კითხვის ან მხარდაჭერისთვის.ჩვენ ყოველთვის მზად ვართ დაგეხმაროთ!

ინტეგრაციის დაწყება

Email — სავალდებულოა. Telegram ან WhatsApp — სურვილისამებრ.

თქვენი სახელი არასავალდებულო
Email არასავალდებულო
თემა არასავალდებულო
შეტყობინება არასავალდებულო
Telegram არასავალდებულო
@
თუ მიუთითებთ Telegram-ს — ვუპასუხებთ იქაც, დამატებით Email-ზე.
WhatsApp არასავალდებულო
ფორმატი: ქვეყნის კოდი და ნომერი (მაგალითად, +995XXXXXXXXX).

ღილაკზე დაჭერით თქვენ ეთანხმებით თქვენი მონაცემების დამუშავებას.