डच कानून के तहत सॉफ्टवेयर लाइसेंसिंग कैसे काम करती है

सॉफ्टवेयर लाइसेंसिंग एक संविदात्मक तंत्र है जिसके द्वारा किसी प्रोग्राम के कॉपीराइट का धारक किसी अन्य व्यक्ति को उसका उपयोग करने की अनुमति देता है। डच कानून के तहत, कंप्यूटर प्रोग्राम कॉपीराइट अधिनियम (Auteurswet) के अनुच्छेद 10, प्रथम पैराग्राफ, बिंदु 12 के अंतर्गत एक संरक्षित कृति है, इसलिए इसे लोड करने, कॉपी करने या अनुकूलित करने के प्रत्येक कार्य के लिए अनुमति या वैधानिक अपवाद की आवश्यकता होती है। लाइसेंस वह अनुमति है, और इसका दायरा, अवधि और शर्तें समझौते द्वारा निर्धारित की जाती हैं, बशर्ते लाइसेंसधारी को कुछ विशेष अधिकारों को छोड़ने के लिए बाध्य न किया जाए।

यह ढांचा उन लगभग सभी गलतियों को स्पष्ट करता है जो संगठन सॉफ्टवेयर लाइसेंसिंग के बारे में करते हैं: वे लाइसेंस को अनुबंध के बजाय रसीद की तरह मानते हैं, वे उन अधिकारों को मान लेते हैं जो लाइसेंस ने कभी प्रदान नहीं किए, और उन्हें विक्रेता ऑडिट या माइग्रेशन के दौरान इस कमी का पता चलता है। यह लेख बताता है कि डच और यूरोपीय कानून वास्तव में आपको क्या देते हैं, लाइसेंस क्या जोड़ता है या घटाता है, और कौन से खंड आपकी जवाबदेही तय करते हैं।

सॉफ्टवेयर का लाइसेंस लेने पर आपको क्या प्राप्त होता है

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

हालाँकि, डच कानून हर सॉफ्टवेयर अधिग्रहण को केवल लाइसेंस के रूप में नहीं मानता है। 27 अप्रैल 2012 के डी बील्डब्रिगेड फैसले (ECLI:NL:HR:2012:BV1301) में होगे राड ने माना कि सिविल कोड के खंड 7 में बिक्री संबंधी नियम एकमुश्त भुगतान के बदले अनिश्चित अवधि के लिए आपूर्ति किए गए मानक सॉफ्टवेयर के अधिग्रहण पर लागू होते हैं, भले ही सॉफ्टवेयर कोई मूर्त वस्तु न हो। इसका व्यावहारिक प्रभाव यह है कि बिक्री कानून की अनुरूपता की आवश्यकता लागू होती है: सॉफ्टवेयर में वे गुण होने चाहिए जिनकी खरीदार को अपेक्षा करने का अधिकार था। यह मात्र संविदात्मक वारंटी की तुलना में कहीं अधिक मजबूत स्थिति है, और यही एक कारण है कि विक्रेता सदस्यता और क्लाउड मॉडल को प्राथमिकता देते हैं, जो बिक्री के बजाय सेवाएं हैं।

जहां ग्राहक उपभोक्ता होता है, वहां एक अतिरिक्त स्तर लागू होता है। नागरिक संहिता की पुस्तक 7 में 1 जनवरी 2022 से डिजिटल सामग्री और डिजिटल सेवाओं की आपूर्ति के लिए अनुबंधों पर नियमों का एक अलग सेट शामिल किया गया है, जो इस विषय पर यूरोपीय निर्देश को लागू करता है। ये नियम अनुरूपता की आवश्यकताओं, उपभोक्ता द्वारा अपेक्षित अद्यतनों की अवधि तक अद्यतन करने के दायित्व और उपभोक्ता के नुकसान के लिए प्रतिबंधित न किए जा सकने वाले उपायों को अनिवार्य बनाते हैं। व्यावसायिक लाइसेंस काफी हद तक अनुबंध की स्वतंत्रता पर निर्भर करते हैं, यही कारण है कि ऐसे मामलों में बातचीत का महत्व अधिक होता है।

