QEMU menetapkan kebijakan "larangan penggunaan generator kode AI"

• Komunitas QEMU baru-baru ini merevisi kebijakannya. Penggunaan generator kode AI (mis. Copilot, ChatGPT, dll.) serta pengajuan kode melalui alat tersebut dilarang

define policy forbidding use of AI code generators

• Minat terhadap penggunaan generator kode AI memang meningkat pesat belakangan ini, tetapi penafsiran lisensi atas hasil keluaran dari alat tersebut belum diterima secara luas di industri
• Vendor-vendor utama mengklaim bahwa tidak ada masalah dan lisensi dapat dipilih secara bebas, tetapi mereka memiliki konflik kepentingan
• Karena generator kode AI dibuat dari data pelatihan di bawah berbagai lisensi, masalah lisensi pada hasil keluarannya masih belum memiliki konsensus di industri
• Dalam DCO (Developer Certificate of Origin), QEMU mensyaratkan agar kontributor secara jelas memiliki hak untuk memberikan kontribusi kode di bawah lisensi proyek tersebut
  • Disebutkan secara jelas bahwa untuk kode yang menggunakan generator kode AI, sulit membuktikan kepatuhan terhadap klausul b/c pada DCO
  • Karena itu, QEMU memperkenalkan kebijakan yang tidak mengizinkan kontribusi kode ke proyek QEMU jika penggunaan generator kode AI terdeteksi secara jelas atau dicurigai

Fleksibilitas kebijakan dan penanganan pengecualian

• Pengembangan perangkat lunak berbantuan AI masih berada pada tahap awal, sehingga ada kemungkinan isu hukum akan diselesaikan di masa depan
• Seiring perkembangan alat, beberapa tool diperkirakan nantinya dapat digunakan dengan aman di proyek open source
• Untuk saat ini, kebijakan yang ketat dan aman diprioritaskan, dan dapat dilonggarkan di masa depan bila diperlukan
• Permintaan pengecualian akan ditinjau secara individual untuk menentukan apakah dapat diizinkan

[GN⁺]

Komentar Hacker News

• Open source dan free software saat ini merasa sangat rentan jika kode yang dihasilkan AI dianggap sebagai karya yang melanggar hak cipta atau diputuskan sebagai public domain. Jika sampai muncul situasi di mana editan AI dan editan manusia harus dibedakan, proyek bisa terjerat masalah hukum selama bertahun-tahun dan tidak akan mampu menanggung biaya litigasi. Jika kode buatan AI nantinya dimodifikasi manusia atau diintegrasikan ke kode yang sudah ada, maka akan muncul pertanyaan apakah editan manusia setelahnya dapat dianggap sebagai karya turunan yang melampaui fair use. Jika kode hasil AI diputuskan sebagai public domain, maka proyek yang hanya sebagian source code-nya berada di bawah lisensi open source/free software akan kehilangan banyak cara kuat untuk melawan perusahaan yang menyalahgunakan lisensi. Bebannya menjadi sangat besar karena harus membuktikan bahwa pelanggar lisensi benar-benar memakai kode buatan manusia, yakni kode yang memang memiliki lisensi. Sebaliknya, proprietary software relatif lebih sedikit terdampak dalam situasi ini. Sebab untuk mengklaim bahwa kode hasil AI adalah kutipan tanpa izin, seseorang pada akhirnya harus membongkar binary milik perusahaan itu dan membandingkannya dengan kode asli, dan bahkan dalam kode proprietary pun sering sudah ada campuran kode public domain
  • Saya justru merasa situasi ini menguntungkan bagi lisensi MIT
  • Dari sudut pandang pengembang berpengalaman, saya paham mengapa banyak orang tidak ingin "pengembang" yang tidak punya pengetahuan menyumbangkan kode AI secara acak. Meninjau kode AI baris demi baris secara manual akan menyita tenaga bertahun-tahun bahkan di luar persoalan hukum. Pertama, ke depan hampir tidak akan ada cara praktis untuk memverifikasi apakah suatu kode dihasilkan AI. Kedua, software yang benar-benar dikembangkan 100% oleh manusia jelas akan kalah kompetitif dibanding proyek yang dibantu atau ditulis AI. Satu-satunya bantahan yang mungkin hanyalah keruntuhan tingkat apokaliptik di mana manusia tak lagi bisa memproduksi semikonduktor atau listrik secara massal. Ketiga, bahkan jika suatu proyek bisa sepenuhnya menyingkirkan kontribusi kode AI, (meski tidak jelas bagaimana caranya, bahkan jika hanya segelintir kontributor anti-AI yang tetap ikut) pada akhirnya seseorang akan menyalin kode itu, menghapus bagian yang berisiko secara hukum, lalu beralih ke proyek baru. Jika lisensinya mengizinkan fork, mungkin akan langsung di-fork, tetapi bisa juga lebih memilih menyalin lalu merapikannya. Open source masih punya jalan panjang, dan software masa depan akan meledak secara kuantitas; mungkin 99% akan buruk, tetapi saya merasa software yang benar-benar bernilai juga akan makin banyak
  • Terkait isu hak cipta AI, dibagikan tautan ke artikel terbaru news.artnet.com tentang posisi US Copyright Office terkait AI art dan wiki putusan monkey selfie, sambil menyebut bahwa diskusi ini sudah memasuki jalan yang tak bisa dibalikkan
  • Jika suatu software benar-benar merupakan open source yang sangat terbuka dalam arti "lakukan apa pun yang kalian mau dengan kode ini, kami tidak peduli", maka tidak ada alasan sama sekali untuk khawatir karena AI
