Flathub, LLM-आधारित submissions की अनुमति नहीं देगा

• Flathub submission review में LLM-आधारित low-quality submissions बढ़ने से volunteer reviewers पर बोझ बढ़ा, और यही policy को स्पष्ट करने की पृष्ठभूमि बना
• अपवादों की संभावना उन projects पर अधिक है जिनमें community participation, release cadence, CI, और कम समय में बने low-effort नतीजों से अलग होने के संकेत मौजूद हों
• मौजूदा development history और project health के मानदंडों से भी review workload कम नहीं हुआ, बल्कि नियमों की व्याख्या को लेकर विवाद बढ़े
• नई policy का उद्देश्य LLM का आंशिक उपयोग करने वाले mature FOSS apps या मौजूदा proprietary apps पर पूर्ण प्रतिबंध लगाना नहीं, बल्कि low-effort submissions को रोकना है
• कुछ लोगों ने Flatpak ecosystem में distribution fragmentation फिर लौटने और कंपनियों द्वारा Flathub से बचने की आशंका जताई, और पूर्ण प्रतिबंध की बजाय fee लगाने का सुझाव दिया

---

Flathub की LLM submission policy में बदलाव

• Flathub submission review में LLM-आधारित low-quality submissions बढ़ने से volunteer reviewers पर बोझ बढ़ना policy change की मुख्य पृष्ठभूमि है
• Sjoerd Stendahl का कहना है कि Flathub PR सूची में “AI-slop” submissions बहुत थीं, और उनके पैमाने को देखते हुए यह कदम बेहतर विकल्प हो सकता है
• Bart Piotrowski ने कहा कि अगर किसी project में community participation, release cadence, CI, और कम समय में बनाए गए low-quality output से अलग होने के संकेत हैं, तो उसके लिए अपवाद की संभावना अधिक है
• पहले भी पर्याप्त development history और समग्र project health के आधार पर low-quality submissions को रोकने की कोशिश हुई थी, लेकिन review workload कम नहीं हुआ और नियमों की व्याख्या को लेकर विवाद ही पैदा हुए

अपवाद और maturity मानदंड

• Nexi के अनुसार low-effort Flathub submissions की समस्या वास्तविक है, लेकिन AI-generated या AI-assisted code पर एकमुश्त प्रतिबंध बहुत कठोर होगा
• उनका सुझाव है कि अगर Firefox, VSCode, Chromium जैसे मौजूदा projects भी बिना किसी अपवाद के हटाने की ज़द में आ सकते हैं, तो low-quality submissions को छाँटने के लिए objective project maturity metrics अधिक उपयुक्त होंगे
• Bart Piotrowski ने जवाब दिया कि maturity criteria व्यवहार में पहले से मौजूद थे, लेकिन अंततः उनसे review burden कम नहीं हुआ
• Nexi का मानना है कि policy में अपवाद के मानदंड साफ़ तौर पर शामिल किए जा सकते हैं, और यह भी जोड़ा जा सकता है कि यदि code quality बहुत खराब हो तो बिना अतिरिक्त स्पष्टीकरण के reject किया जा सकता है
• Sjoerd Stendahl का मानना है कि नई policy mature और अच्छी तरह maintained projects के लिए अपवाद रखती है, और यह LLM का आंशिक उपयोग करने वाले verified FOSS applications या मौजूदा proprietary applications पर पूर्ण प्रतिबंध नहीं है

ecosystem पर असर और distribution paths को लेकर चिंता

