डच आणि युरोपियन युनियन कायद्यांतर्गत ओपन सोर्स सॉफ्टवेअर परवाने

जवळपास प्रत्येक व्यावसायिक सॉफ्टवेअर उत्पादनामध्ये ओपन सोर्स घटक असतात, सहसा शेकडो, जे वकिलांऐवजी डेव्हलपर्सद्वारे निवडले जातात. जेव्हा कोणते परवाने लागू होतात, त्यांच्या आवश्यकता काय आहेत आणि उत्पादन त्यांचे पालन करते की नाही, हे कोणीही निश्चितपणे सांगू शकत नाही, तेव्हा ही एक समस्या बनते. हा लेख डच आणि युरोपियन युनियनच्या कायद्यानुसार ओपन सोर्स परवाने कसे काम करतात, त्यात धोका कोठे आहे आणि कोणती व्यवस्था करणे आवश्यक आहे, हे स्पष्ट करतो.

कायदेशीर भाषेत ओपन सोर्स लायसन्स म्हणजे काय

ओपन सोर्स परवाना हा अटींच्या अधीन राहून दिलेला कॉपीराइट परवाना आहे. हा हक्कांचा त्याग नाही, सार्वजनिक डोमेनला समर्पित करणे नाही, किंवा हक्क सोडून देणे नाही, आणि या बाबतीत तो डच कायद्यानुसार इतर कोणत्याही सॉफ्टवेअर परवान्याप्रमाणेच कार्य करतो . लेखक कलम १ Aw आणि कलम १० Aw अंतर्गत कॉपीराइट राखून ठेवतो, जे संगणक प्रोग्राम्सना 'कृती' म्हणून संरक्षित करते, आणि हा परवाना अशा कृतींना परवानगी देतो ज्या अन्यथा कलम १२ Aw आणि कलम १३ Aw अंतर्गत असलेल्या विशेष हक्कांचे उल्लंघन करतील.

व्याख्येपेक्षा परिणाम अधिक महत्त्वाचा आहे. पालन केल्यास, तुमची प्रत बनवणे आणि वितरण करणे कायदेशीर ठरते. पालन न केल्यास, परवानगी तुमच्या कृतीला लागू होत नाही: तुमचा वापर हा कॉपीराइटचे उल्लंघन ठरतो, कराराचा भंग नाही. बहुतेक कॉपीलेफ्ट परवाने उल्लंघन झाल्यावर आपोआप संपुष्टात येऊन या गोष्टीला बळकटी देतात — GPLv2 मध्ये दुरुस्तीसाठी कोणताही कालावधी दिला जात नाही, तर GPLv3 आणि AGPLv3 मध्ये, सूचना दिल्यानंतर एका निश्चित कालावधीत उल्लंघनाची दुरुस्ती केल्यास अधिकार पुन्हा प्रस्थापित केले जातात.

डच न्यायालये हाच युक्तिवाद लागू करतात. आरबी मध्ये. Amsterdam २२ सप्टेंबर २०२० रोजी, ECLI:NL:RBAMS:2020:4717, एका फोर्क केलेल्या कोडबेसमधून परवाना मजकूर आणि कॉपीराइट सूचना काढून टाकणाऱ्या वितरकाने आपली परवानगी गमावली आहे आणि तो उल्लंघन करत आहे, असे ठरवण्यात आले. मोठ्या प्रमाणात नवीन कोड जोडल्याने एक स्वतंत्र कार्य तयार झाले नाही: मूळ कोड ओळखण्यायोग्यरित्या उपस्थित राहिला, त्यामुळे जबाबदाऱ्या त्याच्यासोबतच राहिल्या.

दोन कुटुंबे: अनुज्ञेयवादी आणि कॉपीलेफ्ट

उदार परवाने — एमआयटी, बीएसडी परवाने, अपाचे २.० — हे कॉपीराइट सूचना आणि परवान्याचा मजकूर जतन करण्याच्या अटीवर, क्लोज्ड-सोर्स उत्पादनांमध्येही वापर, सुधारणा आणि पुनर्वितरणास परवानगी देतात.

कॉपीलेफ्ट परवानग्यांनुसार , जेव्हा तुम्ही सॉफ्टवेअर किंवा त्यावर आधारित काही वितरित करता, तेव्हा ते त्याच परवान्याअंतर्गत करणे आणि संबंधित सोर्स कोड उपलब्ध करून देणे आवश्यक असते. त्यांची व्याप्ती वेगवेगळी असते.

