QEMU - định nghĩa chính sách "cấm sử dụng trình tạo mã AI"

• Cộng đồng QEMU gần đây đã sửa đổi chính sách. Việc sử dụng trình tạo mã AI (ví dụ: Copilot, ChatGPT, v.v.) và gửi mã được tạo qua các công cụ đó đều bị cấm

define policy forbidding use of AI code generators

• Gần đây, sự quan tâm đối với trình tạo mã AI đã tăng vọt, nhưng cách diễn giải giấy phép đối với đầu ra của các công cụ này vẫn chưa được toàn ngành chấp nhận rộng rãi
• Các nhà cung cấp lớn khẳng định rằng không có vấn đề gì và có thể tự do lựa chọn giấy phép, nhưng giữa họ tồn tại xung đột lợi ích
• Vì trình tạo mã AI được xây dựng từ dữ liệu huấn luyện dưới nhiều loại giấy phép khác nhau, nên vấn đề giấy phép của đầu ra hiện vẫn chưa có được sự đồng thuận trong ngành
• QEMU yêu cầu trong DCO (Developer Certificate of Origin) rằng người đóng góp phải rõ ràng có quyền đóng góp mã theo giấy phép của dự án đó
  • Đồng thời nêu rõ rằng với mã sử dụng trình tạo mã AI, rất khó chứng minh việc tuân thủ các điều khoản b/c của DCO
  • Do đó, QEMU đưa ra chính sách không cho phép đóng góp mã vào dự án nếu việc sử dụng trình tạo mã AI là rõ ràng hoặc bị nghi ngờ

Tính linh hoạt của chính sách và xử lý ngoại lệ

• Đây vẫn là giai đoạn đầu của phát triển phần mềm có AI hỗ trợ, nên nhiều khả năng các vấn đề pháp lý sẽ được giải quyết trong tương lai
• Khi công cụ tiếp tục phát triển, trong tương lai một số công cụ có thể sẽ an toàn để sử dụng trong các dự án mã nguồn mở
• Hiện tại ưu tiên áp dụng chính sách nghiêm ngặt và an toàn, và có thể nới lỏng sau nếu cần
• Yêu cầu ngoại lệ sẽ được xem xét riêng từng trường hợp để quyết định có chấp thuận hay không

[GN⁺]

Ý kiến trên Hacker News

