Bitwarden 무료 소프트웨어 종료

 (github.com/bitwarden)
1P by GN⁺ | ★ favorite | 댓글 2개
  • Bitwarden Desktop 2024.10.0 빌드에 @bitwarden/sdk-internal 의존성이 필요해졌고, 해당 SDK 라이선스 조항이 “Bitwarden 외 소프트웨어용 앱이나 다른 SDK 개발에 사용할 수 없다”고 제한해 자유 소프트웨어 요건을 깨뜨린다는 이슈가 제기됨
  • 문제 제기자는 이 제한이 GNU의 freedom 0을 위반하며, 해당 의존성을 제거하면 desktop-v2024.10.0과 현재 master를 빌드할 수 없다고 밝힘
  • 재현 사례로 bitwarden_license 디렉터리를 제거하고 node_modules를 정리한 상태에서 빌드하면 @bitwarden/sdk-internal 및 WASM 모듈을 찾지 못하는 TS2307 오류 6개로 build:preload가 실패함
  • 일부 댓글은 SDK가 Desktop뿐 아니라 browser, CLI, web clients에서도 기능 플래그로 사용된다고 지적했고, Bitwarden 측은 SDK와 클라이언트가 별도 프로그램이며 GPLv3 관점에서 표준 프로토콜 통신만으로 하나의 프로그램이 되지는 않는다고 답함
  • Bitwarden은 이후 SDK 코드 구성과 패키징을 조정해 GPL/OSI 라이선스만 포함한 빌드가 가능하게 했고, 클라이언트의 sdk-internal 참조를 새 sdk-internal 저장소로 옮긴 뒤 이슈를 완료 처리함

제기된 문제: Desktop 2024.10.0 빌드와 SDK 라이선스

  • 이슈는 Bitwarden Desktop 2024.10.0이 더 이상 자유 소프트웨어가 아니라는 문제 제기로 열림
  • 핵심 변경은 Pull request #10974가 데스크톱 클라이언트 빌드에 @bitwarden/sdk-internal 의존성을 도입한 점임
  • 해당 의존성의 라이선스에는 다음 제한이 포함됨
    • “이 SDK를 Bitwarden 외 소프트웨어, Bitwarden과 호환되지 않는 구현을 포함한 소프트웨어용 애플리케이션 개발에 사용할 수 없고, 다른 SDK 개발에도 사용할 수 없다”
  • 문제 제기자는 이 조항이 GNU 자유 소프트웨어 정의의 freedom 0을 위반한다고 봄
  • 또한 이 의존성을 제거하지 않고는 desktop-v2024.10.0, 그리고 아마도 현재 master를 빌드할 수 없다고 밝힘

재현된 빌드 실패

  • 문제 제기자는 기존 방식처럼 bitwarden_license 디렉터리를 제거하고 정리된 node_modules로 빌드를 시도함
  • 빌드는 apps/desktop의 build:preload 단계에서 실패함
  • 오류는 여러 파일에서 @bitwarden/sdk-internal 모듈 또는 타입 선언을 찾을 수 없다는 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 경로인 @bitwarden/sdk-internal/bitwarden_wasm_internal_bg.wasm도 찾을 수 없다는 오류가 발생함
  • 결과적으로 webpack 5.94.0이 6개 오류로 컴파일에 실패하고, npm run build:preload가 코드 1로 종료됨

커뮤니티 반응과 확장된 우려

  • 한 댓글은 관련 이슈로 bitwarden/sdk-sm#898을 언급하며, Bitwarden이 오픈소스로 광고하면서 독점 소프트웨어로 전환하고 있다는 우려를 제기함
  • 다른 사용자는 CLI 클라이언트의 NPM 릴리스에서도 비슷한 문제를 #10648로 두 달 전에 보고했지만 응답을 받지 못했다고 밝힘
  • 일부 사용자는 대안으로 이전 버전 포크, Vaultwarden, Vaultwarden 웹 인터페이스를 감싸는 Tauri 데스크톱 앱 등을 언급함
  • 한 댓글은 비밀번호를 다루는 제품 특성상 “아무 대안”으로 옮기는 것은 조심해야 하며, 클라이언트 포크만으로는 서버 서비스나 서버 소프트웨어 의존 문제가 남는다고 지적함
  • 또 다른 댓글은 SDK가 Desktop 릴리스뿐 아니라 browser, CLI, web clients에서도 기능 플래그로 사용된다고 주장하며, Bitwarden 2024.10.0의 모든 버전이 SDK를 사용한다고 적음

