Claude Code द्वारा लिखे गए कोड का मालिक कौन है?

 (legallayer.substack.com)
5 पॉइंट द्वारा GN⁺ 1 일 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • AI-सहायित कोड का कॉपीराइट इस बात पर निर्भर करता है कि उसमें इंसान का अर्थपूर्ण रचनात्मक योगदान है या नहीं; अगर ज़्यादातर काम AI ने किया है और इंसान ने बहुत कम हस्तक्षेप किया है, तो ऐसे आउटपुट को सुरक्षा न मिल सकती है
  • मुख्य मानदंड meaningful human authorship है; सिर्फ लक्ष्य बताने की तुलना में आर्किटेक्चर तय करना, परिणामों को छाँटना और कोड को फिर से संरचित करना अधिक महत्वपूर्ण रचनात्मक निर्णय माने जाते हैं
  • कोड पर कॉपीराइट बनता है या नहीं, इससे अलग, अगर work-for-hire doctrine या व्यापक IP assignment clauses मौजूद हों, तो कंपनी के समय, उपकरण, प्रोजेक्ट या कंपनी-लाइसेंस प्राप्त टूल्स से बनाया गया AI-सहायित कोड भी कंपनी की संपत्ति माना जा सकता है
  • मालिकाना हक होने पर भी open source license contamination एक अलग मुद्दा है; खासकर अगर आउटपुट ने GPL परिवार के कोड को लगभग ज्यों-का-त्यों कॉपी किया है, तो यह लाइसेंस उल्लंघन तक जा सकता है
  • अभी अपेक्षाकृत स्पष्ट बिंदु हैं: मानव लेखन का अभाव होने पर सुरक्षा नहीं, रोजगार अनुबंध के अनुसार अधिकारों का आवंटन, और GPL को शब्दशः कॉपी करने का जोखिम; व्यवहार में अदालत के फैसले से पहले रिकॉर्ड सुरक्षित रखना और लाइसेंस स्कैन करना अधिक महत्वपूर्ण हो जाता है

कॉपीराइट मानदंड और अनसुलझे हिस्से

  • कॉपीराइट सुरक्षा सिर्फ इंसानों द्वारा बनाए गए कार्यों पर लागू होती है, और ऐसे परिणाम जो मुख्य रूप से AI ने बनाए हों तथा जिनमें इंसान का अर्थपूर्ण रचनात्मक योगदान न हो, वे मौजूदा मानदंडों के तहत संरक्षित न हों
  • Thaler मामले के बाद भी Supreme Court ने merits पर फैसला नहीं दिया है; DC Circuit का फैसला बरकरार रहा, लेकिन AI-सहायित coding outputs पर सीधे लागू होने वाली मिसाल अभी नहीं है
  • अदालतों ने अब तक सीधे जिस मुख्य सवाल को नहीं सुलझाया है, वह यह है कि AI-सहायित कार्य में इंसानी हस्तक्षेप कितना होना चाहिए
    • शुद्ध AI-जनित चित्रों की तरह जहाँ इंसानी हस्तक्षेप 0 हो, उसके विपरीत कोड में अक्सर इंसान कुछ दिशा तय करता है और मंजूरी देता है, इसलिए सीमा और धुंधली हो जाती है
    • कोड के क्षेत्र में अभी तक मानव लेखन के सिद्धांत को AI coding outputs पर सीधे लागू करने वाला कोई फैसला नहीं है
  • अगर AI द्वारा बनाए गए कोड को लगभग बिना संशोधन स्वीकार कर लिया गया, तो संभव है कि कोई भी कॉपीराइट दावा न कर सके, और यदि कोई प्रतिस्पर्धी उसे ज्यों-का-त्यों कॉपी कर ले तो जवाबी विकल्प कमज़ोर पड़ सकते हैं
  • निर्णय का केंद्र meaningful human authorship है; सिर्फ लक्ष्य लिख देने की तुलना में संरचना तय करना, परिणामों को छाँटना और डिज़ाइन को दोबारा गढ़ना अधिक महत्वपूर्ण रचनात्मक निर्णय माने जाते हैं