• Phần mềm nguồn mở và phần mềm tự do hiện đặc biệt dễ tổn thương nếu mã do AI tạo ra bị coi là tác phẩm xâm phạm bản quyền hoặc bị xác định là thuộc phạm vi công cộng. Nếu rơi vào tình huống phải phân biệt giữa phần chỉnh sửa bằng AI và phần chỉnh sửa bởi con người, dự án gần như chắc chắn sẽ bị mắc kẹt nhiều năm trong các vấn đề pháp lý, mà cũng không có khả năng chi trả chi phí kiện tụng. Nếu mã do AI tạo ra sau này được con người chỉnh sửa hoặc tích hợp vào mã hiện có, thì việc các chỉnh sửa tiếp theo của con người có bị xem là tác phẩm phái sinh vượt ra ngoài phạm vi sử dụng hợp lý hay không cũng là một điểm tranh cãi. Nếu mã do AI tạo ra bị xác định là thuộc phạm vi công cộng, thì những dự án mà chỉ một phần mã nguồn áp dụng giấy phép nguồn mở/phần mềm tự do sẽ nhanh chóng mất đi công cụ mạnh để đối phó với các công ty lạm dụng giấy phép. Khi đó sẽ phát sinh gánh nặng rất lớn là phải chứng minh bên vi phạm giấy phép đã sử dụng phần mã do con người viết, tức là phần có giấy phép xác định. Trong khi đó, phần mềm độc quyền chịu tác động tương đối nhẹ hơn trong tình huống này. Bởi để khẳng định mã do AI tạo ra là sao chép trái phép, cuối cùng vẫn phải có ai đó dịch ngược binary của họ để so sánh với mã gốc, và trong mã phần mềm độc quyền vốn cũng thường đã lẫn không ít mã thuộc phạm vi công cộng
  • Tôi nghĩ giấy phép MIT thậm chí còn được lợi trong tình huống này
  • Với tư cách là một lập trình viên giàu kinh nghiệm, tôi đồng cảm với việc nhiều người không muốn các “lập trình viên” thiếu kiến thức đóng góp mã AI một cách ngẫu nhiên. Việc để con người rà từng dòng mã AI, ngay cả bỏ qua vấn đề pháp lý, cũng là chuyện có thể trói nguồn lực trong nhiều năm. Thứ nhất, gần như không có cách thực tế nào để xác minh một đoạn mã có phải do AI tạo ra hay không trong tương lai. Thứ hai, phần mềm được phát triển hoàn toàn 100% bởi con người chắc chắn sẽ kém cạnh tranh hơn so với các dự án có AI hỗ trợ hoặc viết ra. Phản biện duy nhất cho điều đó có lẽ chỉ là một kịch bản sụp đổ cấp tận thế, nơi con người không còn sản xuất hàng loạt được chất bán dẫn hay điện nữa. Thứ ba, ngay cả nếu một dự án có thể loại trừ hoàn toàn đóng góp mã AI, thì cuối cùng cũng sẽ có người sao chép phần mã đó, loại bỏ các phần rủi ro pháp lý rồi chuyển sang một dự án mới. Nếu giấy phép cho phép fork thì cứ fork trực tiếp, nhưng cũng có thể người ta thích sao chép rồi dọn dẹp hơn. Nguồn mở vẫn còn cả một chặng đường dài phía trước, và phần mềm tương lai sẽ bùng nổ về số lượng; dù 99% trong số đó có thể rất tệ, tôi vẫn có cảm giác sẽ có thêm nhiều phần mềm thật sự giá trị
  • Chia sẻ các liên kết tới bài mới nhất trên news.artnet.com về lập trường của Văn phòng Bản quyền Mỹ đối với AI art và wiki về vụ kiện ảnh selfie của khỉ, đồng thời nhắc rằng cuộc tranh luận này đã bước vào con đường không thể đảo ngược
  • Nếu một phần mềm thật sự là nguồn mở cực kỳ rộng theo nghĩa “muốn làm gì với đoạn mã này cũng được, chúng tôi không quan tâm”, thì AI hoàn toàn không phải điều đáng lo
