डच र EU कानून अन्तर्गत खुला स्रोत सफ्टवेयर इजाजतपत्रहरू

लगभग हरेक व्यावसायिक सफ्टवेयर उत्पादनमा खुला स्रोत कम्पोनेन्टहरू हुन्छन्, सामान्यतया सयौं, जुन वकिलहरू भन्दा विकासकर्ताहरूले छनौट गर्छन्। कुन इजाजतपत्रहरू लागू हुन्छन्, के चाहिन्छ, र उत्पादनले पालना गर्छ कि गर्दैन भनेर कसैले भन्न नसक्दा त्यो समस्या बन्छ। यस लेखले डच र EU कानून अन्तर्गत खुला स्रोत इजाजतपत्रहरूले कसरी काम गर्छन्, जोखिम कहाँ बस्छ, र के ठाउँमा हुनुपर्छ भनेर वर्णन गर्दछ।

कानुनी हिसाबले खुला स्रोत इजाजतपत्र भनेको के हो?

खुला स्रोत इजाजतपत्र भनेको सर्तहरूको अधीनमा रहेर प्रदान गरिएको प्रतिलिपि अधिकार इजाजतपत्र हो। यो कुनै त्याग होइन, सार्वजनिक डोमेनप्रति समर्पण होइन, अधिकारहरूको परित्याग होइन, र त्यस सन्दर्भमा यो डच कानून अन्तर्गत अन्य कुनै पनि सफ्टवेयर इजाजतपत्र जस्तै काम गर्दछ । लेखकले कला अन्तर्गत प्रतिलिपि अधिकार कायम राख्छ। १ Aw र कला। १० Aw, जसले कम्प्युटर प्रोग्रामहरूलाई कामको रूपमा सुरक्षित गर्दछ, र इजाजतपत्रले कार्यहरूलाई अनुमति दिन्छ जसले अन्यथा कला अन्तर्गत विशेष अधिकारहरू उल्लङ्घन गर्दछ। १२ Aw र कला। १३ Aw।

परिभाषा भन्दा परिणाम बढी महत्त्वपूर्ण हुन्छ। पालना गर्नुहोस्, र तपाईंको प्रतिलिपि र वितरण कानूनी छ। पालना गर्न असफल भएमा, र अनुमतिले तपाईंले गर्नुभएको कामलाई समेट्दैन: तपाईंको प्रयोग प्रतिलिपि अधिकार उल्लङ्घन हो, सम्झौताको उल्लङ्घन होइन। धेरैजसो प्रतिलिपि अधिकार इजाजतपत्रहरूले उल्लङ्घनमा स्वचालित रूपमा समाप्त गरेर यसलाई सुदृढ बनाउँछन् — GPLv2 कुनै उपचार अवधि बिना, जबकि GPLv3 र AGPLv3 ले सूचना पछि परिभाषित विन्डो भित्र उल्लङ्घन निको भएमा अधिकारहरू पुनर्स्थापित गर्दछ।

डच अदालतहरूले यो तर्क लागू गर्छन्। आरबीमा। Amsterdam २२ सेप्टेम्बर २०२०, ECLI:NL:RBAMS:2020:4717, फोर्क गरिएको कोडबेसबाट इजाजतपत्र पाठ र प्रतिलिपि अधिकार सूचना हटाउने वितरकलाई आफ्नो अनुमति गुमाएको र उल्लङ्घन गरेको ठहर गरिएको थियो। ठूलो मात्रामा नयाँ कोड थप्दा स्वतन्त्र काम सिर्जना भएन: मूल पहिचानयोग्य रूपमा उपस्थित रह्यो, त्यसैले दायित्वहरू यसको साथमा यात्रा गरे।

दुई परिवार: अनुमति दिने र प्रतिलिपिलेफ्ट

अनुमति दिने इजाजतपत्रहरू - MIT, BSD इजाजतपत्रहरू, Apache 2.0 - ले प्रयोग, परिमार्जन र पुनर्वितरणलाई अनुमति दिन्छ, भित्री बन्द-स्रोत उत्पादनहरू सहित, यदि तपाईंले प्रतिलिपि अधिकार सूचनाहरू र इजाजतपत्र पाठ सुरक्षित गर्नुभयो भने।

