Google bị tố đánh cắp mã nguồn mở mà không ghi công tác giả

Công nghệ12 tháng 9, 2026·8 phút đọc

Minitap cáo buộc Google đã sao chép mã nguồn từ dự án mobile-use của họ vào dự án Artemis mà không ghi công, thậm chí còn xóa tên các tác giả gốc khỏi lịch sử commit. Sự việc làm dấy lên lo ngại về cách các tập đoàn lớn đối xử với cộng đồng mã nguồn mở.

Google bị tố đánh cắp mã nguồn mở mà không ghi công tác giả

Google bị tố đánh cắp mã nguồn mở mà không ghi công tác giả

Minitap, một startup công nghệ, vừa công khai cáo buộc Google sao chép mã nguồn từ dự án mã nguồn mở mobile-use của họ vào dự án Artemis mà không ghi công. Đáng chú ý hơn, tên của các tác giả gốc được cho là đã bị xóa khỏi lịch sử commit. Sự việc đặt ra câu hỏi lớn về đạo đức và trách nhiệm của các "ông lớn" công nghệ đối với cộng đồng mã nguồn mở.

Phát hiện gây sốc trong văn phòng Minitap

Nicolas Dehandschoewercker, CEO kiêm đồng sáng lập Minitap, kể lại rằng ông đang ở văn phòng cùng đội ngũ khi nghe tin Google phát hành Artemis — một dự án tự động hóa thiết bị di động. Khi mở kho mã nguồn và xem qua, phản ứng của ông diễn ra tức thì: "Cái quái gì thế này? Chúng ta viết cái này mà."

Mã nguồn bị cáo buộc sao chépMã nguồn bị cáo buộc sao chép

Đội ngũ Minitap đã xây dựng mobile-use như một thử nghiệm nghiên cứu mã nguồn mở nhằm kiểm tra liệu các tác nhân AI (AI agent) có thể tương tác với điện thoại một cách đáng tin cậy hay không. Họ làm việc này suốt tháng Hai, sau đó tập trung vào một phiên bản mã nguồn đóng mạnh mẽ hơn, hiện đang vận hành kiểm thử QA trên cả web và di động tại Minitap.

Việc tìm thấy mã quen thuộc trong một dự án khác là điều bạn có thể lường trước khi công bố tác phẩm của mình. Nhưng tìm thấy nó dưới tên Google, mà không có lời ghi nhận nguồn gốc, thì khó chấp nhận hơn nhiều.

Những điểm trùng khớp cụ thể

Theo Minitap, các bằng chứng rất rõ ràng. Một số đoạn mã kết nối với thiết bị Android khớp chính xác với cách triển khai của họ. Hướng dẫn của tác nhân Hopper giống hệt nhau, từng từ một. Những điểm trùng khớp này vẫn còn tồn tại trong phiên bản Artemis mà họ kiểm tra vào ngày 11 tháng 9.

Điểm thú vị về cái tên Hopper: đội ngũ Minitap không biết đặt tên gì cho tác nhân này. Jean-Pierre, một kỹ sư của họ, thích Minecraft và nghĩ cái tên đó ngầu, nên họ chọn nó. Việc nhìn thấy cùng cái tên gắn với cùng hướng dẫn trong kho mã của Google khiến họ cảm thấy vô cùng quen thuộc.

Một ví dụ khác về việc giữ tác nhân bên trong WhatsApp có cùng nhiệm vụ gửi tin nhắn chúc mừng năm mới tới Alice, Bob và Charlie, với cùng phần chú thích và các bước dọn dẹp. Thậm chí, các phiên bản cũ còn chia sẻ chung một lỗi: một hàm trợ giúp ghi file kết quả, rồi thất bại khi cố đọc chính kết quả đó ở lần chạy tiếp theo. Minitap đã tái hiện cùng lỗi này trên cả hai bản triển khai. Artemis sau đó đã sửa lỗi.

Lịch sử tác giả bị xóa

Phần khó hiểu hơn nằm ở lịch sử tác giả. Một file package trước đó liệt kê tên Pierre-Louis Favreau, Jean-Pierre Lo và Nicolas Dehandschoewercker. Phiên bản thay thế đã xóa cả ba tên này và thay bằng một tác giả khác. Thay đổi duy nhất đối với các file chính là danh sách tác giả.

Theo ghi nhận hoạt động của GitHub, việc thay thế này diễn ra thông qua một lệnh force push vào tháng Tám, trước cuộc điều tra của Minitap vào tháng Chín. GitHub hiện đánh dấu phiên bản cũ là "detached" (tách rời), dù trước đó nó từng nằm trên nhánh main.

So sánh mã nguồnSo sánh mã nguồn

Artemis tất nhiên cũng chứa công trình kỹ thuật của riêng mình. Nó hoàn toàn có thể ghi nhận công trình đó lẫn mã mobile-use mà nó tích hợp ở cùng một chỗ. Nhưng file README mà Minitap kiểm tra đã không hề ghi công mobile-use. Họ đã công bố các so sánh chi tiết, file lưu trữ và dòng thời gian trong một hồ sơ thực tế công khai.

Giấy phép Apache 2.0 và nghĩa vụ ghi công

Minitap nhấn mạnh rằng việc chia sẻ mã nguồn đáng lẽ phải giúp hợp tác dễ dàng hơn. Họ chọn mã nguồn mở vì muốn người khác xây dựng tiếp trên mobile-use — cải tiến nó, biến nó thành sản phẩm, hay thậm chí tạo dự án cạnh tranh, miễn là tuân thủ các điều khoản giấy phép.

