AGPL समझाया: आंतरिक तैनाती पर दायित्व

आपने AGPL कोड पाया जो उपयोगी लग रहा है, लेकिन आप निश्चित नहीं हैं कि इसे अपनी कंपनी के भीतर चलाने का क्या मतलब होगा। सामान्य चिंता व्यावहारिक है: क्या आपको निजी कोड प्रकाशित करने, आंतरिक प्रणालियों को उजागर करने, या सॉफ़्टवेयर में संशोधन करके फ़ायरवॉल के पीछे उपयोग करने पर कानूनी जोखिम खोलने के लिए मजबूर किया जाएगा? यह मार्गदर्शिका कानूनी भाषा को काटती है और तकनीकी शर्तों में दिखाती है कि GNU Affero General Public License (AGPL) वास्तव में किसी कंपनी पर कौन‑से दायित्व लगाती है जो कोड को आंतरिक रूप से तैनात करती है।

संक्षिप्त अवलोकन: AGPL क्या है और यह GPL से कैसे अलग है

AGPL मूलतः GNU GPL है जिसमें एक नेटवर्क क्लॉज जोड़ा गया है। GPLv3 बाइनरी वितरण को कवर करता है: यदि आप किसी संशोधित प्रोग्राम का वितरण करते हैं, तो आपको संबंधित स्रोत प्रदान करना होगा। AGPLv3 में अनुभाग 13 जोड़ा गया है: यदि आप किसी संशोधित AGPL प्रोग्राम को चला रहे हैं और दूसरों को नेटवर्क के माध्यम से उसके साथ इंटरैक्ट करने देते हैं, तो उन रिमोट उपयोगकर्ताओं को भी उस संशोधित संस्करण का स्रोत उपलब्ध कराना होगा। संक्षेप में: नेटवर्क का उपयोग GPL के तहत वितरण पर लागू स्रोत‑प्रदान दायित्वों जैसा ही ट्रिगर करता है।

कब AGPL कंपनी के भीतर लागू होता है

मुख्य प्रश्न यह है कि AGPL के तहत "उपयोगकर्ता" किसे माना जाता है। लाइसेंस सार्वजनिक ग्राहक और कर्मचारियों में भेद नहीं करता: कोई भी जो नेटवर्क के माध्यम से AGPL‑कवर्ड प्रोग्राम के साथ इंटरैक्ट करता है, वह स्रोत का हकदार उपयोगकर्ता है। इसलिए तीन सामान्य आंतरिक परिदृश्य समझने चाहिए:

• कंपनी फ़ायरवॉल के पीछे केवल कर्मचारियों के लिए सुलभ आंतरिक‑केवल तैनाती: AGPL दायित्व उन कर्मचारी‑उपयोगकर्ताओं पर लागू होते हैं — आपको चल रहे संस्करण और किसी भी संशोधन के लिए उनसे संबंधित स्रोत प्रदान करना होगा।
• SaaS‑शैली तैनातियाँ या ग्राहक‑सामना करने वाली सेवाएँ: यदि बाहरी ग्राहक आपकी सेवा के साथ इंटरैक्ट करते हैं, तो आपको उन ग्राहकों को स्रोत उपलब्ध कराना होगा (सार्वजनिक पोस्ट करना सामान्य तरीका है)।
• कठोर रूप से ऑफ़लाइन उपयोग (कोई नेटवर्क इंटरफ़ेस नहीं): यदि प्रोग्राम केवल नेटवर्क इंटरैक्शन के बिना स्थानीय मशीनों पर चलाया जाता है, तो AGPL का नेटवर्क क्लॉज सामान्य GPL वितरण ट्रिगर्स से परे लागू नहीं होता।

निर्णायक रूप से, "आंतरिक उपयोग" अपने आप में "कोई दायित्व नहीं" नहीं कहलाता। यदि कर्मचारी या ठेकेदार सेवा का उपयोग करते हैं, तो वे AGPL के तहत उपयोगकर्ता हैं और स्रोत के हकदार हैं। इसके विपरीत, इंटरनेट पर कोड प्रकाशित करने का AGPL‑दायित्व तभी उठता है जब वे उपयोगकर्ता बाहरी हों (ग्राहक, तृतीय‑पक्ष) या आप स्रोत उपलब्ध कराना सार्वजनिक रूप से करके अपने ऑफर को पूरा करने का निर्णय लेते हैं।