मानव लेखन को सिद्ध करने के तरीके

  • अर्थपूर्ण मानवीय योगदान को प्रतिशत या edits की संख्या से सख्ती से नहीं मापा जाता; महत्वपूर्ण यह है कि क्या इंसान ने वास्तव में रचनात्मक निर्णय लिए

    • आर्किटेक्चर का चयन

      • यह तय करना ज़रूरी है कि ड्राफ्ट में से क्या अस्वीकार किया जाएगा
      • परिणामों को किसी विशेष डिज़ाइन के अनुरूप पुनर्गठित करना चाहिए
      • "API के लिए rate limiting module बनाओ" जैसे छोटे निर्देश के बाद अगर टूल कई फाइलें बनाए और कई बार संशोधन करे, तो अदालत में इसे इंसान का पर्याप्त योगदान माना जाएगा या नहीं, इस पर अभी स्पष्ट निष्कर्ष नहीं है
      • जिन modules को दिशा बदलते हुए काफी हद तक संपादित किया गया हो, उनमें मानव लेखन मानने की संभावना अधिक है, लेकिन जैसे-का-तैसा स्वीकार किया गया कोड उलटी दिशा में पढ़ा जा सकता है
      • Allen v. Perlmutter ऐसा मामला था जिसमें 600 से अधिक prompts और Photoshop edits होने के बावजूद AI द्वारा बनाए गए मूल तत्वों का registration अस्वीकार हुआ; यह इंसानी हस्तक्षेप की पर्याप्तता तय करने वाला महत्वपूर्ण मोड़ बना हुआ है
      • Zarya of the Dawn में केवल इंसान द्वारा लिखा गया text register हुआ और Midjourney द्वारा बनाई गई images को बाहर रखा गया; यह सिद्धांत AI-सहायित codebase में भी इंसान द्वारा सीधे बनाए गए तत्वों को अलग सुरक्षा देने की दिशा से मेल खाता है
      • डिज़ाइन दस्तावेज़ साक्ष्य बन सकते हैं
      • commit messages में छोड़े गए डिज़ाइन निर्णय भी साक्ष्य बन सकते हैं
      • ADR भी साक्ष्य बन सकता है
      • prompts के logs जिनमें जानबूझकर दिशा बदलने के निशान हों, वे भी मददगार होते हैं
      • अगर आप संरक्षित किए जा सकने वाले हिस्से को बढ़ाना चाहते हैं, तो क्या सीधे तय किया और कैसे बदला, इसका रिकॉर्ड रखना फायदेमंद है

रोजगार अनुबंध पहले मालिकाना हक तय करता है

  • यह देखने से पहले कि कोड कॉपीराइट सुरक्षा के योग्य है या नहीं, पहले यह देखना चाहिए कि वह अधिकार शुरू से किसके पास जाता है
  • सामान्य employment agreements काम के दायरे में बनाए गए outputs को कंपनी की संपत्ति बना देते हैं, और इसे work-for-hire doctrine से समझाया जाता है
  • कंपनी के काम के समय, कंपनी के प्रोजेक्ट, कंपनी के उपकरण, या कंपनी द्वारा उपलब्ध कराए गए AI coding tools से तैयार परिणाम मैन्युअल कोड और AI-सहायित कोड दोनों के लिए कंपनी के स्वामित्व में माने जा सकते हैं
  • वास्तविक contracts अक्सर मूल कानूनी सिद्धांत से भी व्यापक लिखे जाते हैं, और अगर निम्न प्रकार की भाषा हो तो उसमें AI-सहायित कोड भी शामिल हो सकता है
    • कंपनी के उपकरण या संसाधनों का उपयोग करके बनाया गया कार्य भी शामिल हो सकता है
    • रोजगार अवधि के दौरान किए गए inventions या developments भी शामिल हो सकते हैं
    • कंपनी द्वारा लाइसेंस किए गए tools की मदद से बना software भी शामिल हो सकता है
  • खासकर company-licensed tools वाली भाषा व्यक्तिगत प्रोजेक्ट्स तक फैल सकती है
    • अगर कंपनी ने Claude Code, Cursor, Copilot को टीम के लिए अपनाया हो
    • और उसी टूल का उपयोग आपने अपने समय के side project में भी किया हो
    • तो व्यापक IP assignment clause के तहत कंपनी के पास अधिकार का दावा करने की गुंजाइश बन सकती है
  • सिर्फ इस आधार पर कि कंपनी का कोड IDE में खुला था और AI उसे देख सकता था, यह दावा कि आउटपुट कंपनी के IP का derivative work बन गया, कानूनी रूप से सीधा-सीधा स्थापित मानना कठिन बताया गया है
  • लेकिन अगर अनुबंध की भाषा व्यापक हो, तो AI ने वास्तव में क्या किया इससे अलग ऊपरी तौर पर दावा करने की गुंजाइश पैदा हो सकती है
  • side projects को अलग रखना हो तो व्यक्तिगत account, व्यक्तिगत उपकरण और स्वयं भुगतान किए गए tools के साथ workflow को पूरी तरह अलग रखना अधिक सुरक्षित है