Có nhiều cách thông thường để làm điều đó mà vẫn giữ rõ nguồn gốc:

  • Một fork sẽ liên kết ngược về dự án gốc
  • Một bản sao được nhập có thể ghi rõ nguồn
  • Các thông báo bản quyền và ghi công có thể đi kèm mã
  • File README có thể giải thích phần nào đến từ đâu và đội mới đã thêm gì

Mã nguồn mobile-use dùng cho các so sánh hiện tại mang giấy phép Apache 2.0, với điều kiện phân phối lại bao gồm việc giữ nguyên các thông báo bản quyền và ghi công hiện hành, đồng thời xác định rõ các thay đổi. Giấy phép này cũng quy định việc giữ lại thông tin ghi công liên quan từ file NOTICE ở thượng nguồn nếu file đó có trong bản phân phối.

Tôi không nên phải đào lại một phiên bản cũ của kho mã để phát hiện ra mối quan hệ đó. Các maintainer vốn đã dành thời gian trả lời câu hỏi, duyệt đóng góp và giữ cho dự án hoạt động. Việc chạy theo những ghi công bị thiếu sau khi một công ty lớn tái phát hành tác phẩm của họ là thêm một cái giá nữa của việc chia sẻ.

Kết quả benchmark cũng bị phớt lờ

Câu chuyện không chỉ dừng ở mã nguồn. Minitap cho biết họ đã dành nhiều tháng yêu cầu kết quả mới của mình được phản ánh trên bảng xếp hạng AndroidWorld.

Người quản lý bảng xếp hạng đã áp dụng các đệ trình trước đó của họ, lên tới 91,4%, với lần xác nhận cuối cùng vào tháng 12 năm 2025. Sau đó họ nộp kết quả 94,8%, tiếp theo là 100% trong đánh giá hồi tháng Một. Họ gửi hai email nhắc lại. Bốn email này đều không được hồi âm. Kết quả và dấu vết tác vụ của họ vẫn có sẵn để kiểm tra.

Tính đến ngày 11 tháng 9, bảng vẫn hiển thị mobile-use ở mức 91,4%, trong khi Artemis xuất hiện ở mức 99,1%. Đây là các kết quả tự báo cáo, và bảng xếp hạng nói rõ rằng họ không tự kiểm chứng độc lập. Điều kiện đó cũng áp dụng cho con số 100% mà Minitap báo cáo.

Biểu đồ so sánh của chính Artemis đã bỏ qua họ. Nó bao gồm DroidRun với cùng điểm số như mobile-use, và một dự án không liên quan tên MadeAgents gọi là MobileUse ở mức điểm thấp hơn.

Biểu đồ so sánh của ArtemisBiểu đồ so sánh của Artemis

Minitap thừa nhận họ không có bằng chứng kết nối những email không được trả lời hay việc thiếu sót trên biểu đồ với hành động xóa tên. Nhưng đây là một phần khác trong trải nghiệm của họ khi cố gắng để hồ sơ công khai phản ánh đúng công trình của mình.

Điều gì khiến Minitap thất vọng

Đội ngũ Minitap cho biết họ đã liên hệ với nhóm Google và mở một issue công khai trên kho Artemis. Họ yêu cầu Google thừa nhận rằng Artemis được phát triển một phần dựa trên mobile-use, ghi công những người đứng sau nó và sửa lại thông tin ghi công.

Tôi thất vọng vì Google. Đây là công ty đã mang đến cho chúng ta Kubernetes và TensorFlow. Khi ra mắt Chrome, họ đã ghi công rõ ràng cho WebKit và Firefox, viết rằng: "Chúng tôi mang ơn rất nhiều dự án mã nguồn mở."

Dehandschoewercker bày tỏ thất vọng cho cả ba phía. Với bản thân, ông kỳ vọng nhiều hơn từ một công ty có lịch sử làm điều này đúng đắn và từng công bố hướng dẫn xử lý mã của người khác. Với đội ngũ, ông muốn họ thấy công sức của mình được sử dụng và cảm thấy tự hào, thay vì phải đào bới trong kho mã của người khác để chứng minh họ là tác giả. Và với cộng đồng mã nguồn mở, ông cho rằng cộng đồng xứng đáng được đối xử tốt hơn thế.

Nếu ngay cả một bản phát hành từ Google cũng khiến các maintainer phải chạy theo việc ghi công của chính mình, chúng ta đang khiến mọi người khó cảm thấy hào hứng với việc chia sẻ hơn. Đó không phải kiểu mã nguồn mở mà tôi muốn trở thành một phần.

Cuối bài viết, ông gửi lời nhắn đến Google với chút mỉa mai: phiên bản đang vận hành Minitap hiện nay là mã nguồn đóng và đã là một "con quái vật" hoàn toàn khác. "Google, các bạn đã trễ bảy tháng rồi. Lần sau, cứ hỏi xin một bản demo."

Sự việc này là lời nhắc nhở đáng suy ngẫm cho cộng đồng công nghệ Việt Nam và toàn cầu: trong kỷ nguyên AI bùng nổ, khi các dự án mã nguồn mở ngày càng trở thành nền tảng cho đổi mới, việc tôn trọng ghi công và giấy phép không chỉ là nghĩa vụ pháp lý mà còn là nền tảng đạo đức giữ cho hệ sinh thái mã nguồn mở tiếp tục phát triển.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