क्या आप यह दावा कर सकते हैं कि आपका उत्पाद उस उद्देश्य के लिए उपयुक्त है जब वह ओएसएस सॉफ्टवेयर का उपयोग करता है जो इसकी गारंटी नहीं देता है?

Question

मैं एक ग्राहक के लिए एक उत्पाद पर काम कर रहा हूं जो वैध होना चाहिए और उद्देश्य के लिए फिट होना चाहिए।

यह एक LAMP स्टैक (PHP / Cake) पर बनाया गया है, इसलिए GPL, MIT, PHP, APACHE लाइसेंस हैं:

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

मेरा तर्क यह है कि मेरा उत्पाद मान्य है और प्रयोजनों के लिए फिट है:

• हस्ताक्षरित यूएटी डॉक्टर उद्देश्य के लिए वैधता और फिटनेस साबित करता है।
• ढेर डेवलपर्स, उद्योग और अंत उपयोगकर्ताओं (नेटक्राफ्ट, गार्टनर आदि आँकड़े) द्वारा व्यापक रूप से उपयोग किया जाता है, कि एक आम सहमति है कि यह उद्देश्य के लिए फिट है। (यानी हम एक हद तक वारंटी अस्वीकरण में उद्देश्य के बयान के लिए फिटनेस की उपेक्षा कर सकते हैं)

क्या यह एक वैध बिंदु है? क्या मैं यह दावा कर सकता हूं कि मेरा सॉफ़्टवेयर उद्देश्य के लिए फिट है?

Comments

"आम सहमति"! = "वारंटी"।

— Joachim Sauer

लेकिन वारंटी = उद्देश्य के लिए फिट बैठता है? मैं वारंटी को समझता हूं कि यदि वह ऐसा नहीं करता है जो वह करने के लिए है, तो उसे ठीक करना / बदलना या पैसा वापस करना है।

— user127379

एक वारंटी किसी भी चीज के लिए हो सकती है। मैं गारंटी दे सकता हूं कि एक दिया गया प्रोग्राम कम से कम 3 सेकंड के लिए क्रैश नहीं होगा, जो इसे किसी विशेष उद्देश्य के लिए फिट नहीं करेगा (जब तक कि आपका उद्देश्य कम से कम 3 सेकंड के लिए किसी भी प्रोग्राम को चलाने के लिए नहीं है)।

— जोकिम सॉयर

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

— ब्लर एफएल

सॉफ्टवेयर इंजीनियरिंग कानूनी सलाह के लिए सबसे अच्छा विकल्प नहीं है। किसी वकील से सलाह लें।

— zzzzBov

Answer 1

सबसे पहले, जैसा कि दूसरों ने कहा है, वास्तव में काम करने वाले सॉफ़्टवेयर के बीच एक अंतर है, जो एक कानूनी गारंटी के साथ बेचा जा रहा है कि यह काम करता है।

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

विशेष रूप से, GPL राज्यों की धारा 4:

आपके द्वारा बताई गई प्रत्येक प्रति के लिए आप कोई मूल्य या कोई मूल्य नहीं ले सकते हैं, और आप शुल्क के लिए समर्थन या वारंटी सुरक्षा प्रदान कर सकते हैं।

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

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

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

Comments

आप किसी कार्य में वारंटी को तब तक जोड़ सकते हैं जब तक ऐसा करने से लाइसेंस की शर्तों का उल्लंघन न हो और यह स्पष्ट हो कि आप वारंटी जोड़ने वाले हैं, न कि लाइसेंस देने वाला।

— ब्लर एफएल

@ ब्लरफ्लेक समझ में आता है। यदि मैं BSD- लाइसेंस कोड को और अधिक कठोर लेकिन संगत लाइसेंसिंग (जैसे, GPL) के साथ बड़े काम में लगा सकता हूं, तो मैं अपनी वारंटी की शर्तों के साथ भी ऐसा कर सकता हूं।

— अप्सिलर्स