• Tôi có ấn tượng đây rõ ràng là lập trường cứng rắn hơn cả chính sách của LLVM. Có thể xem chi tiết trong chính sách dành cho nhà phát triển của LLVM. Là một lập trình viên già đời, tôi tuyệt đối không muốn rơi vào tình huống phải review mã mà tác giả không hiểu và bản thân tôi cũng không hiểu
  • Việc tác giả còn không hiểu chính mã của mình mà tôi lại phải review nó thực sự rất khó chịu. Đã từng có người nhờ tôi làm một việc rồi chuyển tiếp phần giải thích mà AI đưa cho họ, kiểu “nó bảo làm thế này là được”, trong khi nói thẳng “hãy làm giúp tôi việc này” còn tốt hơn nhiều. Tôi thậm chí thấy điều đó mang tính xúc phạm
  • Tôi đã bắt đầu thêm DCO (Developer Certificate of Origin) vào mọi dự án nguồn mở mình quản lý, và dự định đưa chính sách đóng góp mã LLM sau vào CONTRIBUTING.md

  ---

  Chính sách đóng góp do LLM tạo ra
  Thư viện Color là một thư viện đầy toán học phức tạp và nhiều quyết định tinh tế. Mọi issue hay PR đều phải được viết trên cơ sở người gửi thực sự hiểu sâu vấn đề, và đặc biệt với PR thì lập trình viên phải chứng thực DCO cho từng commit. Nếu PR được viết với sự trợ giúp của LLM, điều đó phải được nêu rõ trong commit message và trong PR. Nếu phát hiện có trợ giúp từ LLM mà không có bằng chứng công khai, PR sẽ bị từ chối. Mọi nội dung do LLM tạo ra mà được gửi lên không qua review đều sẽ bị từ chối vô điều kiện

  Trong SECURITY.md cũng sẽ có Chính sách báo cáo bảo mật do LLM tạo ra, theo đó mọi báo cáo bảo mật do LLM sinh ra sẽ không được tiếp nhận

  Với tư cách là người một mình chịu trách nhiệm cho dự án, tôi cố gắng giữ cân bằng nhưng cá nhân thì không thích các đóng góp mã từ LLM
  • Tôi dùng GitHub Copilot trong các dự án cá nhân. Nhưng tôi không dùng nó theo cách nào khác ngoài “tự động hoàn thành thông minh”. Chỉ khi nó đủ giống với đoạn mã tôi vốn định gõ thì tôi mới chấp nhận. Nhờ vậy tôi vẫn hiểu 100% mã của mình, đồng thời tránh được bug do sơ suất hay tranh cãi bản quyền. Dùng Copilot kiểu này giúp phát triển nhanh hơn. Thực ra không phải vì tôi gõ chậm, mà vì tôi thường bị xao nhãng hoặc thấy chán. Copilot giúp tôi nhanh chóng chuyển sang giai đoạn suy nghĩ hoặc debug tiếp theo.
    Tôi rất khó hình dung nổi chuyện người khác có thể gửi PR trong khi bản thân còn không hiểu mã của mình. Tôi hơi bất mãn với thực tế là vì những người như vậy mà các chính sách lại hạn chế cả việc tôi dùng LLM ở mức autocomplete.
    Tôi cũng muốn giao cho Copilot những tác vụ kiểu refactor tự động, nhưng hễ thử là phần lớn đều phá hỏng mọi thứ, lại còn hay sinh mới cả khối mã, khiến trải nghiệm còn chậm hơn tự làm bằng tay.
    Điều thú vị là nếu tôi đang gõ dở một bug, Copilot thường sẽ hoàn thành luôn cả bug đó. Nó tự động hoàn thành y nguyên cả những lỗi sai rõ ràng theo ngữ cảnh như gõ nhầm tên biến
  • Khi dùng LLM cho công việc lập trình, ví dụ tôi sẽ yêu cầu kiểu như “hãy chuyển nội dung YAML này thành struct và tách các mẫu lặp lại thành biến”. Việc này có thể làm bằng công cụ quyết định luận, nhưng AI làm gọn gàng trong 30 giây, và cũng dễ kiểm tra đầu ra có tương đương với đầu vào hay không
    Những công việc cấp cao tôi tuyệt đối không giao cho AI, nhưng các việc lặp lại và ít quan trọng thì AI có thể nhận để tăng tốc. Ví dụ, nếu đưa cho Claude Code file CSV kết quả benchmark cơ sở dữ liệu và yêu cầu nối các loại biểu đồ với phân tích outlier, thì nó có thể nhanh chóng hoàn tất một việc về mặt khái niệm thì dễ, nhưng tốn nhiều thời gian để tìm thư viện hoặc thiết lập môi trường
  • Tôi hoàn toàn hiểu tâm lý không muốn review nếu tác giả không hiểu mã của chính mình. Tuy nhiên, nếu có người đủ kinh nghiệm hướng dẫn đúng cách, công cụ AI cũng có thể tạo ra mã ở trình độ khá cao. Chúng lại còn mạnh hơn lên theo từng vài tháng, và trong nhiều trường hợp có thể tạo ra kết quả chỉ bằng chỉ dẫn ngôn ngữ tự nhiên
    Tôi đang suy nghĩ về ý nghĩa của việc “hiểu” mã. Một dự án tôi đang làm là thêm một backend lưu trữ hoàn toàn mới vào hệ thống điều phối VM hiện có. Từ góc độ không biết mã hiện tại, tôi không có đủ thời gian để tự triển khai từ đầu, nhưng tôi vẫn nắm khá rõ bức tranh tổng thể từ khía cạnh thiết kế và kiểm thử bằng cách dựng test cluster và chạy nhiều kịch bản khác nhau
    Bản thân tôi cũng là một maintainer nguồn mở, nên có thể tưởng tượng việc nhận những PR “slop” từ LLM chất lượng thấp gây stress đến mức nào. Cuối cùng thì dù tác giả có hiểu mã hay không, maintainer vẫn buộc phải review.
    Về sau, tôi nghĩ cần tìm cách vừa tận dụng đúng mức các công cụ này, vừa phát tín hiệu cho các lập trình viên khác về mức chất lượng của đoạn mã được gửi lên. Điều tôi học được từ một lỗi tinh vi tìm ra trong bản port ZFS cho Linux thời kỳ đầu là: kiểm thử kỹ lưỡng quan trọng không kém gì việc con người review và viết từng dòng mã