Bitwarden 측의 초기 답변

  • Bitwarden 측 구성원은 클라이언트에서 SDK 사용 범위를 넓혀 왔지만, 목표는 SDK 사용이 GPL 호환성을 유지하도록 하는 것이라고 답함
  • Bitwarden 측은 다음 세 가지 근거를 제시함
    • SDK와 클라이언트는 별도 프로그램임
    • 각 프로그램의 코드는 별도 저장소에 있음
    • 두 프로그램이 표준 프로토콜로 통신한다는 사실만으로 GPLv3 목적상 하나의 프로그램이 되지는 않음
  • 사용자가 시도한 방식으로 앱을 빌드할 수 없는 문제는 해결할 예정인 버그라고 밝힘
  • 이후 대화는 Bitwarden에 의해 잠기고 collaborator로 제한됨

최종 조정과 종료

  • Bitwarden은 SDK 코드의 구성과 패키징 방식을 조정해 GPL/OSI 라이선스만 포함한 상태로 앱을 빌드하고 실행할 수 있게 했다고 밝힘
  • 클라이언트의 sdk-internal 패키지 참조는 새 sdk-internal repository에서 오도록 변경됨
  • 새 sdk-internal 저장소는 Bitwarden이 기존 클라이언트에 사용해 온 라이선스 모델을 따른다고 설명했고, 관련 정보로 LICENSE_FAQ.md를 제시함
  • 현재 sdk-internal 참조는 GPL 라이선스만 사용함
  • 향후 해당 참조에 Bitwarden License 코드가 포함된다면, web vault 클라이언트 빌드와 비슷하게 여러 빌드 변형을 만들 수 있는 방법을 제공하겠다고 밝힘
  • 기존 sdk repository는 sdk-secrets로 이름이 바뀌며, Secrets Manager 비즈니스 제품을 위한 기존 Bitwarden SDK License 구조를 유지함
  • sdk-secrets 저장소와 패키지는 클라이언트 앱에서 사용되지 않는 코드이므로 더 이상 클라이언트 앱에서 참조되지 않음
  • 이슈는 2024년 10월 25일 completed로 종료됨

함께 보면 좋은 글 β

tribela   [-]

저는 Keepass를 애용하는데 사람들이 하도 Bitwarden 이야기만 해서 한번 써볼까 싶었는데 그냥 Keepass를 유지해야겠습니다. 서버 방식이 아니라 파일만 잘 보관하면 되는 방식이라 훨씬 더 가용성이 높아 제 입맛엔 Keepass가 더 맞습니다

