इस प्रोजेक्ट को फिर से लाइसेंस देने का अधिकार नहीं है

• chardet के मूल लेखक Mark Pilgrim ने प्रोजेक्ट के LGPL लाइसेंस उल्लंघन की ओर इशारा करते हुए, हालिया संस्करण 7.0.0 में किए गए MIT लाइसेंस में बदलाव को वापस लेने की मांग की
• उन्होंने स्पष्ट किया कि भले ही मेंटेनर इसे “पूर्ण पुनर्लेखन” कहें, यह मूल कोड के सीधे संपर्क में रहते हुए लिखा गया व्युत्पन्न कार्य है, इसलिए इसे LGPL ही बनाए रखना चाहिए
• कई डेवलपर्स ने इस पर चर्चा की कि AI-सहायित पुनर्लेखन वास्तव में “क्लीन रूम इम्प्लीमेंटेशन(clean room implementation)” है या नहीं, और क्या LLM ने मूल कोड पर प्रशिक्षण लिया था
• कुछ लोगों ने API compatibility और fair use की संभावना का उल्लेख किया, लेकिन अधिकांश ने कॉपीराइट उल्लंघन की आशंका और AI code generation की कानूनी अनिश्चितता पर चिंता जताई
• इस चर्चा को AI द्वारा जनरेट किए गए कोड की कॉपीराइट जिम्मेदारी, ओपन सोर्स प्रोजेक्ट के लाइसेंस बदलने की प्रक्रिया, और मेंटेनर अधिकारों की सीमाओं को लेकर एक महत्वपूर्ण मिसाल के रूप में देखा जा रहा है

---

Mark Pilgrim की आपत्ति

• Mark Pilgrim ने कहा कि वे chardet के मूल लेखक हैं और यह प्रोजेक्ट LGPL लाइसेंस के तहत वितरित होता रहा है
  • उन्होंने कहा कि संस्करण 7.0.0 में “relicense करने का अधिकार है” वाला मेंटेनर का दावा गलत है
  • LGPL के तहत जारी कोड, संशोधित होने पर भी, उसी लाइसेंस के तहत सार्वजनिक होना चाहिए, और “पूर्ण पुनर्लेखन” का दावा कानूनी आधार से रहित है, इस पर उन्होंने जोर दिया
  • उन्होंने यह भी स्पष्ट किया कि “code generator जोड़ने” से कोई नया अधिकार नहीं मिल जाता
• Pilgrim ने मांग की कि प्रोजेक्ट को उसके मूल LGPL लाइसेंस पर वापस लाया जाए

कम्युनिटी की शुरुआती प्रतिक्रिया

• एक उपयोगकर्ता ने पूछा कि क्या AI-सहायित पुनर्लेखन से पहले वाले संस्करण का कोई fork उपलब्ध है, जिस पर दूसरे उपयोगकर्ता ने 6.0.0 संस्करण का लिंक साझा किया
• कुछ लोगों ने “कानूनी रूप से Mark सही हैं” कहकर LGPL उल्लंघन की संभावना को स्वीकार किया
• अन्य उपयोगकर्ताओं ने “AI के जरिए पुनर्लेखन एक अपरिहार्य trade-off है” कहते हुए व्यावहारिक दृष्टिकोण की बात की

कानूनी चर्चा: API, कॉपीराइट, fair use

• एक उपयोगकर्ता ने Google LLC v. Oracle America, Inc. मामले का हवाला देते हुए कहा कि API भी कॉपीराइट सुरक्षा के दायरे में आ सकते हैं
  • उनका कहना था कि API compatibility के लिए किया गया पुनर्लेखन, यदि fair use की शर्तें पूरी नहीं करता, तो अवैध हो सकता है
• इसके जवाब में दूसरे उपयोगकर्ता ने कहा कि Google के मामले में इसे fair use माना गया था
• चर्चा आगे बढ़कर API-compatible rewrites की वैधता और AI-जनरेटेड कोड की कॉपीराइट स्थिति तक पहुंची

AI code generation और क्लीन रूम इम्प्लीमेंटेशन विवाद