आपके लिए लिखे गए सॉफ़्टवेयर का स्वामित्व किसके पास है, यह एक अलग सवाल है जो कई संगठनों को उलझन में डाल देता है। किसी कर्मचारी द्वारा अपने कर्तव्यों के निर्वहन में लिखे गए प्रोग्राम का कॉपीराइट, ऑटर्सवेट के अनुच्छेद 7 के तहत नियोक्ता के पास होता है। किसी फ्रीलांसर या विकास एजेंसी द्वारा लिखे गए प्रोग्राम का कॉपीराइट उसी पक्ष के पास रहता है, जब तक कि इसे किसी लिखित समझौते द्वारा हस्तांतरित न कर दिया जाए। बिना लिखित अनुबंध के काम सौंपने वाले ग्राहक को अनिश्चित दायरे का एक निहित लाइसेंस प्राप्त होता है, जिसका पता तब चलता है जब उसे व्यवसाय बेचना होता है या आपूर्तिकर्ता बदलना होता है। स्वामित्व वाले सॉफ़्टवेयर लाइसेंसिंग पर हमारा लेख इस संबंध को और अधिक विस्तार से बताता है।

लाइसेंस में चाहे जो भी लिखा हो, कानून आपको वही अधिकार देता है जो आपको प्राप्त हैं।

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

ऑट्यूर्सवेट के अनुच्छेद 45जे के तहत, किसी प्रति के वैध प्राप्तकर्ता को प्रोग्राम के इच्छित उपयोग के लिए आवश्यक प्रतियां बनाने की अनुमति है। पक्षकार अनुबंध में इसे बदल सकते हैं, सिवाय एक अपवाद के जिसे बदला नहीं जा सकता: प्रोग्राम को लोड करने, प्रदर्शित करने या उसमें त्रुटियों को ठीक करने के दौरान होने वाली प्रतियां बनाना समझौते द्वारा प्रतिबंधित नहीं किया जा सकता। ऐसा लाइसेंस जो आपको किसी ऐसी त्रुटि को ठीक करने से रोकता है जो सॉफ़्टवेयर को इच्छित रूप से कार्य करने से रोकती है, उस हद तक अप्रवर्तनीय है।

ऑट्यूर्सवेट के अनुच्छेद 45k के तहत वैध उपयोगकर्ता को आवश्यक होने पर बैकअप कॉपी बनाने की अनुमति है, और इस अधिकार को भी अनुबंध द्वारा समाप्त नहीं किया जा सकता है। अनुच्छेद 45m डीकंपाइलेशन की अनुमति देता है, लेकिन केवल सख्त शर्तों के तहत: यह किसी स्वतंत्र रूप से बनाए गए प्रोग्राम के साथ अंतर-संचालनीयता प्राप्त करने के लिए आवश्यक जानकारी प्राप्त करने हेतु अपरिहार्य होना चाहिए, इसे एक वैध अधिग्रहणकर्ता द्वारा किया जाना चाहिए, जानकारी पहले से आसानी से उपलब्ध नहीं होनी चाहिए, और यह प्रोग्राम के उन भागों तक सीमित होना चाहिए जो उस उद्देश्य के लिए आवश्यक हैं। प्रतिस्पर्धी उत्पाद बनाने के लिए डीकंपाइलेशन इस अपवाद के अंतर्गत नहीं आता है। न्याय न्यायालय ने टॉप सिस्टम (सी-13/20, 6 अक्टूबर 2021) मामले में पुष्टि की कि एक वैध अधिग्रहणकर्ता प्रोग्राम के कामकाज को प्रभावित करने वाली त्रुटियों को ठीक करने के लिए भी डीकंपाइलेशन कर सकता है।

