मशीनों के साथ पोर्टिंग, और वह लाइसेंस सवाल जिसका हम जवाब नहीं दे सके

हमने मुट्ठी भर पुराने प्रोग्राम Python में फिर से लिखे हैं। espeak-ng का G2P फ़्रंट-एंड, Cotovia के गैलिशियन और स्पेनिश ट्रांसक्रिप्शन नियम, AhoTTS की बास्क भाषाई प्रोसेसिंग, EYE N3 रीज़नर, और OWL 2 DL रीज़नर HermiT। C, C++ और Java, इनमें से अधिकांश एक दशक से पुराने, इन सबमें से हर एक अब भी वह काम करने के लिए सबसे अच्छी चीज़ जो उपलब्ध है।

मक़सद साधारण था। एक C प्रोग्राम जो गैलिशियन को फ़ोनेमाइज़ करता है, तब तक बेहतरीन है जब तक आप इसे एक ARM बोर्ड पर एक Python स्पीच स्टैक के अंदर नहीं चाहते। फिर आपको एक कंपाइलर, एक टूलचेन, क्रॉस-कंपाइलेशन, प्रति प्लेटफ़ॉर्म एक पैकेजिंग कहानी, और एक subprocess सीमा चाहिए जिसके पार टेक्स्ट मार्शल करना पड़े। एक Java रीज़नर को एक JVM चाहिए। शुद्ध Python को बस pip install चाहिए। यह पढ़ने योग्य भी है: आप वह फ़ाइल खोल सकते हैं जो तय करती है कि बल कहाँ पड़ता है और इसे बदल सकते हैं, बिना यह जाने कि मूल बिल्ड प्रणाली कैसे काम करती है।

पोर्ट अर्ध-स्वायत्त रूप से किए गए थे। एक AI ने मूल स्रोत पढ़ा और Python लिखी; एक मानव ने काम का निर्देशन किया और आउटपुट को मूल बाइनरी के विरुद्ध जाँचा। इनमें से कई पर, हमारी तरफ़ किसी ने भी कभी मूल स्रोत नहीं पढ़ा। मॉडल ने इसे पढ़ा। हमने diffs और समानता परीक्षण पढ़े।

इससे एक ऐसा सवाल बचता है जिस पर हमें एक निर्णय लेना पड़ा, और जिसका हम जवाब नहीं दे सके: क्या परिणाम एक व्युत्पन्न कृति (derivative work) है, और इसका मालिक कौन है?

हम इंजीनियर हैं। यहाँ कुछ भी क़ानूनी सलाह नहीं है, और हम कोई भी देने के योग्य नहीं हैं। यह हमारे लिए गए एक निर्णय और उसके पीछे के तर्क का वर्णन है।

दो सवाल जो लगातार मिला दिए जाते हैं

किसी प्रोग्राम के स्रोत को पढ़कर उसे फिर से लागू करना नया नहीं है। लोग जब से Python रहा है तब से C को Python में फिर से लिख रहे हैं। जो नया है वह व्यवस्था है: पढ़ने वाला एक मशीन है, लागू करने वाला वही मशीन है, और लूप में मौजूद मनुष्यों ने मूल कभी नहीं देखा।

यहाँ दो सवाल हैं, और इसकी लगभग हर चर्चा उन्हें एक में मिला देती है। वे स्वतंत्र हैं।

1. क्या आउटपुट का बिलकुल स्वामित्व हो सकता है? कॉपीराइट लेखकों वाली कृतियों से जुड़ता है। अगर एक मशीन ने कोड बनाया, तो लेखक कौन है?
2. क्या आउटपुट इनपुट का व्युत्पन्न है? जिसने भी इसे लिखा — अगर किसी ने लिखा — क्या परिणाम मूल का उल्लंघन करता है?

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