open source लाइसेंस contamination का जोखिम

  • भले ही AI द्वारा बनाए गए कोड का स्वामित्व आपके पास हो, यह एक अलग सवाल है कि कहीं वह कोड छिपी हुई open source license obligations तो साथ नहीं ला रहा
  • AI coding tools को सार्वजनिक कोड सहित, और उनमें भी GPL, LGPL जैसी copyleft licenses वाले कोड सहित, विशाल डेटा पर प्रशिक्षित किया जाता है
  • copyleft licenses में उस कोड के derivative work के distribution पर वही लाइसेंस जारी रखने की बाध्यता आ सकती है
    • अगर वह GPL कोड का derivative है, तो अपना source भी उसी लाइसेंस के तहत जारी करना पड़ सकता है
    • यह कहना कि लाइसेंस की जानकारी नहीं थी, बचाव नहीं बनता
  • कानूनी जोखिम का मानदंड कार्यात्मक समानता नहीं बल्कि वास्तविक और पर्याप्त शब्दशः कॉपी है
    • GPL कोड जैसा काम करने वाला परिणाम
    • और GPL कोड को लगभग ज्यों-का-त्यों पुन: प्रस्तुत करने वाला परिणाम अलग मुद्दे हैं
  • जोखिम मुख्य रूप से शब्दशः कॉपी वाले मामलों में केंद्रित है, लेकिन मौजूदा codebase किस तरफ आता है, यह स्कैन किए बिना जानना मुश्किल है
  • 2026 की शुरुआत में chardet community dispute में Claude का उपयोग करके chardet को फिर से लिखकर MIT license के तहत पुनर्वितरित किया गया था, और इस पर टकराव हुआ कि क्या इसे clean room implementation माना जा सकता है
    • यह मामला अदालती मुकदमा नहीं बल्कि community dispute था, इसलिए कानूनी रूप से अंतिम निष्कर्ष नहीं निकला
    • फिर भी GPL परिवार के कोड को ज्यों-का-त्यों कॉपी करना लाइसेंस उल्लंघन है, यह बात पहले से स्थापित है
  • जो हिस्सा अभी तय नहीं है, वह यह है कि अगर AI output ने training data के patterns को दोहराया, तो क्या उसे शब्दशः कॉपी माना जाएगा
  • कॉर्पोरेट M&A सलाह के क्षेत्र में इस जोखिम को वास्तविक मुद्दा माना जा रहा है, और AI codebase license scanning अब due diligence की सूची में शामिल हो रहा है
  • Doe v GitHub में यह विवाद है कि क्या Copilot लाइसेंसयुक्त कोड को बिना attribution के पुन: प्रस्तुत करता है, और अप्रैल 2026 तक यह मामला Ninth Circuit में जारी है
    • निचली अदालत ने अधिकांश दावे खारिज कर दिए थे, लेकिन appeal अभी जारी है
    • मुकदमे के परिणाम से अलग, GitHub ने duplicate detection filters जोड़े हैं और उद्योग का व्यवहार भी बदल रहा है

व्यवहारिक रूप से अभी क्या करना चाहिए

  • लाइसेंस स्कैन चलाएँ

    • AI-सहायित codebase पर पहले open source license scan चलाना महत्वपूर्ण है
    • FOSSA — enterprise में व्यापक रूप से इस्तेमाल होने वाला समग्र टूल
    • Snyk Open Source — GitHub integration अच्छा है, इसलिए dev team workflow में आसानी से फिट हो सकता है
    • Black Duck — M&A due diligence में मानक रूप से इस्तेमाल किया जाता है
    • ये टूल्स codebase को स्कैन करके ज्ञात open source libraries से मेल और उनसे जुड़े लाइसेंस की पहचान करते हैं

  • मानव रचनात्मक योगदान का रिकॉर्ड रखें

    • अर्थपूर्ण मानव लेखन को सिद्ध करने वाली सामग्री सामान्य engineering process में पहले से बनती रहती है, लेकिन उसे जानबूझकर सुरक्षित रखना ज़रूरी है ताकि उसका प्रभाव बढ़े
    • commit messages में AI द्वारा generated result से अधिक यह दर्ज होना चाहिए कि क्या और क्यों बदला गया
      • "Restructured Claude’s module architecture, rejected initial state management approach, rewrote error handling from scratch" जैसे रिकॉर्ड साक्ष्य बन सकते हैं
      • अगर सिर्फ "Add rate limiting module" जैसा रिकॉर्ड हो, तो मानवीय योगदान दिखाना कठिन होगा
    • Claude Code और Cursor के interaction logs को export या screenshot के रूप में सुरक्षित रखना भी अच्छा है
    • generated code से पहले लिखे गए डिज़ाइन दस्तावेज़, ADR, notes इस बात के संकेत बन सकते हैं कि संरचना पहले इंसान ने तय की थी

  • रोजगार अनुबंध की IP clauses जाँचें

    • contract में intellectual property, IP assignment, work product वाले sections को सीधे जाँचना चाहिए
    • "काम के समय बनाया गया कार्य" का दायरा "कंपनी संसाधनों का उपयोग करके बनाया गया कार्य" से संकरा है
    • "कंपनी के business से संबंधित" का दायरा "सभी software development" से संकरा है
    • company-licensed tools वाली भाषा व्यक्तिगत projects में भी AI टूल के उपयोग को जोड़ सकती है
    • अगर स्वतंत्र project करना है
      • शुरू करने से पहले written carveout पर बातचीत करनी चाहिए
      • उसे पूरी तरह व्यक्तिगत उपकरण, व्यक्तिगत समय और व्यक्तिगत tools से अलग रखना चाहिए
      • और संभव है कि कंपनी के दावे के जोखिम को स्वीकार करके आगे बढ़ना पड़े

  • Anthropic terms के प्रकार की जाँच करें

    • commercial launch से पहले anthropic.com/legal देखें और consumer terms तथा commercial terms का अंतर समझें
    • free / Pro उपयोगकर्ता को outputs के अधिकार देते हैं, लेकिन IP indemnification का दायरा संकरा होता है
    • API / enterprise outputs के अधिकारों के assignment के साथ, approved use और outputs से जुड़े copyright infringement claims पर अपेक्षाकृत व्यापक defense scope देते हैं
    • लेकिन ऐसी indemnity भी codebase के भीतर की GPL contamination समस्या को अपने-आप हल नहीं करती
    • उस हिस्से को license scanning और internal governance से खुद संभालना होगा