• Kesan saya, sikap ini jelas lebih keras dibanding kebijakan LLVM. Detailnya bisa dilihat di kebijakan pengembang LLVM. Sebagai developer tua, saya sama sekali tidak ingin berada dalam situasi harus mereview kode yang bahkan penulisnya tidak pahami, sementara saya sendiri juga tidak memahaminya
  • Sangat menyebalkan ketika penulis bahkan tidak memahami kodenya sendiri tetapi saya yang harus mereviewnya. Pernah ada orang meminta saya mengerjakan sesuatu sambil menyampaikan penjelasan yang dia dapat dari AI dan berkata, “katanya kalau begini nanti berhasil”. Jauh lebih baik kalau dia jujur saja bilang “tolong kerjakan ini”. Malah terasa menghina
  • Saya mulai menambahkan DCO(Developer Certificate of Origin) ke semua proyek open source yang saya kelola, dan berencana memasukkan kebijakan kontribusi kode LLM berikut ke CONTRIBUTING.md

  ---

  LLM-Generated Contribution Policy
  Pustaka Color adalah library yang penuh dengan matematika kompleks dan pengambilan keputusan yang subtil. Semua issue atau PR harus ditulis berdasarkan pemahaman mendalam dari pengirimnya sendiri, dan khusus untuk PR, developer harus menyatakan DCO untuk setiap commit. Jika PR ditulis dengan bantuan LLM, hal itu harus dinyatakan di pesan commit dan di PR. Jika bantuan LLM terdeteksi tanpa bukti yang memadai, PR akan ditolak. Mengirim hasil buatan LLM tanpa review akan selalu ditolak

  Di SECURITY.md juga akan ada LLM-Generated Security Report Policy, yaitu rencana untuk tidak menerima laporan keamanan yang dihasilkan LLM dalam kondisi apa pun

  Sebagai orang yang sendirian memikul tanggung jawab proyek, saya berusaha menjaga keseimbangan, tetapi secara pribadi saya memang tidak menyukai kontribusi kode LLM
  • Dalam proyek pribadi saya, saya memakai GitHub Copilot. Namun saya tidak menggunakannya selain sebagai “autocomplete pintar”. Saya baru menerimanya kalau hasilnya cukup mirip dengan kode yang memang hendak saya tulis. Dengan begitu, saya tetap memahami 100% kode saya sendiri dan juga terhindar dari bug karena keteledoran atau kontroversi hak cipta. Dipakai seperti ini, Copilot mempercepat pengembangan. Sebenarnya bukan karena saya lambat mengetik, melainkan karena saya sering terdistraksi oleh pikiran lain atau merasa bosan. Berkat Copilot, saya bisa cepat masuk ke fase berpikir atau debugging berikutnya.
    Sulit membayangkan orang lain bisa mengirim PR ketika mereka bahkan tidak memahami kodenya sendiri. Saya agak kesal karena ulah orang-orang seperti itu membuat saya ikut dibatasi oleh Policies meski saya hanya memakai LLM sebatas autocomplete.
    Saya ingin menyerahkan tugas refactoring otomatis ke Copilot, tetapi dari percobaan saya, hasilnya kebanyakan berantakan dan sering menghasilkan blok besar baru, sehingga justru lebih lambat daripada melakukannya sendiri.
    Yang menarik, kalau saya sedang menulis bug, Copilot sering ikut menyelesaikan bug itu apa adanya. Bahkan kesalahan konteks yang jelas seperti typo nama variabel pun dibiarkan dan dilengkapi begitu saja
  • Saat memakai LLM untuk pekerjaan coding, contohnya saya meminta, “ubah isi YAML ini menjadi struct dan ekstrak pola berulang menjadi variabel.” Ini sebenarnya bisa dilakukan dengan alat deterministik juga, tetapi AI bisa merapikannya dalam 30 detik, dan mudah juga untuk menguji bahwa hasilnya sama dengan input
    Pekerjaan level tinggi yang saya lakukan sama sekali tidak bisa saya serahkan ke AI, tetapi tugas yang repetitif dan kurang penting justru saya serahkan ke AI untuk mempercepat pekerjaan. Misalnya, jika saya memberi Claude Code file CSV hasil benchmark database dan memintanya menghubungkan berbagai grafik serta analisis outlier, ia bisa cepat menyelesaikan pekerjaan yang secara konsep mudah tetapi makan waktu karena harus mencari library atau melakukan setup
  • Saya sangat bisa memahami perasaan tidak mau mereview kode ketika penulisnya sendiri tidak memahami kodenya. Namun jika dibimbing dengan benar oleh manusia yang ahli, alat AI juga bisa menghasilkan kode yang cukup canggih. Beberapa bulan terakhir pun kemampuannya makin kuat, dan sering kali dapat menghasilkan sesuatu hanya dari instruksi bahasa alami
    Saya sedang memikirkan arti “memahami” kode. Salah satu proyek yang saya kerjakan adalah menambahkan backend storage baru sepenuhnya ke sistem orkestrasi VM yang sudah ada. Saya tidak mengenal codebase lamanya dan juga sulit menyediakan waktu untuk mengimplementasikannya sendiri, tetapi saya sudah membangun cluster uji dan menjalankan berbagai skenario, sehingga dari sisi desain dan pengujian saya cukup memahami gambaran besarnya
    Saya juga seorang maintainer open source, jadi saya bisa membayangkan betapa stresnya menerima PR “slop” LLM berkualitas rendah. Pada akhirnya, entah penulis memahami kodenya atau tidak, maintainer tetap harus mereview kodenya.
    Ke depan, kita perlu mencari cara untuk memanfaatkan alat-alat ini dengan tepat dan memberi sinyal tingkat kualitas kode yang dikirim kepada developer lain. Dari bug subtil yang ditemukan pada port awal Linux ZFS, saya belajar bahwa pengujian yang menyeluruh sangat penting, sama pentingnya dengan review dan penulisan manual baris demi baris oleh manusia
