ओपन सोर्स लाइसेंस और प्रतिबंध

1) 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

जब आपके कोड के साथ "कनेक्टिंग" होता है, तो दायित्व एक ही लाइसेंस के तहत व्युत्पन्न कार्य का खुलासा करने के लिए उत्पन्न होता है (शर्तें "टिवोइजेशन", "सास क्लोजर" एजीपीएल बंद)।

गेम कोर, एंटी-फ्रॉड, पेमेंट गेटवे के बंद मॉड्यूल के लिए जोखिम।

💡 अलग से: एसएसपीएल की तरह "छद्म-ओएसएस": पूरे सेवा स्टैक को खोलने की आवश्यकता है - इसे व्यावसायिक रूप से मालिकाना घटकों के साथ असंगत मानते हैं।

3) लिंकिंग और "व्युत्पन्न उत्पाद" (सरलीकृत)

जीपीएल के साथ स्थैतिक जुड़ ना - "संक्रमण" का एक उच्च जोखिम।

LGPL → के साथ गतिशील लिंकिंग को आमतौर पर शर्तों (प्रतिस्थापन, सूचनाओं) के अधीन होने की अनुमति है।

आईपीसी/आरईएसटी/जीआरपीसी, व्यक्तिगत प्रक्रियाएं - प्रदर्शन के जोखिम को कम करती हैं, लेकिन विश्लेषण को रद्द नहीं करती हैं (एजीपीएल "नेटवर्क पर" को "कनेक्शन" के रूप में मानता है)।

प्लगइन/स्क्रिप्ट का मूल्यांकन वास्तविक एकीकरण (एपीआई स्थिरता, पता स्थान में लोड करना) द्वारा किया जाता है।

4) पेटेंट और अस्वीकरण

Apache-2। 0 लेखक के पेटेंट का लाइसेंस देता है - पेटेंट के दावों के जोखिम को कम करता है।

GPL-3। 0/AGPL-3। 0 में एंटी-पेटेंट/एंटी-परिधि पदों हैं।

यदि आपका मॉड्यूल पेटेंट-महत्वपूर्ण है (आरएनजी गणित, धोखाधड़ी विरोधी एल्गोरिदम), तो पेटेंट अनुदान के बिना लाइसेंस से बचें या वाणिज्यिक समझौतों में अलग पेटेंट वाचा जोड़ें।

5) OSS जिम्मेदारियां: वास्तव में क्या करना है

सूचना/सूचना सहेजें (अनुमेय)।

कॉपीलेफ्ट घटकों (एमपीएल/एलजीपीएल/जीपीएल) और पुनर्मूल्यांकन विधि के संशोधनों को प्रकट करें।

जीपीएल/एलजीपीएल (और एजीपीएल के लिए नेटवर्क एक्सेस) के लिए बायनेरी वितरित करते समय स्रोत प्रदान करें।

अबाउट बॉक्स/OSS क्रेडिट पृष्ठ में लाइसेंस निर्दिष्ट करें।

शिपमेंट (गेम विक्रेताओं/एसडीके/मोबाइल बिल्ड) में तृतीय-पक्ष लाइसेंस ट्रैक करें।

6) प्लेटफ़ॉर्म OSS नीति (अनुशंसित न्यूनतम)

1. लाइसेंसों का वर्गीकरण: हरा (एमआईटी/बीएसडी/अपाचे/एमपीएल), पीला (शर्तों के तहत एलजीपीएल), लाल (बंद भागों के लिए जीपीएल/एजीपीएल/एसएसपीएल)।

2. घटक प्रवेश प्रक्रिया: SBOM आवधिक ऑडिट में अनुरोध - कानूनी और तकनीकी मूल्यांकन रिकॉर्ड।

3. कॉपीलेफ्ट अलगाव: अलग प्रक्रिया/माइक्रोसर्विस, जीआरपीसी/एचटीटीपी सीमा, कोई स्थिर लिंकिंग नहीं।

4. बिल्ड SBOM: प्रत्येक प्रोड/स्टेज रिलीज के लिए।

