क्या आपको अपने लिखे हुए सभी कोड की एक प्रति रखनी चाहिए? [बन्द है]

197

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

जाहिर तौर पर इस लड़के को सोर्स कोड कॉपी करने के लिए जेल भेजा गया था।

legal

— सुपरफू
स्रोत

13

यह एक गंभीर कानूनी मुद्दा हो सकता है यदि आप किसी तरह इसे प्रतिस्पर्धी कंपनी को बेचते हैं / फिर से उपयोग करते हैं।

— ईएल यूसुबोव

19

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

— जाइल

10

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

— कीथ थॉम्पसन

37

@DavidPeterman - ऐसा नियोक्ता क्यों नहीं होगा जिसने आपके लिए जो कुछ भी किया है, उसके लिए आपको हर काम पर रखा है। क्या आपको लगता है कि आपके घर का कुछ हिस्सा उस बढ़ई का है जिसने फंदा लगाया था?

— रिएक्टगुलर

10

@MathewFoscarini मैं समझता हूं कि आप क्या कह रहे हैं, लेकिन मैं एल्गोरिदम के बारे में बात कर रहा हूं। यह कहने जैसा होगा कि बढ़ई घर बनाने के लिए अपने द्वारा उठाए गए कदमों के मालिक नहीं हैं

— डेविड पीटरमैन

303

लेकिन क्या डेवलपर्स के लिए उनके द्वारा लिखे गए कोड की एक व्यक्तिगत प्रति (भविष्य के संदर्भ के लिए) रखना असामान्य है?

मुझे नहीं पता कि यह कितना आम है, लेकिन आम है या नहीं, यह अभी भी एक बुरा विचार है।

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

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

जाने दो। आपको इसकी आवश्यकता नहीं है।

— कालेब
स्रोत

7

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

— कोडर

8

बहुत बढ़िया जवाब! मेरे पुराने नियोक्ता को छोड़ने पर मुझे वास्तव में कोड की प्रतिलिपि (या निरंतर पहुंच) की पेशकश की गई थी। मैंने इनकार कर दिया, ठीक 8 नंबर के कारणों के लिए। आखिरकार, उनसे इस्तीफा देने का एक कारण था। अगर मैं अभी भी उनके लिए कांटा बनाना चाहता था, तो मैं

— रहूंगा

79

+1: आपको इसकी आवश्यकता नहीं है । कठिन हिस्सा समझ रहा है कि क्या लिखना है, वास्तव में इसे लिखना नहीं है। यदि आप इसे दूसरी बार लिखते हैं, तो यह शायद और भी बेहतर होगा।

— केविन क्लाइन

6

जब मैं अपने कोड के साथ एक समस्या को हल करता हूं तो मैं एक ब्लॉग का समाधान लिखता हूं। मेरे काम से स्रोत कोड नहीं है, लेकिन जेनेरिक कोड जो समान पैटर्न का अनुसरण करता है (लक्ष्य को पूरा करने के लिए सरल एक पंक्ति या कुछ पंक्तियाँ - कोड के behemoths नहीं)। मुझे लगता है कि मैंने पिछली नौकरियों में जो कुछ भी सीखा, उसे संग्रहीत करने के लिए यह एक शानदार तरीका है। बुलेट # 7 के लिए +1!

— Ga

11

क्या क्वॉलिफाइ करने वाले कोड की मात्रा के लिए किसी प्रकार की सीमा नहीं होनी चाहिए? अगर मैं for (int i=0; i < N; ++i)अपने कोड में उपयोग करता हूं, तो निश्चित रूप से इसे किसी अन्य कंपनी में कहीं और उपयोग करना अवैध नहीं है ...

— vsz

159

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

क्या यह कानूनी है? अधिकार क्षेत्र और परिस्थितियों पर निर्भर करता है, लेकिन यह काफी सामान्य है। नैतिक रूप से, मुझे इससे कोई समस्या नहीं है, बशर्ते आप नए नियोक्ताओं को कोड न दे रहे हों ... यह आपके नियोक्ता के लिए नि: शुल्क संसाधन के बजाय एक अनुस्मारक और प्रदर्शन है जो आपने किया है।

[इस का दूसरा पहलू यह है कि जब आप पुराने कोड को देखते हैं तो अपरिहार्य शर्म आती है: 'मैं क्या सोच रहा था ?? क्यों पृथ्वी पर किया था कि मैं यह कर कि जिस तरह से ?? ']

— cjmUK
स्रोत

35

