1 पॉइंट द्वारा GN⁺ 2024-10-21 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Bitwarden Desktop 2024.10.0 build में @bitwarden/sdk-internal dependency की ज़रूरत पड़ने लगी, और मुद्दा उठाया गया कि इस SDK की लाइसेंस शर्तें “Bitwarden के अलावा किसी software के लिए apps या दूसरे SDKs विकसित करने में इसका उपयोग नहीं किया जा सकता” जैसी पाबंदी लगाती हैं, जिससे free software की शर्तें टूटती हैं
  • मुद्दा उठाने वाले ने कहा कि यह पाबंदी GNU की freedom 0 का उल्लंघन करती है, और इस dependency को हटाने पर desktop-v2024.10.0 और मौजूदा master build नहीं किए जा सकते
  • reproduce करने के उदाहरण में, bitwarden_license directory हटाकर और node_modules साफ़ करके build करने पर @bitwarden/sdk-internal और WASM modules न मिलने वाली 6 TS2307 errors के कारण build:preload fail हो जाता है
  • कुछ comments ने बताया कि SDK सिर्फ Desktop में नहीं, बल्कि browser, CLI, web clients में भी feature flags के रूप में इस्तेमाल होता है, और Bitwarden ने जवाब दिया कि SDK और client अलग-अलग programs हैं तथा GPLv3 के लिहाज़ से केवल standard protocol communication से वे एक program नहीं बन जाते
  • बाद में Bitwarden ने SDK code structure और packaging को adjust करके सिर्फ GPL/OSI licenses शामिल करने वाला build संभव बनाया, client के sdk-internal references को नए sdk-internal repository में ले गया, और issue को completed के रूप में बंद कर दिया

उठाया गया मुद्दा: Desktop 2024.10.0 build और SDK license

  • issue इस आपत्ति के साथ खोला गया कि Bitwarden Desktop 2024.10.0 अब free software नहीं है
  • मुख्य बदलाव यह था कि Pull request #10974 ने desktop client build में @bitwarden/sdk-internal dependency जोड़ी
  • इस dependency के license में यह restriction शामिल है
    • “इस SDK का उपयोग Bitwarden के अलावा किसी software, जिसमें Bitwarden से compatible न होने वाले implementations शामिल हैं, के लिए applications विकसित करने में नहीं किया जा सकता, और न ही दूसरे SDKs विकसित करने में किया जा सकता है”
  • मुद्दा उठाने वाले के अनुसार यह clause GNU free software definition की freedom 0 का उल्लंघन करता है
  • उन्होंने यह भी कहा कि इस dependency को हटाए बिना desktop-v2024.10.0, और संभवतः मौजूदा master, build नहीं किया जा सकता

reproduce किया गया build failure

  • मुद्दा उठाने वाले ने पहले की तरह bitwarden_license directory हटाकर और साफ़ node_modules के साथ build करने की कोशिश की
  • build apps/desktop के build:preload step पर fail हुआ
  • error कई files में @bitwarden/sdk-internal module या type declarations न मिलने वाली TS2307 थी
    • libs/common/src/platform/abstractions/sdk/sdk.service.ts
    • libs/common/src/platform/abstractions/sdk/sdk-client-factory.ts
    • libs/common/src/platform/services/sdk/default-sdk.service.ts
    • libs/common/src/platform/services/sdk/default-sdk-client-factory.ts
    • libs/common/src/platform/services/sdk/noop-sdk-client-factory.ts
  • WASM path @bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasm भी न मिलने की error आई
  • नतीजतन webpack 5.94.0 6 errors के साथ compile करने में fail हुआ, और npm run build:preload code 1 के साथ exit हो गया