अभी क्या स्पष्ट है और क्या अब भी खुला है

  • फिलहाल तीन बातें अपेक्षाकृत स्पष्ट हैं
    • मानव लेखन रहित कार्य को कॉपीराइट सुरक्षा नहीं मिलती
    • work-for-hire doctrine कोड किस तरीके से बना, इससे अलग लागू हो सकता है
    • GPL कोड की शब्दशः कॉपी लाइसेंस उल्लंघन है
  • दो बातें अब भी अदालतों द्वारा स्पष्ट रूप से तय नहीं की गई हैं
    • agentic workflows में कितने मानवीय निर्देश और edits पर्याप्त लेखन माने जाएँगे
    • अगर AI output training data के patterns को दोहराता है, तो क्या उसे शब्दशः कॉपी माना जाएगा
  • निकट भविष्य में ये मुद्दे बड़े मुकदमों में बदलेंगे या नहीं, यह अभी शुद्ध अटकल का विषय है
  • व्यवहार में यह अनिश्चितता अदालतों से पहले M&A due diligence और institutional investment review में वास्तविक समस्या बन रही है
  • खरीदार और निवेशक पहले ही deal-closing conditions के रूप में ऐसे सवाल पूछ रहे हैं, इसलिए भले अभी ऐसी स्थिति न हो, रिकॉर्ड और स्कैन पहले से तैयार रखना फायदेमंद है

संबंधित पढ़ाई

2 टिप्पणियां

 
undeadx1 20 시간 전

क्या कोड को संरक्षण के दायरे में आने वाली चीज़ माना जा सकता है?
 