• Dmitry Mantis ने चिंता जताई कि यह policy Linux distribution fragmentation को फिर से पैदा कर सकती है, जिसे Flatpak हल करना चाहता है
• उनका कहना है कि Slack और Spotify जैसे proprietary apps का Flathub पर sandboxed रूप में उपलब्ध होना एक फायदा है, और यह सवाल भी उठता है कि क्या closed-source code को इस वजह से उल्टा लाभ मिलेगा कि उसके लिखे जाने का तरीका पता ही नहीं चलता
• यह तर्क भी सामने आया कि नए और कम-ज्ञात developers के proprietary applications को इस policy के बिना भी Flathub पर तुरंत publish नहीं करना चाहिए
• कुछ apps का केवल AppImage पर निर्भर रहने से आगे बढ़कर official Flatpak support देना सकारात्मक रुझान है, लेकिन चिंता यह है कि ऐसी policies के बाद कंपनियाँ Flathub में आने से बच सकती हैं
• AI-based submissions पर review cost पूरी करने के लिए fee लगाने का सुझाव भी दिया गया, जिसे पूर्ण प्रतिबंध से बेहतर माना गया
• यह एक संकेत भी बन सकता है कि एक निश्चित स्तर के users मिलने से पहले कहीं और distribute करो; और यदि testing या documentation automation के कुछ हिस्सों में LLM का उपयोग करने वाले well-maintained apps किसी दूसरे distribution path पर टिक जाते हैं, तो Flathub पर आने की उनकी प्रेरणा कम हो सकती है

LLM tools को लेकर परस्पर विरोधी आकलन

• Thomas Fuchs का मानना है कि LLM की समस्या तकनीक से ज़्यादा लोगों और marketing की समस्या है
• उन्होंने कहा कि LLM कंपनियाँ इसे जादू या निजी कामकाजी गुलाम की तरह बेचती हैं, और समस्या यह है कि उपयोगकर्ता इन दावों पर वैसा ही भरोसा कर लेते हैं
• उनके अनुसार, अगर कोई skilled user इसकी strengths और weaknesses समझकर सीमित उपयोग में लगाए तो यह शानदार tool हो सकता है, लेकिन industry इसे “जलती हुई chainsaw को juggling के लिए मुफ्त बाँटने” जैसी आक्रामक शैली में promote कर रही है
• Wolkensteine का कहना है कि LLM पूरी तरह बेकार नहीं हैं, लेकिन अधिकांश मामलों में उपयोगी नहीं हैं, और नैतिक रूप से समर्थन योग्य तरीके से बना कोई वास्तव में उपयोगी model अभी नहीं है
• उनका मानना है कि on-device models spell-check या phone keyboard autocorrect में word prediction के लिए मददगार हो सकते हैं, लेकिन जिन कामों को वे बिना गलती कर सकते हैं, वे आम तौर पर इंसान आसानी से कर सकता है और उनसे सीख भी सकता है
• Ember का कहना है कि ऐसे संभावित उपयोग generative AI से पहले के tools से भी संभव थे, और दुर्लभ मामलों में किसी खास data पर trained specialized ML अधिक बेहतर हो सकता है
• Kroc Camen ने तर्क दिया कि code theft, अंतर्निहित bias, और environmental impact की वजह से LLM का कहीं भी कोई वैध उपयोग नहीं है

community culture और बहस का ध्रुवीकरण

• trisweb का मानना है कि LLM-generated code और उसके उपयोगकर्ताओं के आसपास बनी संस्कृति अक्सर उस विनम्र और सहयोगी दृष्टिकोण से मेल नहीं खाती, जो open source community को बनाए रखने के लिए ज़रूरी है
• ragectl ने कहा कि नए apps के लिए cooling-off period जैसी सोच की ज़रूरत हो सकती है, और कई releases तथा दूसरे human contributor के आने तक वे जोखिमपूर्ण हो सकते हैं
• Sjoerd Stendahl का कहना है कि witch hunt से बचना चाहिए, लेकिन big tech द्वारा LLM को आक्रामक ढंग से आगे बढ़ाने से लोगों की प्रतिक्रिया और तेज़ हुई है
• उन्होंने यह भी कहा कि कुछ employers छँटनी की धमकी के साथ काम में LLM इस्तेमाल करने को मजबूर करते हैं, search जैसी साधारण सुविधाएँ भी बिगड़ गई हैं, और “Agentic future” बहुत सीमित मांग होने के बावजूद कई products इंसानी काम की नकल करते अवशेष जैसे बनते जा रहे हैं
• razze का मानना है कि search या chatbot में LLM के उपयोग की समस्या और code में उसके उपयोग की समस्या अलग-अलग हैं; code को साबित किया जा सकता है और trade-offs भी स्पष्ट होते हैं, इसलिए उसका अलग आकलन होना चाहिए
• Zeeshan Ali Khan ने anti-LLM पक्ष की आक्रामकता की ओर इशारा किया, और Bart Piotrowski ने जवाब दिया कि pro-LLM और anti-LLM दोनों ओर ध्रुवीकरण बहुत बढ़ गया है, और “vibecoders” भी आलोचना होने पर खुद को पीड़ित की तरह पेश करते हैं

