व्यक्तिगत इंजीनियरों को कंपनियों के साथ संयुक्त व्यापार में पूर्वनिर्माण करने के लिए अनिवार्य समझौते
हमारी कानूनी फर्म, जिसका प्रमुख वकील पूर्व IT इंजीनियर है, केवल कंपनियों की ओर से ही नहीं, बल्कि इंजीनियरों की ओर से भी कानूनी सलाह लेती है। एक प्रकार की सलाह यह होती है कि “मैंने व्यक्तिगत रूप से, किसी कंपनी के साथ नए व्यापार को आगे बढ़ाते हुए, कंपनी की ओर से पर्याप्त हिस्सेदारी आदि प्राप्त करने में असमर्थ हो गया हूं”। उदाहरण के लिए, निम्नलिखित परिस्थितियाँ हो सकती हैं।
- व्यक्तिगत रूप से इंजीनियर के रूप में, मैंने IT में अवश्य ही मजबूत नहीं होने वाली कंपनी द्वारा, नए सिस्टम के स्वयं के विकास को शुरू से ही संभाला है।
- उक्त सिस्टम की क्षमता के कारण बिक्री बढ़ रही है।
- मैंने शेयरों की वितरण या बिक्री के आधार पर लाभ का वितरण मांगा, लेकिन कंपनी ने इसे मान्य नहीं किया।
ऐसी स्थिति में, व्यक्तिगत इंजीनियर को क्या सोचना चाहिए, और सबसे पहले, ऐसी स्थिति क्यों उत्पन्न होती है, और इसे कैसे रोका जा सकता है, इस पर हम विवरण देंगे।
साझा व्यापार से संबंधित विवाद को अनुबंध पत्र होने से रोका जा सकता है
सबसे पहले, निष्कर्ष को उल्लेख करने के लिए, ऐसी स्थितियों को “रोकने” का काम वास्तव में आसान है। उत्तर सादा है
ऐसी स्थिति के लिए तैयार होने के लिए, पहले से ही, निम्नलिखित जैसी सामग्री शामिल करने वाला “साझा व्यापार अनुबंध पत्र” सम्बन्धित होना चाहिए।
इसका मतलब है। साझा व्यापार अनुबंध पत्र में, उदाहरण के लिए, निम्नलिखित तरह के निर्धारण किए जा सकते हैं।
- संबंधित सिस्टम के संबंध में कॉपीराइट खुद और कंपनी के साझा होने चाहिए
- बिक्री का ●% खुद को वितरित किया जाना चाहिए
- शेयर ट्रांसफर का निर्धारण
इन्हें सही संतुलन में डिजाइन करने और पहले से ही सम्बन्धित होने की आवश्यकता होती है।
हालांकि, वास्तविक रूप में, ऐसे अनुबंध का सम्बन्ध आमतौर पर टाला जाता है, इसलिए, उपरोक्त तरह की समस्याएं आसानी से सामने आती हैं।
- जब समस्या सामने आती है, तो अधिकार संबंधी मामले आदि कैसी स्थिति में होते हैं
- साझा व्यापार अनुबंध पत्र बनाने के लिए पहले से ही, किस प्रकार की नीति के साथ डिजाइन करना चाहिए
- फिर भी, अनुबंध के बिना समस्या आसानी से सामने आती है, इसका कारण क्या है
निम्नलिखित बिंदुओं पर, निम्नलिखित में, हम क्रमशः विवरण देंगे।
साझा व्यापार में प्रोग्राम सोर्स कोड का स्वामित्व
जैसा कि ऊपर उल्लेख किया गया है, एक व्यक्तिगत इंजीनियर के रूप में, आपका सबसे बड़ा ‘अधिकार’ कंपनी के खिलाफ दावा करने का होता है, वह कॉपीराइट होता है। प्रोग्राम का सोर्स कोड एक ‘कॉपीराइट वर्क’ होता है। और, सोर्स कोड के कॉपीराइट का स्वामित्व,
- सिद्धांततः, उस कोड को लिखने वाले के पास होता है
- अगर कोड लिखने वाला किसी कंपनी में काम कर रहा होता है, तो कुछ निश्चित शर्तों के पूरा होने पर यह ‘कार्यकारी कॉपीराइट’ बन जाता है, और कंपनी के पास चला जाता है
- अगर कॉपीराइट स्वामित्व के बारे में कोई अनुबंध होता है, तो वह अनुबंध का पालन करता है
के नियमों के अनुसार होता है। इसलिए,
- सिद्धांततः, यह व्यक्तिगत इंजीनियर के पास होता है जिसने कोड लिखा है
- व्यक्तिगत इंजीनियर कंपनी के कर्मचारी नहीं होते, और कार्यकारी कॉपीराइट नहीं बनता
- अनुबंध के स्वामित्व के निर्धारण का पालन करते हैं, लेकिन ‘अनुबंध’ मौजूद नहीं होता
ऐसा होता है। इसके बावजूद, यदि यह विवाद किसी कारणवश न्यायालय में चला जाता है, तो न्यायालय अनिवार्य रूप से ऐसा निर्णय नहीं लेता।
वैसे, सिस्टम विकास के लिए अनुबंध क्या बिना अनुबंध पत्र के भी स्थापित हो सकता है, इस बारे में नीचे दिए गए लेख में विस्तार से चर्चा की गई है।
https://monolith.law/corporate/system-development-contract[ja]
अगर समझौता नहीं है तो निर्णय अस्पष्ट हो जाता है
यह सिस्टम विकास का मामला नहीं है, लेकिन एक स्थल पर स्थापित किए जाने वाले स्मारक के डिजाइन के बारे में, व्यक्तिगत डिजाइनर और आदेश देने वाली कंपनी के बीच में कॉपीराइट का मामला उठा, जिसमें टोक्यो उच्च न्यायालय ने 2004 में (हेइसेई 16) 31 मई को,
- समझौता नहीं था
- यह स्मारक शुरू से ही कंपनी के निर्देश के तहत स्थल पर स्थापित किया जाना योजनाबद्ध था, और इसके अलावा कोई उपयोग नहीं सोचा गया था
- कंपनी ने व्यक्तिगत डिजाइनर को भुगतान किया था
इन बिंदुओं के आधार पर, व्यक्तिगत डिजाइनर से कंपनी को कॉपीराइट हस्तांतरण की मान्यता दी।
इस प्रकार, यदि समझौता या अन्य लिखित दस्तावेज़ नहीं हैं, तो कॉपीराइट का हस्तांतरण हुआ था या नहीं, यह निर्णय विभिन्न परिस्थितियों के आधार पर, आदेश देने वाले और आदेश प्राप्त करने वाले की यथार्थ इच्छा को खोजने के रूप में किया जाता है। दूसरे शब्दों में, यह एक बहुत ही ‘अस्पष्ट’ निर्णय होता है, और कोई स्पष्ट नियम नहीं होता है। उदाहरण के लिए, “सोर्स कोड लिखने के लिए भुगतान कैसे किया जाता है” इस बिंदु पर, ऊपर उल्लिखित ‘अस्पष्ट’ निर्णय में, सामान्यतः, निम्नलिखित तरीके से इसका सामना किया जाता है।
- मासिक भुगतान जैसे रूप में भुगतान किया जाता है → यह रखरखाव सहित कुल सेवा का भुगतान है, और विशेष रूप से, यदि आदेश प्राप्त करने वाला व्यक्ति होता है, तो यह वेतन के समान मूल्यांकन होता है, और कॉपीराइट के हस्तांतरण को स्वीकार करने की दिशा
- हर बार जब वर्जन अपग्रेड होता है, तो हर बार अनुमान लिया जाता है → यह सीधे उस वर्जन को बनाने का भुगतान माना जाता है, और कॉपीराइट के हस्तांतरण को नकारने की दिशा
जब व्यक्तिगत इंजीनियर कंपनी से आदेश प्राप्त करते हैं ‘साझा व्यापार’ के रूप में, उनका भुगतान अक्सर मासिक भुगतान के रूप में किया जाता है, और परिणामस्वरूप, कंपनी को कॉपीराइट के हस्तांतरण की मान्यता दी जाती है। इसके अलावा, कम से कम, व्यक्तिगत इंजीनियर के रूप में, यदि कोई लिखित दस्तावेज़ नहीं है, तो ‘कॉपीराइट स्पष्ट रूप से मेरे पास है’ ऐसा कहना मुश्किल हो जाता है।
इन सभी बातों के बारे में, सोर्स कोड के कॉपीराइट के बारे में, निम्नलिखित लेख में विस्तार से व्याख्या की गई है।
https://monolith.law/corporate/copyright-for-the-program-source-code[ja]
साझा व्यापार के संबंध में अनुबंध में निर्धारित करने योग्य मुद्दे क्या हैं
ऐसी स्थिति का मूल कारण यह होता है कि पहले से ही अनुबंध नहीं बनाया गया है। यद्यपि, आपको यह सुनकर लग सकता है कि “पहले से ही अनुबंध बनाना वास्तविक नहीं है”, लेकिन हम इसके बारे में बाद में चर्चा करेंगे। सबसे पहले, हम उस अनुबंध के बारे में विवरण देंगे जो होना चाहिए।
कॉपीराइट के बारे में प्रावधान
अनुबंध में, उपरोक्त बातों से स्पष्ट है कि कॉपीराइट के बारे में प्रावधान होना चाहिए। व्यक्तिगत इंजीनियर की दृष्टि से, “व्यक्तिगत रूप से, कंपनी के साथ, साझा व्यापार के रूप में सिस्टम विकास करने” का सबसे बड़ा जोखिम यह है कि परियोजना के लाभान्वित होने के बाद “कट” जाता है।
अर्थात, जैसा कि हम बाद में चर्चा करेंगे, उदाहरण के लिए, “बिक्री की राशि का 20% व्यक्तिगत इंजीनियर को भुगतान किया जाएगा” ऐसा अनुबंध करने के बावजूद, यदि अनुबंध स्वयं को समाप्त कर दिया जाता है, तो आपको अंततः लाभ नहीं मिल सकता। अनुबंध को समाप्त नहीं करने के लिए, “अधिकार” को अपनी ओर रखना महत्वपूर्ण है, और उस “अधिकार” में सबसे महत्वपूर्ण चीज कॉपीराइट है। कॉपीराइट के बारे में,
- कॉपीराइट व्यक्तिगत इंजीनियर के पास होगी
- कॉपीराइट कंपनी और व्यक्तिगत इंजीनियर के बीच साझा की जाएगी
- कॉपीराइट कंपनी के पास होगी, लेकिन कंपनी व्यक्तिगत इंजीनियर की अनुमति के बिना इसे व्यवहार या हस्तांतरण नहीं कर सकती
ऐसे प्रावधान के साथ, कंपनी की दृष्टि से, “व्यक्तिगत इंजीनियर को काटने से व्यापार को जारी रखना संभव नहीं होगा” ऐसी स्थिति होगी, इसलिए उपरोक्त तरीके से “कट” होने से बचा जा सकता है।
वैसे, IT सिस्टम और कॉपीराइट की सम्पूर्ण छवि के बारे में, हमने नीचे दिए गए लेख में विस्तार से विवेचना की है।
https://monolith.law/corporate/internet-technology-system-copyright-problem[ja]
मुआवजा के बारे में प्रावधान
इसके अलावा, मुआवजे के प्रावधान भी, स्वाभाविक रूप से, आवश्यक हैं। यह केवल ऐसे मामलों पर सीमित नहीं है, लेकिन “साझा रूप से व्यापार करने” के मामले में, बिक्री नहीं होने वाले पक्ष के लिए, लाभ के आधार पर नहीं, बिक्री के आधार पर वितरण प्राप्त करना फायदेमंद होता है। अर्थात, उदाहरण के लिए,
- कंपनी, व्यक्तिगत इंजीनियर के प्रति, उस सिस्टम के व्यापार के लाभ का ●% देगी
- कंपनी, व्यक्तिगत इंजीनियर के प्रति, उस सिस्टम के व्यापार की बिक्री का ●% देगी
संभवतः, आपको बाद वाला करना चाहिए। व्यक्तिगत इंजीनियर को, कंपनी में हुई बिक्री भी, प्रत्येक खर्च की राशि भी, और वह खर्च वास्तव में “उस व्यापार के लिए” है या नहीं, इस बात को भी, सही रूप से समझना संभव नहीं है। बिक्री की राशि प्राप्त करने वाला, खर्च भुगतान करने वाला, और उस खर्च से प्राप्त करने वाला, उदाहरण के लिए स्टाफ को प्रबंधित और निगरानी करने वाला, अंततः कंपनी ही होती है। और उसमें, बिक्री की राशि, सबसे आसानी से समझने योग्य चीज होती है। आसानी से समझने योग्य चीजों से ही सरल रूप से गणना की जा सकने वाली राशि का भुगतान प्राप्त करने का तरीका फायदेमंद होता है।
शेयर्स के हस्तांतरण के बारे में प्रावधान
इसके अलावा, आप शेयर्स के हस्तांतरण की मांग कर सकते हैं। हालांकि, इस लेख में हम विस्तार से नहीं चर्चा करेंगे, लेकिन “साझा व्यापार को संभालने वाले बाहरी ठेकेदार के रूप में व्यक्तिगत इंजीनियर” को, उदाहरण के लिए कई दर्जन प्रतिशत और अधिक शेयर्स की मांग करना, वास्तव में कठिन होता है। ऐसे स्थिति में बाहरी व्यक्ति के पास काफी शेयर्स होने से, VC से निवेश या IPO आदि वास्तव में बहुत कठिन हो जाता है। उदाहरण के लिए, 5% आदि, वास्तविक रूप से संभाव्य सीमा में समझौता करना चाहिए।
संविदा पत्र पूर्व में क्यों नहीं तैयार किए जाते हैं
इस प्रकार, व्यक्तिगत इंजीनियर एक कंपनी के साथ ‘साझेदारी व्यापार’ करते हैं, और इस बात के बारे में भविष्य की भुगतान आदि भी शामिल होने वाले संविदा पत्र का अस्तित्व नहीं होना, व्यक्तिगत इंजीनियर के लिए बहुत ‘अनुकूल’ स्थिति है। संविदा पत्र को पहले से तैयार करना महत्वपूर्ण है, हालांकि, केवल ‘फिर भी पहले से संविदा पत्र को ठीक से तैयार करना और समाप्त करना मुश्किल है’ ऐसा महसूस करने वाले लोग भी बहुत होते हैं।
यह, कठोर शब्दों में कहें तो, ‘व्यापार’ के बारे में जागरूकता का, कंपनी की ओर और व्यक्तिगत ओर का अंतर कारण हो सकता है। पहले से ही, ऐसे साझेदारी व्यापार के बारे में विवाद, अधिकांश मामलों में, निम्नलिखित प्रकार की समय श्रृंखला में होते हैं:
- कंपनी और व्यक्तिगत इंजीनियर, नए व्यापार को शुरू करने के लिए, व्यक्तिगत इंजीनियर को सिस्टम विकास का ठेका देते हैं। इस समय, व्यक्तिगत इंजीनियर की जीवन यात्रा आदि के लिए, उदाहरण के लिए ‘मासिक 3 लाख येन’ के रूप में भुगतान की राशि का समझौता होता है
- उक्त व्यापार मुनाफेमय होता है, और उपरोक्त भुगतान भी कुछ बढ़ जाता है
- उक्त व्यापार और भी बढ़ता है, और कंपनी की ओर से करोड़ों येन, अरबों येन की आय होती है
- इस चरण में, व्यक्तिगत इंजीनियर की ओर से प्राप्त होने वाली, उदाहरण के लिए ‘मासिक 5 लाख येन’ की राशि, कंपनी के पास होने वाले लाभ की तुलना में अत्यधिक कम होती है, और, उस सिस्टम को दूसरी कंपनी द्वारा स्वीकार करने की स्थिति में भी यह सस्ता होता है
- व्यक्तिगत इंजीनियर और कंपनी के बीच का संबंध खराब होता है
व्यक्तिगत इंजीनियर की दृष्टि से, निश्चित रूप से, चरण 1 में मासिक खर्च प्राप्त नहीं करने से, जीवन आदि में बाधा आती है। और चरण 4 में, निश्चित रूप से, उपरोक्त उदाहरण में ‘मासिक 5 लाख येन’ की राशि,
- कंपनी की ओर से प्राप्त होने वाला लाभ
- उस सिस्टम को दूसरी कंपनी ने बनाया होता तो उसकी राशि
की तुलना में बहुत कम होती है। हालांकि, इस तुलना को सीधे करना, आर्थिक रूप से अनुचित है। क्योंकि
- कंपनी की ओर से, चरण 1 में, बिक्री होगी या नहीं, इसका पता नहीं चलता, इसलिए व्यक्तिगत इंजीनियर को भुगतान, विपणन व्यक्ति का वेतन आदि देकर, पूर्व निवेश करती है
- अगर दूसरी कंपनी ने सिस्टम बनाया होता, तो उस समय कॉपीराइट ट्रांसफर का निर्धारण आदि होता, और मूल रूप से ‘बिक्री आधारित लाभ वितरण’ की बात नहीं होती
इसका मतलब है। कठोर शब्दों में कहें तो, ‘यदि आपने जानते हुए भी कि यह लाभदायक होगा या नहीं, फिर भी कार्य के लिए भुगतान प्राप्त किया, तो जब इसका परिणामस्वरूप लाभ होता है, तो लाभ वितरण की मांग करने का अधिकार नहीं होता’। न्यायालय के निर्णय भी, परिणामस्वरूप, इस प्रकार के मूल्य निर्धारण और निष्कर्ष के समान होने की संभावना अधिक होती है।
सारांश
व्यापार सफल होगा या नहीं, इसका कुछ भी पता नहीं होने के दौरान, संयुक्त व्यापार समझौते के अनुबंध पत्र का निर्माण करने में समय बिताने या वकील को काम करने के लिए कहने और उसकी लागत उठाने की बात निश्चित रूप से “जोखिम” है। अगर अंततः वह व्यापार असफल हो जाता है, तो वह समय और लागत “लागत असफलता” बन जाती है।
हालांकि, व्यापार की बात करें तो, “जो जोखिम उठाता है, अगर अंततः सब कुछ अच्छा हो जाता है, तो वह अतिरिक्त लाभ प्राप्त करता है” यह मूलभूत संरचना होती है। व्यक्तिगत इंजीनियर के लिए, “अभी तक पता नहीं कि क्या यह लाभदायक होगा” इस चरण में, उपरोक्त समय और लागत जैसी लागतों को उठाने, और उस सीमा तक “जोखिम” उठाने के बावजूद, अगर अंततः वह व्यापार सफल होता है, तो उन्हें ऐसे “जोखिम” को नहीं उठाने वाले की तुलना में बेहतर परिणाम मिल सकते हैं।
संयुक्त व्यापार से संबंधित अनुभंध पत्र अनिवार्य रूप से विशेषज्ञता वाले होते हैं। भविष्य के विवादों को रोकने, और प्राप्त करने वाले लाभ को सुनिश्चित करने के लिए, यह महत्वपूर्ण होता है कि आप जल्दी से वकील को काम करने के लिए कहें और अनुबंध संबंधों को स्पष्ट करने वाले अनुबंध पत्र का निर्माण करें, और उसे पूरा करें।
हमारे दफ्तर द्वारा अनुबंध पत्र निर्माण और समीक्षा आदि की जानकारी
मोनोलिथ कानूनी दफ्तर, एक IT, इंटरनेट और व्यापार में मजबूत कानूनी दफ्तर के रूप में, इसके अलावा भी विभिन्न प्रकार के अनुबंध पत्रों का निर्माण और समीक्षा जैसे कार्य, हमारे सलाहकार कंपनियों और ग्राहक कंपनियों के लिए प्रदान करता है।
विस्तृत जानकारी के लिए, कृपया नीचे दिए गए पृष्ठ को देखें।
Category: IT
Tag: ITSystem Development