Bitwarden ücretsiz yazılımı sonlandırıyor

 (github.com/bitwarden)
1 puan yazan GN⁺ 2024-10-21 | 2 yorum | WhatsApp'ta paylaş
  • Bitwarden Desktop 2024.10.0 derlemesi artık @bitwarden/sdk-internal bağımlılığını gerektiriyor ve bu SDK’nın lisans şartları, “Bitwarden dışındaki yazılımlar için uygulama ya da başka SDK’ler geliştirmekte kullanılamaz” kısıtını içerdiği için özgür yazılım gereklerini ihlal ettiği yönünde bir sorun gündeme geldi
  • Sorunu bildiren kişi, bu kısıtın GNU’nun freedom 0 ilkesini ihlal ettiğini ve bu bağımlılık kaldırıldığında desktop-v2024.10.0 ile mevcut master’ın derlenemediğini belirtti
  • Yeniden üretim örneğinde, bitwarden_license dizini kaldırılıp node_modules temizlendikten sonra derleme yapıldığında @bitwarden/sdk-internal ile WASM modülünün bulunamadığını söyleyen 6 adet TS2307 hatası nedeniyle build:preload başarısız oluyor
  • Bazı yorumlarda SDK’nın yalnızca Desktop’ta değil browser, CLI, web clients içinde de özellik bayrakları için kullanıldığı belirtildi; Bitwarden ise SDK ile istemcilerin ayrı programlar olduğunu ve yalnızca standart protokol iletişiminin GPLv3 açısından bunları tek bir program yapmadığını söyledi
  • Bitwarden daha sonra SDK kod yapısı ve paketlemeyi düzenleyerek yalnızca GPL/OSI lisanslı içerikle derleme yapılabilmesini sağladı; istemcideki sdk-internal referansını yeni sdk-internal deposuna taşıdı ve sorunu kapattı

Gündeme getirilen sorun: Desktop 2024.10.0 derlemesi ve SDK lisansı

  • Sorun kaydı, Bitwarden Desktop 2024.10.0’ın artık özgür yazılım olmadığı iddiasıyla açıldı
  • Temel değişiklik, Pull request #10974 ile masaüstü istemcisi derlemesine @bitwarden/sdk-internal bağımlılığının eklenmesi oldu
  • Bu bağımlılığın lisansı şu kısıtı içeriyor
    • “Bu SDK, Bitwarden dışındaki yazılımlar için ya da Bitwarden ile uyumlu olmayan uygulamalar dahil yazılımlar için uygulama geliştirmede kullanılamaz ve başka SDK’lerin geliştirilmesinde de kullanılamaz”
  • Sorunu bildiren kişi, bu hükmün GNU özgür yazılım tanımındaki freedom 0 ilkesini ihlal ettiğini düşünüyor
  • Ayrıca bu bağımlılık kaldırılmadan desktop-v2024.10.0’ın ve muhtemelen mevcut master’ın derlenemediğini belirtiyor

Yeniden üretilen derleme hatası

  • Sorunu bildiren kişi, önceki yöntemde olduğu gibi bitwarden_license dizinini kaldırıp temizlenmiş node_modules ile derleme denemesi yaptı
  • Derleme, apps/desktop içindeki build:preload aşamasında başarısız oldu
  • Hata, çeşitli dosyalarda @bitwarden/sdk-internal modülünün veya tür bildirimlerinin bulunamadığını belirten TS2307 oldu
    • 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
  • Ayrıca @bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasm adlı WASM yolunun bulunamadığı hatası da oluştu
  • Sonuç olarak webpack 5.94.0, 6 hata nedeniyle derlemeyi tamamlayamadı ve npm run build:preload kod 1 ile sonlandı