कॉपीलेफ्ट ट्रिगर आणि लिंकिंग प्रश्न

कॉपीलेफ्टचे निर्बंध वितरणावर लागू होतात, वापरावर नाही. एखादी कंपनी, जीपीएल सॉफ्टवेअर अंतर्गत वापरासाठी घेत असेल, मग त्यात कितीही बदल केले असले तरी, ती काहीही वितरित करत नाही आणि तिची कोणतीही जबाबदारी नसते. “आपण वितरण केले आहे का?” हा नेहमीच पहिला प्रश्न असतो, आणि म्हणूनच अंतर्गत साधनांपेक्षा कंटेनर्स, अप्लायन्सेस, फर्मवेअर आणि एसडीके अधिक महत्त्वाचे ठरतात.

दुसरा प्रश्न अधिक कठीण आहे. जीपीएल (GPL) ‘कार्यक्रमावर आधारित कार्य’ असा उल्लेख करते, ज्यासाठी अमेरिकन ‘डेरिव्हेटिव्ह वर्क’ (derivative work) ही संकल्पना वापरली आहे. डच कायद्यात अशी कोणतीही संज्ञा नाही: विश्लेषण पुनरुत्पादन आणि अनुकूलन हक्कांच्या आधारे केले जाते, आणि मूळ कृतीमधील संरक्षित अभिव्यक्तीचे पुनरुत्पादन झाले आहे का, हे तपासले जाते.

व्यावहारिक उदाहरण म्हणजे लिंकिंग. एखाद्या मालकी हक्काच्या मॉड्यूलला GPL लायब्ररीशी लिंक केल्याने कॉपीलेफ्टच्या अधीन असलेले एकच कार्य तयार होते की नाही, यावर डच न्यायालयाने कधीही निर्णय दिलेला नाही आणि युरोपियन युनियनचा (EU) कोणताही बंधनकारक अधिकार नाही. लिंकिंगमुळे एक संयुक्त कार्य तयार होते, हे फ्री सॉफ्टवेअर फाउंडेशनचे मत परवाना व्यवस्थापकाचे (licence steward) अन्वयार्थ आहे, कायदा नाही, आणि याच्या विरुद्धचे मतही तितकेच अप्रमाणित आहे. इंटरनेटवर सर्वाधिक प्रचलित असलेले उत्तर — डायनॅमिक लिंकिंग सुरक्षित, स्टॅटिक लिंकिंग नाही — याला डच कॉपीराइट कायद्यात कोणताही आधार नाही, कारण तो कंपायलर कसे वागतो हे विचारत नाही. अधिक समर्थनीय विश्लेषण हे विचारते की घटक किती जवळून एकत्र जोडलेले आहेत: ते एकच ॲड्रेस स्पेस आणि डेटा स्ट्रक्चर्स वापरतात का, हे संयोजन एकच उत्पादन म्हणून पाठवले जाते का, दोन्हीपैकी एक स्वतंत्रपणे कार्य करू शकते का, मालकी हक्काची बाजू कॉपीलेफ्ट बाजूकडून हेडर, मॅक्रो किंवा इनलाइन कोडची नक्कल करते का? हे प्रश्न सहसा धोका दूर करतात. जिथे ते धोका दूर करत नाहीत, तिथे त्या घटकाला प्रोसेस बाउंड्रीच्या मागे वेगळे करा, तो बदला किंवा व्यावसायिक परवाना घ्या.

एजीपीएल आणि नेटवर्क वापर

AGPL अस्तित्वात आहे कारण वितरणामुळे कॉपीलेफ्ट लागू होतो आणि SaaS प्रदाते वितरण करत नाहीत. त्याच्या नेटवर्क कलमानुसार, जर तुम्ही सॉफ्टवेअरमध्ये बदल करून ते दूरस्थपणे वापरणाऱ्या वापरकर्त्यांना उपलब्ध करून दिले, तर तुम्ही त्यांना तुमच्या बदललेल्या आवृत्तीचा संबंधित सोर्स कोड देणे आवश्यक आहे.

तीन मुद्दे सहसा दुर्लक्षित केले जातात. हे बंधन सेवेच्या वापरकर्त्यांवर येते, जे ओपन-साइनअप उत्पादनामध्ये फारसा दिलासा देत नाही. हे बदलामुळे लागू होते, त्यामुळे न बदललेला घटक ते लागू करत नाही, परंतु पॅच केलेला बिल्ड ते लागू करू शकतो. आणि यामुळे तुमच्या उर्वरित स्टॅकसाठी GPL प्रमाणेच एकत्रित-कामाचा प्रश्न निर्माण होतो — म्हणूनच अनेक कंपन्या प्रोडक्शन कोडमध्ये AGPL वर बंदी घालतात.