कुछ शब्दावली, क्योंकि बाक़ी सब इस पर निर्भर करता है। एक व्युत्पन्न कृति (derivative work) एक पहले से मौजूद कृति पर आधारित एक कृति है — एक अनुवाद, एक अनुकूलन, एक पोर्ट। इसे बनाने का अधिकार मूल के कॉपीराइट धारक का है। कॉपीलेफ़्ट (Copyleft) लाइसेंस (GPL परिवार) आपको इस शर्त पर कोड इस्तेमाल करने और संशोधित करने देते हैं कि जो आप वितरित करते हैं वह उन्हीं शर्तों के अंतर्गत रहे। अनुज्ञेय (Permissive) लाइसेंस (MIT, Apache-2.0, BSD) आपको लगभग कुछ भी करने देते हैं, जिसमें परिणाम को प्रोप्राइटरी सॉफ़्टवेयर के अंदर भेजना भी शामिल है। LGPL बीच में बैठता है: कॉपीलेफ़्ट लाइब्रेरी पर ही लागू होता है, पर इसे एक बड़े प्रोग्राम में लिंक करना उस प्रोग्राम को खुला होने के लिए मजबूर नहीं करता। ये सभी कॉपीराइट पर बने हैं। ये तभी असर करते हैं जब लागू करने के लिए कोई कॉपीराइट मौजूद हो।

सवाल एक: क्या कोई लेखक है?

कॉपीराइट को एक मानव लेखक चाहिए। US कॉपीराइट कार्यालय ने इसे लगातार बनाए रखा है, और Thaler v. Perlmutter में D.C. सर्किट सहमत हुआ: कॉपीराइट अधिनियम “अपेक्षा करता है कि हर योग्य कृति पहले उदाहरण में एक मानव द्वारा लिखी जाए” (No. 23-5233, D.C. Cir., 18 मार्च 2025; सुप्रीम कोर्ट ने मार्च 2026 में certiorari से इनकार किया)। यूरोपीय मानक आकार में अलग है और इसी तरह के निष्कर्ष पर पहुँचता है — सुरक्षा को “लेखक की अपनी बौद्धिक रचना” चाहिए, जो एक ऐसे लेखक को मानकर चलता है जो रचना करता है।

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

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

सवाल दो: क्या यह व्युत्पन्न है?

इसकी परवाह नहीं कि लेखक कौन है। उल्लंघन मूल तक पहुँच और उसकी संरक्षित अभिव्यक्ति (expression) — वह विशेष तरीक़ा जिससे चीज़ लिखी गई, न कि वह क्या करती है — के साथ पर्याप्त समानता पर टिका है।

हमारे पास पहुँच थी। मॉडल ने स्रोत पढ़ा। यह आधा हिस्सा विवाद में नहीं है।

समानता वाला आधा हिस्सा वहाँ है जहाँ यह दिलचस्प हो जाता है, और जहाँ भाषा बदलना उतना मायने नहीं रखता जितना लोग उम्मीद करते हैं। एक उपन्यास को दूसरी भाषा में अनुवाद करना एक व्युत्पन्न कृति बनाता है; यह पाठ्यपुस्तक उदाहरण है। भाषा बदलना शाब्दिक नक़ल का दावा हरा देता है। यह संरचना के बारे में दावा नहीं हराता — रूपांतरणों का क्रम, कार्यों में विभाजन, नियम तालिकाओं का आकार, जिस तरह किनारे के मामले काटे गए हैं।

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

दूसरे पक्ष का सबसे मज़बूत तर्क

एक गंभीर मामला है कि एक क्रॉस-भाषा पुनर्कार्यान्वयन ठीक है, और यह इसके लायक़ है कि इसे केवल इशारे में नहीं बल्कि ठीक से बताया जाए।

