مجوزها و محدودیت های منبع باز

1) چرا OSS در iGaming و خطرات آن چیست ؟

OSS توسعه پلتفرم (جلو/عقب بازی، ادغام پرداخت، ضد تقلب، تجزیه و تحلیل) را تسریع می کند، اما خطاهای صدور مجوز منجر به افشای کد بسته، مسدود کردن انتشار و اختلافات با ارائه دهندگان می شود. ما نیاز داریم: یک سیاست روشن، ثبت وابستگی ها (SBOM)، فرآیندهای حسابرسی و انتخاب صحیح مجوزها.

2) نقشه مجوز: انواع و معنی

2. 1 مجاز است

MIT، 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» نزدیک AGPL).
خطر برای ماژول های بسته هسته بازی، ضد تقلب، دروازه های پرداخت.

3) پیوند و «محصول مشتق شده» (ساده شده)

ارتباط استاتیک با GPL → خطر بالای «عفونت».
پیوند پویا با LGPL معمولاً با توجه به شرایط (جایگزینی، اعلان ها) مجاز است.
IPC/REST/gRPC، فرآیندهای فردی → خطر عملکرد را کاهش می دهد، اما تجزیه و تحلیل را لغو نمی کند (AGPL رفتار «بیش از شبکه» به عنوان «اتصال»).
پلاگین ها/اسکریپت ها → توسط ادغام واقعی ارزیابی (ثبات API, بارگذاری به فضای آدرس).

4) اختراعات و سلب مسئولیت

Apache-2 است. 0 می دهد صدور مجوز از اختراع ثبت شده نویسنده → خطر ادعاهای ثبت اختراع را کاهش می دهد.
GPL-3 است. 0/AGPL-3 است. 0 موقعیت ضد ثبت اختراع/ضد دور زدن دارند.
اگر ماژول شما دارای حق ثبت اختراع است (ریاضیات RNG، الگوریتم های ضد تقلب)، از مجوزهای بدون اعطای حق ثبت اختراع جلوگیری کنید یا میثاق های جداگانه ای را برای موافقت نامه های تجاری اضافه کنید.

5) مسئولیت های OSS: دقیقا چه کاری باید انجام شود

صرفه جویی در اعلان ها/NOTICE (permisisve).
تغییرات اجزای copyleft (MPL/LGPL/GPL) و روش مونتاژ مجدد را نشان دهید.
هنگام توزیع باینری برای GPL/LGPL (و دسترسی به شبکه برای AGPL) منابع را فراهم کنید.
مجوز را در مورد جعبه/OSS اعتبار صفحه مشخص کنید.
پیگیری مجوزهای شخص ثالث در حمل و نقل (فروشندگان بازی/SDKs/تلفن همراه).

6) سیاست OSS پلت فرم (حداقل توصیه می شود)

1. طبقه بندی مجوزها: سبز (MIT/BSD/Apache/MPL)، زرد (LGPL تحت شرایط)، قرمز (GPL/AGPL/SSPL برای قطعات بسته).
2. فرایند پذیرش جزء: درخواست → ارزیابی حقوقی و فنی → ثبت در SBOM → حسابرسی دوره ای.
3. جداسازی Copyleft: فرایند جداگانه/میکروسرویس، مرز gRPC/HTTP، بدون اتصال استاتیک.
4. ساخت SBOM: برای هر تولید/مرحله انتشار.
5. اطلاعیه ها و منابع: تولید خودکار NOTICE/THIRD PARTY و انتشار منابع در صورت لزوم.
6. مشارکت (بالادست): CLA/DCO، عدم اسرار/اختراع ثبت شده، هماهنگی با حقوقی.
7. امنیت: اسکن آسیب پذیری ها، سیاست پچ، ممنوعیت نسخه های آسیب پذیر «پین» بدون چشم پوشی.

7) OSS در مناطق iGaming معمولی (بهترین عمل)