• कुछ लोगों ने कहा कि यदि “AI ने मूल कोड पर प्रशिक्षण लिया हो”, तो इसे क्लीन रूम इम्प्लीमेंटेशन नहीं माना जा सकता
  • chardet कोड पर LLM के प्रशिक्षण का सवाल कानूनी निर्णय का मुख्य बिंदु बन सकता है
• अन्य उपयोगकर्ताओं ने तर्क दिया कि यदि “AI ने सिर्फ इनपुट और आउटपुट के आधार पर कोड बनाया हो”, तो यह संभव हो सकता है
  • लेकिन इसके जवाब में यह आपत्ति उठी कि “अगर ऐसा है, तो फिर लाइसेंस का मतलब ही खत्म हो जाता है”
• AI code की कॉपीराइट जिम्मेदारी की अस्पष्टता और लाइसेंस अनुपालन की जांच की कठिनाई प्रमुख मुद्दों के रूप में उभरे

लाइसेंस compatibility और GPL चर्चा

• कुछ लोगों ने दावा किया कि MIT लाइसेंस GPL-compatible नहीं है, लेकिन दूसरे उपयोगकर्ता ने FSF के आधिकारिक दस्तावेज़ का हवाला देकर समझाया कि MIT(Expat) GPL-compatible है
• हालांकि, इस बात पर अधिकांश सहमत रहे कि “LGPL कोड को MIT के तहत फिर से लाइसेंस देना अब भी उल्लंघन है”
• एक अन्य उपयोगकर्ता ने कहा कि “LGPL कोड से बनी प्रतिष्ठा और repository को बनाए रखते हुए अनुबंध को छोड़ नहीं सकते”

AI training data और भरोसे का सवाल

• कई उपयोगकर्ताओं ने सवाल उठाया: “क्या यह भरोसा किया जा सकता है कि Claude ने LGPL कोड पर प्रशिक्षण नहीं लिया?”
  • AI मॉडल के training data को ट्रैक न कर पाने को कानूनी जोखिम बताया गया
• कुछ लोगों ने कहा कि यदि AI code में साहित्यिक चोरी की संभावना निहित है, तो उसके उपयोग से ही बचना चाहिए
  • एक शोध उद्धरण के माध्यम से यह आँकड़ा साझा किया गया कि AI code का 2~5% हिस्सा मौजूदा कोड की नकल हो सकता है

प्रोजेक्ट की पहचान और मेंटेनर अधिकार

• कुछ लोगों ने कहा कि “यदि पिछले योगदानकर्ताओं का सारा कोड हटा दिया गया हो, तो नया संस्करण स्वतंत्र हो सकता है”
  • लेकिन इसके जवाब में यह तर्क भी आया कि “उसी नाम और प्रतिष्ठा का उपयोग करते रहना अनुचित है”
• यह राय भी सामने आई कि “कॉपीराइट अभिव्यक्ति की रक्षा करता है, नाम की नहीं”
• कुछ लोगों का मानना था कि अगर मेंटेनर ने सारा पुराना कोड हटा दिया हो, तो कानूनी उल्लंघन न भी हो, लेकिन इसका कोई स्पष्ट प्रमाण पेश नहीं किया गया

कम्युनिटी का समग्र दृष्टिकोण

• कई उपयोगकर्ताओं ने कहा कि Mark Pilgrim और Dan Blanchard दोनों के योगदान का सम्मान किया जाना चाहिए, और AI, कॉपीराइट, तथा ओपन सोर्स गवर्नेंस जैसे जटिल सवालों को समझना जरूरी है
• चर्चा का दायरा AI code generation की कानूनी जिम्मेदारी, प्रोजेक्ट लाइसेंस बदलने की वैधता, और ओपन सोर्स मेंटेनर अधिकारों की सीमाओं तक फैल गया
• कुछ लोगों ने “v7.0.0 को fork करके उसे फिर LGPL के तहत वापस ले चलें” जैसा सुझाव भी दिया

मुख्य मुद्दों का सार

