3 คะแนน โดย GN⁺ 2024-10-25 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • คอมมิต db648d7 ของ Bitwarden sdk-internal เป็นการปรับถ้อยคำด้านสัญญาอนุญาตของ SDK และบน HN ก็กล่าวถึงกรณีนี้ว่าเป็นการ เปลี่ยนสัญญาอนุญาตใหม่จากแบบปิดเป็น GPLv3
  • LICENSE ที่รากโปรเจ็กต์ถูกแทนที่ครั้งใหญ่ โดยมี ลบ 295 บรรทัด·เพิ่ม 20 บรรทัด และไฟล์ใหม่ LICENSE_GPL.txt กับ LICENSE_SDK.txt กลายเป็นแกนหลักของโครงสร้างสัญญาอนุญาต
  • Rust workspace เพิ่ม bitwarden_license/* เข้าเป็นสมาชิก และย้ายพาธ dependency ของ bitwarden-sm ไปเป็น bitwarden_license/bitwarden-sm
  • การเปลี่ยนแปลงหลักของ crate bitwarden-sm คือการย้ายไดเรกทอรี โดยไฟล์หลายรายการใน src เป็นการ rename โดยไม่มีการเปลี่ยนเนื้อหา
  • bitwarden-sm/Cargo.toml ระบุไฟล์สัญญาอนุญาตของ crate นี้โดยชี้ตรงไปที่ ../../LICENSE_SDK.txt แทนการใช้ค่ากลางของ workspace

สิ่งที่เปลี่ยนในคอมมิต

  • ชื่อคอมมิตของ bitwarden/sdk-internal คือ “Improve licensing language
  • ชื่อหัวข้อบน HN แนะนำการเปลี่ยนแปลงนี้ว่า “Bitwarden SDK เปลี่ยนสัญญาอนุญาตใหม่จากแบบปิดเป็น GPLv3
  • ใน GitHub diff มีทั้งการเปลี่ยนไฟล์สัญญาอนุญาตและการปรับโครงสร้าง Rust workspace รวมอยู่ด้วย

การจัดโครงสร้างไฟล์สัญญาอนุญาตใหม่

  • ไฟล์ LICENSE ที่รากโปรเจ็กต์แสดงเป็น เพิ่ม 20 บรรทัด, ลบ 295 บรรทัด
    • GitHub จะไม่เรนเดอร์ diff ขนาดใหญ่แบบเต็มโดยอัตโนมัติ จึงไม่แสดงเนื้อหาทั้งหมดในหน้า
  • มีการเพิ่มไฟล์ใหม่ LICENSE_GPL.txt
    • ปริมาณการเปลี่ยนแปลงคือ เพิ่ม 674 บรรทัด, ลบ 0 บรรทัด
  • มีการเพิ่มไฟล์ใหม่ LICENSE_SDK.txt เช่นกัน
    • ปริมาณการเปลี่ยนแปลงคือ เพิ่ม 295 บรรทัด, ลบ 0 บรรทัด
  • รายการไฟล์ที่เปลี่ยนยังรวม LICENSE_GPL.txt ฝั่ง Kotlin และ Swift ด้วย
    • languages/kotlin/sdk/src/main/resources/META-INF/LICENSE_GPL.txt
    • languages/swift/LICENSE_GPL.txt

การเปลี่ยนพาธใน Rust workspace

  • สมาชิก workspace ใน Cargo.toml ที่รากโปรเจ็กต์ถูกขยาย
    • เดิม: members = ["crates/*"]
    • เปลี่ยนเป็น: members = ["crates/*", "bitwarden_license/*"]
  • พาธของ bitwarden-sm ใน workspace dependency ก็เปลี่ยนตามไปด้วย
    • เดิม: crates/bitwarden-sm
    • เปลี่ยนเป็น: bitwarden_license/bitwarden-sm
  • ทำให้ bitwarden-sm ไม่ได้ถูกอ้างอิงภายใต้ crates เดิมอีกต่อไป แต่ย้ายไปอยู่ภายใต้ bitwarden_license

การย้าย bitwarden-sm และการระบุสัญญาอนุญาต

  • crates/bitwarden-sm/Cargo.toml ถูก rename เป็น bitwarden_license/bitwarden-sm/Cargo.toml
  • วิธีระบุสัญญาอนุญาตใน bitwarden-sm/Cargo.toml เปลี่ยนไป
    • เดิม: license-file.workspace = true
    • เปลี่ยนเป็น: license-file = "../../LICENSE_SDK.txt"
  • crate นี้จึงระบุ LICENSE_SDK.txt โดยตรง แทนการใช้การตั้งค่าไฟล์สัญญาอนุญาตส่วนกลางของ workspace

เป็น diff ที่ใกล้เคียงกับการย้ายพาธมากกว่าการเปลี่ยนโค้ด

  • ไฟล์ซอร์ส Rust หลายรายการของ bitwarden-sm ถูก ย้ายโดยไม่มีการเปลี่ยนเนื้อหา
    • client_projects.rs
    • client_secrets.rs
    • lib.rs
    • projects/create.rs
    • projects/delete.rs
  • ใน file tree ยังแสดงว่าโมดูลที่เกี่ยวกับโปรเจ็กต์และซีเคร็ตถูกย้ายไปอยู่ใต้ bitwarden_license/bitwarden-sm/src ด้วย
  • รายการ rename ที่แสดงในเนื้อหานี้เน้นไปที่ การย้ายพาธและการปรับโครงสร้างสัญญาอนุญาต มากกว่าการแก้ไขโค้ด

2 ความคิดเห็น

 
unsure4000 2024-10-25

เกราะกันดราม่า ++;

 
GN⁺ 2024-10-25
ความคิดเห็นจาก Hacker News
  • โล่งใจ แม้บริษัทอาจจะเอาตัวรอดไปได้ไม่ทางใดก็ทางหนึ่ง แต่คงยากที่จะยังเป็นบริษัทที่นักพัฒนาชื่นชอบต่อไป และราคาที่ต้องจ่ายก็คงสูงมาก
    หวังว่า Bitwarden จะตระหนักว่าการเป็น ซอฟต์แวร์เสรี/โอเพนซอร์ส (FOSS) คือความได้เปรียบในการแข่งขันของตัวเอง และเป็นสิ่งที่ทำให้ได้รับความนิยมชมชอบอย่างมาก นั่นแหละคือเหตุผลที่ตั้งแต่แรกผมยังเลือกใช้ผลิตภัณฑ์ที่ไม่ได้ดีที่สุดแบบสมบูรณ์แบบ
    ตอนที่ยังเป็น FOSS คำกล่าวอ้างแรง ๆ ว่าเป็น “ตัวจัดการรหัสผ่านที่ได้รับความไว้วางใจมากที่สุด” ก็ยังพอมีเหตุผลรองรับอยู่บ้าง แต่ถ้าไม่นับ KeePass แล้ว หากไม่ใช่ FOSS ก็ไม่ใช่แบบนั้นเลย
    ตอนนี้ก็ยังไม่แน่ใจว่าควรมองบริษัทนี้อย่างไร ความเชื่อใจว่าแอปจะยังเป็นซอฟต์แวร์เสรีต่อไปมีเพิ่มขึ้นระดับหนึ่ง แต่ความเชื่อใจในตัวบริษัทเองลดลงไปเล็กน้อย และยังไม่เห็นการสื่อสารอย่างเป็นทางการด้วย
    ไม่รู้ว่าการรับเงินลงทุน 100 ล้านดอลลาร์ จะดีต่อผู้ใช้ในระยะยาวได้อย่างไร ผลลัพธ์ที่เป็นไปได้มากที่สุดดูเหมือนจะเป็นฟีเจอร์บวมเกินจำเป็นหรือบริการแย่ลง
    Bitwarden ดูไม่ได้ fork ง่ายนัก เป็นระบบซับซ้อนที่เขียนด้วย C# และแม้การมีอยู่ของ Vaultwarden จะช่วยได้มาก แต่แอปฝั่งไคลเอนต์ก็เป็นอีกเรื่องหนึ่ง
    ในฐานะกลไกป้องกันพฤติกรรมที่เป็นปฏิปักษ์ต่อผู้ใช้ สิ่งที่สำคัญรองลงมาจากโอเพนซอร์สเองคือ ความสามารถในการ fork ถึงอย่างนั้นก็หวังว่าจะไปได้ดี ช่วงหลังเพิ่งเริ่มใช้ Bitwarden และประสบการณ์ผู้ใช้จนถึงตอนนี้ดีกว่า KeePass มาก

    • มองโลกในแง่ดีอย่างระมัดระวัง แต่ยังคงกังวลเรื่อง ทิศทางระยะยาว
    • แม้จะไม่ดีเท่ากับการที่ความเป็นโอเพนซอร์สไม่ถูกตั้งคำถามตั้งแต่แรก แต่ก็แสดงให้เห็นว่าหากลูกค้าลุกขึ้นคัดค้าน พวกเขาก็พร้อมรับฟีดแบ็กและทบทวนใหม่ เรื่องนี้ก็เป็นเรื่องเก่าด้วย
    • มีการสื่อสารบน GitHub หรือช่องทางทางการอยู่แล้ว เห็นได้ชัดว่า ปัญหา dependency ดูเหมือนถูกพูดเกินจริง
  • ขอบคุณที่ Bitwarden เปลี่ยนส่วนนั้นกลับมาเป็นไลเซนส์เสรี/โอเพนอีกครั้ง
    แต่สำหรับผู้ใช้ทั่วไป ผมไม่แนะนำ Bitwarden อีกต่อไป เพราะตัวจัดการรหัสผ่านในตัวของ Firefox ดีพอแล้ว
    อย่างไรก็ตาม สำหรับคนที่ต้องการฟีเจอร์ขั้นสูงกว่า หรือไม่ไว้ใจตัวจัดการรหัสผ่านที่มากับเว็บเบราว์เซอร์ ผมยังแนะนำ Bitwarden เสมอ การเอา KeePassXC ไปผูกกับการซิงก์นั้นยากเกินไปสำหรับผู้ใช้ทั่วไป

    • ผู้ใช้ทั่วไปก็มักต้องการ ตัวจัดการข้อมูลลับ ที่กว้างกว่าเครื่องมือที่แค่เก็บ URL เว็บไซต์กับรหัสผ่าน
      เช่น ต้องมีที่เก็บคำตอบของคำถามความปลอดภัย alias อีเมลที่เกี่ยวข้อง หรือ PIN ของมือถือคู่สมรส ซึ่งเป็นค่าลับที่ไม่ใช่เว็บไซต์ ไว้ในพื้นที่เก็บข้อมูลที่เข้ารหัส
      ตัวจัดการรหัสผ่านของ Firefox มีแค่สองฟิลด์คือ “ชื่อผู้ใช้” และ “รหัสผ่าน” จึงพื้นฐานเกินไป ประสบการณ์ผู้ใช้ที่ดีกว่าสำหรับผู้ใช้ทั่วไปคือการรวมข้อมูลลับทั้งหมดไว้ในแอปเดียว ไม่ใช่เก็บข้อมูลลับบางส่วนใน Firefox และอีกส่วนในแอปอื่นแยกกัน
    • ผมรู้สึกมาตลอดว่าตัวจัดการรหัสผ่านที่อิงเบราว์เซอร์ให้คุณค่าค่อนข้างน้อยสำหรับคนส่วนใหญ่
      ใช้บนมือถือยุ่งยาก พึ่งพาแพลตฟอร์ม และข้อมูลที่เป็น local-only ซึ่งไม่ได้ซิงก์ก็สูญหายได้ง่าย การใช้กับหลายอุปกรณ์ก็ซับซ้อนกว่า โดยเฉพาะในสภาพแวดล้อมการทำงาน
      ในทางกลับกัน ผู้คนโดยทั่วไปเข้าใจวิธีติดตั้งแอปในแต่ละอุปกรณ์แล้วให้แอปนั้นจัดการให้ได้ดี
    • ถ้า Mozilla ออก แอปรหัสผ่านแยกต่างหาก ที่สามารถจัดการและเข้าถึงรหัสผ่านนอก Firefox ได้ ก็น่าจะเทียบกับ Bitwarden ได้มากขึ้น
      แบบนั้นรหัสผ่านจะไม่ใช่แค่ฟีเจอร์ของ Firefox แต่เป็นส่วนหนึ่งของบัญชี Mozilla Bitwarden ทำจุดนี้ได้ยอดเยี่ยม และใกล้เคียงกับโมเดลที่ต้องเอาชนะ
      Mozilla คงมีข้อได้เปรียบที่การผสานกับเบราว์เซอร์เป็นฟีเจอร์ระดับ first-class ที่ให้มาโดยปริยาย แต่ถ้าไม่ได้ใช้ Firefox แบบผูกขาดเพียงตัวเดียว ก็ยากจะมองว่าเบราว์เซอร์เดียวเป็นสถานที่ที่เหมาะสำหรับจัดการรหัสผ่าน
      ข้อดีของ Bitwarden คือแม้เปิดเบราว์เซอร์ค้างไว้ ก็ยังคงให้การเข้าถึงรหัสผ่านอยู่ในสถานะ “ล็อก” ได้ เท่าที่เคยดู Firefox ต้องให้ใส่ master password ตอนเปิดโปรแกรมแม้ยังไม่ต้องใช้รหัสผ่าน และแค่การที่การปลดล็อก vault ถูกผูกกับการเปิดเบราว์เซอร์ก็เป็นเหตุผลพอที่จะเลิกใช้แล้ว
    • ดีใจที่ Bitwarden รีบแก้ไข อย่างน้อยสำหรับผม ตัวจัดการรหัสผ่านของ Firefox ไม่ใช่ตัวทดแทน
      Bitwarden ได้รับอนุมัติให้ใช้ในบริษัท, โฮสต์เอง ได้ และรองรับการล็อกอินของแอปจำนวนมากทั้งบนเบราว์เซอร์และอุปกรณ์มือถือ
      ไม่ว่าจะเป็นแอปมือถือ เว็บไซต์บนมือถือ หรือเว็บไซต์ในเบราว์เซอร์ โดยทั่วไปก็ทำงานได้ดีมาก ยังเก็บข้อมูลตามอำเภอใจอย่างบัตรเครดิต บันทึกปลอดภัย ตัวพิมพ์เล็กใหญ่ของคำตอบคำถามความปลอดภัย การกู้คืนบัญชี และข้อมูลล็อกอินได้ด้วย ถือว่าดีทีเดียว
    • ผมใช้ทั้ง Bitwarden และ Firefox แต่ขอแนะนำอย่างหนักแน่นว่าอย่าใช้ตัวจัดการรหัสผ่านของ Firefox
      รู้ไหมว่า การซิงก์แท็บ ระหว่างอุปกรณ์ของ Firefox พังอยู่? พังมาตั้งแต่ 24 สิงหาคม และยังไม่ถูกแก้จนถึงตอนนี้ https://bugzilla.mozilla.org/show_bug.cgi?id=1913795
      ถ้าแค่แท็บยังซิงก์ข้ามอุปกรณ์ไม่ได้ ผมก็ไว้ใจการซิงก์รหัสผ่านของตัวเองได้ยาก
  • ดีที่เห็น Bitwarden ปรับทิศทาง ในเรื่องนี้ ผมค่อนข้างพอใจ เพราะไม่ได้ตั้งตารอที่จะย้ายไปใช้ตัวจัดการรหัสผ่านตัวอื่น

    • ผมก็เหมือนกัน เป็นสมาชิกแบบจ่ายเงินของ Bitwarden แต่ช่วงหลังเริ่มมองหาทางเลือกอื่นเพราะความวุ่นวายเรื่องไลเซนส์
      การเปลี่ยนตัวจัดการรหัสผ่านเป็นเรื่องน่ารำคาญ เลยดีใจที่ตอนนี้ไม่รู้สึกว่าจำเป็นต้องย้ายแล้ว
  • Bitwarden ยังยอดเยี่ยมอยู่ แต่คงต้องจับตาดูอีกหลายปีข้างหน้า ต้องจำไว้ว่าเดิมที Bitwarden เริ่มต้นขึ้นในฐานะทางเลือกเพื่อหลีกเลี่ยง พฤติกรรมแปลก ๆ ของ LastPass

    • พฤติกรรมแปลก ๆ ของ LastPass มีมานานแล้ว และพูดตรง ๆ คือร้ายแรงมาก
      แต่ไม่เข้าใจว่าทำไม Git commit นี้ถึงถูกลิงก์ไว้ อยากดูการพูดคุยที่เกี่ยวข้องมากกว่า https://github.com/bitwarden/clients/issues/11611
    • ผมยังมองว่าเป็นทางเลือกแบบนั้นอยู่ พูดตรง ๆ คือดีขึ้นด้วยซ้ำ
      หลักฐานคือ Bitwarden เป็นตัวจัดการรหัสผ่านที่ YouTuber ที่ได้รับสปอนเซอร์ไม่แนะนำ แต่ YouTuber ที่ไม่ได้รับสปอนเซอร์แนะนำเสมอ
    • 1Password เป็นซอฟต์แวร์ปิด แต่เท่าที่ผมรู้ก็ยังไม่เคยมีพฤติกรรมแปลก ๆ หลายครั้งผมรู้สึกอยากย้ายไปใช้โซลูชันโอเพนซอร์ส แต่คิดว่าน่าจะอยู่ที่นี่ต่ออีกหลายปี
  • ขอบคุณที่ Bitwarden รับฟัง เรื่องแบบนี้ทำให้มีความหวังต่อ โมเดลธุรกิจโอเพนซอร์ส ด้วย

  • ลิงก์ที่เกี่ยวข้อง: https://github.com/bitwarden/clients/issues/11611#issuecomme...
    การอภิปรายก่อนหน้า: https://news.ycombinator.com/item?id=41893994

    • ขอบคุณ พลาดข่าวนี้ไป เลยกำลังลำบากกับการไล่อ่านคอมเมนต์หลายอันเพื่อปะติดปะต่อบริบทอยู่
  • คิดว่าจัดการได้ค่อนข้างมีประสิทธิภาพและสมกับวิถีโอเพนซอร์ส ดีใจที่แก้ได้โดยไม่ต้องใช้ลูกเล่นแปลก ๆ และทำให้ไม่ต้องเจอความยุ่งยากในการย้ายออกจาก Bitwarden

  • ยังไม่ได้แก้เสร็จสมบูรณ์ บางส่วนถูกเปลี่ยนไลเซนส์แล้ว แต่บางส่วนยังคงอยู่ภายใต้ไลเซนส์ SDK ซอฟต์แวร์ไม่เสรีแบบเดิม
    ตัวอย่าง: https://github.com/bitwarden/sdk-internal/commit/db648d7ea85...

    • ส่วนที่ไม่ใช่ GPLv3 ดูเหมือนจะเป็นของ Secrets Manager ซึ่งเป็นผลิตภัณฑ์แยกต่างหาก ผลิตภัณฑ์นั้นดูไม่ได้ถูกโปรโมตว่าเป็นโอเพนซอร์ส
      Bitwarden เป็น open core มาโดยตลอด ไม่ใช่ GPLv3 ทั้งหมด และเรื่องนั้นก็เข้าใจได้ เพราะท้ายที่สุดก็ต้องมีอะไรสักอย่างไว้ขาย
  • น่าชื่นชมที่ขยับไปในทิศทางที่ถูกต้อง ช่วงหลายวันที่ผ่านมาไม่ชัดเจนเลยว่า Bitwarden จะทำอย่างไร

    • ถ้ายังเริ่มต้นด้วยความสงสัยแบบนี้ต่อไป บริษัทถัดไปก็คงไม่แม้แต่จะลองทำ
      นี่เป็นหนึ่งในบริษัทไม่กี่แห่งที่เปิดเผยผลิตภัณฑ์ของตัวเองเป็นโอเพนซอร์ส ตอนนี้ยังไม่ใช่เวลาที่จะมาสงสัยและสั่งสอนกันเลย
  • เป็นการเปลี่ยนแปลงที่น่ายินดี ถึงอย่างนั้นก็ยังรู้สึกว่าในเรื่องไลเซนส์พยายามฉลาดเกินไปหน่อย โดยเฉพาะวิธีผสม โค้ด GPL กับโค้ดไลเซนส์ปิด น่าจะเป็นสาเหตุหลักของความวุ่นวายครั้งนี้
    โมเดล open core เหมาะกับบริการโฮสติ้งที่ไม่ได้แจกจ่ายผลงานที่รวม GPL กับโค้ดปิดเข้าด้วยกันมากกว่า การทำ open core ในโค้ดฝั่งไคลเอนต์ดูมีช่องให้เกิดความเข้าใจผิดและสับสนมากเกินไป
    แต่ก็หวังว่าจะลงเอยด้วยดี เป็นผลิตภัณฑ์ที่ดี