+1 और यह प्रासंगिक नहीं है कि क्या यह कानूनी है। हम में से कई वैसे भी करते हैं। यह आपके पिछले नियोक्ता को नुकसान नहीं पहुँचा रहा है (आप किसी प्रतियोगी को कोड नहीं बेच रहे हैं), और इसे वैसे भी विनियमित नहीं किया जा सकता है। एक तरह से, यदि आप "याद" करते हैं कि आपने पिछले नियोक्ता के लिए किसी समस्या को कैसे हल किया है, तो आप उनके लिए इस रहस्य को "चोरी" कर रहे हैं - एक तरह से जब तक कि वे मन-नियंत्रण का आविष्कार नहीं कर सकते हैं;)

— एंड्रेस एफ

89

@AndresF। यह एक युक्तिकरण के अलावा और कुछ नहीं है। कोड आपके पुराने नियोक्ता की संपत्ति है, आपकी यादें नहीं हैं। यदि आपको याद है कि आपने एक समस्या को कैसे हल किया है तो आपको कोड की आवश्यकता नहीं है, तो इसे लेने में क्या बात है?

— कालेब

10

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

— तेलेस्टिन

46

आईपी चोरी के आरोप में कंपनी के मामले में, कोड की एक प्रति होने से आप के लिए एक बड़े आक्रामक कारक के रूप में कार्य किया जा सकता है। इसकी स्मृति होना नहीं है। यही अंतर है।

— ओलेक्सी

13

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

— एंड्रेस एफ।

51

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

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

निश्चित रूप से कोड लिखने से आपको जो उपयोगी सामान मिला है वह सटीक वाक्यविन्यास नहीं है; यह आपको प्राप्त ज्ञान है। यह संभवतः इस सभी कानूनी सामान से निपटने के लायक नहीं है।

— ओलेक्सी
स्रोत

9

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

— एंड्रेस एफ।

14

@ मालफिस्ट नहीं, तुम नहीं। IANAL, लेकिन यह बहुत अच्छी तरह से स्थापित है कि, अमेरिका में, कम से कम, जो काम उत्पाद आपको भुगतान करने के लिए करते हैं, वे आपकी संपत्ति हैं, न कि आपकी। विकिपीडिया में किराए के लिए काम देखें ।

— कालेब

5

@ जालिम फिर, नहीं। मेरी पिछली टिप्पणी में लिंक देखें।

— कालेब

4

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

— जूल

5

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

— नादिर संपोली

36

यह असामान्य नहीं है।

मेरे पास लगभग हर ¹ कोड की एक प्रति है जो मैंने पेशेवर रूप से लिखी है, और निश्चित रूप से मेरी वर्तमान परियोजनाओं के सभी कोड, चाहे वह ^{2 भी} लिखे । कोड के साथ मेरे पास कानूनी कागजी कार्रवाई का एक बड़ा ढेर है जो स्पष्ट रूप से परिभाषित करता है कि मैं इसके साथ क्या कर सकता हूं। सिर्फ कोड होने से कोड से लाभ कमाने की कोशिश करना समान नहीं है।

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

_{¹ जो चीज याद आ रही है वह ज्यादातर वही है जो मैंने संग्रह की परवाह नहीं की। कानूनी कारणों से केवल एक छोटी परियोजना का कोड गायब है।}
_{² परियोजनाओं की प्रकृति और उनमें मेरी भूमिका, मैं उन लोगों में से एक हूं, जिन्हें कम से कम इस बात का अंदाजा होना चाहिए कि मैं कहां जाता हूं, भले ही मैं एक विशिष्ट मॉड्यूल के निर्माण में शामिल नहीं था।}

— यानिस रिज़ोस
स्रोत

4

@ हाइलम मैं कंपनी के परिसर में कभी नहीं हूं ;)

— यानि

3

फिर भी मुझे यकीन है कि आपको पता है कि मेरा क्या मतलब था, और यह कि यह शायद कोई फर्क नहीं पड़ता कि आप शारीरिक रूप से कहाँ हैं :)

— जाइलम

3

मैंने एक वर्डप्रेस कॉन्फ्रेंस में एक डेवलपर को सुना और उसने कुछ ऐसा कहा "अगर मैं आपके लिए कॉन्ट्रैक्ट का काम करता हूं तो मुझे यकीन है कि आपको पता है कि मैं आपके लिए लिखे कोड का मालिक हूं, लेकिन इसका मतलब यह नहीं है कि मैंने कुछ भी नहीं सीखा है। अपना कोड लिखकर नया। "

— प्रोग्रामर

3

@ कालेब का उचित दस्तावेज होना असामान्य हो सकता है (मुझे नहीं पता), हालाँकि मुझे नहीं लगता कि कोड की प्रतियां रखना है। मेरे पास बस दोनों होने के लिए;)