• LGPL → MIT बदलाव की वैधता: अधिकांश की राय में मूल लेखक की सहमति के बिना यह संभव नहीं
• AI पुनर्लेखन की कॉपीराइट स्थिति: training data के संपर्क के आधार पर इसे व्युत्पन्न कार्य माना जा सकता है
• क्लीन रूम इम्प्लीमेंटेशन का प्रश्न: यह साबित करना होगा कि AI ने मूल कोड का संदर्भ नहीं लिया
• प्रोजेक्ट नाम और प्रतिष्ठा के उपयोग का मुद्दा: उसी नाम से पुनर्वितरण कानूनी और नैतिक विवाद पैदा कर सकता है
• AI code की विश्वसनीयता: साहित्यिक चोरी के जोखिम और supply chain स्थिरता को लेकर चिंता

यह मुद्दा AI-जनरेटेड कोड के कॉपीराइट और ओपन सोर्स लाइसेंस अनुपालन से जुड़ा एक प्रतिनिधि मामला माना जा रहा है, और आगे चलकर AI डेवलपमेंट टूल्स की कानूनी जिम्मेदारी की संरचना को प्रभावित कर सकता है

[GN⁺]

Hacker News की राय

• मेरा मानना है कि Pilgrim कॉपीराइट (clean room) की अवधारणा को गलत समझ रहा है
  “पूरी तरह से फिर से लिखा गया” होने का दावा महत्वपूर्ण नहीं है। कानूनी रूप से स्वतंत्र implementation संभव है।
  Clean room बस मुकदमेबाज़ी को सरल बनाने के लिए एक प्रक्रियात्मक तरीका है, यह कोई कानूनी शर्त नहीं कि मूल कोड के संपर्क में बिल्कुल न आया गया हो।
  वास्तव में Linux भी Unix की आंतरिक संरचना जानता था, फिर भी उसका implementation स्वतंत्र था

  • कानूनी व्याख्या से अलग, अगर AI GPL कोड को अपने-आप rewrite करके license को दरकिनार कर सकता है, तो यह चिंता की बात है क्योंकि इससे open source community का हथियार ही चला जाएगा
  • यह दावा भी गलत है कि संरचनात्मक समानता परीक्षण से तय किया जा सकता है कि कोई derivative work है या नहीं। सिर्फ Claude इस्तेमाल किया गया, इस आधार पर derivative work मान लेना भी गलत है। असली कानूनी मानक अभी भी अस्पष्ट क्षेत्र में हैं
  • इसे तीन मामलों में बाँटकर सोचना चाहिए।
    1. अगर कोड समान है, तो clean room reimplementation साबित करनी होगी
    2. अगर बिल्कुल अलग है, तो clean room हुआ या नहीं, इससे फर्क नहीं पड़ता
    3. ज़्यादातर मामलों में समान और असमान हिस्से मिले-जुले होते हैं, इसलिए हर हिस्से का अलग विश्लेषण ज़रूरी है। अगर कोई हिस्सा भी copy किया गया है, तो उस हिस्से को फिर से लिखना होगा
  • chardet का function (Unicode encoding detection) मूल रूप से स्थिर है। इसलिए नया implementation वही tests पास करे, यह स्वाभाविक है।
    JPlag में कम similarity यह दिखाने वाला काफ़ी मजबूत सबूत लगती है कि यह plagiarism नहीं है
  • यह सोचकर हैरानी होती है कि AI द्वारा generated rewritten code कॉपीराइट संरक्षण के योग्य माना जाएगा