ریاضی بازی/RNG: اجتناب از GPL/AGPL ؛ کد خود یا کتابخانه های مجاز را ترجیح می دهید.
UI/client: React/Vue/bundlers - مجاز → خوب، نظارت بر مجوزها و فونت ها.
پرداخت/CCM: SDK از فروشندگان با ToS سخت ؛ با Copyleft مخلوط نکنید.
قابلیت مشاهده/DevOps: Prometheus/Grafana/Elastic - مجوزهای آنها را در نظر بگیرید (بخشی از ماژول های غیر OSS) ؛ شرایط «سمت سرور» را بخوانید.
Antifraud/امتیاز دهی: مدل/قوانین - اختصاصی ؛ شخص ثالث libs - مجاز/MIT/آپاچی.

8) ماتریس سازگاری (به طور خلاصه)

9) ماتریس ریسک (RAG)

10) چک لیست

قبل از اضافه کردن کتابخانه

• مجوز کتابخانه در لیست سبز/زرد.
• سازگاری لینک (استاتیک/پویا/IPC) تایید شده است.
• SBOM + نسخه + منبع.
• اطلاعیه های تولید شده (LICENSE/NOTICE).

قبل از انتشار

• SBOM در هر مجمع ذخیره شده (تولید/مرحله).
• اسکن آسیب پذیری گذشت ؛ بحرانی - بسته و یا چشم پوشی.
• منبع مورد نیاز/تکه آماده صادر می شود (در صورت نیاز).
• «اعتبار OSS «/درباره صفحه به روز شد.

برای کمک

• 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/شخص ثالث

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 ثبت سپرده (بالادست)

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، autoscan وابستگی های جدید.
خط مشی پچ: آسیب پذیری های P1 - ≤72 ساعت، P2 - ≤14 روز.
کش مصنوعی: LICENSE/NOTICE اصلی را نگه دارید ؛ بررسی یکپارچگی (هش).

صادرات/تحریم: از اجزای/آینه از کشورهای ممنوعه استفاده نکنید ؛ چک های ورودی

14) کتاب های بازی (سناریوهای عملیاتی)

P-OSS-01: GPL در ماژول بسته شناسایی شده است

Link inventory → isolation/replacement option → legal opinion → release fix → یکپارچهسازی با سیستمعامل در فرایند.

P-OSS-02: منبع مورد نیاز

تعیین محدوده تعهدات → آماده سازی آرشیو و NOTICE → انتقال در زمان → به روز رسانی اسناد.

P-OSS-03: آسیب پذیری بحرانی در وابستگی

Backport/update → انتشار فوق العاده → اطلاع رسانی از علاقه مند → قوانین پس از دریا و پینینگ.

15) مینی سوالات متداول

آیا می توانم از LGPL استفاده کنم ؟ بله، با اتصال پویا/IPC و انطباق با شرایط (جایگزینی، اطلاعیه ها).
AGPL در سرور بدون توزیع باینری - امن است? خیر: AGPL نیاز به ارائه کد منبع به کاربران در تعامل با سرویس از طریق شبکه دارد.
آیا به کمک هزینه ثبت اختراع نیاز دارم ؟ مطلوب برای ماژول هایی با نوآوری های الگوریتمی ؛ Apache-2 است. 0 ترجیح داده می شود.
آیا تعیین OSS در سایت کافی است ؟ نه، تمام الزامات را دنبال کنید: اطلاعیه ها، منابع، دستورالعمل ها.

16) نتیجه گیری

کار با OSS یک فرآیند است، نه یک بار بررسی: استانداردهای پذیرش، جداسازی کپی لفت، اطلاعیه های خودکار و SBOM کامل در هر مونتاژ. با پیروی از این مقاله، شما سرعت توسعه را حفظ خواهید کرد و از تله های قانونی اجتناب خواهید کرد - از «copyleft شبکه» به ادعاهای ثبت اختراع.