5. सूचनाएं और स्रोत: नोटिस/थर्ड-पार्टी की स्वचालित पीढ़ी और जहां आवश्यक हो स्रोतों का प्रकाशन।

6. योगदान (अपस्ट्रीम): सीएलए/डीसीओ, रहस्यों/पेटेंट की कमी, कानूनी के साथ समन्वय।

7. सुरक्षा: कमजोरियों को स्कैन करना, पैच पॉलिसी, बिना छूट के "पिन" कमजोर संस्करणों पर प्रतिबंध लगाना।

7) ठेठ iGaming क्षेत्रों में OSS (सर्वश्रेष्ठ अभ्यास)

खेल गणित/आरएनजी: जीपीएल/एजीपीएल से बचें; अपने स्वयं के कोड या अनुमेय पुस्तकालयों को पसंद करें।

UI/क्लाइंट: रिएक्ट/Vue/bundlers - अनुमेय - ओके, मॉनिटर लाइसेंस और फोंट।

भुगतान/सीसीएम: सख्त टीओएस के साथ विक्रेताओं का एसडीके; Copyleft के साथ मिश्रण न करें।

अवलोकन/DevOps: Prometheus/Grafana/Elastic - उनके लाइसेंस (गैर-OSS मॉड्यूल का हिस्सा) को ध्यान में रखें; "सर्वर साइड" स्थितियों को पढ़ें।

एंटीफ्राड/स्कोरिंग: मॉडल/नियम - मालिकाना; तृतीय-पक्ष लिब्स - अनुमेय/एमआईटी/अपाचे।

8) संगतता मैट्रिक्स (संक्षिप्त में)

आप उपयोग करते हैं... अपने बंद मॉड्यूल में एम्बेड करें	गतिशील लिंकिंग के माध्यम से	आईपीसी/एचटीटीपी के ऊपर	विज्ञापन नोटाटा
एमआईटी/बीएसडी/अपाचे	+	+	+
MPL-2। 0	️ (केवल संशोधित फ़ाइल का विस्तार क	+	+
LGPL-2। 1/3. 0	️ (अवांछनीय स्थिर रूप से)	+	+
GPL-2। 0/3. 0	-	- (बहस करने योग्य)	️ (सेवा को अलग करें)
AGPL-3। 0	-	-	-/ ️ (नेटवर्क कॉपीलेफ्ट)
एसएसपीएल	-	-	-

9) जोखिम मैट्रिक्स (आरएजी)

जोखिम	आर (महत्वपूर्ण)	A (सुधारा जाना है)	जी (सामान्य)
कॉपीलेफ्ट-घटक	मोनोलिथ के अंदर GPL/AGPL	एलजीपीएल कोई शर्त नहीं	अनुमेय/एमपीएल + अलगाव
कर्तव्य	कोई सूचना/स्रोत नहीं	आंशिक रूप से	पूर्ण सेट, स्वचालन
SBOM	अनुपस्थित है	अपूर्ण, कोई संस्करण नहीं	पूर्ण, प्रति विधानसभा, कगार पर
योगदान (ऊपर की ओर)	कोई सीएलए/डीसीओ, लीक रहस्य	आंशिक रूप से	सीएलए/डीसीओ, कानूनी समीक्षा
पेटेंट	कोई पेटेंट वाचा नहीं	स्पष्ट नहीं	Apache-2। 0/जोड़ें। वाचाएं
ओएसएस सुरक्षा	पैच लागू नहीं होते हैं	धीमे तरीके से	एसएलए भेद्यता नीति

10) चेकलिस्ट

लाइब्रेरी जोड़ ने से पहले

हरे/पीले रंग की सूची में पुस्तकालय लाइसेंस।
लिंक संगतता (स्थिर/गतिशील/आईपीसी) सत्यापित।
SBOM + संस्करण + स्रोत।
उत्पन्न सूचनाएं (लाइसेंस/नोटिस)।

रिलीज से पहले