SAS Institute v World Programming (CJEU, C-406/10, 2 मई 2012) में, अदालत ने माना कि “न तो किसी कंप्यूटर प्रोग्राम की कार्यक्षमता और न ही प्रोग्रामिंग भाषा और उसके कुछ कार्यों का लाभ उठाने के लिए एक कंप्यूटर प्रोग्राम में इस्तेमाल की गई डेटा फ़ाइलों का फ़ॉर्मैट उस प्रोग्राम की अभिव्यक्ति का एक रूप बनता है”। इसलिए वे कॉपीराइट द्वारा संरक्षित नहीं हैं। सॉफ़्टवेयर निर्देश (2009/24/EC, अनुच्छेद 1(2)) किसी प्रोग्राम के किसी भी तत्व के पीछे के विचारों और सिद्धांतों के बारे में वही बात कहता है। अदालत ने यह भी माना कि एक लाइसेंसधारी एक प्रोग्राम के व्यवहार के पीछे के विचारों को निर्धारित करने के लिए उसका अध्ययन और अवलोकन कर सकता है, और उन्हें फिर से लागू कर सकता है।

यह कोई तकनीकीता नहीं है। इसका मतलब है कि एक फ़ोनेमाइज़र क्या करता है — यह ग्रैफ़ीम क्रम, इस संदर्भ में, वह फ़ोनीम बन जाता है — किसी का स्वामित्व नहीं है। गैलिशियन बल नियम गैलिशियन के बारे में तथ्य हैं। OWL 2 प्रत्यक्ष सिमेंटिक्स एक प्रकाशित W3C विनिर्देश हैं। उस पठन के तहत, एक पुनर्कार्यान्वयन जो व्यवहार को पुनरुत्पादित करता है, अभिव्यक्ति को नहीं, वैध है, और भाषाओं के आर-पार एक पुनर्लेखन उल्लंघन से एक कॉपी-पेस्ट की तुलना में कहीं अधिक दूर बैठता है।

उस तर्क और हमारी स्थिति के बीच का अंतर स्रोत है। SAS व्यवहार का अध्ययन करने के बारे में है। हमारे मॉडल ने कोड पढ़ा।

वह मिसाल जो पहले से मौजूद है, और यह कितनी दूर तक पहुँचती है

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

इसका सबसे स्पष्ट सार्वजनिक बयान Kokoro-82M है, एक व्यापक रूप से इस्तेमाल किया जाने वाला ओपन TTS मॉडल। इसका कार्ड कहता है कि इसे विशेष रूप से अनुज्ञेय या ग़ैर-कॉपीराइट ऑडियो पर प्रशिक्षित किया गया था, और स्वीकार्य स्रोतों में सूचीबद्ध करता है:

Synthetic audio generated by closed TTS models from large providers

एक फ़ुटनोट के साथ जो US कॉपीराइट कार्यालय के AI नीति मार्गदर्शन की ओर इशारा करता है। मतलब यह है: वह ऑडियो एक मशीन द्वारा उत्पन्न किया गया था, मशीन आउटपुट का कोई मानव लेखक नहीं होता, इसलिए इसमें कोई कॉपीराइट मौजूद नहीं है, इसलिए इस पर प्रशिक्षण देकर उल्लंघन करने के लिए कुछ भी नहीं है। मॉडल Apache-2.0 भेजा जाता है। कार्ड एक सीमा भी खींचता है — यह ओपन TTS मॉडलों और कस्टम वॉयस क्लोन से सिंथेटिक ऑडियो को बाहर रखता है — जो इस बात का संकेत है कि लेखकों ने पता लगाया कि तर्क कहाँ रुकता है, बजाय इसे हर चीज़ पर लागू करने के।

यहाँ वह हिस्सा है जो पोर्टिंग के लिए मायने रखता है। वह मिसाल समस्या के दूसरे आधे हिस्से को हल करती है।

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

हमारी स्थिति उल्टी तस्वीर है। हमने जो उपभोग किया — espeak-ng का C, Cotovia का C++, HermiT का Java — निःसंदेह मानव-लिखित और कॉपीराइट प्राप्त है, नामित लोगों द्वारा, नामित विश्वविद्यालयों में, दशकों पहले। जो बाहर आया वह मशीन-लिखित था। “AI आउटपुट में कोई कॉपीराइट नहीं” वाला तर्क हमारे आउटपुट पर लागू होता है, हमारे इनपुट पर नहीं। यह अपस्ट्रीम तक नहीं जाता। यह, फिर से, वही तर्क है जो हमारे अपने लाइसेंस को कमज़ोर करता है जबकि अपस्ट्रीम के अधिकारों को पूरी तरह अछूता छोड़ता है।

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