• Prediksi saya di blog “yes i will judge you for using AI” kini jadi kenyataan. Open source secara tradisional sangat bergantung pada penanda kompetensi tersembunyi dari kontributor, tetapi LLM membuat orang yang sama sekali tidak berpengalaman pun bisa menghasilkan kode yang tampak kompeten. Bagi orang berpengalaman, ini benar-benar kejutan yang membingungkan. Ke depan, social proof yang tidak terkait langsung dengan PR, seperti pertemuan virtual atau tatap muka, akan makin dibutuhkan untuk masuk ke proyek besar
  • Di perusahaan pun kami mengalami fenomena yang sama. Rekan kerja membuat komentar review kode dengan LLM dan karena terlihat terlalu bagus, saya sempat terkecoh. Akhirnya saya menghabiskan banyak waktu untuk memverifikasi apakah komentarnya benar, dan pada praktiknya saya mengeluarkan energi jauh lebih besar daripada usaha yang dikeluarkan orang yang sekadar copy-paste itu
  • Meminta tautan blognya
• Kebijakan ini tampaknya ditandatangani terutama oleh pihak yang berpusat di RedHat. RedHat sangat serius dan berorientasi korporat. Mungkin kekhawatiran RedHat bukan sekadar “siapa yang bisa memiliki hak cipta atas hasil buatan AI”, melainkan situasi ketika source dari proyek lain yang masuk saat pelatihan AI tiba-tiba muncul tanpa sengaja. Sebagian besar hypervisor bersifat closed source, dan banyak perusahaan yang senang menggugat
  • Jika risikonya adalah AI memuntahkan “kode proyek lain” dari data pelatihan, saya rasa itu sebenarnya berlaku untuk hampir semua kode yang dihasilkan AI
  • Model bahasa sering lebih berisiko membuat kesalahan logika yang subtil, bahkan bisa menembus batas keamanan hypervisor. Pengguna yang terlalu banyak dibantu AI biasanya kurang siap menemukan kesalahan seperti itu, sehingga menurut saya lebih berbahaya
