मंत्रिपरिषद ने 27 जनवरी 2026 को नए सऊदी कॉपीराइट कानून को मंज़ूरी दी। यह 13 फ़रवरी 2026 को उम्म अल-क़ुरा के अंक 5144 में प्रकाशित हुआ, और अनुच्छेद 61 इसे प्रकाशन के 180 दिन बाद, यानी 12 अगस्त 2026 को लागू करता है। कानून अब प्रभावी है, और यह 2/7/1424H के शाही फ़रमान M/41 के तहत जारी 2003 के कॉपीराइट कानून की जगह लेता है, जिसने दो दशकों से अधिक समय तक संरक्षित कृतियों को नियंत्रित किया।

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

तीन स्थितियाँ, दो बिल्कुल अलग नतीजे

अनुच्छेद 18 तीन स्थितियों को अलग करता है, हर एक का अपना नियम है, और हर एक एक ही शर्त के साथ समाप्त होती है: जब तक अन्यथा सहमति न हो।

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

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

आर्थिक अधिकार न होने की आपको असल में क्या क़ीमत चुकानी पड़ती है

आर्थिक अधिकार कोई अमूर्त चीज़ नहीं हैं। अनुच्छेद 9 बताता है कि इनमें क्या शामिल है: पुनरुत्पादन, अनुवाद और रूपांतरण तथा कोई भी संशोधन, वितरण, किराये पर देना, कृति को जनता तक पहुँचाना, और सामान्य रूप से उसके व्यावसायिक दोहन का लाइसेंस देना। जिसके पास ये अधिकार हैं, वही तय करता है कि कृति का पुन: उपयोग हो सकता है या नहीं, उसे कौन संशोधित कर सकता है, और किसे उसकी प्रति बेची जा सकती है।

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

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

नैतिक अधिकार कभी हस्तांतरित नहीं होते, तब भी नहीं जब बाकी सब हो जाता है

यहीं पर कई अनुबंधों को ग़लत पढ़ा जाता है। अनुच्छेद 7 कॉपीराइट को नैतिक अधिकारों और आर्थिक अधिकारों में बाँटता है। आर्थिक अधिकार अनुच्छेद 10 के तहत वैध निपटान से पूरी तरह या आंशिक रूप से हस्तांतरित होते हैं। अनुच्छेद 7(2) नैतिक अधिकारों को स्थायी, कालबाधा से मुक्त, निपटान के अयोग्य, परित्याग के अयोग्य, और किसी भी रूप में आर्थिक दोहन की अनुमति देने से समाप्त न होने वाले अधिकारों के रूप में वर्णित करता है।

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

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

वह खंड जो आपके अनुबंध में होना चाहिए

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

जो बातें स्पष्ट रूप से लिखी जानी चाहिए:

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

पंजीकरण: एक धारणा, स्वामित्व का अनुदान नहीं

अनुच्छेद 42 कृतियों को सऊदी बौद्धिक संपदा प्राधिकरण में पंजीकृत कराने की अनुमति देता है, साथ ही उन्हें प्रभावित करने वाले संशोधनों और निपटानों का दस्तावेज़ीकरण भी, और कहता है कि पंजीकरण कृति के स्वामित्व की खंडनीय धारणा बनाता है।

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

बड़ा बदलाव: स्थानीय रूप से बने से स्थानीय रूप से स्वामित्व वाले तक

अनुच्छेद 18 अकेला नहीं है। मंत्रिपरिषद ने 25 अगस्त 2026 को राष्ट्रीय बौद्धिक संपदा नीति को मंज़ूरी दी, जो दिसंबर 2022 में शुरू हुई राष्ट्रीय बौद्धिक संपदा रणनीति का विस्तार है, जिसके क्रियान्वयन की निगरानी सऊदी बौद्धिक संपदा प्राधिकरण करता है। दोनों दस्तावेज़ों की दिशा एक ही है: अधिकारों की सुरक्षा से उनके उपयोग की ओर बढ़ना, और अमूर्त परिसंपत्तियों को मान्यता देने से उन्हें ऐसी आर्थिक परिसंपत्तियों के रूप में देखने की ओर बढ़ना जिन्हें हस्तांतरित, लाइसेंस और मूल्यांकित किया जा सके।

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

Origami का दृष्टिकोण

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

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

इस हफ़्ते जवाब देने लायक तीन सवाल

शुरुआत के लिए आपको पूरी क़ानूनी समीक्षा की ज़रूरत नहीं है। आपको उन सिस्टम के बारे में तीन जवाब चाहिए जो आप पहले से चला रहे हैं।

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

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

स्रोत