Google ने कुछ Android स्रोत कोड के लिए Git टैग पुश करना बंद कर दिया है

मूल लेख ↗ Hacker News चर्चा ↗

Google ने कुछ Android और Pixel kernel स्रोतों को सार्वजनिक Git टैग्स के माध्यम से प्रकाशित करना बंद कर दिया है और अब developers को Google Form के जरिए tarballs request करने होते हैं, जिन्हें फिर दिनों या हफ्तों की देरी के बाद Google Drive से दिया जाता है। Commenters इस पर बहस कर रहे हैं कि क्या यह GPLv2 की भाषा को पूरा करता है, जबकि उसके उद्देश्य को स्पष्ट रूप से कमजोर करता है; उनका कहना है कि समय पर, git-native source को रोकना custom ROMs जैसे downstream projects के लिए changes को track करना और security updates जारी करना कठिन बना देता है। कई लोग इसे Android के कम खुले और अधिक tightly controlled होने की व्यापक प्रवृत्ति का हिस्सा मानते हैं, साथ ही sideloading और third-party ecosystems पर आने वाली पाबंदियों के संदर्भ में भी।

Google के स्रोत वितरण में क्या बदला

  • Google ने AOSP में कुछ Android-संबंधित Git टैग (खासकर Pixel-विशिष्ट कोड के लिए) प्रकाशित करना बंद कर दिया है।
  • Pixel kernel drivers और अन्य GPL/LGPL घटकों के लिए, स्रोत अब Google Drive पर tarballs के रूप में दिया जाता है, जिसे केवल Google Form सबमिट करने के बाद ही प्राप्त किया जा सकता है।
  • पहले, टैग नियमित रूप से पुश किए जाते थे और tarballs (जब उपयोग होते) आम तौर पर कुछ घंटों के भीतर उपलब्ध हो जाते थे; अब जवाब अक्सर हफ्तों लेते हैं।
  • नए tarballs monolithic हैं, जिनमें squashed history और अतिरिक्त repo metadata है, बजाय कई Git repos की मूल संरचना के।

GPL अनुपालन बनाम “Malicious Compliance”

  • एक पक्ष का तर्क है कि Google स्पष्ट रूप से GPLv2 का उल्लंघन कर रहा है:
    • कई हफ्तों की देरी Google की क्षमताओं को देखते हुए “reasonable time” नहीं है।
    • स्रोत “preferred form for making modifications” में नहीं है, क्योंकि Android का build system कई Git repos की अपेक्षा करता है और Git commands चलाता है; केवल tarball वाली form errors पैदा करती है।
  • अन्य लोग तर्क देते हैं कि यह संभवतः तकनीकी रूप से compliant है:
    • GPLv2 source-on-request और यहां तक कि physical media की अनुमति देता है, लेकिन कोई स्पष्ट time limit नहीं है।
    • ऐतिहासिक रूप से, full VCS history के बिना snapshots स्वीकार किए गए हैं।
    • Google Drive + manual process को hostile माना जा रहा है, लेकिन license की literal भाषा के भीतर।
  • इस पर असहमति है कि क्या “medium customarily used for software interchange” Google Drive को बाहर कर सकता है या timing expectations लागू कर सकता है।

Downstream Projects और Ecosystem पर प्रभाव

  • Pixels को target करने वाले custom OS projects को वास्तविक नुकसान रिपोर्ट हुआ है: kernel sources में देरी stable और beta releases के लिए समय पर support को रोकती है।
  • Pixels को लंबे support windows वाले AOSP reference devices के रूप में marketed किया गया था; कुछ लोगों का तर्क है कि Pixel-specific AOSP releases को छोड़ना उन commitments को कमजोर करता है।
  • यह friction Pixels को third-party ROMs के लिए आसान नहीं, बल्कि कठिन बनाता है, और उन्हें दूसरे vendors (जैसे Motorola) की ओर धकेलता है।

माना गए इरादे और व्यापक चिंताएँ

  • अनुमानित motives में शामिल हैं:
    • Android ecosystem और third-party ROMs पर अधिक नियंत्रण बढ़ाना।
    • security patches और vulnerabilities के analysis को धीमा करना।
    • sideloading और developer verification को सख्त करने जैसे broader moves के साथ alignment।
  • कई लोग इस बदलाव को एक trend का हिस्सा मानते हैं: Android का “open” से अधिक बंद, iOS-like model की ओर drift करना, भले ही core AOSP open source बना रहे।