अमेरिकी एजेंसियों के बीच source code sharing अनिवार्य करने वाला बिल कानून बना

 (fedscoop.com)
1 पॉइंट द्वारा GN⁺ 2024-12-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • राष्ट्रपति Joe Biden ने 23 दिसंबर को SHARE IT Act पर हस्ताक्षर किए, जिसके बाद अमेरिकी संघीय एजेंसियों को duplicate development contracts कम करने के लिए custom source code आपस में share करना होगा
  • संघीय सरकार द्वारा हर साल software खरीद पर खर्च होने वाले अनुमानित लगभग $12 अरब को घटाने के लिए, एजेंसी-विशिष्ट custom code को सार्वजनिक रूप से सूचीबद्ध करना और reuse के लिए उपलब्ध कराना इसका मुख्य उद्देश्य है
  • कानून के दायरे से confidential code, national security systems, और ऐसा code बाहर रखा गया है जिसे share करने पर privacy risk हो सकता है
  • agency CIO को लागू होने के 180 दिनों के भीतर implementation policy बनानी होगी, जिसमें best practices का पालन, metadata का public disclosure, और standardized reporting procedures शामिल हों
  • Atlassian और GitLab Inc. ने बिल का समर्थन किया, और यह बिल दिसंबर में Senate और House से recorded vote के बिना पारित हुआ

SHARE IT Act के तहत code sharing की अनिवार्यता

  • Source Code Harmonization And Reuse in Information Technology Act या SHARE IT Act संघीय एजेंसियों से मांग करता है कि वे custom-developed source code अन्य एजेंसियों के साथ share करें
  • इसका focus ऐसे duplicate development को कम करना है जिसमें किसी दूसरी एजेंसी के लिए पहले से विकसित code की जानकारी न होने पर फिर से contract करके वही चीज बनवाई जाती है
  • एजेंसियों को custom code को सार्वजनिक रूप से सूचीबद्ध करना होगा और अन्य एजेंसियों को उस code का उपयोग करने में सक्षम बनाना होगा

बजट बचत का लक्ष्य और लागू होने की छूट

  • बिल के sponsors का अनुमान है कि संघीय सरकार हर साल software खरीद पर लगभग $12 अरब खर्च करती है
  • SHARE IT Act custom code reuse के जरिए इस लागत को घटाने के लिए बनाया गया कानून है
  • निम्न code कानून के दायरे से बाहर रहेंगे
    • confidential code
    • national security systems
    • ऐसा code जिसे share करने पर privacy risk पैदा हो सकता है

agency CIO पर 180 दिनों के भीतर policy बनाने की जिम्मेदारी

  • agency chief information officer (CIO) को कानून लागू होने के 180 दिनों के भीतर SHARE IT Act implementation policy बनानी होगी
  • policy में ये procedures शामिल होने चाहिए
    • यह सुनिश्चित करने की प्रक्रिया कि custom-developed code best practices के अनुरूप हो
    • custom code के metadata को सार्वजनिक रूप से उपलब्ध कराने की प्रक्रिया
    • standardized reporting procedures

सार्वजनिक किए जाने वाला metadata

  • कानून में उल्लेखित metadata में ऐसी जानकारी शामिल है जिससे custom code के development और sharing status की पुष्टि की जा सके
  • शामिल items इस प्रकार हैं
    • custom code contract के तहत विकसित हुआ या नहीं
    • code repository में share किया गया या नहीं
    • contract number
    • जिस repository में code share किया गया है, उसका hyperlink

legislative progress और industry support

  • Senate में बिल को Ted Cruz और Gary Peters ने, और House में Nicholas Langworthy और William Timmons ने sponsor किया
  • Senate और House ने दिसंबर में recorded yes/no vote के बिना बिल पारित किया
  • Langworthy की सितंबर में House introduction announcement के अनुसार Atlassian और GitLab Inc. ने बिल का समर्थन किया
  • Atlassian के chief legal officer Stan Shepard का मानना है कि custom code पर collaboration और sharing का विस्तार संघीय संगठनों में openness, efficiency और innovation को बढ़ावा देता है

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

