1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Bambu Studio là một phiên bản sửa đổi của PrusaSlicer dựa trên AGPLv3, nhưng đã không cung cấp toàn bộ mã nguồn và thông tin cài đặt của thư viện mạng độc quyền
  • Corresponding Source của AGPLv3 bao gồm mã cần thiết để tạo, cài đặt, chạy, sửa đổi và cả mã nguồn của các thư viện liên kết động gắn chặt với phần mềm
  • Bambu đã yêu cầu xóa bản fork do Paweł Jarczak chỉnh sửa để Orca Slicer có thể liên kết với các thành phần máy chủ của Bambu, điều này xung đột với điều khoản cấm áp đặt hạn chế bổ sung
  • SFC đang thúc đẩy dự án baltobu để dịch ngược thư viện mạng, duy trì Orca Slicer for Bambu và phát triển viscose như một bản fork thay thế cho Bambu Studio
  • SFC bắt đầu gây quỹ US$250,007 trong hai tháng cho hoạt động quyền sửa chữa phần mềm của máy in 3D, và dự kiến công bố chi tiết ủy ban thường trực vào tháng 6/2026

Các vi phạm AGPLv3 đã được xác nhận

  • Không cung cấp mã nguồn libbambu_networking

    • Cuộc điều tra về tuân thủ AGPLv3 đối với phần mềm và firmware của máy in 3D Bambu Lab đã xác nhận hai vi phạm
    • Bambu Studio là một Slicer chia các mô hình thiết kế số như STL thành các lớp 2D ngang để máy in có thể in ra
    • Trong 4 năm qua, Bambu đã công khai rằng Bambu Studio là phiên bản sửa đổi của [PrusaSlicer], một Slicer đối thủ được cấp phép theo AGPLv3
    • PrusaSlicer là phiên bản sửa đổi của Slic3r, ban đầu do Alessandro Ranellucci tạo ra
    • Một phần mã nguồn của Bambu Studio có trong tài khoản tổ chức GitHub của Bambu, nhưng Bambu đã cho biết rằng họ phân phối Bambu Studio cho người dùng thông qua các lời nhắc tương tác trong UI, dưới dạng kết hợp với một thư viện độc quyền
    • AGPLv3 quy định rằng khi chuyển giao một tác phẩm thuộc phạm vi áp dụng dưới dạng mã đối tượng, phải đồng thời chuyển giao Corresponding Source ở dạng máy có thể đọc được theo cùng các điều khoản cấp phép
    • Corresponding Source bao gồm mã nguồn và script cần thiết để tạo, cài đặt, chạy và sửa đổi mã đối tượng
    • Nó cũng bao gồm mã nguồn của các thư viện dùng chung và chương trình con liên kết động mà tác phẩm được thiết kế để yêu cầu thông qua truyền dữ liệu chặt chẽ hoặc luồng điều khiển
    • Việc Bambu không cung cấp Complete Corresponding Source Code và Installation Information cho libbambu_networking.so, bambu_networking.dll, libbambu_networking.dylib được xem là một vi phạm AGPLv3 nghiêm trọng và kéo dài
  • Yêu cầu xóa bản fork của Paweł Jarczak

    • Ngoài việc giữ độc quyền thư viện mạng, hành động của Bambu nhắm vào nhà phát triển kiêm người dùng Bambu Lab Paweł Jarczak cũng được nêu là vi phạm AGPLv3
    • Paweł Jarczak đã công bố một phương thức khác để tích hợp với các thành phần phía máy chủ của Bambu Studio mà không thay thế hay sửa đổi thư viện liên kết động
    • Sau khi xem xét mã nguồn chưa đầy đủ của Bambu Studio, anh đã sửa đổi Orca Slicer, một Slicer AGPLv3 khác
    • Orca Slicer đã sửa đổi này cho phép người dùng thay thế Bambu Studio trong khi vẫn có thể liên kết thông qua truyền dữ liệu chặt chẽ với các phần đang chạy trên máy chủ Bambu Lab nhưng hiện chưa công bố mã nguồn
    • Bambu đã yêu cầu Paweł xóa bản fork OrcaSlicer có chứa các thay đổi đó khỏi GitHub
    • Bambu lập luận rằng điều khoản dịch vụ của họ được ưu tiên hơn AGPLv3, nhưng AGPLv3§10¶3 nêu rõ rằng không được áp đặt thêm hạn chế nào lên việc thực thi các quyền được cấp hoặc được xác nhận bởi giấy phép
    • Paweł đã xóa bản fork Orca Slicer kèm theo tuyên bố phản đối