• Điều tôi dự đoán trong blog “yes i will judge you for using AI” nay đã thành hiện thực. Nguồn mở vốn từ lâu dựa nhiều vào các tín hiệu ngầm về năng lực của người đóng góp, nhưng LLM khiến cả người hoàn toàn không có kinh nghiệm cũng có thể đưa ra đoạn mã trông như của người có trình độ. Với người giàu kinh nghiệm thì đó thực sự là một cú sốc gây rối loạn. Từ nay trở đi, để bước vào các dự án lớn, có lẽ sẽ ngày càng cần nhiều hơn các hình thức chứng thực xã hội không liên quan trực tiếp tới PR, như họp trực tuyến hoặc gặp mặt trực tiếp
  • Ở công ty tôi cũng đang gặp hiện tượng này. Đồng nghiệp tạo comment review mã bằng LLM, nhìn rất ra gì nên mình bị đánh lừa trong chốc lát. Rồi lại phải tốn rất nhiều thời gian xác minh xem comment đó có đúng không, và rốt cuộc năng lượng tôi bỏ ra còn lớn hơn rất nhiều so với công sức của người chỉ copy-paste nó
  • Yêu cầu chia sẻ link blog
• Đây là một chính sách có chữ ký chủ yếu từ phía RedHat. RedHat rất nghiêm túc và thiên về doanh nghiệp. Có lẽ điều RedHat lo không phải là “ai có thể nắm bản quyền đối với sản phẩm do AI tạo ra”, mà là việc mã nguồn từ dự án khác mà AI lấy trong quá trình huấn luyện vô tình bật ra ngoài. Phần lớn hypervisor là mã nguồn đóng, và có rất nhiều công ty thích kiện tụng
  • Nếu rủi ro là AI phun ra nguyên văn “mã của dự án khác” từ dữ liệu huấn luyện, thì tôi nghĩ đó thực ra là vấn đề áp vào gần như mọi đoạn mã mà AI tạo ra
  • Mô hình ngôn ngữ thường có nguy cơ tạo ra các lỗi logic tinh vi dễ hơn, thậm chí có thể xâm phạm cả ranh giới bảo mật của hypervisor. Người dùng phụ thuộc nhiều vào AI thì lại ít sẵn sàng phát hiện ra những sai sót này hơn, nên tôi thấy còn nguy hiểm hơn
• Tôi để ý rằng những người của RedHat sau khi bị IBM mua lại là nhóm ký chính vào chính sách này. IBM từng tạo ra Watson và thắng cả trò Jeopardy năm 2011. Tôi tự hỏi liệu diễn ngôn kiểu AI trong phát triển phần mềm “mới chỉ ở giai đoạn bắt đầu” có thật hay chỉ là thêm một màn trong kiểu mua lại rồi phá nát của IBM.
  Dotnet Runtime thì đang tích cực đón nhận AI. Dù người ngoài có thể chế giễu, vẫn nên chú ý rằng những kỹ sư xuất sắc như Stephen Toub và David Fowler đều đang ủng hộ điều đó.
  Với các doanh nghiệp, tôi khuyên lần tới khi IBM tới chào bán dịch vụ AI, hãy tìm một đối tác thực sự có tầm nhìn tương lai hơn.
  Là người đến từ North Carolina, tôi mong IBM và RedHat sẽ đi đúng hướng
