Kebijakan Penggunaan LLM NLnet Labs

• NLnet Labs membatasi penggunaan LLM dalam kontribusi proyek dan komunikasi; kiriman yang melanggar kebijakan dapat ditutup atau dihapus tanpa pemberitahuan sebelumnya
• Kontribusi kode dan dokumentasi harus ditulis langsung oleh manusia, dan tidak boleh memuat konten yang dihasilkan oleh LLM atau alat probabilistik lain
• Dalam laporan kerentanan dan bug, perbaikan yang disarankan LLM dapat diterima sebagai pengecualian, tetapi kontributor manusia harus memverifikasi masalah dan tingkat keparahannya
• Saat berinteraksi dengan NLnet Labs, seperti membuat issue, laporan kerentanan, atau posting forum, pengungkapan penggunaan LLM diperlukan; pengungkapan penggunaan terjemahan mesin juga dianjurkan karena adanya kemungkinan salah terjemah
• LLM boleh digunakan untuk linting, analisis, dan review, tetapi tanggung jawab untuk memahami dan memverifikasi akurasi informasi yang dibagikan secara eksternal tetap berada pada kontributor

---

Cakupan kebijakan dan kewajiban dasar

• NLnet Labs membatasi cara penggunaan Large Language Models(LLMs) dalam konteks organisasi dan proyek
• Kiriman yang tidak mengikuti kebijakan ini dapat ditutup atau dihapus tanpa pemberitahuan sebelumnya
  • Cakupannya meliputi PR, issue, komentar, posting forum, dan sebagainya
• Selain kebijakan ini, code of conduct dan CONTRIBUTING.md masing-masing proyek juga harus diikuti

Prinsip penulisan kontribusi

• Kontribusi kode dan dokumentasi harus ditulis oleh manusia
  • Tidak boleh memuat konten yang dihasilkan oleh LLM atau alat probabilistik lain
  • Perbaikan yang disarankan LLM yang disertakan dalam laporan kerentanan atau bug diizinkan sebagai pengecualian
  • Pengecualian ini dimaksudkan untuk memudahkan menemukan akar penyebab masalah selama peninjauan awal
• Saat membuka PR, kontribusi yang dihasilkan LLM juga tidak diterima
  • Kode yang dikirimkan tidak boleh dihasilkan oleh LLM
  • Deskripsi PR harus ditulis secara ringkas dengan kata-kata sendiri
  • Secara umum, PR untuk fitur baru tidak boleh dibuka tanpa terlebih dahulu berdiskusi dengan NLnet Labs
  • Ide perubahan perangkat lunak dapat dibagikan dengan pemikiran sendiri di community forum

Pengungkapan penggunaan LLM dan terjemahan

• Saat berinteraksi dengan NLnet Labs, apakah LLM digunakan atau tidak harus diungkapkan
  • Ini mencakup pembukaan issue, laporan kerentanan, dan posting di forum komunitas
• Jika bahasa Inggris bukan bahasa ibu, terjemahan mesin dapat membantu
  • Jika menggunakan terjemahan mesin, pengungkapan dianjurkan agar kedua pihak dapat menyadari kemungkinan masalah komunikasi akibat salah terjemah
  • Jika tidak dapat menilai akurasi terjemahan, Anda juga dapat menulis dalam bahasa ibu
  • Terjemahan LLM tidak dianjurkan karena sifat generatifnya lebih mungkin menimbulkan kebingungan daripada mempermudah diskusi

Penggunaan yang diizinkan dan tanggung jawab verifikasi

• Penggunaan LLM untuk linting, analisis, dan review diizinkan
• Meski LLM membantu menemukan atau menganalisis masalah, pengguna tetap bertanggung jawab memahami dan memverifikasi akurasi informasi yang dibagikan

Laporan kerentanan

• NLnet Labs dapat menerima laporan kerentanan yang ditemukan dengan LLM
  • Laporan dapat menyertakan perbaikan yang disarankan LLM untuk membantu mengidentifikasi lokasi masalah
  • Kontributor manusia harus memverifikasi masalah dan perkiraan tingkat keparahannya
  • Saat melapor ke [e-mail], penggunaan LLM harus diungkapkan
  • Prosedur pelaporan kerentanan harus merujuk ke halaman security report

[GN⁺]

Pendapat di Lobste.rs