एक और सिद्धांत लाइसेंस के एकाधिकार को सीमित करता है। एसएएस इंस्टीट्यूट (सी-406/10, 2 मई 2012) मामले में, न्याय न्यायालय ने फैसला सुनाया कि किसी कंप्यूटर प्रोग्राम की कार्यक्षमता, प्रोग्रामिंग भाषा या उसके द्वारा उपयोग की जाने वाली डेटा फ़ाइलों का प्रारूप, प्रोग्राम के कॉपीराइट द्वारा संरक्षित नहीं है। केवल स्रोत और ऑब्जेक्ट कोड ही संरक्षित हैं। नीदरलैंड्स में बौद्धिक संपदा कानून पर हमारी मार्गदर्शिका सॉफ्टवेयर कॉपीराइट को उन अन्य अधिकारों के साथ रखती है जिन पर कोई प्रौद्योगिकी व्यवसाय निर्भर करता है। यदि कोई प्रतियोगी आपके सॉफ्टवेयर के कार्यों का अध्ययन करके अपना स्वयं का कार्यान्वयन लिखता है, तो वह आपके कॉपीराइट का उल्लंघन नहीं कर रहा है, चाहे यह कितना भी अप्रिय क्यों न हो।

स्वामित्व, ओपन सोर्स और कॉपीलेफ्ट लाइसेंस

लाइसेंस तीन श्रेणियों में आते हैं, और उनके बीच का अंतर वैचारिक नहीं बल्कि परिचालन संबंधी है: यह निर्धारित करता है कि आपको क्या खुलासा करना होगा और आप किस चीज के लिए शुल्क ले सकते हैं।

स्वामित्व लाइसेंस

स्वामित्व लाइसेंस स्रोत कोड को गोपनीय रखता है और उपयोग का एक निश्चित, आमतौर पर गैर-अनन्य और गैर-हस्तांतरणीय अधिकार प्रदान करता है। प्रतिबंध समझौते का सार हैं: नामित उपयोगकर्ताओं या उपकरणों की अधिकतम संख्या, अनुमत वातावरण, उप-लाइसेंसिंग पर प्रतिबंध, और रिवर्स इंजीनियरिंग पर प्रतिबंध जो केवल तभी प्रभावी होता है जब वह ऊपर वर्णित वैधानिक अधिकारों से टकराव न करे। विक्रेता अपडेट, समर्थन और मूल्य निर्धारण को नियंत्रित करता है, और उत्पाद बंद होने या शर्तों में परिवर्तन होने की स्थिति में ग्राहक को माइग्रेशन लागत वहन करनी पड़ती है। यह निर्भरता एक संविदात्मक जोखिम है, और इसे नोटिस अवधि, मूल्य वृद्धि सीमा, निरंतरता व्यवस्था और व्यावसायिक रूप से महत्वपूर्ण प्रणालियों के लिए स्रोत कोड एस्क्रो पर बातचीत करके प्रबंधित किया जाता है।

अनुमेय ओपन सोर्स लाइसेंस

ओपन सोर्स लाइसेंस कॉपीराइट लाइसेंस होते हैं, कॉपीराइट का त्याग नहीं, और वे किसी भी अन्य लाइसेंस की तरह ही लागू करने योग्य होते हैं: शर्तों का उल्लंघन करने पर आप अनुमति खो देते हैं, जिससे आप उल्लंघनकर्ता बन जाते हैं।

MIT, BSD और Apache 2.0 जैसे अनुमेय लाइसेंसों में बहुत कम बाध्यताएँ होती हैं। आप कोड को किसी व्यावसायिक उत्पाद में शामिल कर सकते हैं, जिसमें केवल बाइनरी रूप में वितरित किया जाने वाला उत्पाद भी शामिल है, बशर्ते आप कॉपीराइट सूचना, लाइसेंस पाठ और अस्वीकरणों को पुनः प्रस्तुत करें। Apache 2.0 एक स्पष्ट पेटेंट लाइसेंस और फ़ाइलों में किए गए परिवर्तनों को बताने की आवश्यकता को जोड़ता है। इन बाध्यताओं का पालन करना आसान है, लेकिन इनकी अनदेखी करना भी आसान है, और व्यवहार में ओपन सोर्स अनुपालन में विफलता का सबसे आम कारण एक छूटी हुई सूचना फ़ाइल है।

कॉपीराइट लाइसेंस

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

लेसर जीपीएल एक मध्य मार्ग अपनाता है: आप अपने स्वयं के कोड को खोले बिना मालिकाना कोड को एलजीपीएल लाइब्रेरी से लिंक कर सकते हैं, बशर्ते उपयोगकर्ता लाइब्रेरी को संशोधित संस्करण से बदल सके। क्या स्टैटिक लिंकिंग इस शर्त को पूरा करती है, यह एक ऐसा प्रश्न है जिस पर रिलीज़ से पहले सलाह लेना आवश्यक है, न कि बाद में।