आपको वास्तव में उपयोगकर्ताओं को क्या प्रदान करना होगा

जब AGPL ट्रिगर होता है, तो व्यावहारिक दायित्व ठोस होते हैं। आपको चलाए जा रहे सटीक संस्करण के लिए "Complete Corresponding Source" प्रदान करना होगा। इसमें आमतौर पर शामिल होता है:

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

ऑफर सीधे उन उपयोगकर्ताओं को किया जा सकता है जो प्रोग्राम के साथ इंटरैक्ट करते हैं। व्यवहार में संगठन इसे ऐप UI या About पृष्ठ में एक स्पष्ट लेबल वाले लिंक लगाकर पूरा करते हैं जो एक tarball या git रिपॉजिटरी स्नैपशॉट की ओर इशारा करता है और एक मानव‑पठनीय README देता है जो बिल्ड और तैनाती के कदम समझाता है। AGPL किसी विशिष्ट URL फ़ॉर्मेट या होस्टिंग प्रदाता का निर्देश नहीं देता, लेकिन स्रोत उन अधिकार‑प्राप्त उपयोगकर्ताओं के लिए उपयोगी रूप में सुलभ होना चाहिए।

"स्रोत प्रदान करना" का अर्थ क्या नहीं है (और सामान्य भ्रांतियाँ)

कुछ बातें जो AGPL अपने आप में आप पर लागू नहीं करती:

• यह आपसे असंबंधित प्रोप्राइटरी सेवाओं या AGPL प्रोग्राम से संबंधित नहीं होने वाले कॉन्फ़िगरेशन को प्रकाशित करने की मांग नहीं करता। केवल वही प्रोग्राम और उसका संबंधित स्रोत आवश्यक है।
• यह निरंतर विकास इतिहास प्रकाशित करने की मांग नहीं करता; समुचित बात यह है कि आप उस सटीक स्रोत को प्रदान करें जो सेवा चलाने में उपयोग हुआ है (हालाँकि कई टीम स्पष्टता के लिए VCS टैग या commit hash प्रकाशित करती हैं)।
• यह स्वचालित रूप से प्रमाणपत्र, निजी‑कुंजियाँ, या रहस्यों का सार्वजनिक प्रकाशन नहीं मांगता। वे "स्रोत कोड" नहीं हैं और आपको किसी भी प्रकाशित आर्काइव से रहस्य निकालने चाहिए या शामिल नहीं करना चाहिए। (यदि किसी कार्यशील वितरण के निर्माण के लिए रहस्यों की आवश्यकता है, तो प्लेसहोल्डर और अपेक्षित रहस्य‑सोर्स का विवरण दें न कि रहस्यों को एम्बेड करें।)

पालन कैसे करें — इंजीनियरिंग टीमों के लिए व्यावहारिक चेकलिस्ट

जब आप AGPL कोड (संशोधित या अनसंशोधित) तैनात करते हैं, तो इन चरणों का पालन करें ताकि अनुपालन बना रहे और अनपेक्षित समस्याओं से बचा जा सके:

• इन्वेंटरी: रिकॉर्ड रखें कि AGPL कंपोनेंट्स कहाँ उपयोग हो रहे हैं, क्या उनमें संशोधन हुआ है, और प्रत्येक सेवा कौन उपयोग करता है (कर्मचारी, ठेकेदार, ग्राहक)।
• संस्करण और commit hash: जिस सटीक कमिट या बिल्ड ID को आप चला रहे हैं उसे टैग करें। उस पहचानकर्ता को UI (उदाहरण के लिए About पृष्ठ) में दिखाएँ ताकि प्रकाशित स्रोत को चल रहे इंस्टेंस से मिलाया जा सके।
• संबंधित स्रोत प्रकाशित करें: एक डाउनलोड‑योग्य आर्काइव या read‑only git स्नैपशॉट प्रदान करें जिसमें बिल्ड स्क्रिप्ट्स, Dockerfiles, और चल रहे प्रोग्राम को पुनरुत्पादित करने के लिए आवश्यक तैनाती मैनिफेस्ट्स शामिल हों।
• स्रोत को अधिकार‑प्राप्त उपयोगकर्ताओं के लिए सुलभ बनाएं: ग्राहक‑सामना करने वाली सेवाओं के लिए इंटरफ़ेस से लिंक किए गए सार्वजनिक URL का उपयोग करें। आंतरिक सेवाओं के लिए कर्मचारियों द्वारा पहुँच योग्य आंतरिक git या आर्टिफैक्ट रिपॉज़िटरी सामान्य और पर्याप्त है।
• नोटिस संरक्षित रखें: अपस्ट्रीम कॉपीराइट और लाइसेंस हेडर सुरक्षित रखें और अपने संशोधनों के लिए अपना योगदानकर्ता नोट जोड़ें।
• रहस्यों को एम्बेड करने से बचें: किसी भी प्रकाशित आर्काइव से निजी कुंजियाँ, टोकन, पासवर्ड और आंतरिक नेटवर्क पते हटाएं।
• समर्थन और लीगल टीमों को प्रशिक्षित करें: सुनिश्चित करें कि सपोर्ट इंजीनियर स्रोत अनुरोधों के जवाब देने का तरीका जानते हैं और URL तैयार रखें; लीगल टीम को बताएं कि AGPL कंपोनेंट्स कहाँ उपयोग हो रहे हैं।

Example: a minimal "Source" link shown in an app footer
https://example.com/source/myapp-2026-11-01.tar.gz
Contents: myapp-2026-11-01/  (git snapshot)
  - src/  (full source)
  - Dockerfile
  - build.sh
  - README.build.md  (instructions to reproduce container)

AGPL कोड को प्रोपाइटरी मॉड्यूल्स के साथ मिलाना — सामान्य पिटफॉल्स

एक सबसे कठिन व्यावहारिक प्रश्न यह है कि आपका प्रोपाइटरी कोड जो AGPL सॉफ़्टवेयर से संवाद करता है, कब AGPL के अंतर्गत आ जाता है। लाइसेंस प्रोग्राम और व्युत्पन्न कार्यों पर लागू होता है। लाइसेंस में कोई स्पष्ट‑रेखा नियम नहीं है जो बताता हो कि "X तरीके से लिंक करना सुरक्षित है।" स्वीकार्य इंजीनियरिंग ह्यूरिस्टिक्स निम्नलिखित हैं:

• मानक, अच्छी तरह परिभाषित नेटवर्क प्रोटोकॉल्स (HTTP, gRPC, SMTP, आदि) पर संचार करने वाली अलग प्रक्रियाएँ आमतौर पर एक संयुक्त प्रोग्राम माने जाने की संभावना कम होती हैं। यदि आपका प्रोपाइटरी कंपोनेंट एक अलग सेवा है जो AGPL कंपोनेंट को REST API के माध्यम से उपयोग करती है, तो कई प्रैक्टिशनर्स इसे सुरक्षित अलगाव के रूप में मानते हैं — पर यह निश्चित नहीं है और निर्भर करता है कि दोनों हिस्से कितने कसकर जुड़े हुए हैं।
• लाइब्रेरी को सीधे किसी बाइनरी में लिंक करना, इन‑प्रोसेस API का उपयोग करना, या एक मोनोलिथिक संयुक्त वितरण भेजना जोखिमपूर्ण है: उस संयोजन को व्युत्पन्न कार्य कहा जा सकता है और स्रोत‑दायित्व ट्रिगर हो सकता है।
• प्लगइन्स या मॉड्यूल जो AGPL प्रक्रिया में लोड किए जाते हैं, खतरनाक हो सकते हैं यदि वे स्पष्ट रूप से अलग नहीं हैं; कुछ प्रोजेक्ट्स जोखिम कम करने के लिए अच्छी तरह ऑडिट किए गए, स्थिर IPC सीमाओं का उपयोग करते हैं।

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