परवाना सुसंगतता

सुसंगतता म्हणजे अशा घटकांना एकत्र करण्याची समस्या, ज्यांच्या परवानग्या अशा जबाबदाऱ्या लादतात ज्या एकाच वितरणात पूर्ण केल्या जाऊ शकत नाहीत: परवानगी देणाऱ्या परवानग्या जवळजवळ प्रत्येक गोष्टीशी सुसंगत असतात, तर कॉपीलेफ्ट परवानग्या केवळ त्यांच्या स्वतःच्या अटींनी परवानगी दिलेल्या गोष्टींशीच सुसंगत असतात. याचे एक मानक उदाहरण म्हणजे अपाचे २.० आणि जीपीएलव्ही२ (GPLv2). अपाचे सॉफ्टवेअर फाउंडेशन आणि फ्री सॉफ्टवेअर फाउंडेशन या दोन्ही संस्था या संयोजनास परवानगी नाही यावर सहमत आहेत, कारण अपाचे २.० मधील पेटंट समाप्ती आणि नुकसानभरपाईच्या तरतुदी हे अतिरिक्त निर्बंध आहेत, ज्यांना जीपीएलव्ही२ परवानगी देत ​​नाही. जीपीएलव्ही३ (GPLv3) ची रचना त्यांना स्वीकारण्यासाठीच केली गेली होती. सुसंगतता ही दिशात्मक देखील आहे: अपाचे कोड जीपीएलव्ही३ (GPLv3) प्रकल्पात सामावून घेतला जाऊ शकतो, परंतु याउलट शक्य नाही. चुकीच्या ठिकाणी असलेला एक जीपीएल (GPL) घटक पुनर्परवाना, पुनर्रचना किंवा काढून टाकणे यापैकी एक निवड करण्यास भाग पाडू शकतो — जे प्रकाशनानंतर करण्यापेक्षा प्रकाशनापूर्वी खूपच स्वस्त पडते.

श्रेय देणे आणि सूचना देण्याची बंधने

सर्वात जास्त वेळा उल्लंघन होणारी बंधने ही सर्वात कमी गंभीर असतात: वितरणासोबतच्या साहित्यामध्ये कॉपीराइट सूचना, परवाना मजकूर, अस्वीकरणे आणि, अपाचे २.० अंतर्गत, NOTICE मधील मजकूर पुन्हा छापणे. एमआयटी (MIT) आणि बीएसडी (BSD) सह प्रत्येक प्रणाली ही बंधने लागू करते. त्यांचे उल्लंघन होते कारण त्यांची मालकी कोणाकडेही नसते, आणि ती दुरुस्त करणे सर्वात सोपे असते — सहसा उत्पादनासोबत पाठवलेल्या एका तयार केलेल्या श्रेयनिर्देश फाईलद्वारे. वरील डच प्रकरण नेमक्या याच चुकीमुळे घडले.

पेटंट मंजुरी आणि पेटंट प्रतिशोध

एमआयटी आणि बीएसडी पेटंटबद्दल काहीही सांगत नाहीत, आणि पेटंट परवाना अंतर्भूत मानला जाऊ शकतो की नाही हे अनिर्णित आहे. अपाचे २.० ने प्रत्येक योगदानकर्त्यासाठी एक स्पष्ट, रॉयल्टी-मुक्त पेटंट परवाना जोडला, ज्यासोबत एक प्रतिशोध कलमही होते: तुमच्या कामामुळे पेटंटचे उल्लंघन होत असल्याचा आरोप करून पेटंट खटला दाखल केल्यास, तुमचा पेटंट परवाना रद्द होईल. जीपीएलव्ही३ (GPLv3) मध्ये एक तुलनात्मक अनुदान आणि स्वतःच्या पेटंट तरतुदी आहेत.

पेटंट पोर्टफोलिओ असलेल्या कंपन्यांसाठी याचे दोन परिणाम आहेत. जर तुमचे अभियंते अपाचे- किंवा GPLv3-परवानाधारक प्रकल्पांमध्ये योगदान देत असतील, तर तुम्ही तुमच्या स्वतःच्या पेटंट्सअंतर्गत परवाने देत आहात. आणि जर तुम्ही कधी अशा कंपनीविरुद्ध पेटंटचा दावा केला, जी तुम्ही वापरत असलेल्या त्याच अपाचे-परवानाधारक घटकांवर अवलंबून आहे, तर प्रतिशोधात्मक कारवाईमुळे तुम्हाला तुमचा महत्त्वाचा परवाना गमवावा लागू शकतो.