Kế hoạch ứng phó của SFC

  • Dự án baltobu

    • SFC đã khởi động dự án baltobu để vận hành nhiều kho mã nhằm ứng phó với các vi phạm AGPLv3 liên quan đến Bambu và cải thiện quyền sửa chữa phần mềm cho máy in 3D
    • Từ hành động của Bambu nhắm vào Paweł Jarczak, một nỗ lực đa hướng đã bắt đầu nhằm giúp người tiêu dùng và người dùng trong ngắn hạn, đồng thời cải thiện quyền sửa chữa phần mềm cho người tiêu dùng máy in 3D về lâu dài
    • Vì Bambu từ lâu đã được biết đến là bên vi phạm AGPLv3 nghiêm trọng, SFC ưu tiên dịch ngược để đạt kết quả nhanh hơn thay vì chỉ dựa vào hành động pháp lý
  • reverse-networking

  • orca-slicer-for-bambu

    • Kho orca-slicer-for-bambu của baltobu sẽ trở thành kho chuẩn để duy trì và cải tiến bản fork Orca Slicer mà Paweł đã công bố đầu tiên
    • SFC đang kêu gọi tình nguyện viên duy trì một bản fork OrcaStudio hoạt động với máy in 3D Bambu
    • Các cộng tác viên tình nguyện làm việc thay mặt SFC có thể nhận được một mức độ bảo vệ trách nhiệm cá nhân nhất định, và nếu Bambu đe dọa pháp lý với tình nguyện viên, SFC sẽ cố gắng can thiệp trong khả năng có thể
  • viscose

    • Kho viscose của baltobu là dự án nhằm duy trì một bản fork đang hoạt động của chính Bambu Studio
    • Dựa trên các phát hiện từ hai nỗ lực trước đó, dự án hướng đến việc tạo ra một giải pháp thay thế Bambu Studio hoạt động tốt hơn cho chủ sở hữu máy in 3D Bambu
  • Giám sát thêm các vi phạm

    • SFC sẽ tiếp tục giám sát khả năng tồn tại thêm các vi phạm khác từ Bambu Lab
    • Thông thường họ không chủ động săn lùng vi phạm, nhưng trong trường hợp này sẽ theo dõi chặt Bambu Lab và định kỳ điều tra khả năng vi phạm giấy phép copyleft
  • Ủy ban thường trực của cộng đồng máy in 3D

    • SFC dự kiến thành lập một ủy ban thường trực để thảo luận về tự do và quyền phần mềm trong cộng đồng máy in 3D
    • Chi tiết của ủy ban sẽ được công bố vào tháng 6/2026
    • Ủy ban được lên kế hoạch theo mô hình họp hàng tháng giữa các nhà sản xuất máy in 3D, người dùng, người tiêu dùng, chuyên gia giấy phép copyleft và các nhà hoạt động vì tự do phần mềm
    • Mục đích là chia sẻ các vấn đề và quan ngại về quyền sửa chữa phần mềm liên quan đến máy in 3D và phần mềm liên quan, đồng thời xây dựng kế hoạch hành động để giải quyết

Tham gia và hỗ trợ

  • Tham gia tình nguyện

    • SFC đang kêu gọi tình nguyện viên tham gia ngay vào công việc này
    • Paweł Jarczak đã tham gia với tư cách tình nguyện viên đầu tiên, và công việc của anh đóng vai trò quan trọng trong việc điều tra nhiều vi phạm AGPLv3 của Bambu
    • Nếu muốn hỗ trợ công việc kỹ thuật của dự án baltobu, bạn có thể xem cách yêu cầu tài khoản trên instance Forgejo của SFC
    • Nếu quan tâm đến các sáng kiến khác, bạn có thể gửi email tới 3dprint@sfconservancy.org
  • Gây quỹ cho hoạt động quyền sửa chữa

    • SFC đang tiến hành chiến dịch gây quỹ US$250,007 trong hai tháng
    • Các khoản đóng góp Sustainer mới bắt đầuquyên góp chung cho SFC sẽ được phân bổ cho hoạt động quyền sửa chữa phần mềm
    • Nếu đạt mục tiêu, SFC sẽ ngay lập tức bắt đầu tuyển dụng thêm nhân sự để dẫn dắt hoạt động dài hạn
    • Nhân sự đó sẽ phụ trách điều phối các cộng tác viên tình nguyện, lập chiến lược cải thiện quyền sửa chữa phần mềm cho máy in 3D, và chuẩn bị các bước tiếp theo cần thiết nếu không thể buộc Bambu Lab tuân thủ AGPLv3
    • Nếu không đạt mục tiêu, số tiền gây quỹ sẽ được dùng cho thời gian của nhân sự hiện có tập trung vào dự án này và các hoạt động liên quan đến quyền sửa chữa phần mềm

Những người đã đóng góp

  • Paweł Jarczak đã giúp SFC nhận thức được các vi phạm AGPLv3 kéo dài của Bambu Lab, và đã chỉnh sửa mã nguồn theo cách được AGPLv3 cho phép để thực hiện các công việc liên quan
  • b3nsn0w đã điều tra thêm về tình hình của Bambu Lab và ủng hộ AGPLv3 hơn một năm qua liên quan đến vi phạm thư viện liên kết động
  • FULU đã thu hút sự chú ý đến vấn đề này và đưa ra lập trường đối đầu với Bambu Labs

