Không có quyền tái cấp phép cho dự án này

• Mark Pilgrim, tác giả gốc của chardet, đã chỉ ra việc vi phạm giấy phép LGPL của dự án và yêu cầu rút lại việc chuyển sang giấy phép MIT ở phiên bản 7.0.0 gần đây
• Ông nêu rõ rằng dù các maintainer có cho rằng đây là một “bản viết lại hoàn toàn”, thì nó vẫn là một sản phẩm phái sinh được tạo ra trong trạng thái tiếp xúc trực tiếp với mã gốc, nên phải tiếp tục giữ LGPL
• Nhiều nhà phát triển đã thảo luận liệu bản viết lại có hỗ trợ AI có thực sự là một “clean room implementation” hay không, và LLM có được huấn luyện trên mã nguồn gốc hay không
• Một số người nhắc đến tính tương thích API và khả năng fair use, nhưng đa số lo ngại về khả năng vi phạm bản quyền và sự bất định pháp lý của mã do AI tạo ra
• Cuộc thảo luận này được chú ý như một tiền lệ quan trọng xoay quanh trách nhiệm bản quyền của mã do AI tạo ra, quy trình thay đổi giấy phép của dự án mã nguồn mở, và giới hạn quyền hạn của maintainer

---

Mark Pilgrim nêu vấn đề

• Mark Pilgrim khẳng định mình là tác giả gốc của chardet và dự án này từ trước đến nay được phát hành theo giấy phép LGPL
  • Ông chỉ ra rằng lập luận của maintainer ở phiên bản 7.0.0 rằng họ “có quyền tái cấp phép” là sai
  • Ông nhấn mạnh rằng mã theo LGPL, dù có bị chỉnh sửa, vẫn phải được phát hành theo cùng giấy phép, và tuyên bố “viết lại hoàn toàn” không có cơ sở pháp lý
  • Ông cũng nói rõ rằng việc “thêm trình tạo mã” không làm phát sinh quyền mới
• Pilgrim yêu cầu đưa dự án trở lại giấy phép LGPL ban đầu

Phản ứng ban đầu của cộng đồng

• Một người dùng hỏi liệu có fork của phiên bản trước khi viết lại với hỗ trợ AI hay không, và một người khác đã đưa ra liên kết tới phiên bản 6.0.0
• Một số người đồng ý rằng “về mặt pháp lý Mark là đúng”, thừa nhận khả năng vi phạm LGPL
• Những người khác lại nói “viết lại thông qua AI là một đánh đổi khó tránh khỏi”, nêu ra góc nhìn thực dụng

Tranh luận pháp lý: API, bản quyền và fair use

• Một người dùng viện dẫn án lệ Google LLC v. Oracle America, Inc. và nhắc rằng API cũng thuộc đối tượng được bảo hộ bản quyền
  • Họ giải thích rằng việc viết lại vì mục tiêu tương thích API có thể vẫn bất hợp pháp nếu không đáp ứng các điều kiện của fair use
• Đáp lại, người khác phản biện rằng trong vụ của Google, điều đó đã được công nhận là fair use
• Cuộc thảo luận mở rộng sang tính hợp pháp của việc viết lại tương thích API và tình trạng bản quyền của mã do AI sinh ra

Tranh cãi về mã AI và clean room implementation

• Một số người chỉ ra rằng nếu “AI có khả năng đã được huấn luyện trên mã nguồn gốc”, thì không thể xem là clean room implementation
  • Việc LLM có được huấn luyện trên mã chardet hay không có thể trở thành điểm mấu chốt trong phán quyết pháp lý
• Người khác cho rằng “nếu AI tạo mã chỉ dựa trên đầu vào và đầu ra thì có thể được chấp nhận”
  • Tuy nhiên, ý kiến phản bác cho rằng “nếu vậy thì bản thân giấy phép sẽ trở nên vô nghĩa”
