Bitwarden chấm dứt phần mềm tự do

 (github.com/bitwarden)
1 điểm bởi GN⁺ 2024-10-21 | 2 bình luận | Chia sẻ qua WhatsApp
  • Bản dựng Bitwarden Desktop 2024.10.0 nay yêu cầu phụ thuộc @bitwarden/sdk-internal, và đã có vấn đề được nêu ra rằng điều khoản giấy phép của SDK này giới hạn “không được dùng để phát triển ứng dụng cho phần mềm ngoài Bitwarden hoặc SDK khác”, từ đó phá vỡ các yêu cầu của phần mềm tự do
  • Người nêu vấn đề cho rằng hạn chế này vi phạm freedom 0 của GNU, và cho biết nếu bỏ phụ thuộc đó thì không thể build desktop-v2024.10.0 và cả nhánh master hiện tại
  • Trong trường hợp tái hiện, nếu xóa thư mục bitwarden_license và dọn node_modules rồi build, bước build:preload sẽ thất bại với 6 lỗi TS2307 do không tìm thấy @bitwarden/sdk-internal và mô-đun WASM
  • Một số bình luận chỉ ra rằng SDK này được dùng làm feature flag không chỉ ở Desktop mà còn trong browser, CLI, web clients; phía Bitwarden trả lời rằng SDK và client là các chương trình riêng biệt, và theo góc nhìn GPLv3 thì việc chỉ giao tiếp qua giao thức chuẩn không khiến chúng trở thành một chương trình duy nhất
  • Sau đó Bitwarden đã điều chỉnh cấu trúc mã và cách đóng gói SDK để có thể build chỉ với giấy phép GPL/OSI, rồi chuyển tham chiếu sdk-internal của client sang kho lưu trữ sdk-internal mới và đánh dấu issue là đã hoàn tất

Vấn đề được nêu ra: Bản dựng Desktop 2024.10.0 và giấy phép SDK

  • Issue được mở với lập luận rằng Bitwarden Desktop 2024.10.0 không còn là phần mềm tự do nữa
  • Thay đổi cốt lõi là pull request #10974 đã đưa phụ thuộc @bitwarden/sdk-internal vào bản dựng client desktop
  • Giấy phép của phụ thuộc này có chứa hạn chế sau
    • “Không được sử dụng SDK này để phát triển ứng dụng cho phần mềm ngoài Bitwarden, bao gồm cả phần mềm có triển khai không tương thích với Bitwarden, và cũng không được dùng để phát triển SDK khác”
  • Người nêu vấn đề cho rằng điều khoản này vi phạm freedom 0 trong định nghĩa phần mềm tự do của GNU
  • Đồng thời, họ cho biết nếu không loại bỏ phụ thuộc này thì không thể build desktop-v2024.10.0, và có lẽ cả nhánh master hiện tại

Lỗi build được tái hiện

  • Người nêu vấn đề đã thử build theo cách cũ, tức là xóa thư mục bitwarden_license và dùng node_modules đã được dọn sạch
  • Quá trình build thất bại ở bước build:preload của apps/desktop
  • Lỗi là TS2307, báo không tìm thấy mô-đun @bitwarden/sdk-internal hoặc phần khai báo kiểu trong nhiều tệp
    • 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
  • Ngoài ra còn có lỗi không tìm thấy đường dẫn WASM @bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasm
  • Kết quả là webpack 5.94.0 biên dịch thất bại với 6 lỗi, và npm run build:preload thoát với mã 1

Phản ứng của cộng đồng và lo ngại mở rộng

  • Một bình luận nhắc đến issue liên quan bitwarden/sdk-sm#898, bày tỏ lo ngại rằng Bitwarden quảng bá mình là mã nguồn mở nhưng đang chuyển sang phần mềm độc quyền
  • Một người dùng khác cho biết họ đã báo cáo vấn đề tương tự trong bản phát hành NPM của client CLI qua #10648 từ hai tháng trước nhưng không nhận được phản hồi
  • Một số người dùng nêu các lựa chọn thay thế như fork phiên bản cũ, Vaultwarden, hoặc ứng dụng desktop Tauri bọc giao diện web của Vaultwarden
  • Một bình luận lưu ý rằng với sản phẩm xử lý mật khẩu, việc chuyển sang “bất kỳ lựa chọn thay thế nào” cũng cần thận trọng, và chỉ fork client thôi vẫn để lại vấn đề phụ thuộc vào dịch vụ máy chủ hoặc phần mềm máy chủ
  • Một bình luận khác cho rằng SDK này không chỉ được dùng trong bản phát hành Desktop mà còn làm feature flag trong browser, CLI, web clients, và viết rằng mọi phiên bản của Bitwarden 2024.10.0 đều dùng SDK này