1 bình luận

 
Ý kiến trên Lobste.rs
  • Bản thân nỗ lực này đáng được ghi nhận. Tôi là người dùng mã nguồn mở lâu năm và thỉnh thoảng cũng có đóng góp, đồng thời cũng dùng máy in Bambu, nhưng đã không thể chạy ổn Bambu Studio hay OrcaSlicer tự build từ mã nguồn trên một máy Debian cũ đang ở trạng thái hơi rối
    Tôi cũng theo dõi các giấy phép FLOSS đã lâu, và với AGPLv3 thì dù hiểu động cơ, tôi vẫn luôn thấy hơi không thoải mái. Tôi cũng không thích cách Bambu xử lý việc này, và dù chưa chắc đến mức vi phạm pháp lý, ít nhất theo tôi nó rõ ràng đi ngược lại tinh thần của mã nguồn mở
    Điều khiến tôi vướng mắc là: ý ở đây có phải là phần mềm AGPLv3 không được phép gọi dlopen() tới binary không tự do, hay là việc phân phối một tệp .so chỉ chia sẻ với phần mềm AGPLv3 một phần chữ ký con trỏ hàm cũng đã là vi phạm giấy phép? Trong vụ này, cùng một chủ thể phát hành phần mềm AGPLv3 đã sửa đổi kèm binary không tự do, nên cảm giác khó chịu là điều dễ hiểu, nhưng nếu khái quát hóa thì tôi thấy khá khó hình dung
    Nếu đẩy đến cực đoan, điều đó có thể bị hiểu như việc phần mềm AGPLv3 có thể nạp plugin theo một định dạng tiêu chuẩn nào đó lại tự mâu thuẫn với chính giấy phép của mình. Ví dụ, trường hợp phần mềm âm thanh AGPLv3 có thể nạp VST(https://en.wikipedia.org/wiki/Virtual_Studio_Technology) thì có vẻ khá phức tạp để hiểu đúng các hệ quả về giấy phép
    • Theo chuỗi thảo luận này, có vẻ Bambu cố tình buộc mọi hoạt động mạng phải đi qua thư viện đóng này. Không có nó thì phần mềm gần như vô dụng, và thậm chí dường như còn có cả cơ chế chống gỡ lỗi khiến chương trình bị crash nếu ai đó cố phân tích cách nó hoạt động
    • Cách hiểu kiểu “phần mềm AGPLv3 không được phép gọi dlopen() tới binary không tự do” không phải là quan điểm của FSF. Trong mục FAQ về plugin, FSF giải thích rằng việc có phải là một chương trình kết hợp duy nhất hay không phụ thuộc vào cách chương trình chính gọi plugin
      Nếu chỉ chạy bằng forkexec mà không có giao tiếp chặt chẽ thì có thể là các chương trình riêng biệt; nhưng nếu liên kết động và chia sẻ lời gọi hàm cùng cấu trúc dữ liệu với nhau thì FSF cho rằng đó nên được xem là một chương trình kết hợp duy nhất. Việc trao đổi các cấu trúc dữ liệu phức tạp qua bộ nhớ dùng chung cũng được xem gần như tương đương với liên kết động
      Theo tôi biết thì điều này nhìn chung áp dụng cho mọi phiên bản GPL. Nói ngắn gọn, tiêu chí là plugin đó có dùng được với phần mềm khác ngay cả trước khi được viết cho chương trình GPL hay không. Nếu nó chỉ hữu ích với đúng chương trình GPL đó, thì trên thực tế nó được xem là gần như một phần của chính chương trình
    • SFC đã trích dẫn phần liên quan trong chính văn bản giấy phép. Corresponding Source bao gồm mã nguồn của các thư viện dùng chung và các chương trình con được liên kết động mà tác phẩm đó được thiết kế chuyên biệt để yêu cầu
      Vì vậy, bản thân việc hỗ trợ plugin là ổn. Vấn đề phát sinh khi một plugin cụ thể trên thực tế gần như là bắt buộc để có được chức năng thông thường của ứng dụng. Tệp .so được nêu trong bài của SFC dường như liên quan đến mạng, và việc khó có thể sử dụng máy in một cách thuận tiện nếu không có truy cập mạng nghe cũng khá hợp lý
      Trong ngữ cảnh rộng hơn, “Corresponding Source” của một tác phẩm ở dạng mã đối tượng được hiểu là toàn bộ mã nguồn và script cần thiết để tạo, cài đặt, chạy và sửa đổi mã đối tượng đó, nhưng loại trừ các thư viện hệ thống hoặc các công cụ đa dụng, cũng như các chương trình tự do có sẵn phổ biến được dùng mà không cần chỉnh sửa
      Cụ thể, vẫn có thể phát triển phần mềm AGPL trên OSX dù nó phụ thuộc vào SDK độc quyền do Apple cung cấp trên mọi máy OSX. Trường hợp ứng dụng Windows phụ thuộc vào các thành phần phía Windows cũng tương tự vậy