क्लाइंट सोर्स कोड चाहता है, लेकिन इसमें बहुत सारे साझा कोड हैं जिनका मैं अन्य परियोजनाओं के साथ पुन: उपयोग करता हूं

Question

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

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

मैं इसे एक उत्पाद के लिए उपयोग करने का इरादा रखता हूं, इसलिए मैं वास्तव में इसे अपेक्षाकृत छोटे प्रोजेक्ट के लिए प्रदान नहीं करना चाहता।

मैं अनुमान लगा रहा हूं कि यह पहली बार नहीं है जब इस उद्योग में ऐसा हुआ है। इस मुद्दे को दरकिनार करने का सबसे अच्छा तरीका क्या है? मैं अनुमान लगा रहा हूं कि साझा लाइब्रेरी जैसी चीजें मदद कर सकती हैं।

Comments

उन्हें इसके लिए क्या चाहिए? संभावना है कि वे केवल यह सुनिश्चित करना चाहते हैं कि यदि आप व्यवसाय से बाहर जाते हैं तो कोड होना चाहिए। आप संभवतः लाइसेंसिंग को जोड़ सकते हैं जो अनुमत उपयोग को सीमित करता है। एक बार एक कंपनी में मैंने काम किया (सही शब्द?) स्रोत कोड एक वकील कंपनी के साथ इस तरह के मामले के लिए सुरक्षा के रूप में।

— थोरस्टेन मुलर

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

— कोडएन्ज्री

@CodeAngry "चाहिए"? नहीं, केवल अगर वे पैसे की सही राशि का भुगतान करते हैं।

— ओ ० '।

@CodeAngry nope यह तुम्हारा है, जब तक कि अन्यथा सहमत न हो ...

— o0 '।

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

— गुंट्रम ब्लोम

Answer 1

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

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

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

Comments

क्या होगा अगर सॉफ्टवेयर कोड एस्क्रो सर्विस दिवालिया हो जाए?

— user11153

फिर कोड का मालिक है - उम्मीद है - अभी भी आस-पास है, और अपने कोड को किसी अन्य एस्क्रो सेवा को वितरित कर सकता है। सेवा का उद्देश्य एकल बिंदु विफलता को दूर करना है।

— अलेक्जेंडर

क्या सॉफ्टवेयर कोड एस्क्रो सर्विसेज सॉफ्टवेयर कोड एस्क्रो सर्विसेज का उपयोग करते हैं?

— FreeAsInBeer

@FreeAsInBeer: नहीं, वे सॉफ़्टवेयर कोड एस्क्रो एस्क्रो सर्विसेज का उपयोग करते हैं। जाहिर है।

— nnonneo

@ अलेक्जेंडर, केवल अगर फिर से एस्क्रौ करना एक अनुबंधित दायित्व है। अन्यथा डेवलपर फिर से दूसरे एस्क्रो के लिए शुल्क लेगा।

— पचेरियर

Answer 2

"नहीं" एक पूरी तरह से ठीक जवाब है, वास्तव में यह एक अविश्वसनीय रूप से उपयोगी उत्तर है जो किसी कारण से मुझे समझ नहीं आ रहा है, बहुत कम है।

"हाय, हमने निश्चय ही निश्चय किया है कि हम स्रोत कोड भी चाहते हैं, नि: शुल्क।"
"हाय, नहीं।"

यह वास्तव में इतना मुश्किल नहीं है।

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

सरल चीजों को जटिल मत करो।

Comments

शानदार, संक्षिप्त जवाब।

— तिब्बत का सागर तट

Answer 3

आपका सवाल है, "इस मुद्दे को दरकिनार करने का सबसे अच्छा तरीका क्या है?" लेकिन आप इस मुद्दे के रूप में क्या देखते हैं? दूसरों ने सही ढंग से बताया है कि यह बातचीत का विषय है: हर चीज का एक मूल्य होता है, और यह आप पर निर्भर करता है कि ग्राहक को वह मूल्य प्रदान करें जो आप के लिए कह रहे हैं।

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

आपको अनुबंध को स्पष्ट रूप से यह सुनिश्चित करने की आवश्यकता है कि किसके पास कोड का उपयोग करने का अधिकार है, और किन तरीकों से।

Answer 4

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

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

Comments

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

— ओ ० '।

@ हालांकि, यदि आपको संदेह है कि कोई एप्लिकेशन आपके कोड का उपयोग कर रहा है, तो यह वास्तव में बताना आसान है, कोई फर्क नहीं पड़ता कि यह सिर्फ एक द्विआधारी है। बेसिक रिवर्स इंजीनियरिंग कौशल आपको सुनिश्चित करने की आवश्यकता है।