community की प्रतिक्रिया और बढ़ी हुई चिंताएं

  • एक comment ने संबंधित issue के रूप में bitwarden/sdk-sm#898 का ज़िक्र करते हुए चिंता जताई कि Bitwarden खुद को open source बताकर advertise कर रहा है, जबकि proprietary software की ओर जा रहा है
  • एक अन्य user ने कहा कि CLI client के NPM release में भी इसी तरह की समस्या उन्होंने दो महीने पहले #10648 में report की थी, लेकिन कोई response नहीं मिला
  • कुछ users ने alternatives के रूप में पुराने version का fork, Vaultwarden, और Vaultwarden web interface को wrap करने वाले Tauri desktop app जैसे विकल्पों का ज़िक्र किया
  • एक comment ने कहा कि passwords संभालने वाले product की प्रकृति देखते हुए “किसी भी alternative” पर जाना सावधानी से करना चाहिए, और सिर्फ client fork से server service या server software dependency की समस्या बाकी रहती है
  • एक और comment ने दावा किया कि SDK Desktop release के अलावा browser, CLI, web clients में भी feature flags के रूप में इस्तेमाल होता है, और लिखा कि Bitwarden 2024.10.0 के सभी versions SDK का उपयोग करते हैं

Bitwarden की शुरुआती प्रतिक्रिया

  • Bitwarden के एक सदस्य ने जवाब दिया कि वे clients में SDK का उपयोग बढ़ाते आए हैं, लेकिन लक्ष्य यह है कि SDK का उपयोग GPL compatibility बनाए रखे
  • Bitwarden ने ये तीन आधार दिए
    • SDK और client अलग-अलग programs हैं
    • हर program का code अलग repository में है
    • दो programs standard protocol से communicate करते हैं, केवल इस तथ्य से वे GPLv3 के उद्देश्य से एक program नहीं बन जाते
  • उन्होंने कहा कि user ने जिस तरीके से app build करने की कोशिश की और वह नहीं हो पा रहा, यह एक bug है जिसे वे fix करेंगे
  • इसके बाद बातचीत Bitwarden ने lock कर दी और collaborators तक सीमित कर दी

अंतिम adjustment और closure

  • Bitwarden ने कहा कि उन्होंने SDK code की structure और packaging method adjust की है ताकि app को सिर्फ GPL/OSI licenses शामिल होने की स्थिति में build और run किया जा सके
  • client के sdk-internal package references को नए sdk-internal repository से आने के लिए बदल दिया गया
  • नए sdk-internal repository के बारे में बताया गया कि यह उस license model का पालन करता है जिसे Bitwarden अपने मौजूदा clients के लिए इस्तेमाल करता आया है, और संबंधित जानकारी के लिए LICENSE_FAQ.md दिया गया
  • मौजूदा sdk-internal reference केवल GPL license का उपयोग करता है
  • उन्होंने कहा कि भविष्य में अगर उस reference में Bitwarden License code शामिल होता है, तो web vault client build की तरह कई build variants बनाने का तरीका उपलब्ध कराया जाएगा
  • मौजूदा sdk repository का नाम बदलकर sdk-secrets किया जाएगा, और यह Secrets Manager business product के लिए मौजूदा Bitwarden SDK License structure बनाए रखेगा
  • sdk-secrets repository और package में ऐसा code है जिसका उपयोग client apps में नहीं होता, इसलिए अब client apps से उसका reference नहीं रहेगा
  • issue 25 अक्टूबर 2024 को completed के रूप में बंद हुआ

2 टिप्पणियां

 
tribela 2024-10-21