Topluluk tepkisi ve genişleyen endişeler

  • Bir yorum, ilişkili sorun olarak bitwarden/sdk-sm#898 bağlantısını vererek Bitwarden’ın kendini açık kaynak olarak tanıtırken kapalı/proprietary yazılıma yöneldiği endişesini dile getirdi
  • Başka bir kullanıcı, CLI istemcisinin NPM sürümünde de benzer bir sorunu iki ay önce #10648 ile bildirdiğini ancak yanıt alamadığını söyledi
  • Bazı kullanıcılar alternatif olarak eski sürüm fork’larını, Vaultwarden’ı ve Vaultwarden web arayüzünü saran Tauri masaüstü uygulamalarını andı
  • Bir yorumda, ürünün parola yönetimi gibi hassas doğası nedeniyle “herhangi bir alternatife” geçmenin dikkat gerektirdiği, yalnızca istemci fork’unun sunucu hizmeti veya sunucu yazılımı bağımlılığı sorunlarını çözmeyeceği vurgulandı
  • Başka bir yorum ise SDK’nın yalnızca Desktop sürümünde değil browser, CLI, web clients içinde de özellik bayrakları için kullanıldığını ve Bitwarden 2024.10.0’ın tüm sürümlerinin SDK kullandığını öne sürdü

Bitwarden’ın ilk yanıtı

  • Bitwarden’dan bir ekip üyesi, istemcilerde SDK kullanım alanını genişlettiklerini ancak amaçlarının SDK kullanımının GPL uyumluluğunu koruması olduğunu söyledi
  • Bitwarden şu üç gerekçeyi sundu
    • SDK ile istemciler ayrı programlardır
    • Her programın kodu ayrı depolarda bulunur
    • İki programın standart protokoller üzerinden iletişim kurması, GPLv3 açısından tek bir program sayılmaları için yeterli değildir
  • Kullanıcının denediği yöntemle uygulamanın derlenememesi durumunun çözülecek bir hata olduğunu da belirtti
  • Daha sonra tartışma Bitwarden tarafından kilitlendi ve yalnızca collaborator’larla sınırlandı

Nihai düzenleme ve kapanış

  • Bitwarden, SDK kodunun yapısını ve paketleme biçimini değiştirerek uygulamanın yalnızca GPL/OSI lisanslı içerikle derlenip çalıştırılabilmesini sağladığını açıkladı
  • İstemcideki sdk-internal paket referansı, yeni sdk-internal repository üzerinden gelecek şekilde değiştirildi
  • Yeni sdk-internal deposunun, Bitwarden’ın mevcut istemcilerinde kullandığı lisans modelini izlediği belirtildi ve ilgili bilgi olarak LICENSE_FAQ.md gösterildi
  • Şu anda sdk-internal referansı yalnızca GPL lisansı kullanıyor
  • Gelecekte bu referansa Bitwarden License kodu eklenirse, web vault istemcisi derlemesine benzer şekilde birden fazla derleme varyantı oluşturma yöntemi sunulacağı ifade edildi
  • Eski sdk repository, sdk-secrets olarak yeniden adlandırılıyor ve Secrets Manager kurumsal ürünü için mevcut Bitwarden SDK License yapısını koruyor
  • sdk-secrets deposu ve paketleri, istemci uygulamalarında kullanılmayan kodlardan oluştuğu için artık istemci uygulamaları tarafından referans alınmıyor
  • Sorun 25 Ekim 2024 tarihinde completed olarak kapatıldı

İlgili okumalar

2 yorum

 
tribela 2024-10-21

Ben Keepass’i severek kullanıyorum ama herkes durmadan Bitwarden’den bahsettiği için bir denesem mi diye düşünmüştüm; sanırım Keepass ile devam etmeliyim. Sunucu tabanlı değil de sadece dosyayı iyi saklamanın yeterli olduğu bir yöntem olduğu için erişilebilirliği çok daha yüksek; bu yüzden benim zevkime Keepass daha çok uyuyor.
 