• Saya menyoroti bahwa yang banyak menandatangani kebijakan ini adalah orang-orang RedHat setelah diakuisisi IBM. IBM membuat Watson dan perusahaan itu juga menang di Jeopardy pada 2011. Saya jadi bertanya-tanya apakah wacana software development AI yang katanya “baru tahap awal” ini benar adanya, atau cuma bagian lain dari pola penghancuran akibat akuisisi ala IBM.
  Dotnet Runtime justru sangat menerima AI. Orang luar mungkin menertawakannya, tetapi perlu diperhatikan bahwa engineer hebat seperti Stephen Toub dan David Fowler mendukungnya.
  Kepada perusahaan-perusahaan, saya menyarankan agar saat IBM berikutnya datang menjual layanan AI, mereka mencari mitra yang benar-benar berorientasi masa depan.
  Sebagai orang North Carolina, saya berharap IBM dan RedHat bisa mengambil arah yang benar
• Saya penasaran apakah motivasinya benar-benar legal. Beberapa proyek tampaknya hanya lelah dengan review kode buruk buatan AI
  • QEMU adalah software yang sangat krusial di industri. Dipakai di VM desktop, cloud, build server, sandbox keamanan, lingkungan lintas platform, dan banyak lagi. Risiko hukum sekecil apa pun dapat berdampak serius pada industri
  • Kebijakannya jelas dan terbatas. Tampaknya menekankan bahwa kepemilikan hak cipta atas kode yang dihasilkan secara algoritmik tidak bisa diamankan. Kata “secara algoritmik” sengaja dipakai. Kebijakan saat ini juga tampak menuju ke sana, dan kalimat seperti “kami mulai hari ini dengan pendekatan paling ketat dan paling aman, lalu nanti bisa dilonggarkan” sejak awal terdengar masuk akal. Memang ada unsur menolak apa yang disebut ‘slop massal’, tetapi strateginya adalah lebih dulu membereskan risiko hukum dan atribusi. Menurut saya ini jauh lebih baik daripada kebijakan curl
  • Diingatkan dengan contoh Monsanto yang sangat agresif menegakkan hak atas benih
  • Saya jujur tidak yakin bagaimana AI akan mengubah kualitas kode tingkat menengah, tetapi manusia pun kebanyakan menghasilkan kode yang tidak berguna. Kalau commit terlalu banyak dan sulit dikelola, mungkin tiap proyek memang butuh tim triage. Saya rasa sebagian besar kontribusi datang dengan niat baik.
    Saya paham orang yang menghindari AI karena risiko hukum, tetapi saya juga ragu pada sikap yang terlalu khawatir. Siapa pun yang merasa benar-benar sudah menurunkan suatu kemungkinan menjadi nol, menurut saya belum cukup memikirkannya
  • Jika tren ini berlanjut, open source bisa rusak. Kode copy-paste jadi terlalu mudah muncul, dan waktu untuk meninjau serta menolaknya terlalu besar. Makin banyak proyek mungkin akan berubah menjadi model ala Android, di mana semua orang bisa mengunduh source code, tetapi orang luar nyaris mustahil benar-benar bisa berkontribusi