• Saya ingin mendengar logika latar belakang dari aturan semacam ini
  Misalnya, saya penasaran apakah motivasi utamanya adalah ketidakpastian hukum, kekhawatiran soal kualitas atau pemeliharaan, atau alasan lain

  • Seperti yang dijelaskan Alex Band dari NLnet Labs dengan cukup terkendali di this toot, seseorang bisa saja menulis prompt dengan baik untuk menghasilkan 10 ribu baris kode yang tampak secara fungsional sesuai niat, demi berkontribusi pada fitur yang bagus dan dibutuhkan
    Namun sebelum mengajukannya sebagai pull request ke tim NLnet Labs, poin utamanya adalah apakah orang itu sudah meninjau dan memahami setiap baris yang dihasilkan serta bisa bertanggung jawab atasnya. Berdasarkan pengalaman setahun terakhir, kasus seperti itu jarang terjadi; kode seperti hadiah dengan niat baik ditaruh di depan pintu, tetapi beban untuk meninjau, bertanggung jawab, dan menggabungkannya ke branch main beralih ke tim. Mengingat perangkat lunak ini berjalan pada infrastruktur inti yang menjadi fondasi internet, itu adalah tuntutan yang besar. Dalam proses review, kedua pihak harus bisa berdialog dengan pemahaman bersama atas domain masalah dan detail solusi yang diusulkan, tetapi penggunaan LLM tidak memberi pemahaman semacam itu kepada pengirim dan juga berdampak buruk pada pemeliharaan jangka panjang
  • Alasan langsung penulisan dokumen ini adalah untuk melindungi waktu para developer
    Tentu saja, hak cipta, kendali kualitas, pemeliharaan jangka panjang, dan kekhawatiran etis juga semuanya dipertimbangkan

• Saya juga menyukai fokusnya pada patch yang ditulis dan direview oleh manusia, serta pengecualian untuk usulan patch dalam laporan kerentanan
  Jika sederhana dan langsung ke inti, usulan seperti itu layak dibaca

• Saya bisa memahami mengapa orang mulai lelah dengan hasil buatan AI, terutama ketika skalanya membesar
  Bahkan di tim kecil tempat saya bekerja pun ada hal-hal yang menjengkelkan. Ketika ditanya, “Mengapa dibuat seperti ini?”, jawabannya adalah, “Oh, Claude yang membuatnya begitu,” dan itu bukan jawaban. Orang-orang seolah menyerahkan bukan hanya proses berpikir, tetapi juga tanggung jawab kepada mesin. Untuk saat ini, penggunaan yang konservatif belum tentu buruk, dan menurut saya baru tepat dilonggarkan setelah kita tahu cara menggunakan teknologi ini secara bertanggung jawab dalam skala besar. Untuk saat ini, tidak ada yang tahu caranya

• Ini hanyalah kebijakan internal NLnet Labs, dan bukan kebijakan yang wajib diadopsi oleh proyek-proyek yang didukung NLnet

• Saya memahami latar belakang keputusan ini, tetapi cara penerapannya mendekati “semuanya tidak boleh”, sehingga terlihat berpandangan sempit

  • Bisa jelaskan dari mana penilaian normatif itu berasal? Saya penasaran mengapa Anda berkepentingan terhadap orang lain yang menerima kontribusi hasil LLM di proyek mereka sendiri, dan apa yang mereka atau masyarakat dapatkan darinya
    Menurut saya logika ini konsisten dan masuk akal, dan pada masa seperti sekarang merupakan langkah perlindungan yang sehat. Saya juga penasaran apakah Anda khawatir kontribusi Anda akan ditolak karena alasan ini, atau apakah Anda sudah pernah mengalaminya. Apakah mengikuti kebijakan ini memang sesulit itu? Apakah Anda sendiri, sebagai pemelihara jangka panjang infrastruktur inti, setiap hari menangani banjir noise berkualitas rendah di issue tracker? Menurut Anda, bagaimana seharusnya motivasi tetap dijaga dalam workflow yang berpusat pada manusia sambil mengurangi dampak banjir false positive?
  • Saya akan menyebutnya hati-hati, bukan berpandangan sempit
  • Ketika terbukti bahwa komunitas terkait tidak mampu menangani aturan yang terbuka dan kompleks yang mencerminkan kepentingan semua pihak dengan lebih akurat, cukup umum jika akhirnya ditetapkan aturan yang sempit dan sederhana
    Ini bukan hal buruk. Jika para developer menjadi sedikit lebih dewasa, hal ini bisa ditinjau kembali