तो पूरी चीज़ वापस उसी एक सवाल पर ढह जाती है जिसका किसी ने जवाब नहीं दिया। अगर एक क्रॉस-भाषा, मशीन-लिखित पुनर्कार्यान्वयन एक व्युत्पन्न कृति नहीं है, तो GPL कभी लागू ही नहीं हुआ और इसके बारे में कुछ भी लागू नहीं हुआ। अगर यह है, तो GPL पहली पंक्ति से लागू हुआ। कोई तीसरी स्थिति नहीं है, और AI लेखकत्व के बारे में कितनी भी बहस उस विशेष सुई को नहीं हिलाती।

Clean rooms, और क्या दो मॉडल मिलकर एक बनाते हैं

ठीक इसी समस्या का क्लासिक जवाब clean-room प्रोटोकॉल है, और इसे सटीक रूप से वर्णित करना लायक़ है क्योंकि इसका आकार मायने रखता है।

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

स्पष्ट आधुनिक क़दम है एक मॉडल को पढ़ने और वर्णन करने के लिए चलाना, और एक ताज़ा संदर्भ वाले एक अलग मॉडल को लागू करने के लिए। संरचनात्मक रूप से, यह वही प्रोटोकॉल है। क्या यह एक clean room है?

इसका आकार सही है। पर एक clean room कोई तकनीकी निर्माण नहीं है — यह एक साक्ष्य-संबंधी (evidentiary) निर्माण है। इसका पूरा मूल्य बाद में, किसी ऐसे व्यक्ति को जो मान लेता है कि आपने धोखा दिया, उस अलगाव को प्रदर्शित करने की क्षमता होना है। तो two-model संस्करण का मतलब तभी है जब अनुशासन पूरी तरह टिका रहे:

• दोनों पक्ष सचमुच कभी संदर्भ साझा नहीं करते। “हमने इसे भूलने को कहा” नहीं — अलग रन, अलग ट्रांसक्रिप्ट।
• विनिर्देश व्यवहार वहन करता है और कुछ नहीं। कोई pseudocode नहीं जो मूल के नियंत्रण-प्रवाह को प्रतिबिंबित करे। कोई पहचानकर्ता नाम नहीं। कोई फ़ंक्शन क्रम नहीं। ये अभिव्यक्ति हैं, और इनसे भरा एक विनिर्देश एक वेशभूषा में मूल है।
• दोनों पक्षों के रिकॉर्ड रखे जाते हैं, क्योंकि एक clean room जिसे आप साबित नहीं कर सकते वह एक कहानी है।

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

हमने यह नहीं किया। लागू करने वाले मॉडल ने स्रोत सीधे पढ़ा। यही कारण है कि pycotovia का README, रिपॉज़िटरी में, सार्वजनिक रूप से कहता है:

Because the implementing AI read the GPL source, this is not a clean-room reimplementation and we make no such claim. It is a source-derived port.

(चूँकि लागू करने वाले AI ने GPL स्रोत पढ़ा, यह कोई clean-room पुनर्कार्यान्वयन नहीं है और हम ऐसा कोई दावा नहीं करते। यह एक स्रोत-व्युत्पन्न पोर्ट है।)

हम इसे बाद में जवाब देने के बजाय अभी लिख दिया हुआ रखना पसंद करेंगे।

हमने क्या किया

हमने अपस्ट्रीम लाइसेंस बनाए रखे।