• Saya berharap ada pembedaan antara memakai LLM di IDE sebagai alat autocomplete pintar, dan situasi memberi instruksi tingkat tinggi lalu membiarkannya menghasilkan banyak kode sekaligus. Saya akui memang ada wilayah abu-abu, tetapi saya tetap berharap autocomplete seperti Copilot masih bisa dipakai tanpa risiko hak cipta. Misalnya, saat menulis serangkaian case, Copilot bisa mendeteksi pola dan sangat mengurangi jumlah input yang perlu saya ketik
  • Lebih jauh lagi, saya membayangkan masa depan di mana AI menjadi seperti kacamata bagi pikiran dan tubuh saya. Seperti kacamata biasa yang membantu penglihatan, smart glasses bisa saja membantu proses berpikir juga.
    Otak saya sendiri sebenarnya juga sudah “dilatih” oleh banyak kode closed source, dan saya menyindir bahwa diskusi hak cipta AI ini adalah pola pikir NIMBY khas Barat. Saya khawatir kalau teknologi keren ditolak dengan dalih segala macam kemungkinan hukum seperti ini, peradaban Barat sendiri bisa runtuh
• Saya paham mengapa kebijakan seperti ini muncul, tetapi menurut saya ini kesalahan. Soal AI dan hak cipta, putusan hukumnya masih tidak jelas dan legislasi pun hampir belum ada.
  Terlepas dari kebijakan pelarangan kontribusi AI, saya justru merasa perlu ada pembagian area yang jelas tentang “di bagian ini AI boleh dipakai”. Misalnya setup CI QEMU bukan area inti yang harus dijaga dari sisi keamanan. Untuk kontribusi berupa test case atau environment yang menarik dan baru, menurut saya sangat mungkin AI diizinkan dengan syarat tertentu
  • Saya memikirkan risiko apa yang akan muncul jika kebijakan ini tidak diterapkan. Mungkin kode yang dihasilkan sedikit lebih lambat datangnya, tetapi akan lebih baik, dan untuk proyek sepenting QEMU, pengorbanan kecepatan demi risiko sebesar itu menurut saya layak. Penulis kebijakan tampaknya bukan anti-GenAI pada dirinya sendiri, melainkan berhati-hati karena begitu sesuatu berjalan, situasinya sulit dibalik
  • Solusi paling mudah adalah sekadar “menunggu sampai situasi hukum lebih jelas”. QEMU hampir seluruh kodenya berlisensi GPL 2.0; jika kode GenAI masuk secara keliru dan nanti secara hukum muncul preseden bahwa “lisensi kode aslinya wajib diikuti”, maka rollback kode terkait dan dampaknya ke seluruh downstream akan menjadi beban besar. Bahkan jika dari awal dilabeli “bagian ini AI, jangan dipakai ulang”, masalah penulisan ulang total di kemudian hari tetap tersisa.
    Pada akhirnya, “untuk sekarang tidak kami terima dulu” adalah pilihan yang lebih sederhana dan kurang dramatis bagi semua pihak
    Sebagai referensi, dilampirkan tautan ke lisensi QEMU dan daftar lisensi nonfree
  • Persoalan seperti ini bukan debat hukum yang akan berlangsung puluhan tahun; sudah ada puluhan gugatan terkait yang masuk pengadilan, jadi preseden kemungkinan akan muncul dalam beberapa tahun. QEMU sudah berkembang dengan sangat baik selama 22 tahun tanpa AI, jadi menunggu beberapa tahun lagi sama sekali bukan hal buruk
  • Saran saya, baca kebijakan ini dengan cermat, baik sisi luar maupun isi sebenarnya. Semua tindakan memang punya risiko hukum, tetapi perusahaan global besar justru menanggung risiko seperti itu setiap hari. QEMU bukan sedang bertindak aneh; menurut saya mereka sebenarnya hanya benar-benar tidak ingin memakai kode LLM, lalu menggunakan alasan “coba tanya pengacara → ada risiko hukum → jadi tidak bisa dipakai” untuk mengakhiri perdebatan. Pola yang sama juga terjadi di perusahaan
  • Di industri komputasi ada kebiasaan lama: “jangan menjiplak kode”. Bahkan untuk potongan kode yang sangat pendek, meski secara hukum mungkin termasuk fair use, budaya yang ada tetap tidak menyalin kode aslinya
