NLnet Labs’in LLM kullanım politikası

• NLnet Labs, proje katkıları ve iletişimlerde LLM kullanımını kısıtlar; politikayı ihlal eden gönderimler önceden bildirim yapılmadan kapatılabilir veya silinebilir
• Kod ve dokümantasyon katkıları doğrudan insanlar tarafından yazılmalı; LLM’ler ya da diğer olasılıksal araçlar tarafından üretilmiş içerik içermemelidir
• Güvenlik açığı ve hata raporlarında, LLM’in önerdiği düzeltmeler istisnai olarak kabul edilebilir; ancak insan katkıda bulunan kişi sorunu ve ciddiyetini doğrulamalıdır
• Issue’lar, güvenlik açığı raporları ve forum gönderileri gibi NLnet Labs ile etkileşimlerde LLM kullanımının açıklanması gerekir; makine çevirisi için de yanlış çeviri olasılığı nedeniyle açıklama yapılması önerilir
• LLM’ler linting, analiz ve inceleme için kullanılabilir; ancak dışarıyla paylaşılan bilgilerin doğruluğunu anlama ve doğrulama sorumluluğu katkıda bulunan kişide kalır

---

Politikanın kapsamı ve temel yükümlülükler

• NLnet Labs, kuruluş ve proje bağlamında Large Language Models (LLMs) kullanım biçimini kısıtlar
• Politikaya uymayan gönderimler önceden bildirim yapılmadan kapatılabilir veya silinebilir
  • Kapsama PR’lar, issue’lar, yorumlar, forum gönderileri vb. dahildir
• Bu politikanın yanı sıra code of conduct ve her projenin CONTRIBUTING.md dosyasına da uyulmalıdır

Katkı hazırlama ilkeleri

• Kod ve dokümantasyon katkıları insanlar tarafından yazılmalıdır
  • LLM veya diğer olasılıksal araçların ürettiği içerikler dahil edilemez
  • Güvenlik açığı veya hata raporlarında yer alan LLM önerisi düzeltmeler istisnai olarak kabul edilir
  • Bu istisna, ilk inceleme sırasında sorunun kök nedenini daha kolay bulmaya yöneliktir
• PR açarken de LLM tarafından üretilmiş katkılar kabul edilmez
  • Gönderdiğiniz kod LLM tarafından üretilmiş olmamalıdır
  • PR açıklaması kısa ve kendi sözlerinizle yazılmalıdır
  • Genel olarak yeni özellik PR’ları, önce NLnet Labs ile konuşulmadan açılmamalıdır
  • Yazılım değişikliği fikirleri community forum üzerinde kendi düşüncelerinizle paylaşılabilir

LLM kullanımının açıklanması ve çeviri

• NLnet Labs ile etkileşim kurarken LLM kullanılıp kullanılmadığı açıklanmalıdır
  • Buna issue açma, güvenlik açığı raporlama ve topluluk forumunda gönderi paylaşma dahildir
• İngilizce ana diliniz değilse makine çevirisi yardımcı olabilir
  • Makine çevirisi kullandıysanız, yanlış çeviri kaynaklı iletişim sorunları olasılığının her iki tarafça da fark edilebilmesi için bunu açıklamanız önerilir
  • Çevirinin doğruluğunu değerlendiremiyorsanız ana dilinizde de yazabilirsiniz
  • LLM çevirisi, üretken niteliği nedeniyle tartışmayı kolaylaştırmak yerine daha kafa karıştırıcı hale getirme olasılığı yüksek olduğundan önerilmez

İzin verilen kullanımlar ve doğrulama sorumluluğu

• LLM’lerin linting, analiz ve inceleme için kullanılması mümkündür
• LLM bir sorunu bulmaya veya analiz etmeye yardımcı olmuş olsa bile, paylaştığınız bilgilerin doğruluğunu anlama ve doğrulama sorumluluğu kullanıcıya aittir

Güvenlik açığı raporları

• NLnet Labs, LLM ile bulunmuş güvenlik açığı raporlarını kabul edebilir
  • Rapora, sorunun yerini saptamaya yardımcı olmak için LLM’in önerdiği düzeltmeler eklenebilir
  • İnsan katkıda bulunan kişi sorunu ve tahmini ciddiyetini doğrulamalıdır
  • [e-mail] adresine rapor gönderirken LLM kullanımı açıklanmalıdır
  • Güvenlik açığı raporlama süreci için security report sayfasına bakılmalıdır

[GN⁺]