• “अगर codebase पता है, तो rewrite भी कॉपीराइट उल्लंघन है” यह दावा पूरी तरह सही नहीं है
  अंदरूनी जानकारी patent का क्षेत्र है, कॉपीराइट का नहीं।
  लेकिन अगर मूल कोड सामने रखकर सिर्फ वाक्य बदल दिए जाएँ, तो वह उल्लंघन है।
  अगर AI मूल कोड देखकर मिलता-जुलता कोड बनाए, तो उसे व्यवहार में parallel copy माना जाने की संभावना काफ़ी है।
  लेकिन अगर मूल देखे बिना पूरी तरह नया लिखा जाए, तो यह संभव है। बस कानूनी बचाव कठिन होगा, इसलिए कंपनियों को इसे जोखिम मानना चाहिए

  • patent और copyright का अंतर स्पष्ट होना चाहिए।
    patent में स्वतंत्र आविष्कार होने पर भी infringement हो सकता है, लेकिन copyright में रचना की स्वतंत्रता केंद्रीय है।
    फिर भी, अगर आपने पहले से देखे गए काम जैसा ही परिणाम बना दिया, तो jury को मनाना मुश्किल होगा
    आख़िरकार, समानता होने पर preponderance of evidence के मानक पर उल्लंघन माना जाने की संभावना काफ़ी है
  • अगर Mario Puzo की 『The Godfather』 पढ़कर उसी संरचना वाला उपन्यास लिखा जाए, तो उसे derivative work माना जाएगा।
    वहीं अगर मूल रचना के बारे में कुछ पता ही न हो, तो उसे independent creation माना जाएगा
  • अगर Claude.md फ़ाइल मौजूद है, तो संभावना है कि नए maintainer ने Claude को code generator की तरह इस्तेमाल किया, और उस model को chardet के मूल कोड पर train किया गया होगा
  • सवाल उठता है: “कितना अलग होना चाहिए ताकि उसे नया कोड माना जाए?”
  • rewrite अनुवाद जैसा है। अनुवाद भी कॉपीराइट उल्लंघन हो सकता है।
    ideas स्वयं सुरक्षित नहीं होते, लेकिन expression सुरक्षित होता है।
    अगर LLM ने training के दौरान मूल कोड देखा है, तो यह कानूनी gray area है

• मुख्य मुद्दा LGPL उल्लंघन का है।
  अगर नया कोड मूल पर आधारित है, तो उसे derivative work माना जाएगा और LGPL बनाए रखना होगा।
  भले ही “पूरी तरह से rewrite” होने का दावा किया जाए, अगर मूल कोड के संपर्क में आया गया था, तो यह license violation हो सकता है

  • सिर्फ exposure होने से अपने-आप derivative work नहीं बन जाता।
    clean room सिर्फ मुकदमे में बचाव का एक प्रक्रियात्मक तरीका है, और सबूत का भार वादी पर होता है।
    Linux और GNU tools भी Unix को जानते थे, फिर भी वैध थे
  • अगर Claude ने मूल कोड पर training ली है, तो उस व्याख्या के अनुसार एक दिलचस्प निष्कर्ष निकलता है कि AI सिर्फ LGPL derivatives ही बना सकता है
  • कॉपीराइट ही असली केंद्र है। अगर नया कोड मूल का derivative है, तो LGPL लागू होगा; नहीं तो नया copyright holder अपनी मर्ज़ी से license तय कर सकता है
  • अगर वही नाम रखकर सिर्फ version बढ़ाया जाए, तो उसे व्यवहार में वही project माना जा सकता है

• consulting के दौरान एक दिलचस्प मामला देखा।
  एक SaaS कंपनी के engineer ने Claude Code से अपनी ही app का reverse engineering करके API-compatible backend एक हफ़्ते में बना लिया।
  सवाल था, “अगर कोई competitor ऐसा करे, तो बचाव कैसे होगा?”

  • वह बस तकनीकी प्रगति है।
    अगर कोड ही business का मूल है, तो जोखिम पहले से है।
    competition की चिंता करने से ज़्यादा ज़रूरी बेहतर product बनाना है
  • StrongDM Factory के उदाहरण की तरह, बाहरी services को clone करके testing में इस्तेमाल करना अब वास्तविकता बन रहा है।
    अब “Slack या Drive को फिर से implement करें” जैसी बात अवास्तविक नहीं रही
  • अगर AI ने सिर्फ frontend देखकर backend को फिर से implement किया, तो वह वैध है।
    API एक public interface है, इसलिए वह संरक्षित विषय नहीं है
  • patent बाद में register नहीं किया जा सकता, और copyright ideas की रक्षा नहीं करता।
    IBM BIOS या DOS के reverse engineering मामलों की तरह, independent implementation वैध है

• maintainer trustee है, मालिक नहीं।
  उसे मूल लेखक के license को मनमाने ढंग से नहीं बदलना चाहिए।
  अगर कोड सचमुच पूरी तरह नया है, तो नए नाम से project शुरू करना चाहिए।
  “पुराने version पर freeze कर दो” जैसी बात community spirit के ख़िलाफ़ है