— यानिस

2

@Krelp, एन्क्रिप्शन कुंजियों, जैसे कि तिजोरियों की चाबी को एक सबपोना के माध्यम से मजबूर किया जा सकता है।

— मलफिस्ट

29

मैं आपके गिरफ्तार चीनी आदमी को देखता हूं और आपको "कोड संपत्ति नहीं है, इसलिए चोरी नहीं किया जा सकता है" के साथ बढ़ाता है।

Ref .: कोड 'भौतिक संपत्ति नहीं', गोल्डमैन सैक्स जासूसी मामले में अदालत के नियम

उस के साथ कहा।

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

— TimSonOfSteve
स्रोत

14

+1 हेहे, एक अच्छा, ईमानदार जवाब। सबसे अच्छी बात यह है कि यह सच है कि आप वास्तव में कभी भी पुराने कोड पर वापस नहीं जाते हैं। यदि आप इसे अपने साथ लेते हैं, तो आप इसे सुरक्षित महसूस करते हैं, इसे अपने जीवन में दोबारा देखने की ज़रूरत नहीं है!

— एंड्रेस एफ।

क्या यह हाल के Oracle v Google मामले में भी एक प्रमुख मुद्दा नहीं था?

— रॉबर्ट जुब

1

आपसे पूर्णतः सहमत हूँ। मैं भी यही कर रहा हूं। यह बहुत अच्छा संदर्भ है।

— एंड्रिया गिरधारी

2

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

— नैट

संबंधित लेख: क्या गोल्डमैन सैक्स ने अपने पूर्व-प्रोग्रामर को अपराध के आरोप में पछाड़ दिया था? । यह भी एक अच्छा उदाहरण है कि यदि आप अंत में जीत जाते हैं, तो भी कानूनी लड़ाई खुद को बहुत नुकसान पहुंचा सकती है।

— कोडइंचोज

10

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

उनकी अगली हरकतें तय करेंगी (हाँ, यह शब्द उत्तरी अमेरिका / विश्व में मौजूद है) यदि आप उनकी नज़र में गलत या सही हैं।

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

अब यह ईमानदारी का सवाल है। मैंने एक पिछले कर्मचारी को हमारा कुछ कोड लेने दिया है, लेकिन मैंने सबसे पहले उसका वीटो किया है।

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

— रेयान टर्नियर
स्रोत

"जब मैंने यहां काम किया" का अर्थ है कि प्रश्न में व्यक्ति अब आपका बॉस नहीं है। यदि यह आपका पूर्व बॉस है, तो आप उससे पूछने की परवाह क्यों करेंगे?

— अलेक्जेंडर

क्यों? ठेके? अखंडता?

— बजे रयान टर्निर

आप अपने द्वारा लिखे गए कोड को किसी भी चीज़ के लिए उपयोग नहीं करते हुए रख सकते हैं और फिर भी दोनों आपके अनुबंधों को बनाए रखते हैं और आपकी अखंडता को बनाए रखते हैं।

— अलेक्जेंडर

2

यदि आप एक अनुबंध पर हस्ताक्षर करते हैं जो बताता है कि सभी कोड आपके नियोक्ता की संपत्ति है, तो आप इसे घर ले जा रहे हैं यह उस अनुबंध का उल्लंघन है यदि वे नहीं जानते कि आपके पास यह है, या आपने इसे अनुमति दी है। यह प्रभावी रूप से चोरी है। हाँ यह "कोड", डिजिटल 0 और 1 का है, लेकिन ज्यादातर मामलों में यह काला और सफेद है।

— रयान टर्निर

यह शास्त्रीय "चोरी चोरी है" चर्चा है।

— अलेक्जेंडर

8

क्या डेवलपर्स के लिए उनके द्वारा लिखे गए कोड की एक व्यक्तिगत प्रति रखना असामान्य है

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

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

— फ्रस्ट्रेटेडविथफॉर्म्सडिजेनर को पुनर्जीवित करता है
स्रोत

3

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

— कैमिलो मार्टिन

1

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

— क्रिस

8

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

इसके परिणामस्वरूप जीत की स्थिति बनी। यह भी लिखा गया सभी कोड का एक सबसेट था।

बेशक, जो कुछ निजी पुस्तकालयों में था, वह आज मानक पुस्तकालयों में होगा।

— जॉन स्ट्रायर
स्रोत