ईयूपीएल आणि डच सार्वजनिक क्षेत्र

युरोपियन कमिशनने मे २०१७ मध्ये अंमलबजावणी निर्णयाद्वारे मंजूर केलेला युरोपियन युनियन पब्लिक लायसन्स आवृत्ती १.२, हा तीन वैशिष्ट्यपूर्ण गुणधर्म असलेला OSI-मान्यताप्राप्त कॉपीलेफ्ट लायसन्स आहे.

• भाषा ते युरोपियन युनियनच्या अधिकृत भाषांमध्ये उपलब्ध आहे, आणि त्याच्या सर्व मान्यताप्राप्त आवृत्त्यांचे मूल्य एकसारखेच आहे, त्यामुळे डच प्राधिकरण डच भाषेत करार करू शकते.
• सुसंगतता. एका परिशिष्टात सुसंगत परवान्यांची यादी दिली आहे — त्यामध्ये GPLv2 आणि v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL आणि CeCILL यांचा समावेश आहे — आणि EUPL कोडला सूचीबद्ध परवान्याखालील कोडसह एकत्रित करून तयार केलेले व्युत्पन्न कार्य त्याऐवजी त्या परवान्याअंतर्गत वितरित करण्याची परवानगी देते.
• पोहोच. वितरणाच्या व्याख्येमध्ये एखादे कार्य ऑनलाइन किंवा ऑफलाइन उपलब्ध करून देण्याचा समावेश होतो. किंवा त्याच्या आवश्यक कार्यप्रणालींमध्ये प्रवेश प्रदान करणेआणि EUPL चे कलम ५, कॉपीलेफ्टचे बंधन दूरस्थ संवादापर्यंत पोहोचवते, ज्यामध्ये तीच कार्यक्षमता प्रदान केली जाते. त्यामुळे, ते सेवा म्हणून वितरित केलेल्या सॉफ्टवेअरपर्यंत अशा प्रकारे पोहोचते, ज्या प्रकारे GPL पोहोचत नाही.

डच सार्वजनिक क्षेत्रातील ग्राहकाला कायद्याऐवजी धोरणाचा भाग म्हणून EUPL ची आवश्यकता असू शकते. इंटरऑपरेबल युरोप कायदा, नियमन (EU) 2024/903, सार्वजनिक क्षेत्रातील संस्थांना प्रतिबंधात्मक परवाना अटी नसलेल्या इंटरऑपरेबिलिटी सोल्यूशन्सना प्राधान्य देण्याचे निर्देश देतो, जसे की ओपन सोर्स, जेथे ते समकक्ष असेल; राष्ट्रीय स्तरावर, ओपन सोर्सचे तत्त्व कायद्यावर नव्हे, तर मंत्रिमंडळाच्या निर्णयांवर आणि धोरणांवर अवलंबून आहे: डिजिटल सरकार डिजिटल ओळख पायाभूत सुविधा सुलभ करते परंतु सर्व सोर्स कोड प्रकाशित करण्याचे कोणतेही बंधनकारक बंधन घालत नाही. निविदा दस्तऐवज वाचा: EUPL ची आवश्यकता तुमच्या डिलिवरेबलला बंधनकारक आहे आणि तुम्ही पुन्हा वापरू इच्छित असलेल्या प्रोप्रायटरी कोडशी विसंगत असू शकते.

व्यवहारात अंमलबजावणी

कोण दावा दाखल करू शकतो? हक्कधारक — वैयक्तिक योगदानकर्ते, किंवा नियुक्त कॉपीराइट धारण करणारी संस्था किंवा कंपनी. खंडित स्वामित्व ही एक व्यावहारिक अडचण आहे: दावा करणाऱ्याला संबंधित कोडची मालकी सिद्ध करावी लागते. यामुळेच युरोपमधील सर्वात प्रसिद्ध GPL प्रकरण अयशस्वी ठरले, ज्यात एका कर्नल डेव्हलपरचा व्हर्च्युअलायझेशन विक्रेत्याविरुद्धचा दावा स्वामित्वाचा पुरावा नसल्यामुळे अयशस्वी झाला (LG Hamburg 8 July 2016, 310 O 89/15; upholded OLG Hamburg 28 February 2019, 5 U 146/16).