व्यवसायिक विकल्प: वाणिज्यिक लाइसेंसिंग, ड्युअल‑लाइसेंसिंग, और संचालन विकल्प

AGPL का उपयोग करने वाले ओपन‑सोर्स प्रोजेक्ट अक्सर वाणिज्यिक लाइसेंस या ड्युअल‑लाइसेंस मॉडल ऑफर करते हैं: आप या तो AGPL दायित्वों का पालन कर सकते हैं या एक प्रोप्राइटरी लाइसेंस खरीद सकते हैं जो नेटवर्क‑स्रोत आवश्यकता को हटाता है। यह मॉडल उन प्रोजेक्ट्स के लिए सामान्य है जो सर्वर‑साइड वैल्यू की रक्षा करना चाहते हैं जबकि AGPL के तहत मुक्त उपयोग की अनुमति देते हैं।

ऑपरेशनल परिप्रेक्ष्य से जब आप किसी AGPL निर्भरता का सामना करते हैं तो आपके पास तीन वास्तविक रास्ते होते हैं:

• पालन करें: ऊपर दिए गए चेकलिस्ट का उपयोग करके संबंधित स्रोत को उन अधिकार‑प्राप्त उपयोगकर्ताओं को प्रकाशित करें। आंतरिक टूल्स और छोटे तैनाती के लिए यह अक्सर सबसे सस्ता मार्ग है।
• वाणिज्यिक लाइसेंस पर बातचीत करें: यदि आप अपने संशोधनों को बंद रखना चाहते हैं या AGPL दायित्वों से बचना चाहते हैं तो अपस्ट्रीम से प्रोप्राइटरी लाइसेंस खरीदें।
• कंपोनेंट बदलें: यदि लाइसेंस परिवर्तन व्यावहारिक नहीं है तो एक परमीशनलीसेंस्ड या प्रोप्राइटरी विकल्प का उपयोग करें।

यदि आपका उत्पाद एक रिमोट‑एक्सेस या रिमोट‑डेस्कटॉप सेवा है, तो विचार करें कि AGPL कॉम्पोनेंट केवल क्लाइंट को प्रभावित करता है या आपके सर्वर/रिले को भी। कई डिप्लॉयमेंट्स में, मैनेज्ड रिले सेवा आपका परिचालन और अनुपालन बोझ कम कर देती है; Tenvo हमारे द्वारा संचालित मैनेज्ड रिले है (सर्वर जर्मनी में) और उन टीमों के लिए हमारी डिफ़ॉल्ट सलाह है जो सेल्फ़-होस्टिंग के बोझ के बिना सरल मैनेज्ड रिले चाहती हैं। यदि अनुपालन ऑन‑प्रेम इन्फ्रास्ट्रक्चर की मांग करता है (उदाहरण के लिए, कोई लिखित आवश्यकता तृतीय‑पक्ष अवसंरचना को वर्जित करती है), तो स्वयं‑होस्टिंग सही कदम है — RustDesk को स्वयं‑होस्ट करने पर विचार करें, पर उस मार्ग को चुनने से पहले रखरखाव, प्रमाणपत्र नवीनीकरण, और फेलओवर योजना की लगातार लागतों को गिन लें।

आंतरिक‑केवल बनाम सार्वजनिक प्रकाशन — महत्वपूर्ण भेद

दो अंतिम स्पष्टीकरण जो भ्रम उत्पन्न करते हैं:

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

जब स्वयं‑होस्टिंग या अन्य विशेष व्यवस्थाएँ आवश्यक हों

जब लिखित आवश्यकता तृतीय‑पक्ष इन्फ्रास्ट्रक्चर पर निर्भरता को मना करती है (नियामक डेटा‑निवास नियम, वर्गीकृत नेटवर्क, या संविदात्मक दायित्व), तब स्वयं‑होस्टिंग उचित है। अन्यथा, मैनेज्ड रिले / प्रबंधित इंफ्रास्ट्रक्चर विकल्प आमतौर पर वास्तविक रूप से कम खर्चीला होता है यदि आप ऑन‑कॉल भार, पैचिंग, TLS सर्टिफिकेट की देखभाल, और परिचालन फेलओवर को जोड़ते हैं। हम इन ट्रेड‑ऑफ्स पर अधिक गहराई से चर्चा करते हैं Self hosting hidden costs में और अपनी व्यापक लेख में Open source business model: why AGPL works for SaaS में।