Phản hồi ban đầu từ phía Bitwarden

  • Một thành viên Bitwarden trả lời rằng họ đã mở rộng phạm vi sử dụng SDK trong client, nhưng mục tiêu là bảo đảm việc dùng SDK vẫn giữ được tính tương thích GPL
  • Phía Bitwarden đưa ra ba cơ sở sau
    • SDK và client là các chương trình riêng biệt
    • Mã của mỗi chương trình nằm ở các kho lưu trữ riêng
    • Chỉ vì hai chương trình giao tiếp qua giao thức chuẩn thì không có nghĩa chúng trở thành một chương trình duy nhất theo mục đích của GPLv3
  • Họ cho biết việc không thể build ứng dụng theo cách người dùng đã thử là một bug và sẽ được khắc phục
  • Sau đó cuộc thảo luận bị Bitwarden khóa và giới hạn cho collaborator

Điều chỉnh cuối cùng và kết thúc

  • Bitwarden cho biết họ đã điều chỉnh cấu trúc mã SDK và cách đóng gói để có thể build và chạy ứng dụng trong trạng thái chỉ bao gồm giấy phép GPL/OSI
  • Tham chiếu gói sdk-internal trong client được đổi sang lấy từ sdk-internal repository mới
  • Họ giải thích rằng kho sdk-internal mới theo mô hình giấy phép mà Bitwarden đã dùng cho client trước đây, và dẫn LICENSE_FAQ.md làm tài liệu tham khảo
  • Hiện tại tham chiếu sdk-internal chỉ dùng giấy phép GPL
  • Họ cũng cho biết nếu trong tương lai tham chiếu đó có bao gồm mã theo Bitwarden License, thì sẽ cung cấp cách tạo nhiều biến thể build tương tự như bản dựng web vault client
  • Kho sdk repository cũ được đổi tên thành sdk-secrets, và tiếp tục giữ cấu trúc Bitwarden SDK License hiện có cho sản phẩm doanh nghiệp Secrets Manager
  • Vì mã trong kho và gói sdk-secrets không được dùng trong các ứng dụng client, chúng sẽ không còn bị tham chiếu từ ứng dụng client nữa
  • Issue được đóng với trạng thái completed vào ngày 25 tháng 10 năm 2024

Bài viết liên quan

2 bình luận

 
tribela 2024-10-21

Tôi rất thích dùng KeePass, nhưng vì ai cũng chỉ nhắc đến Bitwarden nên tôi cũng định thử một lần; thôi thì cứ tiếp tục dùng KeePass vậy. Vì đây không phải kiểu phụ thuộc vào máy chủ mà chỉ cần lưu trữ tệp cẩn thận là được, nên tính sẵn sàng cao hơn nhiều và KeePass hợp gu của tôi hơn.
 