न्यायनिर्णय काय स्थापित करतात. पहिल्या GPL मनाई हुकुमापासून (LG München I 19 May 2004, 21 O 6123/04), जर्मन न्यायालयांनी वारंवार हे मान्य केले आहे की ओपन सोर्स परवाने वैध आहेत आणि त्याचे उल्लंघन झाल्यास वितरण बेकायदेशीर ठरते. यूएस फेडरल सर्किट ' Jacobsen v Katzer' , 535 F.3d 1373 (Fed. Cir. 2008) मध्ये याच निष्कर्षावर पोहोचले: परवान्याच्या अटी या अनुदानाच्या व्याप्तीवरील अटी आहेत, केवळ करार नाहीत, त्यामुळे उल्लंघन झाल्यास कॉपीराइटचा दावा आणि मनाई हुकूम मिळू शकतो. यूएसमधील खटल्यांमध्ये हे तपासले जात आहे की, एखादा डाउनस्ट्रीम प्राप्तकर्ता तृतीय-पक्ष लाभार्थी म्हणून GPL लागू करू शकतो का. कॅलिफोर्नियाच्या सुपीरियर कोर्टासमोर 'Software Freedom Conservancy v Vizio' या खटल्यातील हाच मुख्य प्रश्न आहे : ग्राहक, तृतीय-पक्ष लाभार्थी म्हणून, GPLv2 अंतर्गत सोर्स कोड जारी करण्याची मागणी करू शकतात का. २३ डिसेंबर २०२५ रोजी न्यायालयाने संक्षिप्त न्यायनिवाड्याद्वारे एका मुद्द्यावर निर्णय दिला, की GPLv2 आणि LGPLv2.1 कायद्यांनुसार, डिव्हाइसवर त्याची कार्यक्षमता अबाधित ठेवून पुन्हा स्थापित करता येणाऱ्या स्रोताऐवजी, इतरत्र वापरण्यासाठी मिळवता आणि त्यावर पुनर्प्रक्रिया करता येणाऱ्या स्रोताची आवश्यकता आहे. तृतीय-पक्ष लाभार्थीचा प्रश्न खंडपीठाच्या सुनावणीसाठी ठेवण्यात आला, जी एकापेक्षा जास्त वेळा पुढे ढकलण्यात आली आहे. हा प्रश्न मुळात कॅलिफोर्नियाच्या करार कायद्याशी संबंधित आहे, त्यामुळे तो नेदरलँड्समध्ये बंधनकारक नाही; यामुळे जो बदल होईल तो म्हणजे तक्रार करू शकणाऱ्या लोकांची संख्या.

डच न्यायालय या प्रकरणाकडे कसे पाहिल. 'ऑटर्सवेट' (Auteurswet) अंतर्गत कॉपीराइट उल्लंघन म्हणून: फिर्यादी मालकी आणि पुनरुत्पादन किंवा संप्रेषण सिद्ध करतो; प्रतिवादी परवान्याचा मुद्दा उपस्थित करतो; फिर्यादी उत्तर देतो की त्याच्या अटींची पूर्तता झाली नाही, त्यामुळे बचाव अयशस्वी ठरतो. कलम ६:२६५ बीडब्ल्यू (BW) अंतर्गत करारात्मक उपाययोजना समांतरपणे चालतात, परंतु कॉपीराइट हा अधिक मजबूत मार्ग आहे.

उपाय. कलम ३:२९६ बीडब्ल्यू अंतर्गत मनाई हुकूम, जो सामान्यतः दंडासहित असतो आणि संक्षिप्त कार्यवाहीमध्ये उपलब्ध असतो; कलम २७ एडब्ल्यू अंतर्गत नुकसान भरपाई आणि कलम २७ए एडब्ल्यू अंतर्गत नफ्याचा हिशोब; कलम २८ एडब्ल्यू अंतर्गत परत मागवणे, सुपूर्द करणे किंवा नष्ट करणे; आणि कलम १०१९एच आरव्ही अंतर्गत वाजवी आणि प्रमाणशीर कायदेशीर खर्चाची पूर्ण वसुली. जिथे सॉफ्टवेअर विनामूल्य वितरित केले गेले होते, तिथे नुकसानीचे मोजमाप करणे कठीण असते, आणि एका जर्मन अपीलीय न्यायालयाने मनाई हुकूम कायम ठेवत नुकसान भरपाई देण्यास नकार दिला (ओएलजी हॅम १३ जून २०१७, ४ यू ७२/१६). सहसा नुकसान भरपाई त्रासदायक नसते: त्रासदायक असते ती मनाई हुकूम, परत मागवणे, खर्चाचा आदेश, आणि असा सोर्स कोड प्रकाशित करावा लागणे जो तुम्हाला कधीच प्रकाशित करायचा नव्हता.