वैसे: "बिना किसी प्रकार के युद्ध, या किसी भी तरह के व्यक्त या निहित सहित कथन, बिना किसी सीमा के, किसी भी वारंटी या TITLE, NON-INFRINGEMENT, MERCHANTABILITY, या एक पक्षीय सर्वेक्षण के लिए उपयुक्तता"। कुछ देशों में शून्य हैं , उदाहरण के लिए इटली। आप बस वारंटी के बिना कुछ वितरित नहीं कर सकते । या तो पूरे अनुबंध को शून्य माना जाता है या आप कानूनी जिम्मेदारियों को लेने के लिए बस अंत करते हैं।

— बाकूरी

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

— जोआचिम सॉयर 16

Answer 2

यह एक मानक अस्वीकरण है, जो अक्सर सॉफ्टवेयर के लिए दिया जाता है, विशेष रूप से मुफ्त सॉफ्टवेयर।

इसका मतलब सिर्फ इतना है कि सॉफ़्टवेयर का प्रदाता सॉफ़्टवेयर की फिटनेस के बारे में कोई गारंटी नहीं देता है । वह बहुत अच्छी तरह से आश्वस्त हो सकता है अपने आप को है कि सॉफ्टवेयर यह क्या करता है के लिए अच्छा है, लेकिन वह कानूनी सुरंग है कि यह गारंटी प्रवेश करने के लिए नहीं चाहता है।

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

संक्षेप में: जब तक आप इसके लिए भुगतान नहीं करते, तब तक आपको किसी भी तरह की फिटनेस की गारंटी देने वाला कोई भी नहीं मिलेगा। और अगर आप किसी को भुगतान करते हैं, तो भी वे इसकी गारंटी नहीं दे सकते।

Comments

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

— user127379

@ user127379: 1.) हां, यह अस्वीकरण केवल मुफ्त सॉफ्टवेयर तक सीमित नहीं है , यही कारण है कि मैंने " विशेष रूप से मुफ्त सॉफ्टवेयर" लिखा है । 2.) सावधान रहें: "यह एक्स के लिए फिट नहीं है" ऐसा नहीं है "मैं गारंटी नहीं देता कि यह एक्स के लिए फिट है"!

— जोआचिम सॉयर

विंडोज जाहिर तौर पर इस उद्देश्य के लिए इतना अयोग्य है कि दुनिया का हर व्यवसाय इसका उपयोग करता है।

— एलन बी

Answer 3

मुझे लगता है कि अन्य उत्तर आपके प्रश्न के विभिन्न पहलुओं को कवर कर रहे हैं, लेकिन मुझे विश्वास नहीं है कि वे आपके विवरणों को सीधे संबोधित कर रहे हैं।

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

आप (और आपकी कंपनी) उस वारंटी द्वारा उत्पन्न देयता के एकमात्र वाहक होंगे। और यह सब एक वारंटी है - यह एक दायित्व है। यदि उत्पाद काम करने में विफल रहता है तो आप गारंटी दे रहे हैं कि आप उत्तरदायी हैं।

आप ऐसा करने के लिए नहीं कह रहे हैं, लेकिन आप उस दायित्व को अन्य सॉफ्टवेयर घटकों / प्रकाशकों को "अप-स्ट्रीम" पर नहीं धकेल सकते हैं , जिनका आप उल्लेख करते हैं क्योंकि उन्होंने स्पष्ट रूप से उस देयता कवरेज को स्वीकार करने से इनकार कर दिया है।

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

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

Comments

हां, मैंने एक कंपनी देखी है जिसके साथ मैंने काम किया है। मुझे सभी विवरणों की जानकारी नहीं है, इसलिए मुझे इस प्रश्न का उत्तर देने में सहज महसूस नहीं हुआ, लेकिन मुझे खुशी है कि आपने किया।

— रेडियन

Answer 4

मैं एक चिकित्सा सॉफ्टवेयर परियोजना पर काम कर रहा हूं, जहां हम एक ही तरह के विनियमन के तहत थे, हमें उत्पाद को सत्यापित और मान्य दोनों करना होगा।

और हम एफडीए की आवश्यकताओं को पूरा कर सकते हैं।

मैंने 3 पार्टी टूल्स के वास्तविक सत्यापन में भाग नहीं लिया, लेकिन जहाँ तक मैं समझ सकता था, हमें जो करना था वह यह निर्दिष्ट करना था कि तीसरा पक्ष सॉफ्टवेयर हमें क्या सेवा देगा। फिर हमें स्वयं उन उत्पादों को मान्य करना था, जिसका अर्थ है कि हमने यह पुष्टि की है कि चुने हुए 3 पार्टी सॉफ्टवेयर पैकेजों ने उस उद्देश्य की पूर्ति की है।

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