मैं Keepass का बड़ा प्रशंसक हूँ, लेकिन लोग बार-बार सिर्फ Bitwarden की ही बात करते रहे, इसलिए सोचा था कि एक बार उसे भी आज़माऊँ। अब लगता है कि Keepass ही बनाए रखना चाहिए। यह server-based नहीं है; बस फ़ाइल को ठीक से सुरक्षित रखना होता है, इसलिए availability भी कहीं ज़्यादा है और मेरी पसंद के हिसाब से Keepass ज़्यादा उपयुक्त है।

 
GN⁺ 2024-10-21
Hacker News की राय
  • मैंने पैसे इसलिए दिए थे क्योंकि उम्मीद थी कि मैं open source को support कर रहा हूं, और इसी वजह से LastPass से Bitwarden पर आया था
    यह घटना पीठ में घुसे चाकू को और घुमाने जैसी लगती है। लगता है CEO Michael Crandell उसी तरह के financial inflection point पर पहुंच गए हैं जैसा RightScale बेचते समय था, इसलिए शायद acquisition की तैयारी हो रही है: https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

    • उस page के 2022 के material में भी “क्या बदल रहा है?” के नीचे लिखा था कि Bitwarden open source architecture को बनाए रखेगा
      अब ऐसा नहीं लगता। जोखिम भरा कदम है। open source में कई अच्छी खूबियां हैं, लेकिन यहां अहम बात security है। कंपनियां opaque binary blob को सुरक्षित बताती हैं, यह हमेशा हैरान करता है। Intel Management Engine भी ऐसा ही है, और अब Bitwarden भी IME और Juniper switches की कतार में शामिल हो गया है
      closed source की ओर जाना high-risk choice है। लंबे समय तक मैंने software के लिए पैसे नहीं दिए, लेकिन security के लिए पैसे दे सकता हूं और सच में देता हूं। मैं Bitwarden को पैसे इसलिए देता हूं क्योंकि यह वह चीजें store करता है जिन्हें मैं अपनी सबसे कीमती और निजी जानकारी मानता हूं। लेकिन आखिरकार यह सिर्फ software ही है, और “bitwarden” कहे जाने वाले bytes कहां से आते हैं, यह मायने नहीं रखता। कोई भी fork करके वही bytes दे सकता है। अगर कोई ऐसा Bitwarden mirror चलाए जो सिर्फ open source software इस्तेमाल करता हो, तो मेरा पैसा उधर जाएगा। अगर running binary और वे binaries जिन्हें मैं अपने कई devices पर download करता हूं, उन्हें identical reproduce करने के build instructions भी हों तो और अच्छा होगा। जब तक मेरे passwords open source software द्वारा manage नहीं होते, मैं उन्हें सुरक्षित नहीं मानता
  • यह कदम बहुत चौंकाने वाला नहीं है। पिछले कुछ वर्षों में Bitwarden बहुत मजबूती से enterprise sales की तरफ गया है, और इस दौरान consumer side को लगभग छोड़ दिया गया
    हाल ही में ही यह पुराने MAUI-based app से native iOS app पर बदला है, जबकि पुराना app कई मायनों में बहुत अटपटा था। मौजूदा iOS client में भी अभी कई चीजें catch up करनी बाकी हैं
    venture funding मिलने के बाद लगता है कि वे revenue और profit की तरफ ज्यादा झुक गए हैं। यह choice अपने-आप में गलत नहीं है, लेकिन यह कंपनी के शुरू होने और बढ़ने के तरीके से काफी अलग दिशा में धक्का है
    Proton Pass भी थोड़ा दिलचस्प है, लेकिन बाकी Proton services की तरह उसका pricing model हमेशा थोड़ा महंगा लगता है। कुछ समय से free Proton Pass आजमा रहा हूं, और क्योंकि Bitwarden उन दिशाओं में बेहतर नहीं हुआ जिनका मैं कई सालों से इंतजार कर रहा था, देखूंगा कि alternative पर जाना worth it है या नहीं
    iOS का built-in password manager भी काफी ठीक है, लेकिन वह सिर्फ passwords के लिए है और दूसरे तरह के data को store, search या autofill करने की सुविधा नहीं देता

    • विडंबना है। कुछ companies शायद Bitwarden इसलिए इस्तेमाल कर रही थीं क्योंकि यह open था, और कोई बहुत उपयोगी चीज इस्तेमाल करने के लिए enterprise sales call से नहीं गुजरना पड़ता था
      product को इस्तेमाल करना मुश्किल बनाएंगे तो customers और sales opportunities खोएंगे। हाल में Postman के साथ हुई भयानक calls याद आती हैं। एक और call करने से तो अब Hoppscotch कहीं बेहतर लग रहा है
    • आखिर लगभग हमेशा venture funding सब कुछ खराब क्यों कर देती है
  • CTO का जवाब कहता है कि उन्होंने SDK के use scope को ज्यादा client cases तक बढ़ाया है, लेकिन लक्ष्य यह है कि SDK का इस्तेमाल इस तरह हो कि वह GPL compatibility बनाए रखे
    उनका मानना है कि SDK और client अलग programs हैं, हर program का code अलग repository में है, और सिर्फ इस तथ्य से कि दोनों programs standard protocol से communicate करते हैं, वे GPLv3 के तहत एक program नहीं बन जाते। उनके मुताबिक जिस तरीके से यहां app build किया जा सके, उस issue को वे एक simple bug के रूप में ठीक करेंगे

    • इस तरह के जवाब सच में frustrate करते हैं। क्योंकि वे सवाल के scope को जानबूझकर गलत समझते हुए असली सवाल से बच जाते हैं
      CTO से पूछना चाहूंगा कि बात कुछ ऐसी है: “क्या आपके lawyers को लगता है कि आप legally इससे बच निकल सकते हैं?” इसका जवाब तो दिया गया, लेकिन लोगों की चिंता वाले मुख्य सवाल का जवाब नहीं दिया। क्या Bitwarden team को इसमें कोई ethical problem नहीं दिखती कि जिस project को बहुत लोगों ने स्पष्ट रूप से open source होने की वजह से support और contribute किया, उसे proprietary बनाया जा रहा है? password management स्वभाव से ही high trust वाला business है; open source से closed source की ओर rug pull से जो trust breakdown, forks और churn होंगे, उन्हें वे कैसे संभालेंगे? अगर company इतनी desperate स्थिति में है कि ऐसा decision consider कर रही है, तो क्या community मिलकर बिना privatization के इससे निकलने का कोई तरीका नहीं ढूंढ सकती?
      CTO के तौर पर अभी आपका काम चिंता जताने जैसा दिखना है, खासकर उन forums में जहां आप बातचीत बंद नहीं कर सकते—यह समझता हूं। लेकिन current approach असल में सबसे बुरे डर को confirm करता है कि “हम मानते हैं यह legally possible है, और हमें अपने action में कोई problem नहीं दिखती।” यह उस company के लिए बिल्कुल गलत vibe है जिसकी revenue users के code और update करने वाले लोगों पर trust पर निर्भर है
    • दूसरे शब्दों में, bitwarden/clients GPLv3 है, और working whole के रूप में Bitwarden client proprietary software है; CTO को इसमें कोई problem नहीं दिखती, और issue lock कर दिया गया है
    • जरूरी नहीं कि core issue यह हो कि यह “एक program” है या नहीं। समस्या यह हिस्सा है
      “object code form work का ‘Corresponding Source’ object code को generate, install और run करने तथा work को modify करने के लिए जरूरी सभी source code, और उन activities को control करने वाली scripts को शामिल करता है।”
      समझता हूं कि open source company के तौर पर पैसा कमाना सच में मुश्किल है। इसलिए मैं भी paying customers में से एक हूं
      SDK पर लगाई गई exception काफी हद तक उस BitKeeper version control software जैसी लगती है जो कुछ समय तक Linux kernel के लिए इस्तेमाल हुआ था। उसका अंत कैसा हुआ, बस देख लें
  • मुझे यह पसंद था, मैंने पैसे भी दिए, दोस्तों को recommend भी किया और उन्हें भी पसंद आया
    अब KeePassXC पर जाने की सोच रहा हूं। Android के साथ database sync करने का recommended तरीका क्या है? मेरे पास सिर्फ cloudflared चलाने वाला Raspberry Pi server है

    • अगर आप files move करने से होने वाले sync conflicts में लौटे बिना cloud convenience बनाए रखना चाहते हैं, तो Proton Pass GPLv3 है। हालांकि अगर आगे चलकर rug pull हुआ तो self-hosting की स्थिति क्या होगी, यह मुझे personally नहीं पता
      https://github.com/ProtonMail/WebClients/tree/proton-pass%40...