• Tôi tự hỏi liệu động cơ thật sự có phải là pháp lý không. Có những dự án trông như chỉ đơn giản là đã quá mệt mỏi vì phải review thứ mã AI tệ hại
  • QEMU là phần mềm cực kỳ cốt lõi trong ngành. Nó được dùng khắp nơi: desktop VM, cloud, build server, sandbox bảo mật, môi trường đa nền tảng, v.v.. Chỉ một rủi ro pháp lý rất nhỏ thôi cũng có thể gây ảnh hưởng nghiêm trọng tới cả ngành
  • Chính sách này rõ ràng và có phạm vi hạn chế. Nó dường như nhấn mạnh rằng không thể đảm bảo an toàn về quyền sở hữu bản quyền cho mã được tạo ra theo thuật toán. Họ cố tình dùng từ “theo thuật toán”. Chính sách hiện tại cũng có vẻ theo đúng tinh thần đó, và cách bắt đầu bằng kiểu “chúng tôi khởi đầu hôm nay theo hướng nghiêm ngặt và an toàn nhất, rồi sau này sẽ nới lỏng” nghe khá hợp lý ngay từ đầu. Có thể đúng là họ cũng muốn từ chối thứ gọi là ‘hàng đống slop’, nhưng chiến lược chính là xử lý trước rủi ro pháp lý và vấn đề quy thuộc. Tôi thấy nó tốt hơn chính sách của curl khá nhiều
  • Cảnh giác bằng cách nêu ví dụ Monsanto kiên quyết thực thi quyền đối với hạt giống
  • Thành thật mà nói tôi không chắc AI sẽ thay đổi chất lượng của mã tầm trung ra sao, nhưng con người cũng chủ yếu tạo ra mã vô dụng. Nếu commit quá nhiều và khó quản lý, có lẽ các dự án sẽ cần đội triage riêng chăng. Tôi nghĩ phần lớn đóng góp đều xuất phát từ thiện chí.
    Tôi hiểu những người tránh AI vì rủi ro pháp lý, nhưng cũng nghi ngờ chuyện lo lắng quá mức. Ai tin rằng mình đã đưa một khả năng nào đó về 0 thì có lẽ vẫn chưa nghĩ đủ kỹ
  • Nếu xu hướng này tiếp diễn, nguồn mở có thể bị hỏng. Mã copy-paste sẽ được tạo ra quá dễ dàng, còn thời gian để xem xét và từ chối lại quá lớn. Về sau có lẽ sẽ có nhiều dự án chuyển sang mô hình kiểu Android hơn, tức là ai cũng tải được mã nguồn nhưng người ngoài gần như không thể đóng góp thực sự
• Tôi hy vọng cần phân biệt giữa việc dùng LLM trong IDE như một công cụ autocomplete thông minh với việc đưa chỉ dẫn cấp cao và để nó sinh hàng loạt cả khối mã hoàn chỉnh. Tôi thừa nhận đây là một vùng xám, nhưng vẫn mong có thể dùng autocomplete kiểu Copilot mà không vướng rủi ro bản quyền. Ví dụ, khi viết một loạt case, Copilot có thể nhận ra mẫu và giúp giảm đáng kể lượng nhập liệu
  • Hơn nữa, tôi mơ tới một tương lai nơi AI trở thành cặp kính của tôi, như một phần của tư duy và cơ thể mình. Giống như kính thường giúp cải thiện thị lực, kính thông minh cũng có thể hỗ trợ cả suy nghĩ.
    Não tôi thực ra cũng đã học từ rất nhiều mã nguồn đóng, nên tôi châm biếm rằng các cuộc tranh luận bản quyền quanh AI là kiểu tư duy NIMBY của phương Tây. Tôi lo rằng nếu cứ lấy các giả định pháp lý “nếu mà” này để từ chối công nghệ hay ho, thì chính nền văn minh phương Tây cũng có thể suy yếu