यह सत्यापन वास्तविक सॉफ्टवेयर में निर्मित दोनों घटकों के लिए होगा, लेकिन विकास के वातावरण, स्रोत नियंत्रण प्रणाली आदि के लिए भी।

नोट: यह इस बात पर आधारित है कि मैंने कैसे समझा कि हमें क्या करना है। मुझे गलत मुद्दों का सामना करना पड़ सकता है। और कंपनी वास्तव में आवश्यकता की तुलना में सत्यापन प्रक्रिया में बहुत अधिक हो सकती है (मुझे लगता है कि यह कुछ हद तक मामला था)।

लेकिन सॉफ्टवेयर को मान्य किया गया था।

लेकिन आपको एक वैध उत्पाद की आवश्यकता क्यों है? क्या आप एक विनियमित खंड में पहुंच रहे हैं, जैसे चिकित्सा या वित्त। या ग्राहक आईएसओ 9001 (या समान) प्रमाणित है? यदि हां, तो आपको इस तरह के नियमों के लिए आवश्यकताओं का अध्ययन करना चाहिए कि आपके स्वयं को यह पता लगाना है कि क्या आवश्यक है।

Comments

GCP और संभवतः CFR भाग 11. यह ज्यादातर GCP से संबंधित आवश्यकताएं हैं। यह मूल रूप से एक CRUD है, स्थिति परिवर्तन के साथ कि यह पूरा हुआ है या नहीं। मैं हर छोटी चीज का दस्तावेजीकरण करने से बचने की कोशिश कर रहा हूं। मैंने एक परीक्षण के रूप में phpinfo () को चलाने जैसी चीजों का दस्तावेजीकरण किया है जो LAMP स्टैक काम कर रहा है और पृष्ठों की सेवा कर रहा है, आउटपुट को पास करने के लिए सूचीबद्ध मॉड पुनर्लेखन और mysql आदि को दिखाना चाहिए।

— user127379

Answer 5

जीएनयू लाइसेंस का अस्वीकरण वहाँ है ताकि, डिफ़ॉल्ट रूप से, डेवलपर्स को सॉफ़्टवेयर चलाने से उत्पन्न होने वाली किसी भी देयता से अवगत कराया जाए।

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

डिस्क्लेमर बस कहता है कि जो वितरित किया जा रहा है वह केवल सॉफ्टवेयर है, न कि कोई वारंटी सुरक्षा।

सॉफ्टवेयर से पैसा बनाने के लिए GNU मॉडल सेवाओं, या वारंटी सुरक्षा को बेचना है।

एक वारंटी अधिक है तो बस विश्वास का एक बयान है कि उत्पाद एक उद्देश्य के लिए फिट है। उस पर कुछ पैसे की सवारी करनी होगी। बहुत कम से कम "पैसा वापस", या अधिक: उत्पाद को एक स्थिति में लाने के लिए काम करने के लिए एक दायित्व ऐसा है कि यह कवर किए गए उद्देश्य के लिए फिट है, या यहां तक ​​कि कुछ नुकसान और नुकसान को कवर करने के लिए भी।

वारंटी की मौजूदगी या अनुपस्थिति उस उत्पाद को नहीं बदलती जो उत्पाद है ; यह केवल बीमा का एक रूप है जो बदलता है कि विक्रेता और ग्राहक के बीच जोखिम कैसे वितरित किया जाता है।

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

Answer 6

आपका तर्क कई कारणों से दोषपूर्ण है:

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

• शर्तों को बदलने के काम को व्यापक रूप से अपनाने के लिए लाइसेंस में कोई प्रावधान नहीं हैं।

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

आपके द्वारा हाइलाइट किए गए वाक्य ("आप पूरी तरह से निर्धारित करने के लिए ज़िम्मेदार हैं ...") इसे अपनी गोद में वर्गाकार रूप से उपयोग करने के प्रभाव डालता है।

Comments

क्या डाउनवॉटरों की देखभाल करनी होगी?

— ब्लर एफएल