Lobste.rs yorumları

• Bu tür kuralların arkasındaki mantığı duymak isterim
  Örneğin ana motivasyonun hukuki belirsizlik mi, kalite ya da bakım kaygıları mı, yoksa başka bir şey mi olduğunu merak ediyorum

  • NLnet Labs'tan Alex Band'in bu toot'ta oldukça ölçülü biçimde açıkladığı gibi, biri iyi prompt yazarak harika ve gerekli bir özelliğe katkı vermek isteyip işlevsel olarak amaçlandığı gibi görünen 10 bin satır kod üretebilir
    Ancak bunu NLnet Labs ekibine pull request olarak göndermeden önce, üretilen her satırı gözden geçirip anlamış ve sorumluluğunu alabilecek durumda olup olmadığı asıl mesele. Son bir yıllık deneyime göre bu nadiren böyle oldu; iyi niyetli bir hediye gibi kod kapıya bırakılıyor, fakat onu inceleme, sorumluluğunu üstlenme ve main dalına birleştirme yükü ekibin üzerine kalıyor. Bu yazılımın internetin temelini oluşturan kritik altyapıda çalıştığı düşünülürse bu büyük bir talep. İnceleme sürecinde, sorun alanının ve önerilen çözümün ayrıntılarının iki tarafça da anlaşılmış olduğu bir zeminde konuşabilmek gerekir; LLM kullanımı ise gönderene böyle bir anlayış sağlamıyor ve uzun vadeli bakımı da olumsuz etkiliyor
  • Bu belgeyi hazırlamaya girişmelerinin doğrudan nedeni geliştiricilerin zamanını korumaktı
    Elbette telif hakkı, kalite kontrol, uzun vadeli bakım ve etik kaygılar da hep dikkate alındı

• Odağın insanların yama yazıp incelemesine verilmesi de iyi; güvenlik açığı raporlarındaki yama önerilerinin istisna tutulması da iyi
  Basit ve özüne odaklanmışsa, bu tür öneriler okunmaya değer

• İnsanların yapay zeka üretimi içeriklerden neden yorulduğunu anlayabiliyorum; özellikle ölçek büyüdükçe bunun daha da böyle olduğunu düşünüyorum
  Çalıştığım küçük ekipte bile can sıkıcı şeyler oluyor. “Bunu neden böyle yaptınız?” diye sorunca “Aa, Claude öyle yaptı” cevabı geliyor; bu bir cevap değil. İnsanlar sadece düşünme sürecini değil, sorumluluğu da makineye devrediyor. Şimdilik muhafazakâr kullanmak illa kötü bir şey değil; bu teknolojiyi büyük ölçekte sorumlu biçimde kullanmayı öğrendikten sonra gevşetmek daha doğru olur. Şu anda kimse bunun yolunu bilmiyor

• Bu yalnızca NLnet Labs'ın kendi politikası; NLnet tarafından desteklenen projelerin mutlaka benimsemesi gereken bir politika değil

• Bu kararı almalarının arka planını anlıyorum, ancak uygulama biçimi “hiçbiri olmaz”a yakın olduğu için dar görüşlü görünüyor

  • Bu normatif yargının nereden geldiğini açıklayabilir misin? Başka birinin kendi projesine LLM tarafından üretilmiş gönderimleri kabul etmesinde neden bir çıkarın olduğunu, onların ya da toplumun bundan ne kazandığını merak ediyorum
    Ben bu mantığın tutarlı ve makul olduğunu, bugünlerde sağlıklı bir koruma önlemi sayılacağını düşünüyorum. Bu nedenle gönderiminin reddedilmesinden mi endişelisin, yoksa başına böyle bir şey zaten geldi mi, onu da merak ediyorum. Bu politikaya uymak bu kadar zor mu? Sen de temel altyapının uzun vadeli bakımcısı olarak her gün issue tracker'a yağan düşük kaliteli gürültüyle mi uğraşıyorsun? İnsan merkezli bir iş akışında yanlış pozitif selinin etkisini azaltırken motivasyonu korumak için ne yapılması gerektiğini düşünüyorsun?
  • Dar görüşlü demektense temkinli derdim
  • İlgili topluluğun, herkesin çıkarlarını daha doğru yansıtan açık ve karmaşık kuralları kaldıramadığı ortaya çıkarsa, dar ve basit kuralların konması oldukça yaygındır
    Bu kötü bir şey değil. Geliştiriciler biraz daha olgunlaştığında yeniden değerlendirilebilir