Cyber Resilience Act पर Debian का वक्तव्य
EU Cyber Resilience Act के लिए योजनाएँ बना रहा है, जो software “manufacturers” पर सुरक्षा और दायित्व संबंधी आवश्यकताएँ लागू करेगा; इससे open-source डेवलपर्स और छोटे व्यवसायों में चिंता बढ़ रही है। टिप्पणीकार बड़े commercial vendors को ऊँचे मानकों पर रखने का व्यापक रूप से समर्थन करते हैं, लेकिन “commercial activity” की अस्पष्ट परिभाषाओं और free या donation-funded परियोजनाओं को शामिल करने से hobbyists और non-profits पर भारी compliance बोझ और जुर्माने लगने का डर है। कुछ लोगों का कहना है कि इससे यूरोप में open-source विकास ठंडा पड़ सकता है या परियोजनाएँ EU users को block करने पर मजबूर हो सकती हैं, जबकि अन्य कहते हैं कि सार्थक विनियमन की आवश्यकता है और उसे छोड़ने के बजाय सावधानी से लिखना चाहिए.
CRA का दायरा और उद्देश्य
- कई टिप्पणीकार मानते हैं कि Cyber Resilience Act (CRA) के कुछ हिस्से वास्तविक समस्याओं को संबोधित करते हैं: कमजोर सुरक्षा प्रथाएँ, शून्य कानूनी दायित्व, और न्यूनतम कठोरता के साथ जारी किया गया “enterprise” सॉफ़्टवेयर।
- अन्य लोग पूछते हैं कि यह “खराब” क्यों है, इसके ठोस प्रमाण क्या हैं; समर्थकों का कहना है कि सॉफ़्टवेयर में दायित्व और न्यूनतम मानक बहुत पहले आ जाने चाहिए थे, ठीक वैसे ही जैसे अन्य विनियमित उद्योगों में होते हैं।
दायित्व, सुरक्षा उपमाएँ, और मानक
- भोजन सुरक्षा, एयरोस्पेस, चिकित्सा, कारों में बोल्ट आदि से बार-बार उपमाएँ दी गईं।
- एक पक्ष: अन्य क्षेत्रों में पहले विनियमन और मानकीकरण आया और उनसे वे अधिक सुरक्षित बने; सॉफ़्टवेयर को भी इसी दिशा में जाना चाहिए, खासकर जहाँ जीवन निर्भर करता है।
- दूसरा पक्ष: सॉफ़्टवेयर की जटिलता, तेज़ बदलाव, और दुर्भावनापूर्ण शोषण पर निर्भरता (जैसे विष जैसे आंतरिक नुकसान के बजाय) प्रत्यक्ष उपमाओं को कमज़ोर बनाती है, और विनियमन को कहीं अधिक जोखिमभरा करती है।
FOSS, शौक़ीन डेवलपर्स, और छोटे व्यवसायों पर प्रभाव
- केंद्रीय चिंता: CRA की व्यापक “commercial activity” परिभाषा, जिसमें “free of charge” और समर्थन, प्लेटफ़ॉर्म, या डेटा के माध्यम से monetization शामिल है।
- आशंका कि:
- शौक़ीन परियोजनाएँ, दान-वित्तपोषित उपकरण, और छोटी परामर्श फर्में भारी अनुपालन और दायित्व बोझ झेल सकती हैं।
- open-source मेंटेनर (log4j, OpenSSL जैसी परियोजनाएँ) को बिना उपयुक्त फंडिंग के “industrial-grade” प्रक्रियाएँ अपनानी पड़ेंगी।
- इससे कई व्यक्ति और छोटी कंपनियाँ EU बाज़ार से बाहर हो सकती हैं या कोड प्रकाशित करना बंद कर सकती हैं।
छूट देने के प्रयास
- बाद के संशोधनों में कथित रूप से व्यक्तिगत FOSS डेवलपर्स को छूट देने की कोशिश की गई है, लेकिन:
- नौकरीपेशा योगदानकर्ता और कॉर्पोरेट समर्थन या नियमित दान वाली परियोजनाएँ अभी भी “commercial” मानी जा सकती हैं।
- गैर-लाभकारी संस्थाएँ और फाउंडेशन अभी भी एक धुंधला क्षेत्र बने हुए हैं, और FOSS के माध्यम से “liability laundering” का जोखिम है।
विनियमन बनाम नवाचार और पेशेवरकरण
- कुछ लोगों का तर्क है कि software engineering को पेशेवर लाइसेंसिंग और संहिताबद्ध सर्वोत्तम प्रथाओं की ओर बढ़ना चाहिए; विनियमन इस क्षेत्र के परिपक्व होने का हिस्सा है।
- अन्य लोग regulatory capture, लागत में विस्फोट (1–2 orders of magnitude), और “aerospace-style” ठहराव की चेतावनी देते हैं जहाँ बदलाव बहुत महँगा हो जाता है।
- इस पर असहमति है कि क्या self-regulation पहले आनी चाहिए थी, या क्या “the time for the whip” पहले ही आ चुका है।
लाइसेंसिंग, ब्लॉकिंग, और वैकल्पिक उपाय
- सुझाए गए उपायों में शामिल हैं: सरकारी/EU उपयोग पर रोक लगाने वाले लाइसेंस, EU IPs को ब्लॉक करना, या नए FOSS लाइसेंस जो नियामक दायित्व उत्पन्न होने पर स्वयं को अमान्य कर दें।
- कई उत्तरों में यह नोट किया गया:
- कानून लाइसेंसों पर हावी होते हैं; ऐसे खंड संभवतः CRA दायित्वों से सुरक्षा नहीं देंगे।
- उपयोग-आधारित भेदभाव सामान्य FOSS परिभाषाओं और Debian के social contract का उल्लंघन होगा, भले ही infrastructure blocking के ज़रिए तकनीकी रूप से लागू किया जा सके।