GN⁺ 2024-10-21
Hacker News yorumları

  • Para ödememin nedeni açık kaynağı desteklediğim beklentisiydi; bu yüzden LastPass’ten Bitwarden’a geçmiştim.
    Bu olay sırtıma saplanan bıçağın çevrilmesi gibi hissettiriyor. CEO Michael Crandell’ın RightScale’i sattığı zamankine benzer bir finansal dönüm noktasına gelmişler; sanki bir satın almaya hazırlanıyorlar: https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

    • O sayfadaki 2022 tarihli materyalde de “Ne değişiyor?” başlığının altında Bitwarden’ın açık kaynak mimarisini korumayı sürdüreceği yazıyordu.
      Artık öyle değil gibi. Tehlikeli bir hamle. Açık kaynağın pek çok iyi özelliği var ama burada önemli olan güvenlik. Şirketlerin opak ikili dosya yığınlarını güvenli diye sunması her zaman şaşırtıcı. Intel Management Engine de öyleydi; şimdi Bitwarden da IME ve Juniper switch’lerinin safına katılmış oldu.
      Kapalı kaynağa geçmek yüksek riskli bir tercih. Uzun süre yazılımın kendisine para ödemedim ama güvenlik için ödeme yapabilirim ve gerçekten de yapıyorum. Bitwarden’a para ödüyorum çünkü en değerli ve en özel bilgilerim olarak gördüğüm şeyleri saklıyor. Ama sonuçta bu yalnızca yazılım ve “bitwarden” dediğimiz baytların nereden geldiği önemli değil. Herkes fork edip aynı baytları sağlayabilir. Yalnızca açık kaynak yazılım kullanan bir Bitwarden aynası işletilirse param oraya gider. Çalışan ikili dosyayla çeşitli cihazlarıma indirdiğim ikili dosyaların aynı olduğunu yeniden üretilebilir biçimde doğrulayan derleme talimatları da olursa daha da iyi olur. Parolalarımın, açık kaynak yazılım tarafından yönetilmediği sürece güvende olduğunu düşünmüyorum.

  • Bu hamle çok da şaşırtıcı değil. Bitwarden son birkaç yılda güçlü biçimde kurumsal satış tarafına kaydı ve bu sırada tüketici tarafını ihmal etti.
    Ancak yakın zamanda önceki MAUI tabanlı uygulamadan yerel iOS uygulamasına geçildi; eski uygulama birçok açıdan fazla aykırı duruyordu. Mevcut iOS istemcisinin de hâlâ yetişmesi gereken noktalar var.
    Girişim sermayesi aldıktan sonra gelir ve kâr odağına daha fazla eğilmiş gibi görünüyor. Bu tercihin kendisi yanlış değil ama şirketin başladığı ve büyüdüğü biçimden epey farklı bir yöne itiyorlar.
    Proton Pass de biraz ilginç, ancak diğer Proton servislerinde olduğu gibi fiyat modeli her zaman biraz yüksek tarafta. Bir süredir ücretsiz Proton Pass kullanıyorum; Bitwarden uzun yıllardır beklediğim yönde iyileşmediği için alternatif olarak geçmeye değip değmeyeceğine bakacağım.
    iOS’un yerleşik parola yöneticisi de yeterince iyi, fakat yalnızca parolalara yönelik; başka tür verileri saklama, arama ve otomatik doldurma işlevlerini desteklemiyor.

    • İronik. Bazı şirketler Bitwarden’ı tam da açık olduğu ve çok yararlı bir şeyi kullanmak için kurumsal satış görüşmesinden geçmek gerekmediği için kullanıyor olabilir.
      Ürünü kullanmayı zorlaştırırsanız müşteri ve satış fırsatı kaybedersiniz. Yakın zamanda Postman ile yaptığım berbat görüşmeler aklıma geliyor. Bir görüşme daha yapmaktansa artık Hoppscotch çok daha iyi görünüyor.
    • Girişim sermayesi neden neredeyse her zaman her şeyi mahvediyor?

  • CTO’nun yanıtı, SDK kullanım kapsamını daha fazla istemci senaryosuna genişlettiklerini, ancak hedefin SDK’nın GPL uyumluluğunu koruyacak şekilde kullanılması olduğunu söylüyor.
    SDK ile istemcinin ayrı programlar olduğu, her programın kodunun ayrı depolarda bulunduğu ve iki programın standart bir protokolle iletişim kurmasının tek başına GPLv3 kapsamında tek bir program oluşturmaya yetmeyeceği görüşündeler. Burada denenen yöntemle uygulamanın derlenebilmesi gerektiği sorununun da çözülecek basit bir hata olduğunu söylüyorlar.

    • Bu tür yanıtlar gerçekten sinir bozucu. Çünkü sorunun kapsamını kasıtlı olarak yanlış anlamış gibi yapıp asıl sorudan kaçıyorlar.
      CTO’ya sormak istediğim kabaca şu: “Avukatlarınız bunun hukuken etrafından dolaşabileceğinizi mi düşünüyor?” sorusunu yanıtlamışsınız ama insanların endişelendiği asıl soruya yanıt vermediniz. Bitwarden ekibi, pek çok kişinin özellikle açık kaynak olduğu için desteklediği ve katkı verdiği bir projeyi özelleştirmenin etik bir sorun taşımadığını mı düşünüyor? Parola yönetimi doğası gereği yüksek güven gerektiren bir iş; açık kaynaktan kapalı kaynağa geçiş şeklindeki bu rug pull’un yaratacağı güven kırılmasını, fork’ları ve ayrılmaları nasıl yönetmeyi planlıyorsunuz? Şirket böyle bir kararı düşünecek kadar zor durumdaysa, topluluğun birlikte yardım edip özelleştirme olmadan bu dönemi atlatmasının bir yolu yok mu?
      CTO olarak şu anda görevin endişeliymiş gibi davranmak olduğunu, özellikle de konuşmayı kapatamayacağınız forumlarda bunun böyle olduğunu anlıyorum; ama mevcut yaklaşım “bunun hukuken mümkün olduğuna inanıyoruz ve davranışımızda bir sorun görmüyoruz” şeklindeki en kötü korkuları fiilen doğruluyor. Gelir elde etmek için kullanıcıların koda ve güncelleme yapan insanlara güvenmesi gereken bir şirket için bu tam olarak yanlış hava.
    • Başka bir deyişle bitwarden/clients GPLv3, çalışan bir bütün olarak Bitwarden istemcisi ise tescilli yazılım ve CTO bunda bir sorun görmüyor; issue da kilitlenmiş demek.
    • Asıl mesele bunun mutlaka “tek bir program” olup olmaması değil. Sorun şu kısım:
      “‘Nesne kodu biçimindeki’ bir çalışmanın ‘karşılık gelen kaynağı’, nesne kodunu oluşturmak, kurmak, çalıştırmak ve çalışmayı değiştirmek için gereken tüm kaynak kodunu ve bu faaliyetleri kontrol eden betikleri içerir.”
      Açık kaynak şirketi olarak para kazanmanın gerçekten zor olduğunu anlıyorum. Bu yüzden ben de ücretli müşterilerden biriyim.
      SDK’ya ekledikleri istisna koşulu, bir dönem Linux çekirdeğinde kullanılan BitKeeper sürüm kontrol yazılımına çok benziyor. Sonunun nasıl olduğuna bakmak yeterli.

  • Sevmiştim, para da ödemiştim, arkadaşlarıma önermiştim; onlar da sevmişti.
    Şimdi KeePassXC’ye geçmeyi düşünüyorum. Android ile veritabanını senkronize etmek için önerilen yöntem nedir? Elimde yalnızca cloudflared çalıştıran bir Raspberry Pi sunucusu var.

    • Dosya taşımanın yol açtığı senkronizasyon çakışmalarına dönmeden bulut rahatlığını korumak istiyorsanız Proton Pass GPLv3. Ancak ileride rug pull yapmaları durumunda kendi kendine barındırma durumunun nasıl olacağını şahsen bilmiyorum.
      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 ile KeePass kasasını yalnızca gereken cihazlara tam olarak dağıtıp kullanıyorum. Bende çok iyi çalışıyor. İhtiyaca göre değişebilir.

  • KeePass’i ve ekosistemini gerçekten kullanmak istiyorum ama parola paylaşımı pek iyi değil. Eşimle benim çok sayıda ortak parolamız var ve Bitwarden bu konuda çok iyi çalışıyor. Bizim için pratik bir alternatifin ne olduğunu bilmiyorum.

  • Keepass2Android, ssh(sftp), Nextcloud vb. birçok yöntemle senkronize edilebiliyor. Size uyan yöntemi bulabilirsiniz.

  • KeePassXC ile Android için Nextcloud istemcisi kombinasyonu benim için mükemmel. Yıllardır sorunsuz kullanıyorum.

  • GitHub issue’sunu daha fazla tartışılmasın diye kilitlemişler. Olası alternatiflerden biri Vaultwarden gibi görünüyor.
    https://github.com/dani-garcia/vaultwarden
    Paralı insanlar işin içine girince açık kaynak projelerde böyle şeylerin sürekli yaşanması gerçekten üzücü.

    • Vaultwarden bir sunucu ikamesi; burada sorun, anladığım kadarıyla masaüstü istemci lisansı.
    • García yakın zamanda Bitwarden’da çalışmaya başladı. Onun ne düşündüğünü duymak ilginç olurdu.
    • Vaultwarden passkey destekliyor mu?

  • Ayrıntılı bakmış değildim ama pazarlamasına bakarak Bitwarden’ın tamamen özgür yazılım olduğunu sanıyordum. Ancak 2020 civarından beri tuhaf bazı tescilli unsurlar girmiş gibi görünüyor.

  • Bir gün Bitwarden’a geçmeyi umuyordum ama sağlıklı bir açık ekosistem bulamazsam artık geçmeyecek gibiyim. Nasıl gelişeceğini izlemeye devam edeceğim.

    • 1 yıl boyunca Vaultwarden backend’iyle Bitwarden’a tamamen geçmeyi denedim; daha önce kullandığım 1Password ile karşılaştırınca deneyim ciddi ölçüde daha kötüydü.
      Değerlendirme ölçütlerimden biri “Ailemdeki herkes 1Password kullanıyor ve memnun; bu haliyle onları geçmeye ikna edebilir miyim?” idi. Nihai geçiş kararını ben verebilirim ama yaşlı ebeveynlere yeni bir şey yaptırmak için kullanıcı deneyimi çok önemli.
      Sonuç olarak cevap hayırdı. Genel olarak UX’in kötü olmasının yanı sıra Bitwarden istemcisi Linux, Mac, Windows ve iOS’ta çok daha yavaştı; aramadan oturum açmaya kadar her şeyde böyleydi. Özellikleri de daha azdı; parola sıralama, favoriler, iyi düzenleme araçları gibi göze çarpan şeyler eksikti ve otomatik doldurma da çok daha az güvenilirdi.
      1Password’ün iş yapma biçimi ve müşteriyle iletişimi konusunda yıllardır ciddi memnuniyetsizliklerim vardı. Yine de parola yöneticisi — artık paroladan fazlasını taşıyan bir sır yöneticisine daha yakın bir araç — günlük hayatın merkezinde olduğu için mümkün olduğunca az acı veren şeyi kullanmak gerektiğini hissettim ve ne yazık ki geri döndüm.
      Bitwarden’ı açık kaynak olduğu için kullanmadım; mümkün olan en iyi parola yöneticisini kullanmaya çalışıyordum. Yine de açık olması hoşuma gidiyordu ve Vaultwarden bir mücevher gibi. Keşke gerçekten daha iyi bir frontend yapacak zamanım ve becerim olsaydı.

  • “Şu an için SDK lisansını ayarlama planımız yok. Kendi F-Droid depomuzda https://mobileapp.bitwarden.com/fdroid/repo/ yayımlamaya devam edeceğiz.”
    https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
    Bu sorun SDK deposunda zaten temmuz ayında gündeme getirilmişti ve söz konusu SDK bir yıldan uzun süredir bu lisansa sahipti.

  • iOS, PC ve Mac’te Bitwarden kullanıyorum. Artık alternatif aramam gerekiyor. Gerçekten üzücü bir gün.
    Ben de yıllık 10 dolarlık premium üyeyim. Şüpheli uygulamalar yüzünden kaybedilmiş gelir sayılır.
    Dışa aktarıp başka bir alternatife geçmenin bir yolu var mı?

  • Benim için daha iyi bir Keepass(X,XC) alternatifi olabilir mi diye takip ettiğim bir projeydi; artık sonunda geçmeyecek gibiyim.