जेव्हा तुम्हाला अनुपालनाची समस्या आढळते

सामान्यतः, ग्राहकाच्या सुरक्षा प्रश्नावलीतून, योग्य तपासणीदरम्यान केलेल्या तपासणीतून किंवा हक्कधारकाच्या पत्रातून त्रुटी उघडकीस येते. त्यानंतर उपाययोजना खालीलप्रमाणे केली जाते. जर त्रुटी गंभीर असेल, तर प्रभावित बिल्डचे वितरण थांबवा. कोणता घटक, कोणती आवृत्ती, कोणता परवाना, कोणती उत्पादने आणि प्रकाशनं, आणि कोणत्या कालावधीत, हे निश्चित करा. परवान्यासाठी नेमके काय आवश्यक आहे हे ठरवा — अनेकदा सोर्स रिलीजऐवजी ॲट्रिब्युशन फाईलची आवश्यकता असते. आवश्यक कागदपत्रे तयार करा: सूचना, परवान्याचे मजकूर, बिल्ड स्क्रिप्टसह संबंधित संपूर्ण सोर्स कोड आणि जिथे वापरले आहे तिथे लेखी प्रस्ताव. एक अनुरूप रिलीज पाठवा, आणि मग ते करणे आवश्यक होते की नाही यावर वाद घालण्याऐवजी, तुम्ही काय केले आहे हे हक्कधारकाला सांगा.

GPLv3 आणि AGPLv3 अंतर्गत, सुधारणेसाठी मिळणारी मुदत (cure window) वेगाला कायदेशीर मूल्य देते; GPLv2 अंतर्गत सुधारणेचा कोणताही अधिकार नाही, म्हणूनच बहुतेक अंमलबजावणी वाटाघाटीद्वारे अनुपालनाच्या हमीपत्रात (negotiated compliance undertaking) संपते. हे देखील लक्षात घ्या की विशेषाधिकार तुमच्या वकिलाच्या सल्ल्याला लागू होतो, अंतर्गत अभियांत्रिकी अहवालाला नाही.

विलिनीकरण आणि अधिग्रहण (M&A) आणि योग्य तपासणीमध्ये ओपन सोर्स

सॉफ्टवेअर अधिग्रहणामध्ये, ओपन सोर्स ही एक मानक तपासणी प्रक्रिया आहे, आणि मुख्य उत्पादनातील अप्रकाशित कॉपीलेफ्ट घटक हा अशा काही मोजक्या निष्कर्षांपैकी एक आहे ज्यामुळे व्यवहाराला खऱ्या अर्थाने गती मिळते: जर उत्पादनाचा सोर्स कोड प्रसिद्ध केल्याशिवाय त्याचे वितरण करता येत नसेल, तर खरेदीदार किंमत ठरवलेल्या मालमत्तेपेक्षा वेगळीच मालमत्ता मिळवत असतो.

कोडबेस स्कॅन, परवान्यांसह घटकांची यादी आणि योगदानकर्ते व कंत्राटदारांच्या व्यवस्थेबद्दलच्या प्रश्नांची अपेक्षा ठेवा. विशिष्ट नुकसानभरपाई, दुरुस्ती होईपर्यंत रोखून धरणे, काढून टाकण्याची पूर्व-अट किंवा सानुकूलित ओपन सोर्स वॉरंटी हे सामान्य परिणाम आहेत. विक्रेत्यांनी प्रथम तपासणी करावी: तुम्ही उघड केलेले निष्कर्ष हे वाटाघाटीचा भाग असतात, तर खरेदीदाराच्या सल्लागाराने केलेले निष्कर्ष हे दबावतंत्राचा भाग असतात. खरेदीदारांनी "कंपनी तिच्या बौद्धिक संपदेची मालक आहे" असे न मागता, कोणत्याही उत्पादनात मालकी हक्काच्या सोर्स कोडचा खुलासा आवश्यक असलेला ओपन सोर्स समाविष्ट नाही, असे प्रतिनिधित्व मिळवावे.

सामग्रीची यादी, स्कॅनिंग आणि सायबर लवचिकता कायदा