• Tôi hiểu vì sao những chính sách như thế này xuất hiện, nhưng tôi nghĩ đó là sai lầm. Tôi cho rằng các phán quyết pháp lý liên quan đến AI và bản quyền vẫn chưa rõ ràng, và lập pháp cũng gần như chưa có gì.
  Tách biệt với chính sách cấm đóng góp bằng AI, tôi lại nghĩ cũng cần khoanh vùng rõ “những phần này có thể dùng AI”. Ví dụ, thiết lập CI của QEMU không phải là khu vực cốt lõi cần duy trì an ninh. Với các đóng góp cho test case hoặc môi trường mới mẻ, thú vị, hoàn toàn có thể cho phép AI theo một số điều kiện nhất định
  • Tôi suy nghĩ về rủi ro nếu không áp dụng chính sách này. Có thể mã sẽ ra chậm hơn đôi chút nhưng tốt hơn, và ngay cả khi phải hy sinh tốc độ thì với một dự án quan trọng như QEMU, mức rủi ro đó vẫn đáng để chấp nhận. Có vẻ các tác giả không hẳn bài xích GenAI, mà là đang tiếp cận một cách thận trọng vì một khi đã đi vào rồi thì khó quay lại
  • Cách giải quyết dễ nhất đơn giản là “đợi đến khi tình hình pháp lý rõ ràng hơn”. QEMU gần như toàn bộ là mã GPL 2.0; nếu mã GenAI bị đưa vào sai cách, rồi sau này có tiền lệ pháp lý rằng “bắt buộc phải tuân theo giấy phép của mã gốc”, thì việc rollback phần mã liên quan và xử lý toàn bộ downstream sẽ trở thành gánh nặng. Ngay từ đầu, dù có gắn nhãn kiểu “phần này là AI, không được tái sử dụng”, thì về sau vẫn còn vấn đề phải viết lại toàn bộ.
    Cuối cùng, “tạm thời chưa nhận” là lựa chọn ít phức tạp và ít kịch tính hơn cho tất cả mọi người
    Đính kèm tài liệu liên quan là giấy phép của QEMU và danh sách giấy phép không tự do
  • Đây không phải là một cuộc tranh chấp pháp lý sẽ kéo dài hàng chục năm; hiện đã có hàng chục vụ kiện liên quan được đưa ra tòa, nên trong vài năm tới sẽ có án lệ. QEMU đã phát triển rất tốt suốt 22 năm không cần AI, nên chờ thêm vài năm nữa cũng hoàn toàn không có gì xấu
  • Lời khuyên là hãy đọc kỹ cả bề mặt lẫn ẩn ý của chính sách này. Mọi hành động đều có rủi ro pháp lý, nhưng các tập đoàn đa quốc gia lớn trên thế giới vẫn chấp nhận những rủi ro đó. QEMU không có gì quá dị biệt; thực ra có thể đọc ra rằng họ đơn giản là thật sự không muốn dùng mã LLM nên mới đưa ra lập trường như vậy. Đó là chiến lược kết thúc tranh cãi bằng cái cớ “hãy hỏi luật sư đi → có rủi ro pháp lý → không dùng được”. Ở công ty cũng thấy đúng y kiểu này
  • Trong ngành máy tính có một tập quán lâu đời là “không đạo mã”. Dù chỉ là đoạn mã rất ngắn, dù về mặt pháp lý có thể thuộc ‘sử dụng hợp lý’, văn hóa chung vẫn là không sao chép mã gốc
• Lập trường “bắt đầu nghiêm ngặt và an toàn, rồi dần nới lỏng” thực sự hợp lý
  Nhưng tôi cũng băn khoăn liệu có cách thực tế nào để phân biệt mã do AI tạo ra với mã con người đã sao chép từ đâu đó hay không. Vì nguồn mở cho phép bất kỳ ai đóng góp, nên việc con người chịu ảnh hưởng từ mã nguồn khác khi viết mã cũng là điều tương tự
  Ở góc nhìn hiện tại, tôi nghĩ mã do AI tạo ra tự thân không có một bản sắc độc lập nào; nó gần hơn với một công cụ nằm trong tay con người
  • Một phép so sánh là “mã do AI tạo ra giống như cái cưa máy công suất lớn trong tay con người”. Đó là một công cụ mạnh, nên sau con người thì nó có thể trở nên nguy hiểm.
    Giờ tôi còn thấy phép so sánh này đã kéo dài quá mức đến mức không cần dùng nữa
• Những chính sách như thế này trên thực tế có vẻ hoàn toàn không thể thực thi. Zed, Cursor, VS code, mọi editor đều cung cấp autocomplete dựa trên AI, và gần như không thể phân biệt mã tôi tự gõ với mã gợi ý từ AI.
  Nó giống như việc tôi vẽ một hình người que rồi bị nói rằng “bức vẽ đó có thể đã sao chép từ hình người que của người khác nên bạn không có quyền nộp nó”
  Mục tiêu thật sự của chính sách này, rốt cuộc chỉ là tích lũy lý do để sau này nếu ai đó có gửi thứ gì trộn lẫn với mã AI thì họ có thể nói “chúng tôi cũng hết cách”. Tôi không tin những người soạn chính sách lại không biết chính họ cũng thấy nó vô nghĩa
  • Những chính sách như thế này về bản chất là để tự tạo sẵn cái cớ miễn trách nhiệm kiểu “nếu có mã đáng ngờ theo chính sách bị nộp lên thì chúng tôi cũng không thể làm gì hơn”. Trong commit message hoặc patch cũng đã có lập trường kiểu “các vấn đề giấy phép của trình sinh mã vẫn chưa được xác lập về mặt pháp lý”.
    Ngoài vấn đề pháp lý, hiển nhiên vẫn còn nhiều vấn đề khác nảy sinh khi dùng mã AI
  • Neovim không ép dùng AI. Phải tự cấu hình thì nó mới hoạt động. Nếu một editor khiến người dùng không thể tắt AI, thì bản thân editor đó đã có vấn đề nghiêm trọng