प्रतिलिपि अधिकार लाइसेन्सको लागि जब तपाईंले सफ्टवेयर वितरण गर्नुहुन्छ, वा त्यसमा निर्मित केहि चीज, तपाईंले उही इजाजतपत्र अन्तर्गत त्यसो गर्नुपर्छ र सम्बन्धित स्रोत उपलब्ध गराउनुपर्छ। तिनीहरू पहुँचमा फरक हुन्छन्।

प्रतिलिपि बायाँ ट्रिगर र लिङ्क गर्ने प्रश्न

प्रतिलिपिलेफ्ट दायित्वहरू वितरणमा निर्भर गर्दछन्, प्रयोगमा होइन। आन्तरिक रूपमा GPL सफ्टवेयर चलाउने कम्पनी, जतिसुकै परिमार्जन गरिएको भए पनि, केही वितरण गर्दैन र केही पनि ऋणी हुँदैन। "के हामीले वितरण गरेका छौं?" भन्ने प्रश्न सधैं पहिलो हुन्छ, र त्यसैले कन्टेनर, उपकरणहरू, फर्मवेयर र SDK हरू आन्तरिक उपकरणभन्दा बढी महत्त्वपूर्ण हुन्छन्।

दोस्रो प्रश्न अझ गाह्रो छ। GPL ले "कार्यक्रममा आधारित काम" को कुरा गर्छ, जसले अमेरिकी व्युत्पन्न कामको अवधारणालाई उधारो लिन्छ। डच कानूनमा त्यस्तो कुनै शब्द छैन: विश्लेषण पुनरुत्पादन र अनुकूलन अधिकारहरू मार्फत चल्छ, सोध्छ कि मूलबाट सुरक्षित अभिव्यक्ति पुनरुत्पादित गरिएको छ कि छैन।

व्यावहारिक मामला लिङ्किङ हो। GPL पुस्तकालयमा स्वामित्व मोड्युल लिङ्क गर्दा प्रतिलिपि अधिकारको अधीनमा रहेको एउटा काम सिर्जना हुन्छ कि हुँदैन भन्ने कुरा डच अदालतले कहिल्यै निर्णय गरेको छैन, र त्यहाँ कुनै बाध्यकारी EU अधिकार छैन। फ्री सफ्टवेयर फाउन्डेसनको दृष्टिकोण कि लिङ्किङले संयुक्त काम सिर्जना गर्दछ लाइसेन्स भण्डारीको व्याख्या हो, कानून होइन, र विपरीत दृष्टिकोण उत्तिकै परीक्षण नगरिएको छ। इन्टरनेटको मनपर्ने उत्तर - गतिशील लिङ्किङ सुरक्षित, स्थिर लिङ्किङ होइन - डच प्रतिलिपि अधिकार कानूनमा कुनै आधार छैन, जसले कम्पाइलरले कसरी व्यवहार गर्छ भनेर सोध्दैन। थप सुरक्षित विश्लेषणले कम्पोनेन्टहरू कति घनिष्ठ रूपमा संयुक्त छन् भनेर सोध्छ: के तिनीहरूले ठेगाना ठाउँ र डेटा संरचनाहरू साझा गर्छन्, के संयोजन एक उत्पादनको रूपमा पठाइएको छ, या त एक्लै काम गर्न सक्छ, के स्वामित्व पक्षले प्रतिलिपि अधिकार पक्षबाट हेडरहरू, म्याक्रोहरू वा इनलाइन कोड पुनरुत्पादन गर्दछ? ती प्रश्नहरूले सामान्यतया जोखिम समाधान गर्छन्। जहाँ तिनीहरूले गर्दैनन्, प्रक्रिया सीमा पछाडिको घटकलाई अलग गर्नुहोस्, यसलाई प्रतिस्थापन गर्नुहोस्, वा व्यावसायिक इजाजतपत्र लिनुहोस्।

AGPL र नेटवर्क प्रयोग