• Alasan “mulai dengan ketat dan aman, lalu pelan-pelan dilonggarkan” memang terdengar sangat masuk akal
  Namun saya bertanya-tanya apakah secara praktis ada cara membedakan kode hasil AI dan kode yang disalin manusia dari tempat lain. Open source terbuka bagi siapa saja untuk berkontribusi, dan manusia pun bisa saja terpengaruh oleh source lain saat menulis kode
  Dari sudut pandang saya saat ini, kode hasil AI belum punya identitas mandiri; ia lebih mirip alat di tangan manusia
  • Ada analogi bahwa “kode hasil AI seperti gergaji mesin bertenaga tinggi di tangan manusia”. Alat yang sangat kuat, dan karena itulah setelah manusia, ia juga bisa menjadi berbahaya.
    Rasanya analogi ini pun sudah dipanjangkan terlalu jauh sampai tak perlu lagi dipakai
• Kebijakan seperti ini secara realistis tampak sama sekali tidak bisa ditegakkan. Zed, Cursor, VS code, semua editor menyediakan autocomplete berbasis AI, dan tidak mungkin membedakan kode yang saya ketik sendiri dengan petunjuk kode dari AI.
  Rasanya seperti saya menggambar orang lidi lalu ada yang berkata, “gambar itu mungkin menjiplak gambar orang lidi milik orang lain, jadi Anda tidak berhak menyerahkannya”
  Tujuan sebenarnya dari kebijakan ini pada akhirnya hanya untuk menyiapkan alasan agar ketika suatu hari seseorang tetap mengirim sesuatu yang sudah bercampur dengan kode AI, mereka bisa bilang “ya mau bagaimana lagi”. Saya rasa para penyusun kebijakan sendiri juga paham kebijakannya pada dasarnya tidak bermakna
  • Kebijakan seperti ini pada dasarnya adalah cara untuk sejak awal menyiapkan alasan lepas tanggung jawab: “kalau ada kode yang secara kebijakan patut dicurigai, kami juga tidak bisa berbuat apa-apa”. Dalam pesan commit atau patch juga ada posisi seperti “masalah lisensi code generator belum mapan secara hukum”.
    Selain isu hukum, jelas masih ada berbagai masalah lain yang muncul saat memakai kode AI
  • Neovim tidak memaksa AI. Itu hanya berjalan jika pengguna mengaturnya sendiri. Jika ada editor yang membuat AI tidak bisa dimatikan, menurut saya itu sendiri sudah merupakan masalah serius