GN⁺ 1 일 전
Hacker News टिप्पणियाँ

  • इसे image generation precedent जैसी ही श्रेणी में देखना चाहिए
    Zarya of the Dawn में जैसा पहले ही स्पष्ट किया गया था, इंसान द्वारा लिखे गए हिस्से सुरक्षित थे, लेकिन AI द्वारा बनाई गई images सुरक्षित नहीं थीं, और इंसान द्वारा चुने गए, prompt किए गए, और curate किए गए character designs को भी copyright नहीं मिला
    मुझे नहीं लगता कि code अलग है। Claude से एक function बनवाना, मेरे खुद function लिखने से कम और Midjourney से एक frame निकलवाने के ज़्यादा करीब है
    engineers अलग तरह से महसूस करते हैं क्योंकि वे आमतौर पर compiler analogy के बारे में सोचते हैं, लेकिन compiler एक deterministic tool है जिसमें same input पर same output आता है, जबकि LLM ऐसा नहीं है। Copyright Office भी रेखा यहीं खींचता है, और image वाले मामलों में यह निष्कर्ष पहले ही आ चुका है

    • तब मुझे यह जानने की जिज्ञासा है कि क्या वास्तव में किसी इंसान को अपने नाम से copyright registration के लिए आवेदन करने से रोका जाता है
      यह भी अस्पष्ट है कि कोई दूसरा व्यक्ति वही prompt फिर से लिखकर कुछ वैसा ही दोबारा बना सकता है, तो क्या इससे पहले व्यक्ति का अधिकार दावा ही अमान्य हो जाता है

  • cert denial कानून को अंतिम रूप से तय नहीं करता
    Supreme Court कई बार merits से असंबंधित कारणों से भी certiorari देने से मना कर देता है, इसलिए केवल इससे मुद्दा nationwide settled नहीं हो जाता

    • TFA में मूल रूप से यही लिखा था
      Supreme Court ने Thaler appeal नहीं सुना, इसका यह मतलब नहीं कि उसने lower court की reasoning को approve किया या nationwide conclusion दे दिया; बस इतना कि DC Circuit का फैसला कायम रहा, Copyright Office की स्थिति बनी रही, और अभी तक कोई विपरीत फैसला देने वाली court नहीं है
      लेकिन जो वाक्य अभी quote किया गया है, वह अब TFA में नहीं है
    • मुझे लगता है कि इस निष्कर्ष को सीधे परखने वाला case law अभी कम है
      सूचीबद्ध तत्वों में से कौन-सा authorship मानने के लिए पर्याप्त है, इसकी पुष्टि करने वाला precedent मुझे याद नहीं आता
      खासकर यह जानना चाहता हूँ कि क्या बार-बार output ठुकराकर उसे दूसरी दिशा में guide करना कभी human authorship माना गया है
      फिलहाल जो स्पष्ट है, वह यह कि इंसान द्वारा न लिखे गए code हिस्सों को disclaim किया जा सकता है, और वास्तव में Copyright Office disclosure और disclaimer दोनों मांगता है। अगर इससे अधिक quote करने योग्य सामग्री हो तो देखना चाहूँगा
    • फिर भी appellate precedent effect तो बना रहता है, ऐसा मुझे लगता है
      उस फैसले को पलटने का मुख्य कानूनी असर ही क्या उसकी precedent value का खत्म होना नहीं है
      Supreme Court review से न गुज़रे precedents को सैद्धांतिक रूप से कभी भी चुनौती दी जा सकती है, लेकिन व्यवहार में वे अक्सर उलटे जाने तक कानून की तरह काम करते रहते हैं। यह मामला भी बहुत अलग नहीं लगता
    • meaningful human authorship ठीक-ठीक कैसे परिभाषित होता है, यह मुझे नहीं पता
      क्या मेरा code review meaningful है
      generated code को मैंने modify और edit किया, तो क्या वह human authorship माना जाएगा
    • यह सही बात थी, इसलिए मैंने post सुधार दी
      cert denial का मतलब सिर्फ इतना है कि Supreme Court ने मामला नहीं सुना; इसका मतलब यह नहीं कि उसने lower court की reasoning को approve किया या nationwide conclusion दे दिया
      DC Circuit का फैसला कायम है और Copyright Office की position भी consistent है, लेकिन यह Supreme Court द्वारा तय किया गया कानून कम और settled doctrine ज़्यादा है

  • मुझे लगता है कि agent को निर्देश देने वाले व्यक्ति के पास output का copyright होना चाहिए, लेकिन शुरुआत में जिस आधार पर वह agent यह बना पा रहा है, वही चोरी किए गए IP पर टिका है
    खासकर OSS में, मुझे चिंता है कि यह तरीका copyright washing को संभव बनाता है, इसलिए OSS developers को अपनी क्षमता के भीतर सबसे मज़बूत copyleft license के तहत publish करना चाहिए, ऐसा मेरा मानना है
    https://jackson.dev/post/moral-ai-licensing/

    • यह दिलचस्प है कि copyright industry ने धीरे-धीरे copyright infringement को निंदात्मक शब्द stealing से बदल दिया है
      अगर original अब भी आपके पास है, तो आखिर चोरी क्या हुई
      Dowling v. United States, 473 U.S. 207 (1985) में भी यह माना गया था कि unauthorized sale, National Stolen Property Act के तहत "stolen, converted or taken by fraud" property नहीं है
    • मुझे copyright laundering लगभग एक भ्रम लगता है
      अगर court यह मान ले कि LLM output पर्याप्त रूप से derivative है, खासकर तब जब वह LLM किसी infringing original पर trained हो, तो उस derivative output को redistribute करने वाला व्यक्ति copyright infringement के लिए liable होगा
      LLM बनाना transformative हो सकता है, लेकिन infringing output खुद transformative नहीं होता
    • copyright कोई प्राकृतिक अधिकार नहीं, बल्कि सरकार द्वारा science and useful arts की प्रगति को बढ़ावा देने के लिए दी गई व्यवस्था है
      इसलिए अगर copyright खुद प्रगति में बाधा बनने लगे, तो exceptions बनाना पूरी तरह उचित है
    • क्या वास्तव में कोई कानूनी आधार है कि agent को निर्देश देने वाले व्यक्ति के पास copyright हो
      Community for Creative Non Violence v. Reid(https://en.wikipedia.org/wiki/Community_for_Creative_Non-Violence_v._Reid) को देखें, तो सिर्फ काम commission करने और दिशा देने से commissioner author नहीं बन जाता; actual काम करने वाला व्यक्ति author होता है
      contract के ज़रिए rights transfer हो सकते हैं, लेकिन monkey selfie जैसे मामलों के बाद यह भी स्थापित हो चुका है कि copyright सिर्फ इंसानों को दिया जाता है
      LLM इंसान नहीं है, इसलिए वह copyright नहीं रख सकता, और अगर उसके पास कानूनी copyright ही नहीं है तो वह वह अधिकार आपको transfer भी नहीं कर सकता
    • ईमानदारी से कहूँ तो समझ नहीं आता कि यह रवैया इतना व्यापक क्यों है
      जब मैं code लिखता हूँ, तब भी मैं अपनी शिक्षा और career भर देखे गए असंख्य source code से प्रभावित रहता हूँ, और LLM भी देखे गए code के आधार पर आगे output को shape करता है, इस अर्थ में दोनों समान लगते हैं
      तुरंत जवाब आता है, "उस code को पढ़ने का अधिकार नहीं था", लेकिन वह तर्क भी मुझे बहुत संतोषजनक नहीं लगता। मैंने जो अधिकांश code सीखा, उस पर copyright था, और जब तक वह मेरा निजी code न हो, rights आमतौर पर किसी और के ही थे। NDA या defense-related confidential code तक ने बाद में मेरी coding style को प्रभावित किया
      कला में भी यही बात लागू होती है। फ़ोटोग्राफ़ी में Ansel Adams, painting में Bob Ross और कई शिक्षकों का प्रभाव रहा, और मैंने दूसरों के काम में देखे गए टुकड़ों को अपनी दृष्टि के साथ मिलाकर कुछ और बनाया
      फिर भी मुझे नहीं लगता कि केवल उस प्रभाव-संबंध के आधार पर कोई मेरे output पर अधिकार जता सकता है
      मेरे जूनियर्स ने भी मेरे code से सीखा है, और software development पर मेरी लिखी किताबें भी हैं। उम्मीद है कि कभी मेरी visual art भी ऐसी मूल्यवान चीज़ बने जिसे कोई absorb करे
      LLM आने से बहुत पहले भी मैंने कभी यह नहीं चाहा कि मेरा काम मेरे साथ sealed हो जाए और ideas कब्र तक चले जाएँ
      आखिरकार हम सब giants के shoulders पर खड़े हैं, और पिछले काम को absorb किए बिना हम आज जो हासिल कर पाए हैं उसका बहुत छोटा हिस्सा भी संभव नहीं होता
      कुछ दशकों बाद मैं मर जाऊँगा और मेरा नाम भी जल्दी भुला दिया जाएगा, लेकिन अगर मेरे बनाए software, photos, या paintings समय में छोटी-सी लहर छोड़ जाएँ, तो वह मुझे एक तरह की छोटी अमरता जैसा लगेगा

  • मैं चाहूँगा कि generated comments HN पर डालना बंद किया जाए
    rules के हिसाब से यह allowed नहीं है, और ऐसा pattern मैं पहले ही 30 से ज़्यादा बार देख चुका हूँ
    बेशक मैं 100% निश्चित नहीं हो सकता, लेकिन software judgment और पूरे pattern को देखें तो मामला काफ़ी persuasive है
    https://news.ycombinator.com/newsguidelines.html#generated और https://news.ycombinator.com/item?id=47340079 देखें

    • यह point सही है और मैं माफ़ी चाहता हूँ
      मैंने reply लिखने में AI assistant का इस्तेमाल किया था, आगे से नहीं करूँगा

  • बौद्धिक खेल के रूप में यह सवाल मज़ेदार है, लेकिन वास्तविक दुनिया में अंततः जिसके पास पैसा है वही इसे ले जाएगा, ऐसा मुझे लगता है
    सिर्फ इसलिए कि Claude ने लिखा, यह उम्मीद करना कि Anthropic के पास Claude Code नहीं होगा, कुछ wishful thinking जैसा लगता है

    • ऊपर से, देश-दर-देश जवाब अलग हो सकता है
      हर देश चुपचाप अमीर पक्ष का साथ नहीं देता, इसलिए नतीजे का पहले से अनुमान लगाना मुश्किल है
    • अगर चीज़ें इस दिशा में जाएँ कि genAI art पर copyright नहीं होगा लेकिन genAI code पर होगा, तो यह सचमुच Almighty Dollar के काम करने जैसा होगा
    • मेरी intuition कहती है कि Anthropic के मालिक होने की बात को असल में work-for-hire doctrine बेहतर समझाती है
      Claude ने लिखा या नहीं, उससे ज़्यादा यह plausible है कि उसे निर्देश देने वाले engineers के employment contracts की वजह से company के पास rights हों
      दूसरी ओर DMCA takedown requests का सवाल अधिक दिलचस्प है, क्योंकि DMCA में claimant को good faith से copyright ownership का दावा करना होता है
      अगर बाद में court यह मान ले कि codebase मुख्यतः AI द्वारा लिखा गया था और इसलिए copyright योग्य नहीं था, तो वे 8,000 takedowns bad faith DMCA claims के रूप में चुनौती दिए जा सकते हैं
      ownership से अधिक यह एक अलग किया जा सकने वाला और व्यावहारिक कानूनी मुद्दा है
    • यह कोई wishful thinking नहीं है, और ownership अपने-आप तय भी नहीं हो गई है
      U.S. legal system में model इंसान नहीं है, इसलिए वह property own नहीं कर सकता, और जिस intellectual property का वह खुद मालिक नहीं है उसे contract से फिर transfer भी नहीं कर सकता—यह बात काफ़ी स्पष्ट लगती है
    • malware, illegal code, या crimes में इस्तेमाल हुआ code शायद companies own करना नहीं चाहेंगी
      फिर भी ऐसा लगता है कि investigators को grok द्वारा CSAM या revenge porn जैसे illegal material बनाने की समस्या में बहुत दिलचस्पी नहीं है, इसलिए यह अजीब लगता है कि शायद वे अच्छी चीज़ों की ownership लेना चाहती हैं लेकिन बुरी ज़िम्मेदारियों से बचना चाहती हैं

  • companies के नज़रिए से यह काफ़ी चालाक approach लगता है
    पहले claude code से बनाओ, और उसके बाद सोचो कि वह code आखिर किसका है
    अभी आसपास जो gold rush चल रहा है, वह management की short-sightedness दिखाता है। हमारी company में EMs भी अधिक से अधिक जल्दी Claude इस्तेमाल करने के लिए push कर रहे हैं
    पहला, Claude Code पर बहुत ज़्यादा निर्भर होने से codebase की समझ कम हो जाती है
    दूसरा, XP या code review जैसी अच्छी development habits टूट जाती हैं। अब तो Claude, Claude के code का review कर रहा है
    तीसरा, team work खराब होता है। पहले जो काम FE team और BE team में बंटा था, वह अब एक developer के लिए backend से frontend तक सब कुछ खुद संभालना आसान और सस्ता बना देता है
    चौथा, पहले कहा जाता था कि code ही documentation है, इसलिए comments को नज़रअंदाज़ किया जाता था; लेकिन अब context limits की वजह से Claude के लिए फिर से explanations लिखनी पड़ती हैं। जब इंसान समझ न पाए तो गलती उसी की मानी जाती थी, लेकिन Claude के संकुचित context के लिए अचानक इस regression को स्वीकार करना अनुचित लगता है
    और भी बहुत कुछ कह सकता हूँ, लेकिन इस सांस्कृतिक बदलाव की driving force आखिरकार पैसा ही है। इसलिए मैं इसे goldrush कहता हूँ और popcorn लेकर देख रहा हूँ

    • लगता है लोग बहुत जल्दी भूल गए
      जब Copilot पहली बार आया था, तब license attribution issues की वजह से साफ़ चेतावनी दी जाती थी कि इसे company code में इस्तेमाल न करें
      अब क्या बदल गया। क्या Anthropic का legal defense और indemnify देने का वादा माहौल बदलने के लिए काफ़ी था
    • बाकी बातों से मैं मोटे तौर पर सहमत हूँ, लेकिन FE और BE को एक ही व्यक्ति द्वारा साथ में design करना कई बार मूल रूप से बेहतर होता है
      backend और frontend को एक-दूसरे के अनुरूप design होना चाहिए, इसलिए अगर teams अलग हों तो coordination cost और बढ़ सकती है
    • लंबी अवधि में गलत abstractions लाना बहुत आसान लगता है
      अगर इंसानों के दिमाग़ के models धीरे-धीरे भूखे रहकर खत्म होने लगें, तो outage होने पर यह ज़िम्मेदारी से समझाना भी मुश्किल होगा कि system कैसे काम करता है और आगे की योजना क्या है
      भले ही गलत generalizations आ जाएँ, AI code, review, और approval सब पार करा सकते हैं; तब समझ नहीं आता कि वास्तव में steering wheel किसके हाथ में है
    • #3 शायद ही कभी बेहतर नतीजा देता है
      आम तौर पर requirements और pitfalls पर team को साथ चर्चा करनी चाहिए, लेकिन implementation की ज़िम्मेदारी एक ही व्यक्ति के पास होना बेहतर लगता है

  • EU AI Act इसमें एक और परत जोड़ता है
    Article 50 कहता है कि AI द्वारा generated या manipulated content को end users के सामने disclose किया जाए, और यह transparency obligation model provider पर नहीं बल्कि deployer पर लागू होती है
    इसलिए भले copyright सवाल human prompter के पक्ष में सुलझ जाए, AI-assisted outputs को बड़े पैमाने पर distribute करने वाली companies पर अलग disclosure duty फिर भी रहेगी
    ज़्यादातर लोग अभी यह ठीक से नहीं कर रहे हैं
    ownership और disclosure obligations एक-दूसरे से स्वतंत्र हैं, लेकिन organizations अक्सर दोनों को मिला देती हैं

    • लेकिन क्या code content है
      यह provision internal application code से ज़्यादा उस तरह की चीज़ों के लिए उपयुक्त लगता है जैसे ऐसे videos जो AI ने बनाए हों और जिन्हें वास्तविक जैसा दिखाया जा रहा हो

  • अगर आपने किसी tool को अपने मनचाहे code की specification दे दी, तो यह साफ़ तौर पर creative input देना माना जाना चाहिए
    आखिर compiler भी कुछ ऐसा ही नहीं करता। LLM agent पारंपरिक compiler की तुलना में कहीं अधिक उन्नत tool है, जो कहीं कम detailed specification से भी output दे देता है

    • लेकिन courts ने बार-बार यह नहीं माना कि किसी human contractor को desired code की specification देना copyright के लिहाज़ से creative input है
      उस code की ownership पाने के लिए contractor से rights का explicit assignment चाहिए होता था
    • specification हमेशा creative input नहीं होती
      उदाहरण के लिए, अगर मैं सिर्फ यह prompt दूँ कि "Python में rate limiter लिखो", तो न API मैंने तय की, न request bucket algorithm, न counter कहाँ store होगा
      मैंने केवल facts बताए, और facts अपने-आप में creative नहीं होते
      compiler भी अलग है क्योंकि उसके output binary को अलग work नहीं माना जाता। यह वैसा ही है जैसे image format को PDF में बदलना—work वही रहता है
      लेकिन LLM ऐसा नहीं है। input copyright योग्य न भी हो सकता है, और output सिर्फ mechanical transformation नहीं बल्कि choices का परिणाम होता है
      व्यवहार में भी, same prompt को 10 बार चलाएँ तो 10 अर्थपूर्ण रूप से अलग outputs मिल सकते हैं
      इसलिए मुझे संदेह है कि किसी भी स्तर की prompting को पर्याप्त creativity माना जाएगा
    • compiler analogy शुरुआत के लिए ठीक है, लेकिन Copyright Office ने भी इस पर सीधे बात की है
      मुद्दा यह नहीं कि आपने input दिया या नहीं, बल्कि यह कि output की creative expression human authorship को reflect करती है या नहीं
      पारंपरिक compiler में programmer source की हर expression का author होता है, लेकिन LLM में programmer सिर्फ intent देता है, जबकि structure, naming, patterns, और implementation जैसी expressive choices model करता है
      कानूनी रूप से यह अंतर कितना महत्वपूर्ण है, यही Allen v. Perlmutter में फिलहाल विवाद का विषय है, और 2026 की शुरुआत में summary judgment briefing भी पूरी हो चुकी है, इसलिए अगला milestone decision वही हो सकता है
    • मुझे यह आखिरकार compiler द्वारा बनाए गए binary की ownership पूछने जैसा लगता है

  • यह सब सिद्धांत के स्तर पर दिलचस्प है, लेकिन व्यवहार में शायद ज़्यादा महत्वपूर्ण नहीं है
    लगभग कोई भी गंभीरता से यह नहीं मानता कि उसका code ही उसका मज़बूत moat है, और copyrightable होने का एहसास भी field में कमज़ोर है
    मैंने भी कई employers के तहत एक जैसे code fragments बार-बार लिखे हैं, और शायद अधिकांश engineers ने ऐसा किया होगा। Stack Overflow जैसी जगहों से लिया गया code भी लोग अक्सर attribution को बहुत सख्ती से देखे बिना इस्तेमाल कर लेते हैं
    यह मुद्दा आमतौर पर तब सामने आता है जब कोई दुर्भावनापूर्ण लड़ाई शुरू होती है। उदाहरण के लिए Oracle ने Android पर यह कहते हुए Google पर मुक़दमा किया कि उसने उसकी API की बहुत मिलती-जुलती नकल की, और Supreme Court ने अंततः उसे fair use माना
    high-frequency hedge funds ने resign करने वाले कर्मचारियों पर मुक़दमे किए हैं, और U.S. में कोई भी किसी भी वजह से मुक़दमा कर सकता है
    इसलिए Ellison द्वारा Page और Brin के खिलाफ Supreme Court तक जाने जैसी लड़ाइयाँ संभव हैं, लेकिन 99.9% मामलों में इसका ज़मीनी स्तर पर असर नहीं पड़ता, ऐसा मुझे लगता है
    https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf

    • non-technical executives की तरफ़ जाएँ तो सोच आश्चर्यजनक रूप से अलग होती है
      बहुत से लोग code को बेहद मूल्यवान IP और trade secret मानते हैं
      CTO के रूप में जब मैं कहता हूँ कि "आम तौर पर code उतना बड़ा secret नहीं होता", तो अक्सर लोगों के चेहरों पर shock दिखता है
      एक company तो NDA के तहत source code disclosure मांगने वाले बड़े contract से लगभग पीछे हट गई थी, लेकिन जब समझाया कि यह overreaction क्यों है, तो उन्हें बात समझ आई
      फिर भी यह पुरानी सोच अब भी काफ़ी मज़बूती से बनी हुई है
    • यह अजीब है कि कोई convergence की बात नहीं कर रहा
      हम अभी ठीक उसी convergence की बात कर रहे हैं: अगर लिखे जाने वाले code का हर character आवश्यक APIs द्वारा लगभग पहले से तय है, तो उसमें न artistic expression बचती है न copyright
      लेकिन अगर आप पूरी तरह नया API design करते हैं, तो वह हिस्सा सुरक्षित हो सकता है
    • सभी open source licenses इस धारणा पर आधारित हैं कि code copyright योग्य है
    • "code copyright योग्य नहीं है" यह विचार मुझे काफ़ी असामान्य लगता है
      जो छोटे snippets तुमने गिनाए वे शायद न हों, लेकिन बड़े स्तर पर companies और individuals दोनों आम तौर पर मानते हैं कि code copyright law के तहत intellectual property है
      अगर code copyright योग्य नहीं है, तो GPL को ताकत कहाँ से मिलती है
      उदाहरण के लिए, सिर्फ इस शक से कि Microsoft code शायद ReactOS में मिल गया हो, किसी project को महीनों या सालों तक locked-down review mode में क्यों जाना पड़ता है
      employment contracts में companies code copyright ownership को स्पष्ट रूप से क्यों लिखती हैं
      बल्कि APIs, interoperability, या अत्यंत तुच्छ implementations को छोड़ दें, तो लगभग सभी लोग code की copyrightability को स्वीकार करते हैं
    • अगर ऐसा नहीं है, तो फिर clean room implementation की ज़रूरत क्यों पड़ती
      emulator developers या ReactOS developers से पूछ लीजिए
      https://reactos.org/forum/viewtopic.php?t=21740

  • "Claude Code या Cursor ने generate किया और आपने उसे meaningful तरीके से modify नहीं किया, तो उस code पर शायद किसी का copyright न हो" — इस बात के भी अपवाद हैं
    अगर उस code ने किसी मौजूदा work के substantial excerpts को लगभग ज्यों-का-त्यों दोहरा दिया, तो मूल author अब भी अपना copyright दावा कर सकता है, और मामला तुरंत infringement तक पहुँच सकता है