सॉफ्टवेयर बेचने वाली कंपनी के लिए व्यावहारिक समाधान एक लिखित ओपन सोर्स नीति, प्रत्येक घटक और उसके लाइसेंस की सूची, और निर्माण प्रक्रिया में स्वचालित जाँच है। अधिग्रहणकर्ता ड्यू डिलिजेंस के दौरान सूची की ही माँग करेगा, और इसकी अनुपस्थिति से खरीद मूल्य में निश्चित रूप से कमी आती है।

लाइसेंसिंग मॉडल और कानूनी तौर पर उनका अर्थ

लाइसेंस का प्रकार बताता है कि आप कोड के साथ क्या कर सकते हैं। लाइसेंसिंग मॉडल बताता है कि आप भुगतान कैसे करेंगे और उपयोग को कैसे मापा जाएगा, और यह निर्धारित करता है कि अनुपालन जोखिम कहाँ मौजूद है।

नेम्ड-यूज़र या प्रति-सीट लाइसेंस किसी पहचाने गए व्यक्ति से जुड़ा होता है। दो कर्मचारियों के बीच एक ही नेम्ड अकाउंट साझा करना उल्लंघन है, भले ही वे दोनों कभी एक साथ काम न करते हों, और यह वह उल्लंघन है जिसे विक्रेता सबसे आसानी से पकड़ लेते हैं। कॉन्करेंट या फ़्लोटिंग लाइसेंस एक साथ उपयोग करने वाले उपयोगकर्ताओं की संख्या को सीमित करता है और इसे लाइसेंस सर्वर द्वारा लागू किया जाता है; यहाँ जोखिम साझा करने का नहीं बल्कि अधिकतम सीमा से अधिक उपयोग करने का है। प्रति-डिवाइस या प्रति-कोर लाइसेंस हार्डवेयर के आधार पर मापा जाता है, और वर्चुअलाइज़ेशन में यह समस्या आती है: कुछ विक्रेताओं के मापदंडों के अनुसार, क्लस्टर पर लाइसेंस प्राप्त इंस्टेंस चलाना उस क्लस्टर के प्रत्येक भौतिक कोर को लाइसेंस देने के समान माना जा सकता है। मापदंड की परिभाषा पढ़ें, मूल्य सूची नहीं।

स्थायी लाइसेंस और सदस्यता के बीच चुनाव करना कानूनी और वित्तीय दोनों ही दृष्टि से महत्वपूर्ण है। स्थायी लाइसेंस किसी विशिष्ट संस्करण का अनिश्चित काल तक उपयोग करने का अधिकार देता है; समर्थन और नए संस्करण एक अलग रखरखाव समझौते के अंतर्गत आते हैं , और उस समझौते के समाप्त होने से आपके पास मौजूद सामग्री का उपयोग जारी रखने का अधिकार समाप्त नहीं होता है। सदस्यता केवल भुगतान अवधि तक ही उपयोग की अनुमति देती है, इसलिए अनुबंध की समाप्ति के साथ ही आपकी पहुंच भी समाप्त हो जाती है; पहले से तय किए जाने वाले प्रश्न हैं कि आपके डेटा का क्या होगा, यह किस प्रारूप में वापस किया जाएगा, और विक्रेता निकास में कितने समय तक सहायता करेगा।

क्लाउड और ऑन-प्रिमाइसेस परिनियोजन में अलग-अलग मुद्दे सामने आते हैं। विक्रेता के बुनियादी ढांचे पर चलने वाले सॉफ़्टवेयर के साथ, आप एक सेवा खरीद रहे हैं, और समझौते में उपलब्धता, समर्थन प्रतिक्रिया समय, उप-ठेकेदार, डेटा का स्थान और समाप्ति के परिणामों को शामिल किया जाना चाहिए। जहां व्यक्तिगत डेटा संसाधित किया जाता है, वहां आपको GDPR के अनुच्छेद 28 की आवश्यकताओं को पूरा करने वाले डेटा प्रसंस्करण समझौते की भी आवश्यकता होती है; एक लाइसेंस समझौता यह काम नहीं करता है। नीदरलैंड में क्लाउड अनुबंध पर हमारा लेख बताता है कि उस अनुबंध में क्या-क्या शामिल होना चाहिए।

