רישיונות קוד פתוח והגבלות

1) מדוע OSS ב ־ iGaming והיכן הסיכונים

OSS מאיץ פיתוח פלטפורמה (משחק קדמי/אחורי, שילוב תשלומים, אנטי הונאה, אנליטיקה), אך שגיאות רישוי מובילות לגילוי קוד סגור, שחרור חסימות ומחלוקות עם ספקים. אנחנו צריכים: מדיניות ברורה, רישום של תלויות (SBOM), תהליכי ביקורת ובחירה נכונה של רישיונות.

2) מפת רישיון: סוגים ומשמעות

2. 1 מתירני

אם-איי-טי, BSD-2/3-Clause, Apache-2. 0

האחריות העיקרית היא לשמור על ההודעה/זכויות יוצרים Apache-2. 0 גם מענק פטנט + ”סיום הגנתי”.
מתאים: מסגרות UI, תשתיות, לקוחות SDK, ספריות רישום/HTTP.

2. 2 זכיונות חלשים

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

דרוש שינויים פתיחה בתוך הספרייה/מודול עצמו, אבל לא כל הפרויקט.
קישור דינמי עם LGPL מותר בדרך כלל אם מתקיימים התנאים (החלפת משתמש, הודעות).

2. 3 זכיונות חזקים

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

כאשר ”מתחבר” עם הקוד שלך, החובה עולה לחשוף את העבודה הנגזרת תחת אותו רישיון (התנאים ”tivoization”, ”SaaS clock” close AGPL).
סיכון למודולים סגורים של ליבת המשחק, אנטי הונאה, שערי תשלום.

3) קישור ו ”מוצר נגזרת” (מפושט)

קשר סטטי עם GPL = סיכון גבוה של ”זיהום”.
קישור דינמי עם LGPL # מותר בדרך כלל בכפוף לתנאים (החלפה, הודעות).
IPC/REST/gRPC, תהליכים בודדים, מפחיתים את הסיכון לביצועים, אך לא מבטלים את הניתוח (AGPL מתייחס ”מעל הרשת” כ ”חיבור”).
תוספים/תסריטים מוערכים על ידי אינטגרציה ממשית (יציבות API, טעינה לתוך מרחב הכתובות).

4) פטנטים ומכתבי ויתור

Apache-2. 0 נותן רישוי הפטנטים של המחבר מפחית את הסיכון של תביעות פטנטים.
GPL-3. 0/AGPL-3. ל-0 יש עמדות אנטי-פטנט/אנטי-עקיפה.
אם המודול שלך הוא פטנט משמעותי (מתמטיקה RNG, אלגוריתמים נגד הונאה), להימנע מרישיונות ללא מענק פטנט או להוסיף בריתות פטנט נפרדות להסכמים מסחריים.

5) אחריות אוס: מה בדיוק לעשות

שמור הודעות/הודעה (מותרת).
חשיפת השינויים של רכיבי copyleft (MPL/LGPL/GPL) ושיטת ההרכבה מחדש.
ספק מקורות בעת הפצת Binaries עבור GPL/LGPL (וגישה לרשת עבור AGPL).
ציין את הרישיון בדף ה ־ About Box/OSS Credits.
רשיונות צד שלישי במשלוחים (ספקי משחק/SDKs/mobile builds).

6) מדיניות Platform OSS (מינימום מומלץ)

1. סיווג רישיונות: ירוק (MIT/BSD/Apache/MPL), צהוב (LGPL בתנאים), אדום (GPL/AGPL/SSPL לחלקים סגורים).
2. הליך קבלת רכיבים: בקשה להערכה משפטית וטכנית # רשומה בביקורת תקופתית של SBOM.
3. בידוד Copyleft: תהליך נפרד/מיקרו-רוויס, גבול gRPC/HTTP, ללא קישור סטטי.
4. לבנות SBOM: עבור כל פרוד/שלב שחרור.
5. הודעות ומקורות: דור אוטומטי של התראה/צד שלישי ופרסום של מקורות במידת הצורך.
6. תרומות (במעלה הזרם): CLA/DCO, חוסר סודות/פטנטים, תיאום עם Legal.
7. אבטחה: סריקת נקודות תורפה, מדיניות תיקון, איסור על גירסאות פגיעות ללא ויתור.

