उपयोगकर्ता ने शर्तों का कौन-सा संस्करण स्वीकार किया? हर संस्करण को दिनांकित करें

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

हर शर्त-विवाद के पीछे का सवाल

जब कोई ग्राहक आपकी शर्तों को चुनौती देता है, तो आपको वही सटीक संस्करण दिखाना होता है जिसे उसने स्वीकार किया।

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

स्विस क़ानून असल में क्या माँगता है

अनुबंध तब बनता है जब दोनों पक्ष सहमत हों, और जो किसी खंड पर निर्भर करता है उसे उसे साबित करना होता है।

Code of Obligations के अनुच्छेद 1 (OR) के अनुसार, अनुबंध के लिए पक्षों की परस्पर और मेल खाती इच्छा की अभिव्यक्ति चाहिए। यह इच्छा स्पष्ट या निहित हो सकती है, इसलिए किसी स्वीकार बटन पर क्लिक भी गिना जा सकता है। अनुच्छेद 11 OR के अनुसार, अनुबंध को विशेष फ़ॉर्म तभी चाहिए जब क़ानून उसे तय करे। आम शर्तों के लिए कोई हस्ताक्षर ज़रूरी नहीं, इसलिए ऑनलाइन स्वीकृति बाध्यकारी हो सकती है। पर एक पेच है। Civil Code के अनुच्छेद 8 (ZGB) के अनुसार, जो व्यक्ति अपने बताए तथ्यों से कोई अधिकार निकालता है, उसे वे तथ्य साबित करने होते हैं। सीधे शब्दों में, अगर आप किसी खंड पर निर्भर रहना चाहते हैं, तो यह दिखाना आपका काम है कि वह सौदे का हिस्सा था।

"हमने अपनी शर्तें अपडेट कर दीं" क्यों काफ़ी नहीं

आपका मौजूदा शर्तें-पेज यह नहीं दिखाता कि किसी पुराने उपयोगकर्ता ने स्वीकार पर क्लिक करते समय क्या देखा था।

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

अपनी शर्तों के हर संस्करण को दिनांकित करना

हर संस्करण को सील करने से उस समय मौजूद सटीक पाठ का दिनांकित प्रमाण बनता है।

जब आप किसी दस्तावेज़ को सील करते हैं, तो प्लेटफ़ॉर्म उसका एक cryptographic hash, यानी एक छोटा fingerprint, RFC 3161 के तहत एक भरोसेमंद टाइमस्टैम्प अथॉरिटी को भेजता है। बदले में आपको एक टाइमस्टैम्प मिलता है जो उसी सटीक पाठ को उस पल से बाँध देता है। एक अक्षर बदलिए, fingerprint बदल जाता है। इसलिए आपकी शर्तों का सील किया गया संस्करण अपनी तारीख़ से बँधा रहता है। अगर आप हर संस्करण को प्रकाशित करते समय सील करें, तो एक सरल समय-रेखा बनती है। संस्करण एक जनवरी का। संस्करण दो अप्रैल का। संस्करण तीन सितंबर का। हर एक दिनांकित है, और हर एक को कोई भी एक सार्वजनिक लिंक से बिना अकाउंट जाँच सकता है।

सील क्या दिखाती है और क्या नहीं

सील दिखाती है कि किसी समय कौन-सा पाठ मौजूद था, यह नहीं कि उसे किसने लिखा या किसने स्वीकार पर क्लिक किया।

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

हर अपडेट के लिए एक सरल दिनचर्या

हर संस्करण को प्रकाशित करने से पहले सील करें, और दिनांकित प्रमाण को अपने साइन-अप लॉग के साथ रखें।

एक छोटी दिनचर्या आपको सुरक्षित रखती है:

• नया संस्करण प्रकाशित करने से पहले अंतिम पाठ को सील करें।
• उस संस्करण के साथ सार्वजनिक verification link अपने रिकॉर्ड में सहेजें।
• पक्का करें कि आपका साइन-अप फ़्लो यह दर्ज करे कि हर उपयोगकर्ता ने कौन-सा संस्करण स्वीकार किया, और कब।
• पुराने सील किए संस्करण रखें। नया लाइव होने पर उन्हें न मिटाएँ।

इसमें हर रिलीज़ पर कुछ मिनट लगते हैं। यह किसी भविष्य के विवाद को अटकल से बदलकर एक दिनांकित प्रमाण बना देता है जिसे आप दिखा सकते हैं।

वापस Maria पर

Maria की कंपनी अब अपनी शर्तों के हर संस्करण को उसी दिन सील करती है जिस दिन वह लाइव होता है। अगली बार जब कोई ग्राहक पूछेगा कि उसके साइन-अप के समय कौन-से नियम लागू थे, तो सहायता उस तारीख़ के सील किए संस्करण और एक सार्वजनिक लिंक की ओर इशारा कर सकती है जिसे कोई भी जाँच सके। काम प्रकाशन के समय होता है, बहस के दौरान नहीं। हर संस्करण को प्रकाशित करने से पहले सील करें, ताकि पाठ और उसकी तारीख़ तब तय हो जाएँ जब उन्हें साबित करना अब भी आसान हो। आप swisstrustlayer.com पर शुरू कर सकते हैं।