— संशोधित करें

-1 चूंकि मुझे नहीं लगता कि आपके "एक प्रमुख कंपनी ..." के दावे के लिए कोई सबूत है, यह सिर्फ एक अनुमान है।

— djechlin

@ लोरिस: यदि ऐसा होता है, तो आपको क्या नुकसान है? सबसे अच्छा मामला: पोस्टर एक अन्य कंपनी को अपनी सेवाएं प्रदान करता है, और पाता है कि उनके पास पहले से ही वह पुस्तकालय है जिस पर उन्हें बहुत गर्व है। मेजर पे!

— gnasher729

Answer 5

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

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

कुंजी है: "ये घटक एक अलग उत्पाद हैं" और सभी शुरू होने से पहले एक अनुबंध में लिखे गए हैं।

तो हाँ, आप साझा पुस्तकालयों का उपयोग करने के बारे में विचार सही हो सकता है। हालाँकि, मैं आपसे पूछता हूं, आप उन्हें एक लाइसेंस के तहत स्रोत कोड प्रदान क्यों नहीं करते हैं, जो उन्हें अपने जोखिम को कम करने की अनुमति देगा? मुझे लगता है कि यह उचित होगा।

Comments

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

— केसी

Answer 6

इससे निपटने का तरीका बातचीत करना है।

यदि वे स्रोत कोड चाहते हैं, तो उन्हें इसके लिए भुगतान करने के लिए तैयार रहना चाहिए, और यह आपको तय करना है कि कितना होना चाहिए।

दूसरी ओर ... यदि वे भुगतान करने के लिए तैयार नहीं हैं जो आप चाहते हैं, तो वे "अपने व्यवसाय को कहीं और ले जाने" का फैसला कर सकते हैं।

व्यापार की दुनिया में आपका स्वागत है :-)

---

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

---

यह भी ध्यान देने योग्य है कि आप जो कर रहे हैं, वह खुले स्रोत डेवलपर्स के लिए, और (शिक्षित) ग्राहकों के लिए है, जो खुले स्रोत समाधान की तलाश कर रहे हैं।

Comments

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

— djechlin

@djechlin - 1) मैंने ओपी को दोष नहीं दिया। लेकिन अगर वह उस बिंदु पर बातचीत करने के लिए तैयार नहीं है ... तो उसे >> << इसे पहले लाना चाहिए। यह bespoke सॉफ्टवेयर के लिए एक जानकार ग्राहक के लिए एक स्पष्ट और उचित आवश्यकता है। 2) "अनात्म" वह होगा जो ओपी कर रहा है ... स्रोत कोड पर पकड़ बनाने की कोशिश कर रहा है। 3) जबकि, ऐसा कोई संकेत नहीं है कि ग्राहक ने खुले स्रोत के लिए पूछा (हो सकता है, वे वास्तव में इसके लाभों को नहीं समझते हैं) यह स्पष्ट है कि >> >> << स्रोत कोड चाहते हैं, जो ओएसएस के अपने प्रमुख लाभों में से एक है। ।

— स्टीफन C

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

— डॉटनचेन

@dotancohen: मुझे आशा है कि उन्हें "गैर-अनन्य" लाइसेंस मिलेगा। यदि उनके पास एक विशेष लाइसेंस है, तो आप अगले ग्राहक के लिए कोड का पुन: उपयोग नहीं कर सकते। आपके पास समान कोड के लिए "अनन्य" लाइसेंस वाले दो ग्राहक नहीं हो सकते।

— gnasher729 13

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

— dotancohen

Answer 7

आपके लिए यह बहुत देर हो सकती है, इसमें आप पहले से ही ऐसा करने के लिए अनुबंध पर सहमत हो सकते हैं, और आप विभिन्न ग्राहकों के साथ पारस्परिक रूप से असंगत शब्दों पर सहमत हो सकते हैं।

दो तरीके हैं जिनसे आप अपने ग्राहकों को अपने स्रोत कोड प्रदान कर सकते हैं। कॉपीराइट का स्वामित्व और लाइसेंस।

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

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

हालाँकि, इस प्रश्न में स्थिति दोनों की एक मिशाल है।

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

इस बात पर निर्भर करते हुए कि आपने पहले से ही क्या किया है, आप मुक्त करने के लिए एक प्रतिस्थापन कार्यक्षमता लिख ​​सकते हैं, या अपने स्रोत कोड को दे सकते हैं।

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

Comments

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

Answer 8

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