हमारे कोड के अंदर का कानून

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

चार उदाहरण, जहाँ यह खास तौर पर साफ़ हुआ। पहले ही साफ़ कर दें कि यह क्या है: यह हमारे इम्प्लीमेंटेशन का विवरण है, कानूनी सलाह नहीं। नीचे दिए नियम जर्मन कानून के हैं, क्योंकि AlphaCloud वहीं से चलता है।

रद्द करने का वह बटन, जिसके आगे लॉगिन नहीं हो सकता

जर्मन सिविल कोड की धारा 312k कहती है कि ऑनलाइन किए गए अनुबंधों में रद्द करने का एक सीधा पहुँचने लायक तरीका होना चाहिए। इससे ऐसी ज़रूरतें निकलती हैं जिन्हें बाद में शब्दों से नहीं जोड़ा जा सकता:

• पेज को बिना साइन इन किए काम करना चाहिए
• उसे हर पेज के फ़ुटर में होना चाहिए
• उसमें दो चरण होने चाहिए: जानकारी भरना, फिर एक साफ़-साफ़ लेबल वाले बटन से पुष्टि करना
• लिखित रूप में प्राप्ति की पुष्टि भेजी जानी चाहिए

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

फ़ॉर्म आपको कभी अस्वीकार नहीं कर सकता

यहीं सबसे ज़ाहिर तरीके से हम लगभग एक गलती कर बैठे थे।

ज़ाहिर तरीका: रद्द करने की घोषणा तभी स्वीकार करें जब सर्वर ID और ईमेल किसी चालू सब्सक्रिप्शन से मेल खाएँ। सुनने में उचित लगता है, और दो बार गलत है।

पहला, यह ऐसे असली ग्राहक को बाहर कर देगा जो अपना ईमेल गलत टाइप करता है या कोई दूसरा पता देता है। उसकी रद्द करने की घोषणा प्राप्त ही नहीं मानी जाती, सब्सक्रिप्शन रिन्यू हो जाता है, और उसके पास इस बात का सबूत होता है कि उसने कोशिश की थी।

दूसरा, और यह ज़्यादा अप्रिय हिस्सा है: एरर संदेश खुद एक जवाब होता। जिसे भी "कोई सब्सक्रिप्शन नहीं मिला" वापस मिलता है, उसे पता चल जाता है कि यह सर्वर भुगतान नहीं करता। Discord सर्वर ID कोई राज़ नहीं है, कोई भी सदस्य उसे पढ़ सकता है। फ़ॉर्म दूसरों के सर्वरों की टोह लेने का एक औज़ार बन जाता।

समाधान उन दो चीज़ों को अलग करता है जो एक जैसी लगती हैं:

	शर्त
घोषणा की प्राप्ति	बिना शर्त, हमेशा लॉग और पुष्टि की जाती है
रद्द करने का अमल	सिर्फ़ तब, जब भेजा गया ईमेल रिकॉर्ड में दर्ज खरीदार से मेल खाए

बाकी सब एक कतार में जाता है और एक इंसान उसकी समीक्षा करता है। इसकी अनुमति है क्योंकि धारा 312k(2) पहचान से जुड़ी जानकारी मांगने की साफ़ इजाज़त देती है। मना सिर्फ़ उसके आगे लॉगिन लगाना है।

इसी वजह से सार्वजनिक जवाब में समाप्ति की तारीख तभी बताई जा सकती है जब पहचान की पुष्टि हो जाए। वरना पुष्टि फिर से जानकारी उगलवाने का ज़रिया बन जाती है।

वापसी, जिसके आगे जानबूझकर लॉगिन है

ठीक उसके बगल में एक फ़ीचर है जिसे हमने उल्टे तरीके से बनाया: आनुपातिक रिफ़ंड के साथ वापसी साइन इन के पीछे है।

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

इससे तीन नियम निकलते हैं, जिन्हें हम ढीला नहीं करते:

कोई अनिवार्य कारण नहीं। धारा 355(1) साफ़ तौर पर बिना कारण बताए वापसी का अधिकार देती है। यह फ़ील्ड वैकल्पिक है और वैकल्पिक ही रहना चाहिए, आँकड़ों के लिए इसे ज़रूरी बनाना कितना भी लुभावना हो।

14 दिन बाद सिर्फ़ ऑटोमैटिक रास्ता मना होता है, घोषणा कभी नहीं। अगर ग्राहक को ठीक से जानकारी नहीं दी गई थी, तो अवधि बारह महीने और चौदह दिन तक बढ़ जाती है। इसलिए एक आम "बहुत देर हो गई" गलत हो सकता है।

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

Discord DM एक टिकाऊ माध्यम नहीं है

धारा 312f(3) अनुबंध की पुष्टि एक टिकाऊ माध्यम पर मांगती है, और उसमें दी गई सहमति दोहराई जानी चाहिए।

हमने पहले एक Discord डायरेक्ट मैसेज भेजा, क्योंकि हमारे ग्राहक वैसे भी उसी चैनल पर होते हैं। यह काफ़ी नहीं है। एक DM ऐसे प्लेटफ़ॉर्म पर रहता है जिस पर हमारा नियंत्रण नहीं है, और वह उस अर्थ में न तो सेव करने लायक है और न ही अपरिवर्तनीय, जिसकी यह प्रावधान बात करता है।

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

कोई VAT नहीं, और यह हर जगह एक जैसा लिखा होना चाहिए

AlphaCloud जर्मन VAT अधिनियम की धारा 19 के तहत एक छोटा व्यवसाय है। कीमतें अंतिम कीमतें हैं, VAT कभी नहीं दिखाया जाता।

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

और AI

अगस्त 2026 से यूरोपीय AI अधिनियम के पारदर्शिता दायित्व पूरी तरह लागू हैं। जो कोई किसी AI सिस्टम से बात कर रहा है, उसे यह पहचान पाना चाहिए, ज़्यादा से ज़्यादा पहली बातचीत तक।

उस समीक्षा से हमारे लिए सबसे अहम वाक्य: फ़ुटर में एक कानूनी पेज शायद इसके लिए काफ़ी नहीं है। जानकारी वहीं दी जानी चाहिए जहाँ बातचीत होती है, यानी खुद Discord संदेश में। इसीलिए हमारा AI टिकट सपोर्ट बिना पूछे अपना परिचय देता है और उसे बंद करने के लिए एक दिखने वाला बटन है। हमारा विस्तृत आकलन AI पारदर्शिता पर है।

साझा धागा

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

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