सॉफ्टवेअर बिल ऑफ मटेरियल्स म्हणजे उत्पादनाच्या घटकांची, आवृत्त्या आणि परवानग्यांसह असलेली एक यादी. अलीकडेपर्यंत पूर्णपणे करारात्मक असलेले हे दस्तऐवज आता नियामकसुद्धा बनले आहे.

सायबर रेझिलियन्स कायदा, नियमन (EU) 2024/2847, १० डिसेंबर २०२४ रोजी अंमलात आला आणि तो टप्प्याटप्प्याने लागू होईल. हा कायदा डच सायबर सुरक्षा कायद्याच्या सोबत आहे , जो उत्पादनाऐवजी संस्थेशी संबंधित आहे. सक्रियपणे वापरल्या जाणाऱ्या असुरक्षितता आणि गंभीर घटनांसाठी CRA च्या कलम १४ मधील अहवाल देण्याची जबाबदारी ११ सप्टेंबर २०२६ पासून लागू होते; अनुरूपता मूल्यांकन संस्थांना सूचित करण्यासंबंधीच्या तरतुदी ११ जून २०२६ पासून लागू होतात; आणि संपूर्ण नियमन ११ डिसेंबर २०२७ पासून (CRA चे कलम ७१) लागू होते. CRA च्या परिशिष्ट I नुसार, उत्पादकांनी उत्पादनातील घटक ओळखणे आणि त्यांचे दस्तऐवजीकरण करणे आवश्यक आहे, ज्यामध्ये सामान्यतः वापरल्या जाणाऱ्या आणि मशीन-वाचनीय स्वरूपात सॉफ्टवेअर बिल ऑफ मटेरियल्स तयार करणे समाविष्ट आहे, ज्यात किमान टॉप-लेव्हल डिपेंडन्सीजचा समावेश असेल. हे प्रकाशित करणे आवश्यक नाही; बाजार देखरेख प्राधिकरणे त्याची विनंती करू शकतात.

व्यावसायिक उपक्रमांव्यतिरिक्त पुरवलेले मोफत आणि मुक्त स्रोत सॉफ्टवेअर सायबर रेझिलिअन्स कायद्याच्या (CRA) कक्षेत येत नाही. हे नियमन मुक्त-स्रोत सॉफ्टवेअर स्टुअर्डची (एक कायदेशीर व्यक्ती जी व्यावसायिक उपक्रमांसाठी असलेल्या मुक्त स्रोत सॉफ्टवेअरच्या विकासाला सातत्यपूर्ण पाठिंबा देते) ओळख करून देते, ज्यावर CRA च्या कलम २४ अंतर्गत कमी जबाबदाऱ्या आहेत: एक दस्तऐवजीकृत सायबर सुरक्षा धोरण, बाजार देखरेख प्राधिकरणांशी सहकार्य आणि अहवाल देणे. जर तुम्ही मुक्त स्रोताचे व्यापारीकरण करत असाल, किंवा इतरांनी व्यापारीकरण केलेल्या प्रकल्पाला निधी देत ​​असाल, तर तुमची भूमिका कोणती आहे हे स्पष्ट करा. आयोगाने २७ जुलै २०२६ रोजी आपले पहिले मार्गदर्शन स्वीकारले: सायबर रेझिलिअन्स कायद्याच्या (CRA) अंमलबजावणीवरील आयोगाचे मार्गदर्शन, जे कम्युनिकेशन C(2026) 5252 ला जोडलेले आहे, आणि ज्यात इतर गोष्टींबरोबरच मोफत आणि मुक्त स्रोत सॉफ्टवेअर केव्हा कक्षेत येते हे सांगितले आहे. सॉफ्टवेअर बिल ऑफ मटेरियल्ससाठी स्वरूप विहित करणारा कोणताही अंमलबजावणी कायदा स्वीकारला गेला नाही, त्यामुळे नियमनाचे स्वतःचे मानक — एक सामान्यपणे वापरले जाणारे, मशीन-वाचनीय स्वरूप — सध्यासाठी मापदंड म्हणून कायम आहे.

CI मध्ये चालवलेले सॉफ्टवेअर कंपोझिशन विश्लेषण एकाच वेळी अनुपालन, परवाना पुनरावलोकन आणि योग्यतेची पूर्तता करणारी इन्व्हेंटरी तयार करते. अशी साधने व्हेंडर्ड कोडकडे दुर्लक्ष करतात, दुहेरी परवाना असलेल्या प्रकल्पांना चुकीच्या पद्धतीने ओळखतात आणि परवान्याच्या अटी वाचू शकत नाहीत: आउटपुटला पुनरावलोकनाची सुरुवात माना, अंतिम पुनरावलोकन नव्हे.