AGPL अवस्थित छ किनभने copyleft वितरणद्वारा ट्रिगर हुन्छ र SaaS प्रदायकहरूले वितरण गर्दैनन्। यसको नेटवर्क क्लजले आवश्यक छ कि यदि तपाईंले सफ्टवेयर परिमार्जन गर्नुभयो र यसलाई टाढाबाट अन्तर्क्रिया गर्ने प्रयोगकर्ताहरूलाई उपलब्ध गराउनुभयो भने, तपाईंले तिनीहरूलाई आफ्नो परिमार्जित संस्करणको सम्बन्धित स्रोत प्रस्ताव गर्नुहुन्छ।

तीन बुँदाहरू सामान्यतया छुटेका छन्। यो दायित्व सेवाका प्रयोगकर्ताहरूमा पर्छ, जुन खुला-साइनअप उत्पादनमा थोरै आरामदायी हुन्छ। यो परिमार्जनद्वारा ट्रिगर हुन्छ, त्यसैले परिमार्जन नगरिएको कम्पोनेन्टले यसलाई संलग्न गर्दैन तर प्याच गरिएको निर्माणले गर्न सक्छ। र यसले तपाईंको बाँकी स्ट्याकको लागि GPL जस्तै संयुक्त-कार्य प्रश्न उठाउँछ — त्यसैले धेरै कम्पनीहरूले उत्पादन कोडमा AGPL लाई निषेध गर्छन्।

लाइसेन्स अनुकूलता

अनुकूलता भनेको कम्पोनेन्टहरू संयोजन गर्ने समस्या हो जसको इजाजतपत्रहरूले दायित्वहरू लगाउँछन् जुन दुवै एउटै वितरणमा पूरा गर्न सकिँदैन: अनुमति दिने इजाजतपत्रहरू लगभग सबै कुरासँग उपयुक्त हुन्छन्, प्रतिलिपि अधिकार इजाजतपत्रहरू केवल तिनीहरूको आफ्नै सर्तहरूले अनुमति दिएको कुरासँग मात्र। मानक केस Apache 2.0 र GPLv2 हो। Apache सफ्टवेयर फाउन्डेसन र फ्री सफ्टवेयर फाउन्डेसन सहमत छन् कि संयोजनलाई अनुमति छैन, किनभने Apache 2.0 को पेटेन्ट समाप्ति र क्षतिपूर्ति प्रावधानहरू GPLv2 ले अनुमति दिँदैन अतिरिक्त प्रतिबन्धहरू हुन्। GPLv3 तिनीहरूलाई स्वीकार गर्न मस्यौदा गरिएको थियो। अनुकूलता पनि दिशात्मक छ: Apache कोड GPLv3 परियोजनामा ​​अवशोषित गर्न सकिन्छ, तर उल्टो होइन। गलत ठाउँमा रहेको एउटा GPL कम्पोनेन्टले पुन: इजाजतपत्र, पुन: इन्जिनियरिङ वा हटाउने बीच छनौट गर्न बाध्य पार्न सक्छ - रिलीज पछि भन्दा धेरै सस्तो।

श्रेय र सूचना दायित्वहरू

सबैभन्दा धेरै उल्लङ्घन गरिएका दायित्वहरू सबैभन्दा कम नाटकीय हुन्छन्: प्रतिलिपि अधिकार सूचनाहरू, इजाजतपत्र पाठहरू, अस्वीकरणहरू र, Apache 2.0 अन्तर्गत, वितरणको साथमा रहेका सामग्रीहरूमा NOTICE सामग्रीहरू पुन: उत्पादन गर्ने। प्रत्येक परिवारले तिनीहरूलाई लागू गर्दछ, MIT र BSD सहित। तिनीहरू उल्लङ्घन गरिएका छन् किनभने तिनीहरूको स्वामित्व कसैको छैन, र समाधान गर्न सजिलो छ - सामान्यतया उत्पादनसँगै पठाइएको उत्पन्न एट्रिब्युसन फाइल। माथिको डच केसले यो असफलतालाई ठ्याक्कै सक्रिय बनायो।

