التراخيص والقيود مفتوحة المصدر

1) لماذا برمجيات المصدر المفتوح في iGaming وأين المخاطر

تعمل OSS على تسريع تطوير النظام الأساسي (اللعبة الأمامية/الخلفية، وتكامل الدفع، ومكافحة الاحتيال، والتحليلات)، لكن أخطاء الترخيص تؤدي إلى إفشاء رمز مغلق، وحظر إطلاق ومنازعات مع مقدمي الخدمة. نحن بحاجة إلى: سياسة واضحة، وسجل للأقاليم التابعة (SBOM)، وعمليات مراجعة الحسابات والاختيار الصحيح للتراخيص.

2) خريطة الترخيص: الأنواع والمعنى

2. 1 متساهل

معهد ماساتشوستس للتكنولوجيا، BSD-2/3-Clause، Apache-2. 0

المسؤولية الأساسية هي الحفاظ على الإشعار/حقوق النشر Apache-2. 0 أيضًا منحة براءة الاختراع + «الإنهاء الدفاعي».
مناسب لـ: أطر واجهة المستخدم والمرافق وعملاء SDK ومكتبات قطع الأشجار/HTTP.

2. 2 ضعف حقوق الطبع والنشر

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

تتطلب تغييرات افتتاحية داخل المكتبة/الوحدة نفسها، ولكن ليس المشروع بأكمله.
عادة ما يُسمح بالربط الديناميكي مع LGPL إذا تم استيفاء الشروط (إمكانية استبدال المستخدم، الإشعارات).

2. 3 حقوق الطبع والنشر القوية

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

عند «الاتصال» برمجك، ينشأ الالتزام بالكشف عن العمل المشتق بموجب نفس الترخيص (شروط «التقسيم»، «إغلاق SaaS» إغلاق AGPL).
مخاطر الوحدات المغلقة من اللعبة الأساسية، ومكافحة الاحتيال، وبوابات الدفع.

3) الربط و «المنتج المشتق» (مبسط)

الارتباط الثابت مع GPL → خطر كبير للإصابة «بالعدوى».
عادة ما يُسمح بالربط الديناميكي مع → LGPL رهنا بشروط (قابلية الاستبدال والإشعارات).
IPC/REST/gRPC، العمليات الفردية → تقلل من مخاطر الأداء، ولكن لا تلغي التحليل (AGPL تعامل «عبر الشبكة» على أنها «اتصال»).
يتم تقييم الملحقات/النصوص → عن طريق التكامل الفعلي (ثبات واجهة برمجة التطبيقات، التحميل في مساحة العنوان).

4) براءات الاختراع وإخلاء المسؤولية

Apache-2. 0 منح ترخيص لبراءات اختراع صاحب البلاغ → يقلل من خطر مطالبات براءات الاختراع.
GPL-3. 0/AGPL-3. 0 لديها أوضاع مناهضة لبراءات الاختراع/مناهضة الالتفاف.
إذا كانت وحدتك ذات أهمية في براءة الاختراع (رياضيات RNG، خوارزميات مكافحة الاحتيال)، فتجنب التراخيص بدون منحة براءة اختراع أو أضف مواثيق براءات اختراع منفصلة إلى الاتفاقيات التجارية.

5) مسؤوليات برمجيات المصدر المفتوح: ما الذي يجب فعله بالضبط

حفظ الإشعارات/الإشعارات (السماح).
كشف عن تعديلات مكونات حقوق النشر (MPL/LGPL/GPL) وطريقة إعادة التجميع.
توفير المصادر عند توزيع الثنائيات لـ GPL/LGPL (والوصول إلى الشبكة لـ AGPL).
حدد الترخيص في صفحة About box/OSS Credits.
تتبع تراخيص الأطراف الثالثة في الشحنات (بائعو الألعاب/SDKs/منشآت الهاتف المحمول).

6) سياسة برمجيات المصدر المفتوح (الحد الأدنى الموصى به)