GN⁺ 2024-10-21
Ý kiến trên Hacker News

  • Tôi trả tiền vì kỳ vọng mình đang ủng hộ mã nguồn mở, nên mới chuyển từ LastPass sang Bitwarden
    Chuyện này có cảm giác như bị xoáy sâu thêm con dao sau lưng. Có vẻ họ đã đến một bước ngoặt tài chính tương tự lúc CEO Michael Crandell bán RightScale, nên có lẽ đang chuẩn bị cho việc bị mua lại: https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

    • Ngay cả trong tài liệu năm 2022 trên trang đó, dưới mục “Điều gì sẽ thay đổi?”, Bitwarden vẫn viết rằng họ sẽ tiếp tục duy trì kiến trúc mã nguồn mở
      Giờ thì có vẻ không còn như vậy nữa. Đây là một động thái nguy hiểm. Mã nguồn mở có nhiều đặc tính tốt, nhưng điều quan trọng ở đây là bảo mật. Việc các công ty đưa ra những khối binary mù mờ rồi bảo là an toàn luôn khiến tôi ngạc nhiên. Intel Management Engine là một ví dụ, và giờ Bitwarden cũng như gia nhập hàng ngũ IME và switch Juniper vậy
      Chuyển sang mã nguồn đóng là một lựa chọn rủi ro cao. Lâu nay tôi không trả tiền cho bản thân phần mềm, nhưng tôi có thể và thực sự sẵn sàng trả tiền cho bảo mật. Tôi trả tiền cho Bitwarden vì nó lưu trữ những gì tôi coi là thông tin riêng tư và quý giá nhất của mình. Nhưng suy cho cùng thì nó vẫn chỉ là phần mềm, và việc các byte được gọi là “bitwarden” đến từ đâu không quan trọng. Bất kỳ ai cũng có thể fork và cung cấp cùng những byte đó. Nếu có một mirror Bitwarden chỉ dùng phần mềm mã nguồn mở, tiền của tôi sẽ chuyển sang đó. Còn tốt hơn nữa nếu có hướng dẫn build để có thể tái tạo chính xác binary đang chạy và binary tôi tải xuống trên nhiều thiết bị. Tôi không cho rằng mật khẩu của mình là an toàn nếu không được quản lý bởi phần mềm mã nguồn mở

  • Động thái này không làm tôi ngạc nhiên nhiều. Bitwarden đã chuyển mạnh sang phía bán hàng cho doanh nghiệp trong vài năm qua, và trong lúc đó thì mảng người dùng cá nhân bị bỏ mặc
    Chỉ gần đây họ mới chuyển từ nền tảng MAUI cũ sang ứng dụng iOS native, còn ứng dụng trước đây thì lệch chuẩn quá nhiều ở nhiều mặt. Ngay cả client iOS hiện tại vẫn còn nhiều điểm cần bắt kịp
    Sau khi nhận vốn đầu tư mạo hiểm, có vẻ họ nghiêng hơn về doanh thu và lợi nhuận. Bản thân lựa chọn đó không sai, nhưng nó đang đẩy công ty theo một hướng khá khác so với cách họ đã khởi đầu và phát triển
    Proton Pass cũng hơi thú vị, nhưng giống các dịch vụ khác của Proton, mô hình giá của họ lúc nào cũng có phần hơi cao. Tôi đã dùng Proton Pass bản miễn phí một thời gian, và vì Bitwarden chưa cải thiện theo hướng mà tôi chờ đợi suốt nhiều năm, tôi sẽ xem liệu có đáng để chuyển sang giải pháp thay thế đó không
    Trình quản lý mật khẩu tích hợp của iOS cũng đủ ổn, nhưng nó chỉ dành cho mật khẩu và không hỗ trợ lưu trữ, tìm kiếm hay tự động điền các loại dữ liệu khác

    • Thật mỉa mai. Một số công ty có khi lại dùng Bitwarden chính vì nó cởi mở, và vì có thể dùng một thứ rất hữu ích mà không cần phải trải qua các cuộc gọi bán hàng cho doanh nghiệp
      Khi bạn làm cho sản phẩm khó dùng hơn, bạn sẽ mất khách hàng và cả cơ hội bán hàng. Tôi lại nhớ đến những cuộc gọi kinh khủng gần đây với Postman. Nếu phải gọi thêm lần nữa thì giờ Hoppscotch trông hấp dẫn hơn nhiều
    • Tại sao gần như lúc nào vốn đầu tư mạo hiểm cũng làm hỏng mọi thứ vậy

  • Phản hồi của CTO nói rằng họ đã mở rộng phạm vi dùng SDK sang nhiều trường hợp client hơn, nhưng mục tiêu là để SDK được dùng theo cách vẫn giữ tính tương thích GPL
    Họ cho rằng SDK và client là các chương trình riêng biệt, mã của mỗi chương trình nằm ở các repository riêng, và việc hai chương trình giao tiếp qua giao thức chuẩn không tự động khiến chúng trở thành một chương trình duy nhất theo GPLv3. Vấn đề không build được ứng dụng theo cách đã thử ở đây được nói là chỉ là một lỗi đơn giản và sẽ được sửa

    • Những kiểu trả lời như vậy thật sự rất bực mình. Chúng né câu hỏi thực sự bằng cách cố tình hiểu sai phạm vi câu hỏi
      Điều tôi muốn hỏi CTO đại khái là thế này. Ông đã trả lời câu “Các luật sư của công ty có cho rằng việc này về mặt pháp lý là lách được không?”, nhưng lại không trả lời câu cốt lõi mà mọi người lo ngại. Đội ngũ Bitwarden có cho rằng không có vấn đề đạo đức gì trong việc tư hữu hóa một dự án mà nhiều người đã ủng hộ và đóng góp chính vì nó rõ ràng là mã nguồn mở hay không? Quản lý mật khẩu vốn là một ngành đòi hỏi mức độ tin cậy rất cao, vậy họ định xử lý thế nào với sự đổ vỡ niềm tin, các bản fork và làn sóng rời bỏ sẽ phát sinh từ cú rug pull chuyển từ mã nguồn mở sang mã nguồn đóng? Nếu công ty đang tuyệt vọng đến mức phải cân nhắc những quyết định như vậy, thì liệu có cách nào để cộng đồng cùng giúp họ vượt qua mà không cần tư hữu hóa hay không?
      Tôi hiểu rằng với tư cách CTO thì lúc này công việc của ông là tỏ ra quan tâm, nhất là trên một diễn đàn nơi không thể đơn giản đóng cuộc trò chuyện lại, nhưng cách tiếp cận hiện tại thực chất xác nhận nỗi sợ tệ nhất: họ tin rằng việc này là hợp pháp và không thấy có vấn đề gì trong hành động của mình. Đó chính xác là kiểu tín hiệu sai lầm đối với một công ty kiếm tiền nhờ người dùng phải tin vào code và những người đẩy bản cập nhật
    • Nói cách khác, bitwarden/clients là GPLv3, còn Bitwarden client như một tổng thể đang hoạt động là phần mềm độc quyền; CTO cho rằng điều đó không có vấn đề gì, và issue thì đã bị khóa
    • Không nhất thiết trọng tâm nằm ở việc nó có phải là “một chương trình” hay không. Vấn đề là đoạn này
      “Corresponding Source for a work in object code form means all the source code needed to generate, install, and run the object code and to modify the work, including scripts to control those activities.”
      Tôi hiểu là kiếm tiền với một công ty mã nguồn mở thực sự rất khó. Vì thế tôi cũng là một trong những khách hàng trả phí
      Điều khoản loại trừ họ gắn vào SDK trông rất giống phần mềm quản lý phiên bản BitKeeper từng được dùng cho Linux kernel một thời gian. Cứ nhìn kết cục của chuyện đó là rõ

  • Tôi đã thích nó, đã trả tiền, còn giới thiệu cho bạn bè, và họ cũng thích
    Giờ tôi định chuyển sang KeePassXC. Có cách nào được khuyến nghị để đồng bộ cơ sở dữ liệu với Android không? Tôi chỉ có một máy chủ Raspberry Pi đang chạy cloudflared

    • Nếu muốn giữ sự tiện lợi của đám mây mà không quay lại cảnh xung đột đồng bộ do di chuyển file gây ra, thì Proton Pass là GPLv3. Tuy vậy, nếu sau này họ rug pull thì cá nhân tôi không rõ tình hình self-host sẽ ra sao
      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>;)

  • Dùng SyncThing để phân phối chính xác kho KeePass chỉ tới những thiết bị cần thiết. Với tôi thì nó hoạt động rất tốt. Có thể sẽ khác tùy nhu cầu

  • Tôi thực sự muốn dùng KeePass và cả hệ sinh thái của nó, nhưng chia sẻ mật khẩu không được ổn lắm. Tôi và vợ có nhiều mật khẩu dùng chung, và Bitwarden làm phần đó rất tốt. Tôi không biết đâu là lựa chọn thay thế thực tế cho chúng tôi

  • Keepass2Android có thể đồng bộ bằng nhiều cách như ssh(sftp), Nextcloud, v.v. Có lẽ bạn sẽ tìm được cách phù hợp

  • Kết hợp KeePassXC với ứng dụng khách Nextcloud trên Android là hoàn hảo với tôi. Tôi đã dùng nhiều năm mà không gặp vấn đề gì

  • Họ đã khóa GitHub issue để không thể thảo luận thêm nữa. Một trong những lựa chọn thay thế khả dĩ có vẻ là Vaultwarden
    https://github.com/dani-garcia/vaultwarden
    Thật đáng buồn khi cứ có người có tiền nhảy vào là những chuyện như thế này lại tiếp diễn trong các dự án mã nguồn mở

    • Vaultwarden là bản thay thế phía máy chủ, còn vấn đề ở đây, theo như tôi hiểu, là giấy phép của ứng dụng desktop
    • García gần đây đã bắt đầu làm việc tại Bitwarden. Sẽ rất thú vị nếu được nghe quan điểm của anh ấy
    • Vaultwarden có hỗ trợ passkey không?

  • Tôi chưa xem kỹ, nhưng chỉ nhìn phần marketing thì tôi đã nghĩ Bitwarden hoàn toàn là phần mềm tự do. Nhưng có vẻ từ khoảng năm 2020 họ đã đưa vào những yếu tố độc quyền kỳ lạ

  • Có lúc tôi đã hy vọng sẽ chuyển sang Bitwarden, nhưng giờ có lẽ sẽ không nữa nếu không tìm thấy một hệ sinh thái mở lành mạnh. Tôi sẽ tiếp tục theo dõi xem mọi chuyện diễn biến thế nào

    • Tôi đã thử chuyển hẳn sang Bitwarden với backend Vaultwarden trong 1 năm, nhưng trải nghiệm kém hơn rất nhiều so với 1Password mà tôi dùng trước đó
      Một trong những tiêu chí đánh giá của tôi là: “Cả gia đình đều đang dùng 1Password và hài lòng, vậy mức này có đủ để thuyết phục họ chuyển sang không?” Tôi có thể tự quyết định việc chuyển đổi cuối cùng, nhưng để bố mẹ lớn tuổi của tôi dùng một thứ mới thì trải nghiệm người dùng là cực kỳ quan trọng
      Kết quả là không. Ngoài việc UX nói chung không tốt, ứng dụng Bitwarden còn chậm hơn nhiều trên Linux, Mac, Windows và iOS, từ tìm kiếm đến đăng nhập, mọi thứ đều vậy. Tính năng cũng ít hơn, thiếu những thứ dễ thấy như sắp xếp mật khẩu, đánh dấu yêu thích, công cụ tổ chức tốt, và tự động điền cũng kém ổn định hơn nhiều
      Trong nhiều năm tôi đã có những bất mãn lớn với cách 1Password kinh doanh và ứng xử với khách hàng. Dù vậy, tôi cảm thấy một trình quản lý mật khẩu — giờ gần như là một trình quản lý bí mật chứa nhiều thứ hơn mật khẩu — là công cụ ở trung tâm đời sống hằng ngày, nên phải dùng thứ nào gây ít đau đớn nhất có thể, và đáng tiếc là tôi đã quay lại
      Tôi không dùng Bitwarden vì nó là mã nguồn mở, mà vì muốn dùng trình quản lý mật khẩu tốt nhất có thể. Dù vậy, tính mở của nó vẫn là điều tôi thích, và Vaultwarden là một viên ngọc quý. Tôi thực sự ước mình có thời gian và kỹ năng để làm một frontend tốt hơn

  • “Hiện tại, chúng tôi không có kế hoạch điều chỉnh giấy phép SDK. Chúng tôi sẽ tiếp tục phát hành trên kho F-Droid riêng của mình https://mobileapp.bitwarden.com/fdroid/repo/.”
    https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
    Vấn đề này đã được nêu ra từ tháng 7 trong kho SDK, và SDK đó đã dùng giấy phép này hơn 1 năm rồi

  • Tôi đang dùng Bitwarden trên iOS, PC và Mac. Giờ tôi phải tìm giải pháp thay thế. Thật sự là một ngày buồn
    Tôi cũng là thành viên premium 10 USD/năm. Thành ra đây là doanh thu bị mất vì những cách làm đáng ngờ
    Có cách nào để xuất dữ liệu rồi chuyển sang lựa chọn khác không?

  • Đây là dự án mà tôi đã theo dõi vì nghĩ nó có thể là lựa chọn thay thế tốt hơn cho Keepass(X,XC), nhưng giờ có vẻ cuối cùng tôi sẽ không chuyển sang nữa