https://github.com/protonpass/android-pass/blob/1.26.1/LICEN...

[https://github.com/protonpass/ios-pass/blob/1.12.3/LICENSE](<https://github.com/protonpass/ios-pass/blob/1.12.3/LICENSE>;)
  • SyncThing के साथ KeePass vault को सिर्फ उन्हीं devices पर ठीक-ठीक deploy करके इस्तेमाल करता हूँ जहाँ ज़रूरत है। मेरे लिए यह बहुत अच्छी तरह काम करता है। ज़रूरत के हिसाब से अलग हो सकता है

  • मैं सच में KeePass और उसके ecosystem का इस्तेमाल करना चाहता हूँ, लेकिन password sharing बहुत अच्छी नहीं है। मेरी पत्नी और मेरे पास बहुत सारे shared passwords हैं, और Bitwarden इस हिस्से में बहुत अच्छा काम करता है। हमारे लिए practical alternative क्या है, पता नहीं

  • Keepass2Android ssh(sftp), Nextcloud आदि कई तरीकों से sync कर सकता है। कोई-न-कोई सही तरीका मिल ही जाएगा

  • KeePassXC और Android के लिए Nextcloud client का combination मेरे लिए perfect है। कई सालों से बिना समस्या इस्तेमाल कर रहा हूँ

  • GitHub issue को आगे discuss न कर पाने के लिए lock कर दिया गया है। संभावित alternatives में से एक Vaultwarden लगता है
    https://github.com/dani-garcia/vaultwarden
    जब पैसे वाले लोग आते हैं तो open source projects में ऐसी चीजें बार-बार होती रहती हैं, यह वाकई दुखद है

    • Vaultwarden server replacement है, और यहाँ issue, मेरी समझ से, desktop client license है
    • García ने हाल ही में Bitwarden में काम शुरू किया है। उनका विचार सुनना दिलचस्प होगा
    • क्या Vaultwarden passkey support करता है?
  • विस्तार से कभी नहीं देखा, लेकिन marketing देखकर मुझे लगा था कि Bitwarden पूरी तरह free software है। लेकिन लगता है कि करीब 2020 से इसमें अजीब proprietary elements आ गए हैं

  • कभी Bitwarden पर shift होने की उम्मीद थी, लेकिन अगर healthy open ecosystem नहीं मिला तो अब शायद नहीं करूँगा। आगे क्या होता है, देखता रहूँगा

    • मैंने 1 साल तक Vaultwarden backend लगाकर Bitwarden पर पूरी तरह switch करके देखा, लेकिन पहले इस्तेमाल किए गए 1Password की तुलना में experience काफी खराब था
      evaluation criteria में से एक था, “परिवार के सभी लोग 1Password इस्तेमाल करते हैं और संतुष्ट हैं; क्या यह इतना अच्छा है कि इन्हें shift करने के लिए मना सकूँ?” Final switch का फैसला मैं कर सकता हूँ, लेकिन बुज़ुर्ग माता-पिता को कुछ नया करवाना हो तो user experience बहुत ज़रूरी है
      नतीजा था—नहीं। कुल मिलाकर UX अच्छा न होने के अलावा, Bitwarden clients Linux, Mac, Windows, iOS सभी पर काफी धीमे थे—search से लेकर login तक हर चीज़ में। Features भी कम थे, और password sorting, favorites, अच्छे organization tools जैसी दिखने वाली चीज़ें missing थीं; autofill भी बहुत कम reliable था
      1Password के business practices और customer response को लेकर वर्षों से मेरी काफी शिकायतें रही हैं। फिर भी password manager—अब तो password से आगे की secrets रखने वाले manager जैसा tool—daily life के केंद्र में है, इसलिए लगा कि जितना कम दर्द दे वही इस्तेमाल करना चाहिए, और अफसोस के साथ वापस लौट गया
      मैंने Bitwarden open source होने की वजह से नहीं इस्तेमाल किया था, बल्कि संभवतः सबसे अच्छा password manager इस्तेमाल करने की कोशिश की थी। फिर भी इसका open होना मुझे पसंद था, और Vaultwarden एक gem जैसा है। काश मेरे पास सच में बेहतर frontend बनाने का समय और skill होता
  • “फिलहाल SDK license को adjust करने की कोई योजना नहीं है। हम इसे अपने F-Droid repository https://mobileapp.bitwarden.com/fdroid/repo/ में publish करना जारी रखेंगे।”
    https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
    यह issue SDK repository में जुलाई में ही उठाया जा चुका था, और उस SDK के पास यह license एक साल से ज़्यादा समय से था

  • मैं iOS, PC, Mac पर Bitwarden इस्तेमाल कर रहा हूँ। अब alternatives ढूँढने होंगे। सच में दुखद दिन है
    मैं भी सालाना 10 डॉलर वाला premium member हूँ। संदिग्ध practices की वजह से खोई हुई revenue ही समझिए
    क्या export करके किसी दूसरे alternative पर जाने का तरीका है?

  • यह एक ऐसा project था जिसे मैं देख रहा था कि शायद मेरे लिए Keepass(X,XC) का बेहतर alternative बने, लेकिन अब लगता है कि आखिरकार इस पर move नहीं करूँगा