कुछ वातावरणों में, लाइब्रेरी या कंपोनेंट कोड के बीच एक स्पष्ट परिसीमन होता है, या पुन: उपयोग के लिए स्पष्ट रूप से डिज़ाइन किए गए कक्षाएं (पार्सर, आदि) और जो समस्या डोमेन विशिष्ट हैं। कोड जो समस्या डोमेन विशिष्ट है (XWare की प्रमुख इनडोर ऐप या वाणिज्यिक इकाई) उस स्थान के बाहर उपयोगी नहीं हो सकती है, लेकिन निम्न स्तर या पुन: प्रयोज्य घटक / पुस्तकालय वास्तव में वास्तव में बहुत उपयोगी हो सकते हैं।

— वारेन पी

6

एक नियोक्ता के तहत उत्तरी अमेरिका के अधिकांश हिस्सों में कर्मचारी संबंधों के लिए नियोक्ता से पूर्व कानूनी प्राधिकरण के बिना अपने नियोक्ता उपकरण से डिजिटल सामग्री (यानी स्रोत कोड) को स्थानांतरित या प्रसारित करना अवैध है।

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

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

इस संबंध के दौरान किस समय पर नियोक्ता से मूल्यवान सामग्री चोरी करना ठीक है, जिसने उक्त सामग्री के निर्माण के लिए भुगतान किया है और जोखिम लिया है?

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

उस के साथ, अगर किसी नियोक्ता ने आपको अपने स्वयं के उपकरण (यानी लैपटॉप) का उपयोग करने या सामग्री को प्रसारित करने की अनुमति दी है, तो यह अलग बात है। नियोक्ता को आपको समाप्ति पर सूचित करना चाहिए कि किसी भी सामग्री को वापस कर दिया जाना चाहिए / नष्ट कर दिया जाना चाहिए।

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

— मैथ्यू फोसकारिनी
स्रोत

नियोक्ता को आपको समाप्ति पर सूचित करना चाहिए कि किसी भी सामग्री को वापस कर दिया जाना चाहिए / नष्ट कर दिया जाना चाहिए। क्या यह वास्तव में सच है? क्या नियोक्ता ऐसा करने के लिए कानूनी और / या संविदात्मक दायित्व के तहत है?

— रादु मुरझिया

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

— रिएक्टगुलर

5

मैंने पिछले कुछ नौकरियों में ऐसा किया है।

हालांकि मैं एक बार वापस नहीं गया और इसे देखा। मैंने कभी-कभी उन विचारों और चीजों का पुन: उपयोग किया है जिन्हें मैंने सीखा है, लेकिन मुझे एक बार वापस जाने और कोड को देखने का कोई कारण नहीं मिला है।

तो मैं किसी भी अधिक परेशान नहीं करेगा। यह कानूनी रूप से संदिग्ध है, और मैंने वास्तव में इसे व्यवहार में उपयोगी नहीं पाया है।

— JohnB
स्रोत

4

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

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

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

— स्टीव बेनेट
स्रोत

3

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

यह स्मृति लेन नीचे एक छोटी सी यात्रा थी हालांकि :)

— दर्शाता है
स्रोत

2

मुझे लगता है कि एक डिज़ाइन-पैटर्न और वास्तविक कोड (लाइन-बाय-लाइन की नकल) के बीच अंतर होना चाहिए

कुछ psuedocode को कुछ इस तरह से लिखना - यह Y में आलसी लोड करने का एक शानदार तरीका है। सभी कोड को लिखना कुछ और है।

— PSU_Kardi
स्रोत

1

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

इस तरह आप कोड को कानूनी रूप से रख सकते हैं, आपके द्वारा लिखे गए कोड का एक सार्वजनिक पोर्टफोलियो बना सकते हैं और कोड अन्य लोगों को लाभान्वित कर सकता है।

— सरेल बोथा
स्रोत

1

विभिन्न कारणों से, जैसे घर से काम करना, आपके पास पहले से ही एक प्रति हो सकती है, और मैं एक के लिए एक नौकरी के बाद इन्हें हटा नहीं सकता, ऐसा क्यों? यह मेरे विश्वासों या कुछ के खिलाफ नहीं जाता है।

लेकिन, इसका उपयोग करने के बारे में, यह ब्लॉग पोस्ट के रूप में इतना उपयोगी नहीं है !

नीचे पंक्ति: अपना कोड, समस्याओं के बारे में ब्लॉग लिखें, जो आपने सामना किया है और आपने उन्हें कैसे हल किया (विशेषकर जब यह सामान्य और व्यापक सामान है), और अंतिम नौकरी से (संभवतः एन्क्रिप्टेड) स्मारिका रखने के लिए बुरा मत मानना।

— कैमिलो मार्टिन
स्रोत

1

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