답변달기
GN⁺   [-]
Hacker News 의견들

  • 비용을 낸 건 오픈소스를 지원한다는 기대 때문이었고, 그래서 LastPass에서 Bitwarden으로 옮겼음
    이번 일은 등에 꽂힌 칼을 비트는 느낌임. CEO Michael Crandell이 RightScale을 팔 때와 비슷한 재무 변곡점에 도달했으니 인수를 준비하는 것 같음: https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

    • 그 페이지의 2022년 자료에도 “무엇이 바뀌나?” 아래에 Bitwarden은 오픈소스 아키텍처를 계속 지키겠다고 적혀 있었음
      이제는 아닌 듯함. 위험한 움직임. 오픈소스에는 좋은 성질이 많지만, 여기서 중요한 건 보안임. 회사들이 불투명한 바이너리 덩어리를 안전하다고 내세우는 건 늘 놀라움. Intel Management Engine도 그렇고, 이제 Bitwarden도 IME와 Juniper 스위치 대열에 합류한 셈임
      폐쇄 소스로 가는 건 고위험 선택임. 오랫동안 소프트웨어 자체에는 돈을 안 냈지만 보안에는 돈을 낼 수 있고 실제로 냄. Bitwarden은 내가 가장 소중하고 사적인 정보라고 여기는 것을 저장하기 때문에 돈을 내는 것임. 하지만 결국 소프트웨어일 뿐이고, “bitwarden”이라고 부르는 바이트가 어디서 오느냐는 중요하지 않음. 누구든 포크해서 같은 바이트를 제공할 수 있음. 오픈소스 소프트웨어만 쓰는 Bitwarden 미러를 운영한다면 내 돈은 그쪽으로 갈 것임. 실행 중인 바이너리와 내가 여러 기기에 내려받는 바이너리를 동일하게 재현할 수 있는 빌드 지침까지 있으면 더 좋겠음. 내 비밀번호는 오픈소스 소프트웨어가 관리하지 않는 한 안전하다고 보지 않음

  • 이번 움직임이 크게 놀랍지는 않음. Bitwarden은 지난 몇 년간 기업 영업 쪽으로 강하게 이동했고, 그러는 동안 소비자 쪽은 방치했음
    최근에야 이전의 MAUI 기반에서 네이티브 iOS 앱으로 바뀌었는데, 예전 앱은 여러 면에서 너무 튀었음. 지금 iOS 클라이언트도 아직 따라잡을 부분이 남아 있음
    벤처 투자금을 받은 뒤에는 매출과 이익 중심으로 더 기운 것 같음. 그 선택 자체가 잘못은 아니지만, 회사가 시작하고 성장한 방식과는 꽤 다른 방향으로 밀어 감
    Proton Pass도 조금 흥미롭지만, 다른 Proton 서비스처럼 가격 모델이 늘 약간 높은 편임. 한동안 무료 Proton Pass를 써 보고 있고, 여러 해 동안 기다리던 방향으로 Bitwarden이 개선되지 않았기 때문에 대체재로 옮길 가치가 있는지 볼 예정임
    iOS 내장 비밀번호 관리자도 충분히 괜찮지만, 비밀번호 전용이고 다른 종류의 데이터를 저장·검색·자동 입력하는 기능은 지원하지 않음

    • 아이러니함. 일부 기업은 오히려 Bitwarden이 개방적이고, 아주 유용한 걸 쓰려고 기업 영업 통화를 거치지 않아도 돼서 쓰고 있었을 수 있음
      제품을 쓰기 어렵게 만들면 고객과 판매 기회를 잃음. 최근 Postman과 했던 끔찍한 통화들이 떠오름. 또 한 번 통화하느니 이제는 Hoppscotch가 훨씬 나아 보임
    • 왜 거의 항상 벤처 투자는 모든 걸 엉망으로 만드는 걸까

  • CTO 답변은 SDK 사용 범위를 더 많은 클라이언트 사례로 확장해 왔지만, 목표는 SDK가 GPL 호환성을 유지하는 방식으로 쓰이게 하는 것이라고 함
    SDK와 클라이언트는 별도 프로그램이고, 각 프로그램의 코드는 별도 저장소에 있으며, 두 프로그램이 표준 프로토콜로 통신한다는 사실만으로 GPLv3상 하나의 프로그램이 되는 것은 아니라고 봄. 여기서 시도한 방식으로 앱을 빌드할 수 있어야 하는 문제는 해결할 예정인 단순 버그라고 함

    • 이런 답변류는 정말 답답함. 질문 범위를 일부러 오해한 듯한 방식으로 실제 질문을 피해 가기 때문임
      CTO에게 묻고 싶은 건 대략 이럼. “당신들 변호사들이 이걸 법적으로 빠져나갈 수 있다고 보는가?”에는 답했지만, 사람들이 우려하는 핵심 질문에는 답하지 않았음. Bitwarden 팀은 많은 사람이 명시적으로 오픈소스라서 지원하고 기여한 프로젝트를 사유화하는 데 윤리적 문제가 없다고 보는가? 비밀번호 관리는 본질적으로 높은 신뢰가 필요한 사업인데, 오픈소스에서 폐쇄 소스로 가는 러그풀 때문에 생길 신뢰 파열, 포크, 이탈을 어떻게 감당할 생각인가? 회사가 이런 결정을 고려할 정도로 절박한 상황이라면, 커뮤니티가 함께 도와 사유화 없이 지나갈 방법은 없는가?
      CTO로서 지금은 걱정하는 척하는 게 일이고, 특히 대화를 닫을 수 없는 포럼에서는 더 그렇다는 건 알지만, 현재 접근은 “법적으로 가능하다고 믿고 있으며, 자기 행동에 문제가 없다고 본다”는 최악의 두려움을 사실상 확인해 줌. 사용자들이 코드와 업데이트하는 사람들을 신뢰해야 수익이 나는 회사에는 정확히 잘못된 분위기임
    • 다른 말로 하면 bitwarden/clients는 GPLv3이고, 동작하는 전체로서의 Bitwarden 클라이언트는 독점 소프트웨어이며, CTO는 여기에 문제가 없다고 보고, 이슈는 잠겼다는 뜻임
    • 꼭 “하나의 프로그램”인지가 핵심은 아님. 문제는 이 부분임
      “객체 코드 형태 작업물의 ‘대응 소스’란 객체 코드를 생성, 설치, 실행하고 작업물을 수정하는 데 필요한 모든 소스 코드와, 그 활동을 제어하는 스크립트를 포함한다.”
      오픈소스 회사로 돈 벌기가 정말 어렵다는 건 이해함. 그래서 나도 유료 고객 중 하나임
      SDK에 붙인 제외 조건은 한동안 Linux 커널에 쓰였던 BitKeeper 버전 관리 소프트웨어와 매우 비슷해 보임. 그 결말이 어땠는지 보면 됨

  • 좋아했고, 돈도 냈고, 친구들에게 추천까지 했으며 그들도 좋아했음
    이제 KeePassXC로 옮기려고 함. Android와 데이터베이스를 동기화하는 추천 방식이 뭘까? cloudflared를 돌리는 Raspberry Pi 서버만 있음

    • 파일을 옮기다 생기는 동기화 충돌로 돌아가지 않으면서 클라우드 편의성을 유지하고 싶다면 Proton Pass는 GPLv3임. 다만 나중에 러그풀을 할 경우 자체 호스팅 상황이 어떤지는 개인적으로 모름
      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

    • SyncThing으로 KeePass 금고를 필요한 기기에만 정확히 배포해서 씀. 내게는 아주 잘 동작함. 필요에 따라 다를 수는 있음

    • KeePass와 그 생태계를 정말 쓰고 싶지만 비밀번호 공유가 별로 좋지 않음. 나와 아내는 공유 비밀번호가 많고, Bitwarden은 그 부분이 아주 잘 동작함. 우리에게 실용적인 대안이 뭔지 모르겠음

    • Keepass2Android는 ssh(sftp), Nextcloud 등 여러 방식으로 동기화할 수 있음. 맞는 방식을 찾을 수 있을 것임

    • KeePassXC와 Android용 Nextcloud 클라이언트 조합은 내게 완벽함. 몇 년째 문제 없이 쓰고 있음

  • GitHub 이슈를 더 이상 논의하지 못하게 잠가 버렸음. 가능한 대안 중 하나는 Vaultwarden인 듯함
    https://github.com/dani-garcia/vaultwarden
    돈 가진 사람들이 들어오면 오픈소스 프로젝트에서 이런 일이 계속 벌어지는 게 참 안타까움

    • Vaultwarden은 서버 대체품이고, 여기서 문제는 내가 이해하기로 데스크톱 클라이언트 라이선스임
    • García는 최근 Bitwarden에서 일하기 시작했음. 그의 생각을 들어보면 흥미로울 듯함
    • Vaultwarden은 passkey를 지원하나?

  • 자세히 살펴본 적은 없지만, 마케팅만 보고 Bitwarden이 완전히 자유 소프트웨어라고 생각했음. 그런데 2020년쯤부터 이상한 독점 요소가 들어간 것처럼 보임

  • 언젠가 Bitwarden으로 옮기길 바랐지만, 건강한 개방형 생태계를 찾지 못한다면 이제는 안 할 것 같음. 어떻게 전개되는지는 계속 지켜보겠음

    • 1년 동안 Vaultwarden 백엔드를 붙여 Bitwarden으로 완전히 전환해 봤는데, 이전에 쓰던 1Password와 비교하면 경험이 크게 떨어졌음
      평가 기준 중 하나는 “가족 모두가 1Password를 쓰고 만족하는데, 이 정도면 이들을 설득해 옮길 수 있을까”였음. 최종 전환 결정은 내가 내릴 수 있지만, 고령의 부모님에게 새로운 걸 하게 만들려면 사용자 경험이 매우 중요함
      결과적으로 아니었음. 전반적으로 UX가 좋지 않은 것 외에도 Bitwarden 클라이언트는 Linux, Mac, Windows, iOS에서 모두 훨씬 느렸고, 검색부터 로그인까지 모든 면에서 그랬음. 기능도 더 적었고, 비밀번호 정렬, 즐겨찾기, 좋은 정리 도구 같은 눈에 띄는 부분이 빠져 있었으며 자동 입력도 훨씬 덜 안정적이었음
      1Password의 사업 방식과 고객 대응에는 여러 해 동안 큰 불만이 있었음. 그래도 비밀번호 관리자, 이제는 비밀번호 이상을 담는 비밀 관리자에 가까운 도구가 일상생활의 중심이라 가능한 한 고통이 적은 것을 써야 한다고 느껴서 아쉽게도 다시 돌아갔음
      Bitwarden을 열린 소스라서 쓴 것은 아니고, 가능한 최고의 비밀번호 관리자를 쓰려 했음. 그래도 열려 있다는 점은 마음에 들었고 Vaultwarden은 보석 같음. 정말 더 나은 프런트엔드를 만들 시간과 실력이 있었으면 좋겠음

  • “현재로서는 SDK 라이선스를 조정할 계획이 없습니다. 자체 F-Droid 저장소 https://mobileapp.bitwarden.com/fdroid/repo/에 계속 게시할 예정입니다.”
    https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
    이 문제는 이미 7월에 SDK 저장소에서 제기됐고, 해당 SDK는 1년 넘게 이 라이선스를 가지고 있었음

  • iOS, PC, Mac에서 Bitwarden을 쓰고 있음. 이제 대안을 찾아야 함. 정말 슬픈 날임
    나도 연 10달러짜리 프리미엄 회원임. 수상한 관행 때문에 잃어버린 매출이 되는 셈임
    내보내서 다른 대안으로 옮기는 방법이 있나?

  • 내게 더 나은 Keepass(X,XC) 대안이 될까 싶어 지켜보던 프로젝트였는데, 이제는 결국 옮기지 않을 것 같음

답변달기