तुम्ही तुमचा स्वतःचा कोड प्रकाशित केल्यास: सीएलए आणि डीसीओ

जी कंपनी कोड प्रसिद्ध करते आणि बाहेरील योगदान स्वीकारते, तिला हे माहित असणे आवश्यक आहे की ती जे काही विलीन करत आहे त्यावर तिचे हक्क आहेत. योगदानकर्ता परवाना करार हा प्रकल्प आणि योगदानकर्ता यांच्यातील एक करार असतो, जो सामान्यतः मौलिकता आणि अधिकाराच्या हमीसह, एक व्यापक कॉपीराइट परवाना आणि एक स्पष्ट पेटंट परवाना प्रदान करतो. यामुळेच कंपनीला नंतर आपल्या प्रकल्पाचा परवाना बदलता येतो, किंवा ओपन सोर्स परवान्यासोबत व्यावसायिक परवाने देऊ करता येतात. याची किंमत म्हणजे घर्षण होय.

लिनक्स कर्नल आणि इतर अनेक प्रकल्पांद्वारे वापरले जाणारे ' डेव्हलपर सर्टिफिकेट ऑफ ओरिजिन' हे परवाना प्रदान नसून, प्रत्येक कमिटला स्वाक्षरीच्या ओळीत जोडलेले एक हलके प्रमाणीकरण आहे, जे हे दर्शवते की योगदानकर्ता प्रकल्पाच्या परवान्याअंतर्गत कोड सादर करू शकतो. कमी त्रासदायक आणि कमी संरक्षक: पेटंट परवाना नाही, पुनर्परवाना नाही.

जर दुहेरी परवाना किंवा भविष्यातील पुनर्परवाना शक्य असेल, तर CLA वापरा; जर प्रकल्प खऱ्या अर्थाने सार्वजनिक मालमत्ता असेल, तर DCO सहसा पुरेसा असतो. दोन्ही परिस्थितीत, तुमच्या नोकरी आणि कंत्राटदार करारांमध्ये तुमच्या कर्मचाऱ्यांनी लिहिलेल्या कोडचे कॉपीराइट हस्तांतरित केले आहेत याची खात्री करा.

एक व्यावहारिक धोरण तपासणी सूची

• बिल्ड पाइपलाइनमध्ये प्रत्येक उत्पादन आणि रिलीझसाठी घटकांची यादी तयार करा, ती हाताने तयार करू नका.
• एक अंतर्गत धोरण प्रकाशित करा: परवानगी असलेल्या गोष्टींची यादी, प्रतिबंधित गोष्टींची यादी आणि इतर सर्व गोष्टींसाठी मंजुरीचा मार्ग.
• वितरणामध्ये काय गणले जाते ते लेखी स्वरूपात परिभाषित करा — ऑन-प्रिमाइस इन्स्टॉल्स, अप्लायन्सेस, कंटेनर्स, SDKs, मोबाइल ॲप्स, फर्मवेअर.
• प्रत्येक उत्पादनासोबत तयार केलेली श्रेयनिर्देश फाईल पाठवा.
• लायसन्सच्या निवडींना डिझाइनच्या वेळी, जेव्हा एखादा घटक निवडला जातो, तेव्हा मंजूर करा; रिलीजच्या वेळी नाही.
• संबंधित पेटंट अनुदानांचा विचार करता, बाह्य प्रकल्पांमधील योगदानासाठी मंजुरीची आवश्यकता आहे की नाही हे ठरवा आणि पहिले बाह्य योगदान देण्यापूर्वी सीएलए (CLA) किंवा डीसीओ (DCO) निवडा.
• उत्पादनामध्ये प्रत्यक्षात असलेल्या ओपन सोर्सशी बौद्धिक संपदा हमी, नुकसानभरपाई आणि एस्क्रो अटी जुळवा.
• निधी उभारणी किंवा विक्री प्रक्रियेदरम्यान नव्हे, तर त्यापूर्वी पुनरावलोकन करा.

Law & More सॉफ्टवेअर कंपन्या आणि त्यांच्या गुंतवणूकदारांना सल्ला देतात Eindhoven आणि Amsterdam एका व्यवहारामध्ये ओपन सोर्स अनुपालन, परवाना पुनरावलोकन, योगदानकर्त्यांची व्यवस्था आणि ओपन सोर्स वर्कस्ट्रीम यांवर.