1 टिप्पणियां

 
GN⁺ 2024-12-27
Hacker News की राय

  • अगर आपके पास सरकारी अनुभव नहीं है, तो शायद आपको अंदाजा न हो कि यह इतना मुश्किल क्यों है। सेना को internal software से एलर्जी है, और सैन्य IT एक बिल्कुल अलग दुनिया है, जिस पर हर दिन दुनिया के सबसे उच्च-स्तरीय, राष्ट्र-समर्थित घुसपैठिए हमला करते हैं
    स्टार्टअप्स को ऐसी चीजों से नहीं गुजरना पड़ता, और Facebook जैसी बड़ी कंपनियां भी महत्व के लिहाज से बस मुश्किल से इसी तरह के स्तर का अनुभव करती हैं; निजी क्षेत्र में इसके सबसे करीब अगर कुछ है तो बड़े वित्तीय संस्थान हैं। अमेरिकी सेना धरती पर सबसे बड़ा single employer भी है, यानी करीब 4.5 Walmart के बराबर
    इसलिए सेना कई layers पर हर चीज की निगरानी करती है, और layer-wise approved software lists के जरिए सब कुछ कड़ाई से lock down रखती है। security policies लिखने या निगरानी करने वाले लोग संभवतः अनुभवी software directors नहीं होते, और वे NPM या Maven को ऐसे असीमित attack vectors के रूप में देखते हैं जिन्हें security न समझने वालों ने बनाया है—और यह पूरी तरह गलत भी नहीं है
    civilian और contractor क्षेत्रों में code ownership भी जटिल है। अगर सरकारी पैसे से बनाया गया है तो वह सरकार के स्वामित्व में होना चाहिए, लेकिन contractors इसे सरकार से अलग अपनी asset के रूप में रखना चाहते हैं ताकि दोबारा charge कर सकें। अगर subcontractor के लक्ष्य prime contractor के financial goals से मेल न खाएं तो बात और जटिल हो जाती है। निजी तौर पर मुझे लगता है कि सब कुछ सरकार को सौंप देना चाहिए, लेकिन लोगों का परत-दर-परत दीवारें खड़ी करना अजीब है। government-side infrastructure का security certification level कहीं ज्यादा ऊंचा होता है, इसलिए आम तौर पर constraints भी कम होते हैं

    • सैन्य IT को लगभग अभेद्य किले की तरह दिखाना इस वास्तविकता को नजरअंदाज करता है कि पुराना infrastructure और सुस्त policies efficiency को बहुत कम कर देती हैं
      अमेरिकी सेना के कुछ हिस्से बताए गए स्तर के threats और security sophistication का सामना करते होंगे, लेकिन कुल मिलाकर उसमें बहुत सारे legacy systems हैं जिनमें modern solutions या best practices को integrate करना मुश्किल है। ऐसे पुराने systems, workflows और bureaucracy अक्सर बेहतरीन security की बजाय inefficiency और vulnerabilities पैदा करते हैं
      हमें अमेरिकी सेना के breach होने की खबरें इसलिए नहीं सुनाई देतीं कि ऐसा होता नहीं, बल्कि इसलिए कि होने पर उन्हें classified कर दिया जाता है। public embarrassment से बचना classification का नंबर-1 उपयोग है, जिससे competence में विश्वास पैदा होता है। मैं तो कभी भी Facebook security को अमेरिकी सेना से ऊपर रखूंगा, और मुझे लगता है कि अंतर भी छोटा नहीं है। Facebook एक payment processor भी है
    • “Facebook जैसी बड़ी कंपनियां महत्वपूर्ण नहीं हैं, इसलिए वे बस मुश्किल से similar चीजों का सामना करती हैं” — इस बात से सहमत होना मुश्किल है। जब मैं Microsoft में काम करता था और security team से बात की, तो मेरा impression था कि MSFT पर लगातार nation-state attacks हो रहे थे, यहां तक कि government assets को Microsoft में नौकरी दिलाकर secrets निकालने की कोशिशें भी शामिल थीं
      AWS के महत्व को देखते हुए Amazon भी निश्चित रूप से इसी तरह के threats झेल रहा होगा
    • मुझे लगता है इस bill का सेना से बहुत कम लेना-देना है। वास्तविक bill में कहा गया है कि classified source code या national security systems के लिए source code इसके दायरे में नहीं आता
      (A) सामान्य प्रावधान—यह कानून classified source code या 40 U.S.C. 11103 में परिभाषित national security system में मुख्य रूप से उपयोग के लिए विकसित source code पर लागू नहीं होगा
      (B) national security—धारा 3 की requirements से छूट classified source code या निम्न source code पर लागू होगी: (i) national security system में मुख्य रूप से उपयोग के लिए विकसित code, या (ii) 1947 के National Security Act की धारा 3(4) में परिभाषित intelligence community की किसी constituent agency या उसके किसी हिस्से द्वारा विकसित code
    • मैंने एक साल तक अपने department की security team, customer department के आसपास, regional contractor network और कई vendors से बात की, फिर जब पता चला कि किसी दूसरी military branch ने मेरे project जैसी ही चीज कई साल पहले पूरी कर ली थी, और “आप उनसे बात क्यों नहीं कर लेते?” कहने पर government customer बस खाली नजरों से देखता रहा, तो मैंने contracting का काम छोड़ दिया
      तभी मुझे समझ आया कि government contracting का धंधा किस ढांचे पर चलता है, और क्यों काम जरूरत से ज्यादा कई साल तक खिंचता है
    • “सब कुछ सरकार को सौंप देना चाहिए” वाली सोच से मैं सहमत हूं। मैंने सचमुच एक ऐसे contractor के लिए काम किया है जहां customer सभी deliverables का मालिक होता था, और जो साथी ऐसे contractors में काम करते थे जहां ऐसा नहीं था, उन्हें देखकर हमेशा अजीब लगता था
      यह हमारे taxes से दिया गया पैसा है, तो हम सबकी जेब से पैसा निकालकर किसी कंपनी के कुछ बड़े लोगों और sales staff को बहुत अमीर बनाने वाली व्यवस्था का समर्थन क्यों करें?
      अगर रुख यह है कि “सरकार को सब कुछ नहीं देंगे,” तो मेरे हिसाब से तार्किक तरीका यह होगा कि सरकार को deliverables को अपनी जरूरत के अनुसार इस्तेमाल करने का अधिकार दिया जाए, लेकिन non-classified components और उनके derivatives को private sector में स्वतंत्र रूप से बेचने की अनुमति रहे

  • कानून के मुताबिक एजेंसी CIO को लागू होने के 180 दिनों के भीतर नीति बनानी होगी, और वह नीति यह सुनिश्चित करेगी कि custom-developed code best practices के अनुरूप हो, साथ ही custom code के metadata को सार्वजनिक करने की प्रक्रिया और standard reporting procedures तय करेगी
    नए कानून में metadata में यह शामिल है कि custom code contract के तहत विकसित हुआ था या नहीं, repository में share किया गया था या नहीं, contract number, और वह repository link जहाँ code share किया गया है
    अफसोस की बात है कि यह कानून एजेंसी को code को public open source बनाने के लिए बाध्य नहीं करता, बल्कि लगता है कि केवल एजेंसियों के बीच sharing की मांग करता है। सार्वजनिक रूप से share करने की चीज़ सिर्फ “metadata” है। बिल का पूरा पाठ https://www.congress.gov/bill/118th-congress/house-bill/9566... पर है

    • यह एक अच्छा पहला कदम है। अगला चरण शायद state governments, local governments और universities के साथ share करना होगा। Public sharing अभी मौजूद नहीं कई IT responsibilities को distribute कर देगी
    • सिर्फ पोस्ट किए गए title से भी इतना तो काफी स्पष्ट लगता है
    • “best practices” शब्द आते ही पहले शक होता है। क्योंकि इससे bureaucratic cargo cult को और बढ़ावा मिलने की संभावना ज्यादा होती है
    • अधिकांश DOE contracts, यानी वे contracts जो सरकार labs चलाने वाली universities या consortiums के साथ करती है, आम तौर पर कुछ ऐसा कहते हैं: “अगर यह साबित नहीं किया जा सकता कि इस source code की marketability या SBIR value है, तो इसे private रखा जा सकता है या open source के रूप में जारी किया जा सकता है। लेकिन GPL नहीं”
      exceptions हैं, लेकिन यह तर्क भी था कि दूसरे contractors को भी source code में बदलाव करने और उसे उसी तरह public न करने की क्षमता बनाए रखनी चाहिए। शायद defense क्षेत्र की वजह से, ऐसा अनुमान है
      पैसे के कारण private रखने के लिए standard ऊँचा था, लेकिन किसी भी अन्य वजह से private रखना हमेशा संभव था। DOE Code open source software को track करने वाला program है और आम तौर पर GitHub organization के जरिए manage होता है। OSTI वह department है जो सारी intellectual property और research को track करता है
    • ZFSOnLinux जैसी कुछ चीजें पहले से ही publicly share होती हैं। repository अब OpenZFS repository बन चुकी है और इसने कई लोगों की जिंदगी बेहतर बनाई है। मेरी जिंदगी भी आसान हुई है
      open source development model LLNL के लिए भी फायदेमंद था, और उन्हें अकेले develop करने की तुलना में कहीं बेहतर codebase मिला
      NASA IKOS जैसी चीजें भी पहले से public हैं: https://github.com/NASA-SW-VnV/ikos
      इस project को third parties से जितना ध्यान मिलना चाहिए, उससे बहुत कम मिल रहा है। अगर यह multithreading संभालने वाले general-purpose sound static analyzer के रूप में विकसित हो सके, तो यह कई अन्य projects को बेहतर बनाने में मदद करेगा

  • “अगर public budget है, तो उस पैसे से निकले परिणाम जनता को दिखने चाहिए” इस विचार के साथ कभी पूरा open source model आगे बढ़ाने की कोशिश की थी: https://web.archive.org/web/20200920095030/http://oss4gov.or...
    मेरा मानना था कि government software का default open source होना चाहिए, जब तक minister-level approval exception न हो। हालांकि तब मैं युवा और भोला था

    • मुझे नहीं लगता कि यह इतना विवादास्पद है। UK government भी कुछ ऐसा ही मानती है: https://www.gov.uk/service-manual/technology/making-source-c...
    • military contractor में कई साल काम किया है, और बहुत से लोग मानते हैं कि अगर taxpayers ने software का खर्च उठाया है और software classified नहीं है, तो वह open source होना चाहिए
      Ghidra एक अच्छा उदाहरण है, और इस software का free होना security community के लिए बड़ा लाभ रहा
    • FSFE भी Atlantic के उस पार यही सोच share करता है: https://publiccode.eu/en/
    • आप भोले नहीं थे, अपने समय से आगे थे। progress कठिन काम है और marathon भी

  • हम open source software बनाते हैं और चाहते हैं कि government agencies उसे adopt या use करें, लेकिन इन agencies में open source से allergy का स्तर चौंकाने वाला है
    कुछ जगहें दूसरों का code इस्तेमाल करने के बजाय CSV uploads या broken parsers जैसे legacy तरीकों से खुद बनाती हैं, और predictable bugs और flaws भी साथ में बना देती हैं
    RFP का जवाब देते समय भी open source को closed systems की तुलना में अधिक कठोर review झेलना पड़ता है। अगर वह public है तो आपको साबित करना पड़ता है कि यह अच्छा है, लेकिन closed होने पर vendor कह सकता है “हाँ, यह perfect है” और agency आगे बढ़ सकती है। लगता है agencies और staff कोई responsibility नहीं लेना चाहते। फिर भी incompetence की वजह से किसी को government job खोते नहीं देखा

    • बड़े स्तर पर यह job protectionism है, और व्यक्तिगत स्तर पर अपने codebase को promotions के लिए इस्तेमाल करने वाले subject-matter expert बनने की संरचना है। आम तौर पर agencies खुद को एक ही team में काम करते हुए नहीं देखतीं। Congress में अपनी agency के resources हासिल करने के लिए lobbying करते समय वे बहुत competitive हो सकती हैं
      मैं government में काम करता हूँ और यह खुद अनुभव किया है। culture बहुत toxic और broken है। Elon और Trump team क्या बदलाव propose करेगी, यह देखने की उत्सुकता है
    • open source में किसी को accountable ठहराना मुश्किल है। closed software हो तो जब कुछ गलत होता है, उंगली उठाने के लिए कोई target मिल जाता है

  • अमेरिकी रक्षा विभाग के पास open source software FAQ है: http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx और https://github.com/risacher/DoD-OSS-FAQ
    यह version सरकारी policy documents पर public participation के लिए collaborative tool experiment के रूप में GitHub पर प्रकाशित किया गया था, और इसमें कहा गया है कि military और civilian personnel, contractors, और आम नागरिक pull request के जरिए बदलाव या additions के प्रस्ताव submit कर सकते हैं
    2010 का वीडियो: https://www.youtube.com/watch?v=WWt0YiXcEkE
    DoD CIO office के Dan Risacher और open source security expert David A. Wheeler ने हालिया DoD memo के इतिहास और प्रभावों को समझाया, जिसने यह रुख साफ किया कि रक्षा विभाग open source को viable commercial software के एक रूप के तौर पर देखता है
    2024 की सामग्री: https://openssf.org/press-release/2024/10/29/openssf-expands...
    Linux Foundation के OpenSSF ने कहा कि वह security training की जरूरत को मानता है, और OpenSSF के open source supply chain security director David A. Wheeler के मुताबिक course शुरू होने के बाद से 25,000 से अधिक लोगों ने इस training material के लिए registration किया है

  • इरादा अच्छा है, लेकिन व्यवहार में शायद contractor 1 के संभावित competitors के gap कम करने या मौजूदा contract code की quality के आधार पर हमला करने के अलावा ज्यादा कुछ नहीं होगा। code पढ़ना code लिखने से ज्यादा कठिन है

    • अगर संभावित competitors gap कम करते हैं, तो सरकार के नजरिए से competition बढ़ेगा और costs घटेंगी
      अगर वे मौजूदा contract code की quality के आधार पर हमला करते हैं, तो वह code review है, और किसी न किसी तरह code quality में सुधार की ओर ले जाएगा। मुझे समझ नहीं आता कि इसमें समस्या क्या है

  • शानदार बात है। मुझे याद है कि उसी organization के अंदर भी code पढ़ पाने में कितनी दिक्कत हुई थी। ऐसा बदलाव top-down mental model बनाने वालों के लिए काम आसान कर देगा

  • सामान्य तौर पर taxpayers के पैसे से paid हर चीज public होनी चाहिए। Public Monies Public Goods एक absolute basic principle होना चाहिए

    • ऐसे rules पहले से हैं, लेकिन उन्हें गंभीरता से लेने वाली agency सिर्फ DoD है। उदाहरण के तौर पर BRL-CAD और FalconView हैं
      फिर भी यह unethical contractors को code पर copyright लगाने और licensing fees लेने से नहीं रोकता। ज्यादातर DoE code ऐसा ही है, NWCHEM जैसे exceptions हैं। मैं हमेशा सोचता रहा कि यह lawsuits तक क्यों नहीं पहुंचा, शायद इसलिए कि किसी ने बहुत ध्यान नहीं दिया
    • यह दिलचस्प है कि कुछ local governments अपने laws पर copyright लगाती हैं ताकि दूसरी local governments उन्हें बिना पैसे दिए copy न कर सकें
      एक तरफ, यह समझ में आता है कि वे मानते हैं कि दूसरे क्षेत्र उस ordinance system पर free-ride कर रहे हैं जिसकी लागत उनके local taxpayers ने उठाई है। खासकर अगर वह law मुख्य रूप से local government पर ही लागू होता हो। दूसरी तरफ, यह अजीब लगता है कि laws copyright से restricted हों
    • सहमत नहीं हूं। वजह China है। अमेरिकी सरकार को अपना code private रखना चाहिए, जिसमें बेहद महंगे contractors का trash code भी शामिल है
    • software के मामले में मैं सहमत नहीं हूं
    • क्या classified materials से लेकर office memos और personnel records तक सब कुछ public करने की बात है? ऐसा नहीं होने वाला
      जब आप घर पर किसी से कोई काम करवाते हैं, तो यह भी सोचना चाहिए कि final deliverable के अलावा आप exactly क्या own करते हैं

  • बेहतरीन दिशा है। government teams के साथ काम करते हुए मैंने देखा है कि कुछ जगहों पर यह approach recommended practice के तौर पर दी गई है: https://www.forgov.qld.gov.au/information-and-communication-...
    हालांकि कई मामलों में, उस recommendation को सच में follow करवाने के लिए requirement के रूप में law बनाना अभी भी जरूरी कदम है। खासकर public services में, क्योंकि वहां open source community में भाग लेने का अनुभव न रखने वाले लोग आम मिलते हैं
    जैसा कि दूसरों ने जोर दिया है, public budget से public benefit मिलना चाहिए, और open source उस benefit को बढ़ाने का अच्छा तरीका है

  • एक वाक्य है: “नया कानून classified code, national security systems, और ऐसे code पर लागू नहीं होता जो share करने पर privacy risk पैदा करे”
    share करने पर privacy risk पैदा करने वाला code आखिर किस तरह का होगा? सुनने में लगता है कि code और data काफी खराब तरीके से आपस में मिले हुए हैं

    • असल में कोई risk नहीं है, लेकिन यह disclose न करने का अच्छा excuse देता है। companies और government agencies ने technical documents पर information disclosure requests को privacy protection के कारण reject किया है। जैसे “यह personal information process करने वाले systems पर apply होता है” या “system की internal working पता चलने से system के compromise होने की संभावना बढ़ जाती है”
      government contractors खुशी से lines के बीच यह मान लेते हैं कि उनका code खराब है और आम तौर पर security by obscurity पर निर्भर करता है। information commissions ने भी कुछ बार उनके पक्ष में फैसला दिया है
    • काफी customized code में ऐसी functionality होती है जो target task के बारे में बहुत सारी जानकारी reveal कर देती है
      उदाहरण के लिए सोचिए कि Excel formulas में क्या-क्या दिख सकता है
    • दोनों के बीच कोई फर्क नहीं है