1. تصنيف التراخيص: أخضر (MIT/BSD/Apache/MPL)، أصفر (LGPL بشروط)، أحمر (GPL/AGPL/SSPL للأجزاء المغلقة).
2. عملية قبول المكونات: طلب تسجيل → التقييم القانوني والتقني → في مكتب خدمات الرقابة الداخلية → المراجعة الدورية للحسابات.
3. عزل حقوق الطبع والنشر: عملية منفصلة/خدمة مصغرة، حدود gRPC/HTTP، لا ربط ثابت.
4. بناء SBOM: لكل إصدار prod/stage.
5. الإخطارات والمصادر: التوليد التلقائي للإشعار/الطرف الثالث ونشر المصادر عند الاقتضاء.
6. المساهمات (المنبع): CLA/DCO، عدم وجود أسرار/براءات اختراع، التنسيق مع Legal.
7. الأمان: مسح نقاط الضعف، سياسة التصحيح، حظر الإصدارات الضعيفة «الدبوس» دون تنازل.

7) برمجيات المصدر المفتوح في مناطق iGaming النموذجية (أفضل الممارسات)

Game Math/RNG: تجنب GPL/AGPL ؛ تفضل الكود الخاص بك أو المكتبات المتساهلة.
واجهة المستخدم/العميل: رد فعل/Vue/bundlers - متساهل → حسنًا، راقب التراخيص والخطوط.
المدفوعات/CCM: SDK للبائعين الذين لديهم خدمات صارمة ؛ لا تختلط مع حقوق الطبع والنشر.
قابلية الرصد/عمليات التطوير: Prometheus/Grafana/Elastic - تأخذ في الاعتبار تراخيصها (جزء من وحدات غير برمجيات المصدر المفتوح) ؛ اقرأ شروط «جانب الخادم».
Antifraud/scoring: model/rules - propriality; الطرف الثالث - متساهل/معهد ماساتشوستس للتكنولوجيا/أباتشي.

8) مصفوفة التوافق (باختصار)

9) مصفوفة المخاطر (RAG)

10) القوائم المرجعية

قبل إضافة مكتبة

• رخصة المكتبة في القائمة الخضراء/الصفراء.
• التحقق من توافق الوصلة (ثابت/ديناميكي/IPC).
• SBOM + نسخة + مصدر.
• الإشعارات الصادرة (LICENSE/NOTCE).

قبل الإصدار

• SBOM لكل تجميع محفوظ (prod/stage).
• مر مسح الضعف ؛ حرج - مغلق أو تنازل.
• المصدر/البقع المطلوبة جاهزة للإصدار (إذا لزم الأمر).
• «أرصدة برمجيات المصدر المفتوح «/حول الصفحة المحدثة.

للتبرعات

• وقعت CLA/DCO.
• مراجعة لعدم وجود أسرار/براءات اختراع.
• حقوق النشر/حقوق النشر صحيحة.

11) سياسة برمجيات المصدر المفتوح (مقتطفات)

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/طرف ثالث

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 في وحدة مغلقة

ربط قائمة الجرد → خيار العزل/الاستبدال → فتوى قانونية → إصلاح الإصدار → الرجعية في العملية.

P-OSS-02: شرط المصدر

تحديد نطاق الالتزامات → وإعداد محفوظات وإشعارات → تحويلها في الوقت المحدد → تحديث الوثائق.

P-OSS-03: الضعف الشديد في حالة الاعتماد

Backport/update → إصدار → إخطار غير عادي → المهتمين بقواعد ما بعد البحر والتثبيت.

15) الأسئلة الشائعة المصغرة

هل يمكنني استخدام LGPL ؟ نعم، مع الربط الدينامي/التصنيف الدولي الموحد للبراءات والامتثال للشروط (قابلية الاستبدال والإخطارات).
AGPL على الخادم دون توزيع الثنائي - هل هو آمن ؟ لا: تتطلب AGPL توفير رمز المصدر للمستخدمين الذين يتفاعلون مع الخدمة عبر الشبكة.
هل أحتاج إلى منحة براءة اختراع ؟ مستصوب للوحدات ذات الابتكارات الحسابية ؛ Apache-2. 0 هو الأفضل.
هل يكفي تحديد برمجيات المصدر المفتوح على الموقع ؟ لا، اتبع جميع المتطلبات: الإخطارات والمصادر والتعليمات.

16)

العمل مع OSS هو عملية وليس فحصًا لمرة واحدة: معايير القبول، وعزل حقوق الطبع والنشر، والإشعارات الآلية، و SBOM كامل لكل تجميع. من خلال اتباع هذه المقالة، ستحافظ على سرعة التطوير وتجنب الفخاخ القانونية - من «حقوق الطبع والنشر للشبكة» إلى مطالبات براءات الاختراع.