• Sự không rõ ràng về trách nhiệm bản quyền của mã AI và khó khăn trong việc xác minh tuân thủ giấy phép nổi lên như các điểm tranh cãi chính

Tính tương thích giấy phép và tranh luận về GPL

• Một số người cho rằng giấy phép MIT không tương thích với GPL, nhưng người khác đã trích dẫn tài liệu chính thức của FSF để giải thích rằng MIT (Expat) tương thích với GPL
• Tuy vậy, đa số vẫn đồng ý rằng “tái cấp phép mã LGPL sang MIT vẫn là vi phạm”
• Một người khác chỉ ra rằng “không thể vừa giữ danh tiếng và kho mã xây dựng trên nền mã LGPL, vừa vứt bỏ thỏa thuận đó”

Dữ liệu huấn luyện AI và vấn đề niềm tin

• Nhiều người đặt câu hỏi liệu có thể tin rằng “Claude không được huấn luyện trên mã LGPL” hay không
  • Tính không thể truy vết của dữ liệu huấn luyện trong các mô hình AI được nhắc đến như một rủi ro pháp lý
• Một số người cho rằng “nếu mã AI có thể hàm chứa nguy cơ đạo văn, thì nên tránh sử dụng nó ngay từ đầu”
  • Có thống kê được đưa ra thông qua trích dẫn nghiên cứu rằng 2~5% mã do AI tạo ra có thể là bản sao của mã hiện có

Bản sắc dự án và quyền hạn của maintainer

• Một số ý kiến cho rằng “nếu toàn bộ mã của những người đóng góp trước đây đã bị loại bỏ, thì phiên bản mới có thể mang tính độc lập”
  • Tuy nhiên, cũng có phản biện rằng “việc tiếp tục dùng nguyên tên và danh tiếng cũ là không phù hợp”
• Cũng có ý kiến nói rằng “bản quyền bảo vệ cách biểu đạt chứ không bảo vệ tên gọi”
• Có quan điểm cho rằng nếu maintainer thực sự đã loại bỏ toàn bộ mã cũ, thì có thể không cấu thành vi phạm pháp lý, nhưng không có bằng chứng rõ ràng nào được đưa ra

Góc nhìn tổng hợp của cộng đồng

• Nhiều người nhắc rằng cần tôn trọng đóng góp của cả Mark Pilgrim và Dan Blanchard, đồng thời nhận thức được sự phức tạp của các vấn đề AI, bản quyền và quản trị mã nguồn mở
• Cuộc thảo luận tiếp tục mở rộng sang trách nhiệm pháp lý của mã do AI tạo ra, tính chính đáng của việc đổi giấy phép dự án, và giới hạn quyền hạn của maintainer trong mã nguồn mở
• Một số người thậm chí còn đề xuất “fork v7.0.0 rồi đưa nó trở lại LGPL”

Tóm tắt các điểm mấu chốt

• Tính hợp pháp của việc chuyển từ LGPL sang MIT: theo ý kiến của đa số, không thể thực hiện nếu không có sự đồng ý của tác giả gốc
• Tình trạng bản quyền của bản viết lại bằng AI: có thể bị xem là sản phẩm phái sinh tùy theo việc nó có tiếp xúc với dữ liệu huấn luyện chứa mã gốc hay không
• Có phải clean room implementation hay không: cần chứng minh rằng AI không tham chiếu mã nguồn gốc
• Vấn đề sử dụng tên gọi và danh tiếng của dự án: việc tái phân phối dưới cùng một tên gọi gây tranh cãi cả về pháp lý lẫn đạo đức
• Độ tin cậy của mã AI: lo ngại về nguy cơ đạo văn và độ ổn định của chuỗi cung ứng

Vụ việc này là một ví dụ tiêu biểu xoay quanh vấn đề bản quyền đối với mã do AI tạo ra và việc tuân thủ giấy phép mã nguồn mở, và có thể ảnh hưởng tới cấu trúc trách nhiệm pháp lý của các công cụ phát triển AI trong tương lai.