[GN⁺]

Lobste.rs की राय

• "AI द्वारा जनरेट किए गए या उसकी सहायता से बनाए गए code, docs, या अन्य content वाले applications की अनुमति नहीं है" — यह काफ़ी सख़्त लगता है
  Flathub Linux desktop users के लिए apps पाने की बहुत लोकप्रिय जगह है, खुद को "Linux के लिए app store" कहता है, और वहाँ 1000 से ज़्यादा apps हैं
  क्या इसका सचमुच मतलब है कि उन apps में से कोई भी AI-assisted code इस्तेमाल नहीं कर सकता? क्या यह व्यावहारिक है? क्या अब बहुत देर नहीं हो चुकी?

  • "mature और well-maintained projects के लिए exceptions की अनुमति हो सकती है" इस पंक्ति को देखकर लगता है कि असली इरादा पूरी तरह vibe coding से बनाए गए projects को अपलोड करके छोड़ देने से रोकना है
  • कभी भी बहुत देर नहीं होती
    जो projects पहले से FlatHub पर हैं, अगर वे vibe coded निकले तो उन्हें हटाया जा सकता है, और एक स्पष्ट संदेश भी भेजा जा सकता है
  • लगता है इस rule को discretion के साथ लागू किया जाएगा
    कुछ मौजूदा प्रमुख applications को exception माना जा सकता है, और ऐसे मामलों में भी यह सीमा app के अपने code से ज़्यादा अलग flatpak packaging पर लागू होने की संभावना है

• यह सख़्त रुख़ 100% enforceable न भी हो, फिर भी जब कंपनियाँ LLM adoption को ज़बरदस्ती आगे बढ़ा रही हैं, तब community की तरफ़ से संभव न्यूनतम प्रतिरोध के रूप में ऐसा मज़बूत रुख़ ज़रूरी है

• हाल की supply chain घटनाओं को देखते हुए, यह काफ़ी उचित फ़ैसला लगता है

• कोई project LLM पर ban लगाए, या सफ़ेद बालों वाले लोगों पर, या ठीक 160cm लंबे लोगों पर — अपनी मरज़ी से rules तय करने की उसकी आज़ादी का मैं 100% समर्थन करता हूँ
  इसका मतलब यह नहीं कि मैं उस आज़ादी को सीमित करना चाहता हूँ, लेकिन package management ऐसा बेहद सामान्य दोहराव वाला काम है जहाँ LLM की मदद बहुत काम आ सकती है
  जो लोग अपने code को pure art या craftsmanship का नतीजा मानते हैं, उनकी बात कुछ हद तक समझ में आती है, लेकिन सबसे उबाऊ कामों को automate होने से रोकने की वजह क्या है?

  मुझे याद है जब Arch Linux का AUR शुरू हुए ज़्यादा समय नहीं हुआ था, तब कुछ लोग सैकड़ों packages को सफलतापूर्वक maintain कर रहे थे
  वे हमेशा up to date रहते थे और लगभग कभी टूटते नहीं थे, तो साफ़ है कि वे updates को automate कर रहे होंगे
  आज अगर वही काम LLM assistance के साथ किया जाए, तो वह लगभग निश्चित रूप से और मज़बूत हो सकता है

  शायद इस प्रक्रिया में इंसानों पर ही ban लगा देना चाहिए
  supply chain attacks के अलावा इंसान और क्या योगदान देते हैं? कभी न कभी मुझे अपना खुद का LLM distro बनाकर साबित करना चाहिए कि मेरी बात सही है या ग़लत
  उससे पहले मुझे यह programming language ख़त्म करनी होगी, हाहा