• 2021 की एक comment में पहले ही कहा गया था कि “chardet, LGPL पर आधारित है, इसलिए उसका relicense करना संभव नहीं है।”
  यह जानते हुए भी rewrite किया गया, तो यह लापरवाह फ़ैसला था और मूल लेखक के प्रति असम्मान भी

  • इसके उलट, कुछ लोगों का मानना है कि project की उपयोगिता को अधिकतम करने के लिए यह सही फ़ैसला था

• अगर AI ने मूल कोड देखकर लिखा, तो वह clean room implementation नहीं है।
  अगर दो AI teams हों, एक specification बनाए और दूसरी implementation करे, तो क्या वह ठीक होगा?
  यह IBM दौर की मिसाल जैसा है, लेकिन अगर model पहले से ही मूल पर train है, तो समस्या फिर भी रहती है

  • अगर chardet training data में शामिल था, तो किसी भी संरचना में clean room संभव नहीं है
  • अगर specification निकाली जाए और कोई अलग model उसी specification से कोड लिखे, तो सैद्धांतिक रूप से clean room संभव है।
    लेकिन यह verify करना होगा कि specification में अभिव्यक्तिगत तत्व शामिल न हों
  • अगर training data में मूल मौजूद है, तो उल्लंघन की संभावना फिर भी काफ़ी है
  • यह दावा भी था कि API structure भी copyright का हिस्सा है, लेकिन बाद में उसे सुधारा गया
  • IBM/Compaq मामला ऊपर-ऊपर से ही मिलता-जुलता है।
    जहाँ training data में मूल मौजूद हो, वहाँ यह तुलना ही अर्थहीन हो जाती है

• “अगर Wikipedia से copy-paste करके कुछ शब्द बदल दिए जाएँ, तो क्या वह ठीक है?” इस मज़ाक की तरह,
  आख़िरकार जानबूझकर बच निकलना संभव नहीं है।
  यह ऐसा दौर है कि dependency versions तक pin करनी पड़ती हैं क्योंकि भरोसा करना कठिन हो गया है

  • engineers अक्सर कानून को तकनीकी नियम की तरह समझ लेते हैं।
    लेकिन कानून समग्र मूल्यांकन को महत्व देता है।
    अदालतें “preponderance of evidence” के आधार पर फ़ैसला करती हैं, और सिर्फ शब्द बदल देने से कोई नई रचना नहीं बन जाती।
    अगर मूल अनिवार्य था, तो derivative work माना जाने की संभावना अधिक है।
    अगर training data में मूल शामिल है, तो copyright infringement lawsuit लगभग अपरिहार्य होगा, ऐसा अनुमान है

• दूसरी ओर, Mark Pilgrim का फिर से सामने आना दिलचस्प है
  उसके Wikipedia page में “इंटरनेट से गायब हो जाने” की कहानी है।
  उसकी Python किताबें आज भी recommend करने लायक हैं

  • शायद जल्द ही “a2mark” GitHub account का ज़िक्र भी Wikipedia में दिखे

• “अगर AI ने GPL कोड पर training ली है, तो क्या सारा AI code GPL taint नहीं हो गया?” इस पर आश्चर्य जताया गया

  • ReactOS जैसे कुछ projects पूरी clean room प्रक्रिया की मांग करते हैं, लेकिन यह सिर्फ कानूनी safety measure है, कोई अनिवार्य शर्त नहीं
  • “taint” साबित करने के लिए वास्तव में derivative nature साबित करनी होगी।
    अमेरिका में clean room प्रक्रिया बस मुकदमा छोटा करने की रणनीति है
  • कुछ लोगों का मानना है कि copyright व्यवस्था मूल रूप से पूँजी की रक्षा का साधन रही है, इसलिए व्यवहार में इसका इतना कठोर प्रवर्तन होने की संभावना कम है
  • LLM उछाल के शुरुआती दौर से ही कुछ लोग इन समस्याओं के बारे में चेतावनी दे रहे थे