क्या आप सॉफ्टवेयर लाइसेंस को दोबारा बेच या स्थानांतरित कर सकते हैं?

कभी-कभी, और इसका उत्तर स्पष्ट रूप से यूरोपीय दृष्टिकोण का अनुसरण करता है। यूज्डसॉफ्ट (सी-128/11, 3 जुलाई 2012) मामले में, न्याय न्यायालय ने यह माना कि यदि कोई अधिकार धारक किसी प्रोग्राम की प्रति डाउनलोड के लिए उपलब्ध कराता है और शुल्क के बदले उस प्रति का असीमित अवधि तक उपयोग करने का अधिकार प्रदान करता है, तो उसने उस प्रति को बेच दिया है। उस प्रति का वितरण अधिकार तब समाप्त हो जाता है, और अधिकार धारक उसके पुनर्विक्रय का विरोध नहीं कर सकता, भले ही वह प्रति कभी डिस्क पर न रही हो। पहले खरीदार को पुनर्विक्रय के समय अपनी प्रति को अनुपयोगी बनाना होगा, और निश्चित संख्या में उपयोगकर्ताओं के लिए लाइसेंस को विभाजित करके अलग-अलग हिस्सों में बेचा नहीं जा सकता।

सीमाएँ नियम के समान ही महत्वपूर्ण हैं। लाइसेंस की वैधता समाप्त होने का नियम एकमुश्त भुगतान पर बेचे गए स्थायी लाइसेंस पर लागू होता है, न कि सदस्यता या सेवा पर। न्यायालय ने टॉम काबिनेट (सी-263/18, 19 दिसंबर 2019) मामले में पुष्टि की कि स्थायी उपयोग के लिए डाउनलोड द्वारा ई-पुस्तक की आपूर्ति जनता के लिए एक संचार है, न कि वितरण, इसलिए वैधता समाप्त होने का नियम लागू नहीं होता; सॉफ्टवेयर संबंधी निर्णय सॉफ्टवेयर निर्देश के विशिष्ट प्रावधानों पर आधारित है और अन्य डिजिटल कार्यों पर लागू नहीं होता। रखरखाव और सहायता अनुबंध लाइसेंस के साथ हस्तांतरित नहीं होते, जब तक कि विक्रेता सहमत न हो।

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

विक्रेता ऑडिट और एक डच कंपनी को क्या स्वीकार करना होगा

अधिकांश उद्यम समझौतों में एक ऑडिट खंड शामिल होता है, और विक्रेता इसका उपयोग करते हैं। यह खंड ही विक्रेता को उसके अधिकार प्रदान करता है, इसलिए सूचना प्राप्त होने पर सबसे पहले इसी दस्तावेज़ को पढ़ना चाहिए।

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

तीन व्यावहारिक नियम लागू होते हैं। माप स्वयं करने से पहले कच्चा डेटा न सौंपें; चर्चा लगभग हमेशा इस बात पर होती है कि उपयोग की गणना कैसे की जाती है, न कि इस बात पर कि क्या स्थापित किया गया है। सभी संचार एक ही व्यक्ति के माध्यम से करें और प्रत्येक समझौते की लिखित पुष्टि करें। और प्रक्रिया को अनुबंध के दायरे में ही रखें: यदि कोई लेखा परीक्षक लाइसेंस प्राप्त उत्पादों के बाहर के सिस्टम तक पहुंच या कर्मचारियों के व्यक्तिगत डेटा की मांग करता है, तो वह ऐसी चीज मांग रहा है जो अनुबंध में नहीं दी गई है, और GDPR इस अनुरोध पर भी उतना ही लागू होता है जितना किसी अन्य अनुरोध पर।

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

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

वे खंड जो आपके जोखिम का निर्धारण करते हैं

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