पेटेन्ट अनुदान र पेटेन्ट प्रतिशोध

MIT र BSD ले पेटेन्टको बारेमा केही भन्दैनन्, र पेटेन्ट इजाजतपत्र निहित हुन सक्छ कि सक्दैन भन्ने कुरा अनिश्चित छ। Apache 2.0 ले प्रत्येक योगदानकर्ताबाट एक एक्सप्रेस, रोयल्टी-मुक्त पेटेन्ट इजाजतपत्र थप्यो, जसलाई प्रतिशोध खण्डसँग जोडिएको छ: कामले उल्लङ्घन गर्छ र तपाईंको पेटेन्ट इजाजतपत्र समाप्त हुन्छ भन्ने आरोप लगाउँदै पेटेन्ट मुद्दा चलाउनुहोस्। GPLv3 मा तुलनात्मक अनुदान र यसको आफ्नै पेटेन्ट प्रावधानहरू छन्।

पेटेन्ट पोर्टफोलियो भएका कम्पनीहरूका लागि दुई प्रभावहरू। यदि तपाईंका इन्जिनियरहरूले Apache- वा GPLv3-लाइसेन्स प्राप्त परियोजनाहरूमा योगदान गर्छन् भने, तपाईंले आफ्नै पेटेन्ट अन्तर्गत इजाजतपत्र प्रदान गर्दै हुनुहुन्छ। र यदि तपाईंले कहिल्यै प्रयोग गर्ने उही Apache-लाइसेन्स प्राप्त कम्पोनेन्टहरूको आधारमा कुनै कम्पनी विरुद्ध पेटेन्ट दाबी गर्नुभयो भने, बदलाको लागि तपाईंले भर परेको इजाजतपत्र खर्च हुन सक्छ।

EUPL र डच सार्वजनिक क्षेत्र

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

• भाषा। यो आधिकारिक EU भाषाहरूमा अवस्थित छ, सबै अनुमोदित संस्करणहरूको समान मूल्य छ, त्यसैले डच अधिकारीले डच भाषामा सम्झौता गर्न सक्छ।
• अनुकूलता। परिशिष्टले उपयुक्त इजाजतपत्रहरू सूचीबद्ध गर्दछ - GPLv2 र v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL र CeCILL तिनीहरूमध्ये - र सूचीबद्ध इजाजतपत्र अन्तर्गत कोडसँग EUPL कोड संयोजन गर्ने व्युत्पन्न कार्यलाई त्यो इजाजतपत्र अन्तर्गत वितरण गर्न अनुमति दिन्छ।
• पुग्नु। वितरणको यसको परिभाषाले कामलाई अनलाइन वा अफलाइन उपलब्ध गराउनुलाई समेट्छ। वा यसको आवश्यक कार्यक्षमताहरूमा पहुँच प्रदान गर्दै, र धारा ५ EUPL ले रिमोट अन्तरक्रिया मार्फत प्रतिलिपि अधिकार दायित्व वहन गर्दछ जसमा त्यही कार्यक्षमता प्रदान गरिन्छ। त्यसैले यो सेवाको रूपमा डेलिभर गरिएको सफ्टवेयरमा पुग्छ, जुन तरिकाले GPL गर्दैन।

डच सार्वजनिक क्षेत्रको ग्राहकलाई EUPL लाई कानूनको सट्टा नीतिको रूपमा आवश्यक पर्न सक्छ। इन्टरअपरेबल युरोप ऐन, नियमन (EU) २०२४/९०३ ले सार्वजनिक क्षेत्रका निकायहरूलाई प्रतिबन्धित इजाजतपत्र सर्तहरू बिना अन्तरसञ्चालन समाधानहरूलाई प्राथमिकता दिन निर्देशन दिन्छ, जस्तै खुला स्रोत, जहाँ समतुल्य; राष्ट्रिय रूपमा, खुला स्रोतको सिद्धान्त, tenzij क्याबिनेट निर्णयहरू र नीति रेखाहरूमा निर्भर गर्दछ, कानूनमा होइन: Wet digitale overheid ले डिजिटल पहिचान पूर्वाधारलाई सहज बनाउँछ तर सबै स्रोत कोड प्रकाशित गर्न कुनै लागूयोग्य दायित्व लगाउँदैन। टेन्डर कागजातहरू पढ्नुहोस्: EUPL आवश्यकताले तपाईंको डेलिभरेबललाई बाँध्छ र तपाईंले पुन: प्रयोग गर्न चाहनुभएको स्वामित्व कोडसँग असंगत हुन सक्छ।