व्यावहारिक उदाहरण और एक संक्षिप्त FAQ

• Q: यदि मैंने AGPL कोड में संशोधन किया और केवल मेरी ऑप्स टीम उसका उपयोग करती है, क्या मुझे प्रकाशित करना होगा? A: हाँ — आपकी ऑप्स टीम उपयोगकर्ताओं में आती है। स्रोत आंतरिक रूप से उपलब्ध कराएँ।
• Q: यदि मैं ग्राहकों को AGPL‑बैक्ड सेवा प्रदान करता हूँ, क्या मुझे सार्वजनिक रूप से प्रकाशित करना होगा? A: आपको उन ग्राहकों को संबंधित स्रोत उपलब्ध कराना होगा। सार्वजनिक पोस्ट करना उस आवश्यकता को पूरा करने का मानक तरीका है।
• Q: क्या मैं कॉन्फ़िगरेशन और रहस्यों को बंद रख सकता हूँ? A: रहस्य लाइसेंस के तहत "स्रोत कोड" नहीं हैं। प्रकाशित आर्काइव से रहस्यों को हटा दें और अपेक्षित रहस्य इनपुट का दस्तावेज़ीकरण करें।
• Q: क्या यह अपस्ट्रीम की ओर इशारा करना पर्याप्त है अगर मैंने स्थानीय संशोधन किए हों? A: नहीं। आपको उस विशिष्ट संस्करण के लिए स्रोत प्रदान करना होगा जो आप चला रहे हैं, आपके परिवर्तनों सहित।

यदि आप एक ओपन‑सोर्स रिमोट‑डेस्कटॉप स्टैक को स्वयं‑होस्ट करने का विस्तृत उदाहरण और अनुपालन बनाए रखने के सटीक बिल्ड स्टेप्स चाहते हैं, तो हमारी Self-hosted remote desktop मार्गदर्शिका और RustDesk Docker ट्यूटोरियल के लिए RustDesk self-hosted setup देखें जिनसे आप मैकेनिक्स उधार ले सकते हैं।

AGPL का अनुपालन यांत्रिक है: उपयोगकर्ताओं की पहचान करें, चल रहे रिविज़न को फ्रीज़ करें, Complete Corresponding Source और बिल्ड निर्देश इकट्ठा करें, और उसे उन उपयोगकर्ताओं के लिए पहुँचनीय बनाएं। कठिन भाग शासन और वास्तुकला हैं: यह तय करना कि कम्पोनेंट्स को अलग करना है, लाइसेंस पर बातचीत करनी है, या संशोधनों की सार्वजनिक दृश्यता स्वीकार करनी है।

अगर आप रिमोट-एक्सेस इन्फ्रास्ट्रक्चर तैनात कर रहे हैं और कस्टम रिले चलाने और प्रकाशित करने से बचना चाहते हैं, तो Tenvo का मैनेज्ड रिले व्यावहारिक डिफ़ॉल्ट है: Windows, macOS और Linux के लिए नेटिव क्लाइंट, पब्लिक बीटा में ब्राउज़र क्लाइंट, जर्मनी में सर्वरों वाला मैनेज्ड रिले, और Free $0 से Lite $2.99/माह तथा Pro $7.99/माह तक के प्लान। स्वयं‑होस्टिंग केवल तब प्रयोग किया जाना चाहिए जब लिखित आवश्यकता इसे अनिवार्य करे: अन्यथा मैनेज्ड विकल्प आमतौर पर ऑन‑कॉल, पैचिंग, कुंजी प्रबंधन और फेलओवर आवश्यकताओं को जोड़ने पर कम खर्चीला होता है।

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

जब आप परिचालन ओवरहेड छोटा रखना चाहते हैं और एक प्रबंधित रिले आज़माना चाहें, तो Tenvo डाउनलोड करें और तैनाती मॉडल और UI का अनुभव लें: Download Tenvo.