अनुदान का दायरा सर्वप्रथम आता है। इसमें यह स्पष्ट होना चाहिए कि सॉफ़्टवेयर का उपयोग कौन कर सकता है, जिसमें समूह की कंपनियाँ, ठेकेदार और आउटसोर्सिंग प्रदाता शामिल हैं; किन वातावरणों पर, जिनमें परीक्षण, आपदा रिकवरी और बैकअप इंस्टेंस शामिल हैं; और किन क्षेत्रों में। यदि अनुदान का दायरा आपके वास्तविक संचालन के दायरे से कम है, तो यह एक ऐसी कमी है जिसका भविष्य में पता लगाया जा सकता है।

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

तीसरा है बौद्धिक संपदा क्षतिपूर्ति। यदि कोई तीसरा पक्ष दावा करता है कि सॉफ़्टवेयर उसके अधिकारों का उल्लंघन करता है, तो सॉफ़्टवेयर का उपयोग करने वाले ग्राहक पर मुकदमा चलाया जाता है। एक उचित क्षतिपूर्ति विक्रेता को दावे का बचाव करने और परिणामस्वरूप होने वाले नुकसान और लागतों का भुगतान करने के लिए बाध्य करती है, और उसे लाइसेंस प्राप्त करने, सॉफ़्टवेयर को संशोधित करने या शुल्क के आनुपातिक हिस्से को वापस करने का विकल्प देती है। ऐसी क्षतिपूर्तियों से सावधान रहें जो सामान्य देयता खंड के समान ही कम राशि पर सीमित हों, क्योंकि इससे वे लगभग बेकार हो जाती हैं।

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

पांचवा बिंदु परिवर्तन खंड है। विक्रेता अक्सर उत्पाद की शर्तों, मापदंडों या दस्तावेज़ों में एकतरफा संशोधन करने का अधिकार सुरक्षित रखते हैं। इसे बिना किसी सीमा के स्वीकार करने का अर्थ है ऐसी कीमत और दायरे को स्वीकार करना जिसे आपने अभी तक देखा ही नहीं है। एक व्यावहारिक समझौता परिवर्तनों को एक पूर्व सूचना अवधि से जोड़ता है और ग्राहक को परिवर्तन के प्रतिकूल होने की स्थिति में बिना किसी दंड के अनुबंध समाप्त करने का अधिकार देता है। इन दस्तावेजों पर बातचीत करने के संबंध में सामान्य मार्गदर्शन हमारे अनुबंध और समझौतों पर लिखे लेख में दिया गया है ।

हस्ताक्षर करने से पहले क्या करें और हर साल क्या करें

हस्ताक्षर करने से पहले, सॉफ़्टवेयर के वास्तविक उपयोग और अनुदान की शर्तों के बीच संतुलन बनाएँ और बिक्री प्रतिनिधि के ईमेल के बजाय अनुबंध में ही मतभेदों का समाधान करें। यह स्पष्ट करें कि कौन सा मापदंड लागू होता है और उसे कैसे मापा जाता है, साथ ही अपने परिवेश के लिए एक उदाहरण भी दें। पुष्टि करें कि यह व्यवस्था स्थायी लाइसेंस है या सदस्यता, और अनुबंध समाप्त होने पर आपको क्या मिलेगा। ऑडिट क्लॉज़, देयता सीमा, क्षतिपूर्ति और परिवर्तन क्लॉज़ की जाँच करें और सिस्टम के व्यवसाय के लिए मूल्य का आकलन करें।

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

Law & More हम नीदरलैंड्स में व्यवसायों को सॉफ्टवेयर लाइसेंसिंग, विकास और SaaS समझौतों, ओपन सोर्स अनुपालन और सॉफ्टवेयर विक्रेताओं के साथ विवादों, जिनमें ऑडिट और उल्लंघन के दावे शामिल हैं, पर सलाह देते हैं। हम लाइसेंस की शर्तों की समीक्षा और बातचीत करते हैं, विक्रेता द्वारा दावा किए जाने पर आपकी स्थिति का आकलन करते हैं और उन मामलों में कार्यवाही करते हैं जहां समझौता संभव नहीं होता है। यदि आप अपने सॉफ्टवेयर अनुबंधों की समीक्षा करवाना चाहते हैं, तो कृपया हमारे वकीलों से संपर्क करें।