यह निश्चित नहीं है कि यह कितना वैध है, लेकिन मुझे लगता है कि आपका सबसे अच्छा शर्त यह है कि आप अपने स्रोत कोड को छोड़ दें, लेकिन अपने विचारों को लिख लें और आपने घर मिलते ही इसे कैसे किया। चोरी करना चोरी है और अदालत में वे सभी यह पता लगाने की कोशिश कर रहे हैं कि आपने कोड की नकल की है या नहीं।

— पीटर मोर्टेंसन
स्रोत

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

— एंड्रेस एफ।

1

@AndresF। मैंने एक बार हेज फंड में काम किया था जिसने इसे रोकने की कोशिश की। वे ईमानदारी से इसे रोक नहीं सकते थे इसलिए उन्होंने लोगों को गैर-प्रतिस्पर्धा अनुबंधों पर हस्ताक्षर किए और उनके इस्तीफे के बाद 1-2 साल तक काम न करने के लिए भुगतान किया। यद्यपि बहुत महंगा (आप किसी ऐसे व्यक्ति को 2 साल का वेतन दे रहे हैं जो आपके लिए काम नहीं करता है), यह आपके ज्ञान को बासी बना देता है जब आप प्रतिस्पर्धी खतरे के रूप में छोड़ देते हैं और बेकार हो जाते हैं।

— लॉस्टसूल

केवल विचारों के लिए +1 और कोड नहीं। एक कंपनी के साथ शामिल था जिसने एक पूर्व-प्रोग्रामर पर कोड चोरी करने और एक समान उत्पाद बेचने के लिए मुकदमा दायर किया था। न्यायाधीश ने फैसला सुनाया कि क्योंकि कीड़े समान थे उन्होंने कोड चुरा लिया होगा।

— JQA

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

— रिएक्टगुलर

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

— लॉस्टसूल

1

यदि आप अपने कोड को बाद में पुन: उपयोग करने के लक्ष्य के साथ सहेज रहे हैं, तो मेरे पास इसके साथ दो मुद्दे हैं:

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

यदि आप मानते हैं कि आपके पास एक आम समस्या का सबसे अच्छा समाधान है, तो आपको वास्तव में आपको सार्वजनिक रूप से रिपॉजिटरी और / या कोड ब्लॉग पर सार्वजनिक रूप से कोड साझा करने का प्रयास करना चाहिए जब आप इसे लिखते हैं, तो इसे अपने पास न रखें। आपके बॉस को जेनेरिक लाइब्रेरी को साझा करने या आपको पहिया को फिर से मजबूत करने के लिए मजबूर नहीं करना चाहिए (यदि वह करता है, तो एक नया काम खोजें)।

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

— डेविड वीक्स्लर
स्रोत

1

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

— cjmUK

0

मैंने अभी तक कोई कोड नहीं रखा है जो मैंने नियोक्ताओं के लिए किया है। फ्रीलांस सामान जो मैंने रखा है (यदि मैं अपना कोड खो देता हूं तो ग्राहक का समर्थन करना कठिन हो सकता है)।

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

मुझे पता है कि डिजाइनर अक्सर पोर्टफोलियो कार्यों के लिए अपने काम की प्रतियां रखते हैं (भले ही यह काम के लिए किराया हो)।

मुझे यकीन नहीं है कि इस की वैधता क्या है (यह मेरे अनुबंध में स्पष्ट रूप से उल्लिखित नहीं है)।

— Xandor Schiefer
स्रोत

4

but what are your thoughts on this?कृपया किसी अन्य प्रश्न को शुरू करके अपने उत्तर पर बातचीत को खुले तौर पर आमंत्रित न करें। आप हमें बताएं कि क्या हमें लिखे गए सभी कोड की एक प्रति रखनी चाहिए। आप इसे संपादित करके उत्तर को बेहतर बना सकते हैं।

— maple_shaft

1

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

— सेरेल बोथा

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

— Xandor Schiefer

0

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

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

मेरे पास इसका एक वैकल्पिक समाधान है। थोस उपयोगिता के लिए बस एक बिना स्रोत / प्रलेखन JAR बनाएं और इसे अपनी परियोजना में बाहरी तृतीय-पक्ष JAR के रूप में जोड़ें। संभवतः ऐसा करने से आप अपनी जिम्मेदारी के साथ-साथ अपने आत्म संतोष की पुष्टि कर सकते हैं कि आपके पास कोड है ;)

— सौम्यदीप दास
स्रोत

1

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

— जोएल मार्टिनेज

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

— सौम्यदीप दास

0

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

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

— स्कॉट एस
स्रोत