SBOM प्रति विधानसभा बचाया (prod/stage)।
भेद्यता स्कैन पारित; महत्वपूर्ण - बंद या छूट।
आवश्यक स्रोत/पैच जारी किए जाने के लिए तैयार हैं (यदि आवश्यक हो)।
"OSS क्रेडिट "/पृष्ठ अद्यतन के बारे में।

योगदान के लिए

सीएलए/डीसीओ ने हस्ताक्षर किए।
रहस्यों/पेटेंट की कमी के लिए समीक्षा करें।
कॉपीराइट/कॉपीराइट सही है।

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 कॉपीलेफ्ट का अलगाव

अलग सेवा, नेटवर्क इंटरफ़ेस, बायनेरीज़का कोई संयोजन नहीं, कोई स्थिर लिंकिंग नहीं।

लाइब्रेरी बिल्ड और अपग्रेड प्रलेखन (एलजीपीएल/एमपीएल)।

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) सुरक्षा और अनुपालन

CI में SCA/SAST, नई निर्भरता का ऑटोस्कैन।

पैच पॉलिसी: P1 कमजोरियां - ≤72 घंटे, P2 - ≤14 दिन।

आर्टिफ़ैक्ट कैश: मूल लाइसेंस/नोटिस रखें; अखंडता (हैश) की जाँच करें।

निर्यात/मंजूरी: प्रतिबंधित देशों के घटकों/दर्पणों का उपयोग न करें; लॉग चेक।

14) प्लेबुक (परिचालन परिदृश्य)

P-OSS-01: बंद मॉड्यूल में जीपीएल का पता चला

लिंक इन्वेंट्री → अलगाव/प्रतिस्थापन विकल्प → कानूनी राय → प्रक्रिया पर फिक्स → रेट्रो जारी करें।

P-OSS-02: स्रोत की आवश्यकता

दायित्वों का दायरा निर्धारित करें → अभिलेखागार तैयार करें और नोटिस → समय पर हस्तांतरण → अद्यतन दस्तावेज।

P-OSS-03: निर्भरता में महत्वपूर्ण भेद्यता

बैकपोर्ट/अपडेट असाधारण रिलीज रुचि की अधिसूचना - पोस्ट-सी और पिनिंग नियम।

15) मिनी-एफएक्यू

क्या मैं एलजीपीएल का उपयोग कर सकता हूं? हां, गतिशील लिंकिंग/आईपीसी के साथ और शर्तों के अनुपालन (प्रतिस्थापन, सूचनाएं)।

बाइनरी वितरित किए बिना सर्वर पर AGPL - क्या यह सुरक्षित है? नहीं: AGPL को नेटवर्क पर सेवा के साथ बातचीत करने वाले उपयोगकर्ताओं को स्रोत कोड प्रदान करने की आवश्

क्या मुझे पेटेंट अनुदान की आवश्यकता है? एल्गोरिथम नवाचारों के साथ मॉड्यूल के लिए वांछनीय; Apache-2। 0 बेहतर है।

क्या यह साइट पर OSS निर्दिष्ट करने के लिए पर्याप्त है? नहीं, सभी आवश्यकताओं का पालन करें: सूचनाएं, स्रोत, निर्देश।

16) निष्कर्ष

OSS के साथ काम करना एक प्रक्रिया है, एक बार की जांच नहीं: प्रवेश मानक, कॉपीलेफ्ट अलगाव, स्वचालित सूचनाएं और प्रति विधानसभा एक पूर्ण SBOM। इस लेख का पालन करके, आप विकास की गति को बनाए रखेंगे और कानूनी जाल से बचेंगे - "नेटवर्क कॉपीलेफ्ट" से लेकर पेटेंट दावों तक।

ओपन सोर्स लाइसेंस और प्रतिबंध

रिलीज से पहले

योगदान के लिए

हमसे संपर्क करें

त्वरित संपर्क

वीडियो जल्द ही अपडेट किया जाएगा

हम इस समय परियोजनाओं में बहुत व्यस्त हैं