7) OSS באזורי iGaming טיפוסיים (בפועל הטוב ביותר)

מתמטיקת משחק/RNG: הימנע מ ־ GPL/AGPL; מעדיף את הקוד שלך או ספריות מתירניות.
UI/לקוח: React/Vue/Bundlers - מתירני = ok, מנטר רישיונות וגופנים.
תשלומים/CCM: SDK של ספקים עם TOS קפדני; לא לערבב עם copyleft.
Observability/DevOps: Prometheus/Grafana/Elastic - לקחת בחשבון את הרישיונות שלהם (חלק ממודולים שאינם OSS); קרא תנאי ”צד שרת”.
אנטי-פראוד/ניקוד: מודל/כללים - קניין; צד שלישי, מתירני/אם-איי-טי-איי-אפאצ 'י.

8) מטריקס תאימות (בקיצור)

9) מטריקס סיכון (RAG)

10) רשימות בדיקה

לפני הוספת ספרייה

[ רישיון ספריית ] ברשימה הירוקה/צהובה.

[ ] תאימות קישור (סטטית/דינמית/IPC) מאומתת.

[ ] SBOM + גירסה + מקור.

[ ] נוצר הודעות (רישיון/הודעה).

לפני השחרור

[ ] SBOM להרכבה נשמר (prod/stage).

[ ] סריקת פגיעות עברה; קריטי - סגור או ויתור.

[ ] המקור/טלאים הדרושים מוכנים להנפקה (במקרה הצורך).

[ ] "OSS Credits'/על דף מעודכן.

לתרומות

[ ] 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 בידוד copyleft

שירות נפרד, ממשק רשת, אין שילוב של בינאריות, אין קישור סטטי.
Library Build and Digrade Documentation (LGPL/MPL).

12) רשמים (תבניות YAML)

12. 1 SBOM/צד שלישי

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-אס-אס לגילוי

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 רשום הפקדה (במעלה הזרם)

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 ימים.
מטמון חפץ: שמור את הרישיון המקורי/הודעה; בדוק שלמות (חשיש).
ייצוא/סנקציה: אל תשתמש ברכיבים/מראות ממדינות אסורות; בדיקת יומן.

14) ספרי משחק (תרחישים מבצעיים)

P-OSS-01: GPL זוהה במודול סגור

Link Reventory # Bodiation/surface option # legal experience # liew retro on pro

P-OSS-02: דרישת המקור

קבעו את היקף החובות * הכינו ארכיונים ו-INTEGEPT # העברה על תיעוד עדכון זמן.

P-OSS-03: פגיעות קריטית בתלות

Backport/עדכון # הודעה יוצאת מן הכלל על התעניינות בחוקים שלאחר הים ותיקונים.

15) מיני ־ FAQ

אני יכול להשתמש ב-LGPL? כן, עם קישור דינמי/IPC וציות לתנאים (החלפה, הודעות).
AGPL בשרת מבלי להפיץ את הבינארי - האם זה בטוח? לא: AGPL דורש מתן קוד מקור למשתמשים באינטראקציה עם השירות מעל הרשת.
אני צריך מענק פטנט? רצוי למודולים עם חידושים אלגוריתמיים; Apache-2. 0 זה עדיף.
האם זה מספיק כדי לציין OSS באתר? לא, בצע את כל הדרישות: הודעות, מקורות, הוראות.

16) מסקנה

עבודה עם OSS היא תהליך, לא בדיקה חד פעמית: תקני כניסה, בידוד copyleft, הודעות אוטומטיות, ו-SBOM להרכבה מלאה. אם תעקוב אחר מאמר זה, תוכל לשמור על מהירות ההתפתחות ולהימנע ממלכודות חוקיות - החל ב ”רשת זכויות יוצרים” וכלה בתביעות פטנטים. ‏