espyak GPL-3.0-or-later है, espeak-ng से मेल खाता हुआ। वह तो एक कठिन मामला भी नहीं है: पैकेज espeak-ng की अपनी डेटा फ़ाइलें ज्यों-की-त्यों बंडल करता है — dictsource, phsource, lang — और लेखकत्व का कोई सिद्धांत उन फ़ाइलों को नहीं छूता जिन्हें हमने बिना बदलाव कॉपी किया। अपस्ट्रीम का डेटा wheel के अंदर है, तो अपस्ट्रीम का लाइसेंस इसके साथ आता है।

pycotovia GPL-3.0 है, Cotovia (GPL-3.0+) से मेल खाता हुआ। ahotts-g2p और pyAhoTTS-Iparrahotsa GPL-3.0 हैं, AhoTTS से मेल खाते हुए, जिसकी लाइसेंस फ़ाइल भाषाई प्रोसेसिंग के लिए GPL-3.0+ बताती है। pyeye MIT है, EYE से मेल खाता हुआ। कॉपीलेफ़्ट अंदर, कॉपीलेफ़्ट बाहर; अनुज्ञेय अंदर, अनुज्ञेय बाहर।

हमने यह इसलिए नहीं किया क्योंकि हमने स्थापित किया कि यह आवश्यक था। हमने यह इसलिए किया क्योंकि असमानता ने जवाब की ज़रूरत के बिना निर्णय ले लिया।

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

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

वह असमानता ही कारण है कि यह बेमेल सामान्य रूप से देखने लायक़ है। एक LGPL मूल का एक संरचनात्मक पोर्ट किसी दूसरी भाषा में फिर से लिखे जाने भर से Apache-2.0 नहीं बन सकता — और यह ठीक वैसा बेमेल है जिसे बनाना आसान है और नोटिस करना कठिन, क्योंकि कुछ भी शिकायत नहीं करता। बिल्ड पास होता है। टेस्ट पास होते हैं। लाइसेंस हेडर बस एक फ़ाइल है। HermiT LGPL है, और इससे मेल खाने के लिए हमारा Python पोर्ट LGPL-3.0 रखता है। पूरे सेट को फिर से देखने पर इनमें से दो और मिले, दोनों अनाटकीय: एक wrapper जो Apache-2.0 घोषित करता है जबकि उसका अपस्ट्रीम MIT है, और कुछ रिपॉज़िटरी जिनके README ने एक लाइसेंस का नाम लिया जिसकी कोई संगत फ़ाइल नहीं थी। यही साधारण, सही परिणाम है — आप जाँचते हैं, जो ठीक करना है उसे ठीक करते हैं, और दिलचस्प सवाल खुला रहता है।

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

वही सवाल, दूसरी दिशा में इशारा करते हुए

ऊपर की हर चीज़ उस कोड के बारे में है जो हम बनाते हैं। वही तर्क उस कोड पर लागू होता है जो हम प्राप्त करते हैं। कोई हमारी किसी रिपॉज़िटरी के विरुद्ध एक pull request खोलता है। पैच एक मॉडल द्वारा लिखा गया था। वे हमें क्या दे रहे हैं?

अधिकांश परियोजनाएँ इसे Developer Certificate of Origin — DCO, किसी कमिट मैसेज के नीचे Signed-off-by: पंक्ति — से संभालती हैं। यह एक संक्षिप्त बयान है जिस पर योगदानकर्ता हस्ताक्षर करते समय प्रमाणित करता है: कि उन्होंने योगदान ख़ुद बनाया, या कि यह एक ऐसे स्रोत से आया जो एक संगत लाइसेंस के अंतर्गत है और उनके पास इसे परियोजना की शर्तों के अंतर्गत जमा करने का अधिकार है। यह जानबूझकर हल्का-फुल्का है। कोई वक़ील नहीं, कोई काग़ज़ी काम नहीं, प्रति कमिट एक पंक्ति। यही तरीक़ा है जिससे Linux kernel और QEMU, कई और के साथ, यह स्थापित करते हैं कि उनका कोड कहाँ से आया।

एक मशीन-लिखित पैच के लिए, दोनों में से कोई भी हिस्सा सीधे-सीधे सच नहीं है। और यह फ़ोर्क उसी तरह हल होता है चाहे आप कोई भी शाखा लें।