व्यवहारमा कार्यान्वयन

कसले मुद्दा हाल्न सक्छ। अधिकारधारक - व्यक्तिगत योगदानकर्ताहरू, वा तोकिएको प्रतिलिपि अधिकार धारण गर्ने फाउन्डेसन वा कम्पनी। खण्डित लेखकत्व व्यावहारिक ब्रेक हो: दावीकर्ताले मुद्दामा कोडको स्वामित्व प्रमाणित गर्नुपर्छ। यसले सबैभन्दा प्रसिद्ध युरोपेली GPL केसलाई पराजित गर्‍यो, जहाँ लेखकत्वको प्रमाणको अभावमा भर्चुअलाइजेशन विक्रेता विरुद्ध कर्नेल विकासकर्ताको दाबी असफल भयो (LG Hamburg 8 जुलाई 2016, 310 O 89/15; समर्थन OLG Hamburg 28 फेब्रुअरी 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 लागू गर्न सक्छ कि सक्दैन। क्यालिफोर्नियाको सुपीरियर कोर्ट अगाडि सफ्टवेयर स्वतन्त्रता संरक्षण विरुद्ध Vizio मा त्यो केन्द्रीय प्रश्न हो : के उपभोक्ताहरू, तेस्रो-पक्ष लाभार्थीको रूपमा, GPLv2 अन्तर्गत स्रोत कोडको रिलीजको माग गर्न सक्छन्। २३ डिसेम्बर २०२५ मा अदालतले सारांश निर्णयमा एउटा बुँदाको निर्णय गर्‍यो, जसमा भनिएको थियो कि GPLv2 र LGPLv2.1 लाई त्यस्तो स्रोत चाहिन्छ जुन प्राप्त गर्न सकिन्छ र अन्यत्र प्रयोगको लागि पुन: काम गर्न सकिन्छ, यसको कार्यक्षमता अक्षुण्ण राखेर उपकरणमा पुन: स्थापना गर्न सकिने स्रोतको सट्टा। तेस्रो-पक्ष लाभार्थी प्रश्न आफैंलाई बेन्च ट्रायलको लागि छोडिएको थियो, जुन एक पटक भन्दा बढी स्थगित गरिएको छ। यो कुनै पनि अवस्थामा क्यालिफोर्नियाली अनुबंध कानून प्रश्न हो, त्यसैले यसले नेदरल्याण्ड्समा केहि पनि बाँध्दैन; यसले के परिवर्तन गर्नेछ भने गुनासो गर्न सक्ने व्यक्तिहरूको संख्या हो।

डच अदालतले यसलाई कसरी हेर्नेछ। Auteurswet अन्तर्गत प्रतिलिपि अधिकार उल्लङ्घनको रूपमा: दावीकर्ताले स्वामित्व र पुनरुत्पादन वा सञ्चार प्रमाणित गर्दछ; प्रतिवादीले इजाजतपत्र उठाउँछ; दावीकर्ताले जवाफ दिन्छ कि यसको सर्तहरू पूरा भएनन्, त्यसैले बचाउ असफल हुन्छ। धारा अन्तर्गत अनुबंधात्मक उपचारहरू। 6:265 BW समानान्तरमा चल्छ, तर प्रतिलिपि अधिकार बलियो मार्ग हो।

उपचारहरू। धारा ३:२९६ BW अन्तर्गत निषेधाज्ञा, सामान्यतया जरिवाना भुक्तानी सहित र सारांश कार्यवाहीमा उपलब्ध; धारा २७ Aw र धारा २७a Aw अन्तर्गत नाफाको हिसाब। २७a Aw; धारा २८ Aw; र धारा २८ अन्तर्गत उचित र समानुपातिक कानुनी लागतको पूर्ण रिकभरी। १०१९h Rv। जहाँ सफ्टवेयर नि:शुल्क वितरण गरिएको थियो, त्यहाँ नोक्सानको मात्रा निर्धारण गर्न गाह्रो छ, र जर्मन पुनरावेदन अदालतले निषेधाज्ञा कायम राख्दै क्षतिपूर्ति प्रदान गर्न अस्वीकार गर्यो (OLG Hamm १३ जुन २०१७, ४ U ७२/१६)। के काट्ने भनेको विरलै क्षति हो: यो निषेधाज्ञा, फिर्ता, लागत आदेश, र तपाईंले कहिल्यै प्रकाशित गर्न चाहनुभएको स्रोत प्रकाशित गर्नु हो।

जब तपाईंले अनुपालन समस्या पत्ता लगाउनुहुन्छ

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

GPLv3 र AGPLv3 अन्तर्गत उपचार विन्डोले गति कानूनी मूल्य दिन्छ; GPLv2 अन्तर्गत कुनै उपचार अधिकार छैन, त्यसैले धेरैजसो प्रवर्तन वार्ता गरिएको अनुपालन उपक्रममा समाप्त हुन्छ। यो पनि ध्यान दिनुहोस् कि विशेषाधिकार तपाईंको वकिलको सल्लाहमा संलग्न छ, आन्तरिक इन्जिनियरिङ रिपोर्टमा होइन।

M&A मा खुला स्रोत र उचित परिश्रम

सफ्टवेयर अधिग्रहणमा, खुला स्रोत एक मानक परिश्रम कार्यप्रवाह हो, र मुख्य उत्पादनमा एक अज्ञात प्रतिलिपि बायाँ घटक केही निष्कर्षहरू मध्ये एक हो जसले साँच्चै सम्झौतालाई सार्छ: यदि उत्पादनलाई यसको स्रोत जारी नगरी वितरण गर्न सकिँदैन भने, खरिदकर्ताले मूल्य निर्धारण गरिएको भन्दा फरक सम्पत्ति प्राप्त गरिरहेको हुन्छ।

कोडबेस स्क्यान, इजाजतपत्र सहितको कम्पोनेन्ट इन्भेन्टरी, र योगदानकर्ता र ठेकेदार व्यवस्थाको बारेमा प्रश्नहरूको अपेक्षा गर्नुहोस्। विशिष्ट परिणामहरू एक विशिष्ट क्षतिपूर्ति, उपचारको लागि विचाराधीन अवधारण, हटाउन आवश्यक पर्ने पूर्वसर्त, वा बेस्पोक खुला स्रोत वारेन्टी हुन्। विक्रेताहरूले पहिले स्क्यान गर्नुपर्छ: तपाईंले खुलासा गर्ने निष्कर्षहरू वार्ता हुन्, खरिदकर्ताको सल्लाहकारले निकाल्ने निष्कर्षहरू लाभ हुन्। खरीददारहरूले "कम्पनीको आफ्नो आईपीको स्वामित्व छ" होइन तर कुनै पनि उत्पादनले स्वामित्व स्रोत कोडको खुलासा आवश्यक पर्ने खुला स्रोत समावेश गर्दछ भन्ने प्रतिनिधित्व खोज्नुपर्छ।

सामग्रीको बिल, स्क्यानिङ र साइबर लचिलोपन ऐन

सफ्टवेयर बिल अफ मटेरियल भनेको उत्पादनको कम्पोनेन्टहरूको सूची हो, जसमा संस्करण र इजाजतपत्रहरू समावेश छन्। हालसालैसम्म पूर्ण रूपमा सम्झौतामा आधारित, यो अब नियामक पनि हो।

साइबर लचिलोपन ऐन, नियमन (EU) २०२४/२८४७, १० डिसेम्बर २०२४ मा लागू भयो र चरणबद्ध रूपमा लागू हुन्छ। यो डच साइबरसुरक्षा ऐनसँगै बस्छ , जसले उत्पादनको सट्टा संस्थालाई सम्बोधन गर्दछ। सक्रिय रूपमा शोषित कमजोरीहरू र गम्भीर घटनाहरूको लागि रिपोर्टिङ दायित्वहरू कलामा। १४ CRA ११ सेप्टेम्बर २०२६ देखि लागू हुन्छ; ११ जुन २०२६ देखि अनुरूपता मूल्याङ्कन निकायहरूको सूचनामा प्रावधानहरू; ११ डिसेम्बर २०२७ देखि पूर्ण नियमन (धारा ७१ CRA)। अनुसूची I CRA ले निर्माताहरूलाई उत्पादनमा कम्पोनेन्टहरू पहिचान गर्न र दस्तावेजीकरण गर्न आवश्यक छ, जसमा कम्तिमा शीर्ष-स्तर निर्भरताहरू समेट्ने सामान्य रूपमा प्रयोग हुने र मेसिन-पठनीय ढाँचामा सामग्रीहरूको सफ्टवेयर बिल तयार गरेर समावेश छ। यो प्रकाशित गर्न आवश्यक छैन; बजार निगरानी अधिकारीहरूले यसलाई अनुरोध गर्न सक्छन्।

व्यावसायिक गतिविधि बाहिर आपूर्ति गरिएको नि:शुल्क र खुला स्रोत सफ्टवेयर CRA बाहिर पर्छ। नियमनले खुला-स्रोत सफ्टवेयर भण्डारी - व्यावसायिक गतिविधिहरूको लागि लक्षित खुला स्रोत सफ्टवेयरको विकासलाई निरन्तर समर्थन दिने कानूनी व्यक्ति - लाई कलामा हल्का दायित्वहरू सहित परिचय गराउँछ। २४ CRA: एक दस्तावेजीकृत साइबर सुरक्षा नीति, बजार निगरानी अधिकारीहरूसँग सहकार्य, र रिपोर्टिङ। यदि तपाईंले खुला स्रोतको व्यापारीकरण गर्नुहुन्छ, वा अरूले व्यापारीकरण गर्ने परियोजनालाई कोष दिनुहुन्छ भने, तपाईंले कुन भूमिका ओगट्नुहुन्छ भनेर स्थापित गर्नुहोस्। आयोगले २७ जुलाई २०२६ मा आफ्नो पहिलो निर्देशन अपनायो: साइबर लचिलोपन ऐन (CRA) को प्रयोगमा आयोगको निर्देशन, सञ्चार C(२०२६) ५२५२ मा संलग्न, जसले नि:शुल्क र खुला स्रोत सफ्टवेयर दायरा भित्र पर्दा अन्य कुराहरूलाई सम्बोधन गर्दछ। सामग्रीको सफ्टवेयर बिलको लागि ढाँचा तोक्ने कुनै कार्यान्वयन ऐन अपनाइएको छैन, त्यसैले नियमनको आफ्नै मानक - सामान्यतया प्रयोग हुने, मेसिन-पठनीय ढाँचा - अहिलेको लागि मापन रहन्छ।

CI मा सञ्चालित सफ्टवेयर संरचना विश्लेषणले एकैचोटि सूची सेवा अनुपालन, इजाजतपत्र समीक्षा र परिश्रम उत्पन्न गर्दछ। त्यस्ता उपकरणहरूले विक्रेता कोड गुमाउँछन्, दोहोरो-इजाजतपत्र प्राप्त परियोजनाहरूलाई गलत पहिचान गर्छन् र इजाजतपत्रका सर्तहरू पढ्न सक्दैनन्: आउटपुटलाई समीक्षाको सुरुवातको रूपमा व्यवहार गर्नुहोस्, समीक्षा होइन।

यदि तपाईंले आफ्नै कोड प्रकाशित गर्नुभयो भने: CLA र DCO

कोड जारी गर्ने र बाहिरी योगदानहरू स्वीकार गर्ने कम्पनीले के मर्ज हुन्छ भन्ने कुरामा उसको अधिकार छ भन्ने कुरा थाहा पाउनुपर्छ। योगदानकर्ता इजाजतपत्र सम्झौता भनेको परियोजना र योगदानकर्ता बीचको सम्झौता हो, जसले सामान्यतया मौलिकता र अधिकारको वारेन्टी सहितको व्यापक प्रतिलिपि अधिकार इजाजतपत्र र एक्सप्रेस पेटेन्ट इजाजतपत्र प्रदान गर्दछ। यसले कम्पनीलाई पछि आफ्नो परियोजनालाई पुन: इजाजतपत्र दिन वा खुला स्रोतको साथ व्यावसायिक इजाजतपत्रहरू प्रस्ताव गर्न दिन्छ। यसको लागत घर्षण हो।

लिनक्स कर्नेल र अन्य धेरै परियोजनाहरूद्वारा प्रयोग गरिने विकासकर्ता प्रमाणपत्र उत्पत्ति , इजाजतपत्र अनुदान होइन तर हल्का तौलको प्रमाणीकरण हो, जुन प्रत्येक प्रतिबद्धतामा साइन-अफ लाइनको रूपमा थपिएको छ, जसले योगदानकर्ताले परियोजनाको इजाजतपत्र अन्तर्गत कोड पेश गर्न सक्छ। कम बोझिलो, र कम सुरक्षात्मक: कुनै पेटेन्ट इजाजतपत्र छैन, कुनै पुन: लाइसेन्स छैन।

यदि दोहोरो इजाजतपत्र वा भविष्यको रिलेन्स सम्भव छ भने, CLA प्रयोग गर्नुहोस्; यदि परियोजना वास्तविक कमन्स हो भने, DCO सामान्यतया पर्याप्त हुन्छ। जे भए पनि, तपाईंको रोजगारी र ठेकेदार सम्झौताहरूले तपाईंका मानिसहरूले लेखेको कोडमा प्रतिलिपि अधिकार तोकेको सुनिश्चित गर्नुहोस्।

व्यावहारिक नीति चेकलिस्ट

• प्रति उत्पादन कम्पोनेन्ट इन्भेन्टरी उत्पन्न गर्नुहोस् र हातले होइन, निर्माण पाइपलाइनमा रिलीज गर्नुहोस्।
• आन्तरिक नीति प्रकाशित गर्नुहोस्: अनुमति दिइएको सूची, निषेधित सूची र अरू सबै कुराको लागि स्वीकृति मार्ग।
• वितरणको रूपमा के गणना गरिन्छ भनेर लिखित रूपमा परिभाषित गर्नुहोस् — परिसरमा स्थापनाहरू, उपकरणहरू, कन्टेनरहरू, SDK हरू, मोबाइल एपहरू, फर्मवेयर।
• प्रत्येक उत्पादनको साथ उत्पन्न गरिएको एट्रिब्युसन फाइल पठाउनुहोस्।
• डिजाइनको समयमा इजाजतपत्र छनोटहरू अनुमोदन गर्नुहोस्, जब कुनै कम्पोनेन्ट चयन गरिन्छ, रिलीजको समयमा होइन।
• पेटेन्ट अनुदानहरू समावेश भएको अवस्थामा बाह्य परियोजनाहरूमा योगदानलाई स्वीकृति चाहिन्छ कि पर्दैन भन्ने निर्णय गर्नुहोस्, र पहिलो बाह्य योगदान अघि CLA वा DCO छनौट गर्नुहोस्।
• उत्पादनमा रहेको खुला स्रोतसँग IP वारेन्टी, क्षतिपूर्ति र एस्क्रो सर्तहरू मिलाउनुहोस्।
• कोष सङ्कलन वा बिक्री प्रक्रिया अघि समीक्षा चलाउनुहोस्, एक समयमा होइन।

Law & More सफ्टवेयर कम्पनीहरू र उनीहरूका लगानीकर्ताहरूलाई सल्लाह दिन्छन् Eindhoven र Amsterdam खुला स्रोत अनुपालन, इजाजतपत्र समीक्षा, योगदानकर्ता व्यवस्था र लेनदेनमा खुला स्रोत कार्यप्रवाहमा।