अगर मशीन-निर्मित आउटपुट का कोई कॉपीराइट नहीं है, तो योगदानकर्ता के पास इसमें कोई अधिकार नहीं है। आपको लाइसेंस देने के लिए कुछ नहीं है।

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

किसी भी तरह, वे वह नहीं दे सकते जो उनके पास नहीं है। हस्ताक्षर बेईमान नहीं है। योगदानकर्ता ने सद्भावना से हस्ताक्षर किया और काम किया। यह बस ख़ाली है: किसी ऐसी चीज़ का हस्तांतरण जो कभी उनकी नहीं थी।

व्यावहारिक परिणाम उतना अलार्मिंग नहीं है जितना यह सुनने में लगता है, और दोनों शाखाएँ तीखे ढंग से अलग हैं।

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

दूसरी शाखा के दाँत हैं। अगर एक मॉडल अपने याद किए गए प्रशिक्षण डेटा को ज्यों-का-त्यों पुनरुत्पादित करता है — जो होता है, मौलिक लॉजिक की तुलना में सामान्य मुहावरों और जाने-माने कार्यान्वयनों के साथ अधिक — तो आपने किसी और का कॉपीराइट प्राप्त कोड स्वीकार कर लिया है, एक ऐसे योगदानकर्ता के आश्वासन पर जिसके पास जाँचने का कोई तरीक़ा नहीं था। DCO का पूरा मूल्य यह है कि हस्ताक्षर करने वाला व्यक्ति जानने की स्थिति में था। यहाँ वे नहीं हैं।

Debian अभी इससे गुज़र रहा है। LLM उपयोग पर एक general resolution 23 जुलाई 2026 को अपनी चर्चा अवधि में गया, बैलेट पर पाँच प्रस्तावों के साथ। वे पूरे दायरे में फैले हैं: प्रस्ताव A पैकेजों, दस्तावेज़ीकरण और वेब संसाधनों के लिए LLM-सहायता प्राप्त योगदान को पूरी तरह मना करने के लिए Social Contract में संशोधन करेगा; प्रस्ताव C योगदानकर्ताओं से जहाँ तक व्यावहारिक हो LLM से बचने को कहता है, परियोजना संचार के लिए केवल-मानव प्रारूपण की अपेक्षा करता है, और व्यक्तिगत रखरखावकर्ताओं को अपने ख़ुद के प्रतिबंध लगाने देता है; प्रस्ताव B, D और E लाइसेंसिंग सत्यापन, योगदानकर्ता जवाबदेही, प्रकटीकरण, और cloud सेवाओं को गोपनीय सामग्री भेजने पर प्रतिबंधों पर विभिन्न रूप से बने शर्तों के तहत AI-सहायता प्राप्त काम की अनुमति देते हैं। इसे लिखे जाने तक यह चर्चा में है और कुछ भी तय नहीं हुआ है।

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

यह कोई हाशिए की चिंता नहीं है। यह ठीक उन्हीं परियोजनाओं पर सबसे कठोरता से गिरता है जिनकी सबसे सावधान provenance है, क्योंकि एक DCO-आधारित परियोजना का इस बारे में पूरा मॉडल कि उसका कोड कहाँ से आया, उस एक प्रमाणीकरण पर टिका है।

हमने यह तय नहीं किया है कि हम इसे कैसे संभालेंगे, और हम सख़्त होने की अच्छी स्थिति में नहीं हैं। हम मशीन-लिखित पोर्ट भेजते हैं। एक परियोजना जो मशीन-लिखित कोड प्रकाशित करती है और मशीन-लिखित योगदान अस्वीकार करती है, वह एक साथ दो असंगत रुख़ अपना रही है, और हम ऐसा नहीं करना चाहेंगे। ईमानदार विकल्प वही हैं जिन्हें Debian तौल रहा है — प्रकटीकरण, योगदानकर्ता जवाबदेही, या एक ऐसा नियम जिसे कोई सत्यापित नहीं कर सकता — और हमने कोई एक नहीं चुना है।

वह दूसरी धुरी जिस पर तर्क चलता है

Debian की बहस provenance और लाइसेंसिंग के बारे में है। यह अकेली धुरी नहीं है, और दूसरी का कॉपीराइट से कोई लेना-देना नहीं है।

Codeberg, वह FLOSS forge, ने जुलाई 2026 में दो सदस्य-अनुमोदित प्रस्ताव अपनाए और अपना तर्क बताया ऐसी शर्तों में जो लाइसेंसों को मुश्किल से छूती हैं। आपत्तियाँ लागत और मेहनत के बारे में हैं: सब पर धकेली गई ऊर्जा और हार्डवेयर खपत; क्रॉलर ट्रैफ़िक जो छोटी forges को ऐसे बचावों की ओर दबाव डालता है जो सामान्य उपयोगकर्ताओं को भी बाधित करते हैं; एकल-उपयोग “vibe-coded” परियोजनाएँ जो प्रकाशित होती हैं और कभी बनाए नहीं रखी जातीं; और समीक्षा करने वाले लोगों पर भार:

Maintainers are under an increased work-load due to people submitting (often well-meaning) low-effort, LLM-generated contributions that require substantial amounts of time to review.

(रखरखावकर्ता एक बढ़े हुए कार्यभार के अंतर्गत हैं क्योंकि लोग ऐसे कम-मेहनत वाले, अक्सर अच्छी नीयत वाले, LLM-निर्मित योगदान जमा कर रहे हैं जिनकी समीक्षा में काफ़ी समय लगता है।)

उनकी Terms of Use अब ऐसी परियोजनाओं को हतोत्साहित करती हैं, बड़े पैमाने पर हटाने के बजाय मॉडरेटरों द्वारा मामले-दर-मामले लागू की जाती हैं।

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

वह हिस्सा जिसे हम तय हुआ नहीं दिखावा करने वाले

हमें उसमें से कुछ भी करने की ज़रूरत नहीं रही होगी।

तीनों तर्कों को साथ रखकर देखें। कार्यक्षमता संरक्षित नहीं है — CJEU ने सीधे यही कहा। शुद्ध रूप से मशीन-निर्मित आउटपुट का कोई मानव लेखक न हो सकता है, इसलिए चिंता करने के लिए कोई नया कॉपीराइट न हो और, अजीब बात है, हमारा भी कोई नहीं। और वास्तविक अनुशासन के साथ चलाया गया एक two-model प्रोटोकॉल एक असली clean room हो सकता है, जिस स्थिति में पोर्ट ने कभी संरक्षित अभिव्यक्ति को छुआ ही नहीं।

अगर तीनों सच हैं, तो इनमें से कुछ पोर्ट को साफ़ अंतरात्मा के साथ अनुज्ञेय रूप से लाइसेंस दिया जा सकता था। अगर इनमें से कोई सच नहीं है, तो हमारा रूढ़िवादी चुनाव बस सही था। हम नहीं जानते कौन-सा, और हमने इसे परखा नहीं। हम वह मामला बनने में दिलचस्पी नहीं रखते जो इसे तय करता है।

सवाल अनदेखा करने से ग़ायब नहीं होता। इस तरह की पोर्टिंग सामान्य होती जा रही है — यह अब सस्ती है, और बिना बनाए रखे गए C की एक बड़ी मात्रा है जिसे कहीं ऐसी जगह ले जाना लायक़ है जहाँ इसे बनाए रखा जा सके। इनमें से हर पोर्ट को वही दो सवालों का सामना करना होगा, और इनमें से अधिकांश न पूछकर जवाब देंगे। वैसे ही हर परियोजना करेगी जो एक पैच मर्ज करती है जो उसने नहीं लिखा, यानी वे सभी। सवाल आते हैं चाहे आप कोड लिख रहे हों या केवल उसे स्वीकार कर रहे हों।