QEMU - "Yapay zeka kod üreticilerinin kullanımı yasak" politikasını tanımladı

• QEMU topluluğu yakın zamanda politikasını güncelledi. Yapay zeka kod üreticilerinin (ör. Copilot, ChatGPT vb.) kullanımı ve bu araçlar aracılığıyla kod gönderimi yasaklandı

define policy forbidding use of AI code generators

• Son dönemde yapay zeka kod üreticileri kullanımına ilgi hızla artsa da, bu araçların çıktılarıyla ilgili lisans yorumları sektör genelinde geniş kabul görmüş değil
• Başlıca satıcılar bir sorun olmadığını ve lisansın serbestçe seçilebileceğini savunsa da, bu tarafların çıkar çatışması bulunuyor
• Yapay zeka kod üreticileri farklı lisanslar altındaki verilerle eğitildiği için, çıktıların lisans sorunları konusunda sektörde hâlâ bir uzlaşı yok
• QEMU, DCO'da (Developer Certificate of Origin) katkıda bulunanın, ilgili proje lisansı kapsamında koda katkı yapma hakkına açıkça sahip olmasını şart koşuyor
  • Yapay zeka kod üreticisiyle yazılmış kod söz konusu olduğunda, DCO'nun b/c maddelerine uyumu kanıtlamanın zor olduğunu açıkça belirtiyor
  • Bu nedenle, yapay zeka kod üreticisinin açıkça kullanıldığı veya kullanıldığından şüphelenildiği durumlarda QEMU projesine kod katkısına izin vermeyen bir politika getirildi

Politikanın esnekliği ve istisna yönetimi

• Yapay zeka destekli yazılım geliştirmenin henüz erken aşamasında olunduğundan, hukuki meselelerin ileride çözüme kavuşma ihtimali yüksek
• Araçlar geliştikçe, gelecekte bazı araçların açık kaynak projelerde güvenle kullanılabilir hâle gelmesi bekleniyor
• Şimdilik katı ve güvenli politika öncelikli olarak uygulanacak, gerekirse ileride gevşetilebilecek
• İstisna talepleri tek tek incelenerek kabul edilip edilmeyeceğine karar verilecek

[GN⁺]

Hacker News görüşleri

• Açık kaynak ve özgür yazılım, AI ile üretilen kodun ihlal eden bir eser sayılması ya da public domain olduğuna karar verilmesi durumunda özellikle kırılgan hissediyor. Eğer AI düzenlemeleriyle insan düzenlemelerini ayırmak gereken bir durum ortaya çıkarsa, projeler yıllarca hukuki sorunlara takılabilir ve dava masraflarını da karşılayamaz. AI tarafından yazılmış kod ileride insanlar tarafından değiştirilir veya mevcut koda entegre edilirse, sonraki insan düzenlemelerinin adil kullanım sınırlarını aşan türev eser sayılıp sayılmayacağı da ayrı bir tartışma konusu. Eğer AI üretimi kodun public domain olduğuna karar verilirse, kaynak kodunun sadece bir kısmı açık kaynak/özgür yazılım lisansına tabi olan projelerin lisansı kötüye kullanan şirketlere karşı güçlü biçimde karşılık verme araçları hızla azalır. Lisans ihlali yapan tarafın insan tarafından yazılmış, yani lisanslı kod kullandığını ayrıca kanıtlamak gibi ağır bir yük doğar. Buna karşılık proprietary yazılım bu durumda görece daha az etkilenir. Çünkü AI üretimi kodun izinsiz alıntı olduğunu iddia etmek için birilerinin ilgili binary’yi tersine mühendislikle inceleyip asıl kodla karşılaştırması gerekir ve proprietary yazılımların içinde de zaten çoğu zaman public domain kod bulunur
  • MIT lisansı için bunun aksine faydalı bir sonuç doğurduğunu düşünüyorum
  • Deneyimli bir geliştirici olarak, bilgisi olmayan “geliştiricilerin” rastgele AI kodu katkısı yapmasını istemeyen pek çok kişiye katılıyorum. AI kodunu satır satır insan eliyle incelemek, hukuki meseleleri bir kenara bıraksak bile yıllarca insan kaynağını bağlayacak bir iş. Birincisi, gelecekte bir kodun AI ile üretildiğini doğrulamanın pratik bir yolu neredeyse hiç olmayacak gibi görünüyor. İkincisi, gerçekten %100 yalnızca insanlar tarafından geliştirilen yazılımlar, gelecekte AI destekli veya AI tarafından yazılan projelere göre bariz biçimde rekabet gücü kaybedecek. Buna karşı tek itiraz, insanların artık yarı iletken ya da elektriği seri üretemediği kıyamet ölçekli bir çöküş senaryosu olabilir. Üçüncüsü, bir proje AI kod katkılarını tamamen dışlamayı başarsa bile, (nasıl başaracağı belirsiz olsa da ve AI karşıtı küçük bir azınlık katkı verse bile) sonunda biri o kodu kopyalayıp hukuken riskli kısımları çıkararak yeni bir projeye geçecektir. Eğer lisans fork’a izin veriyorsa doğrudan fork da edilebilir ama kopyalayıp temizleme yaklaşımı daha çok tercih edilebilir. Açık kaynağın önünde hâlâ uzun bir yol var ve geleceğin yazılımları nicelik olarak patlayıcı biçimde artacak; bunların %99’u vasat olsa bile gerçekten değerli yazılım sayısı da artacak gibi görünüyor
  • AI telif hakkı konusu bağlamında US Copyright Office’in AI sanatı hakkındaki tutumuna dair news.artnet.com güncel haberi ile maymun selfie kararı vikisi paylaşılıyor ve bu tartışmanın artık geri döndürülemez bir yola girdiği belirtiliyor
  • Eğer bir yazılım gerçekten “bu kodla ne istersen yap, umurumuzda değil” anlamına gelen gerçek anlamda çok geniş açık kaynaklıysa, AI yüzünden endişelenecek hiçbir şey yok
• Bunun LLVM politikasından kesinlikle daha sert bir tutum olduğu izlenimini aldım. Ayrıntılar için LLVM geliştirici politikası görülebilir. Ben eski kafalı bir geliştiriciyim; yazarın da benim de anlamadığı kodu incelemek zorunda kalmak istemem
  • Yazar kendi kodunu bile bilmiyorken benim onu review etmem gerçekten rahatsız edici. Gerçekten biri benden bir işi yapmamı isterken, kendisine AI’ın verdiği açıklamayı aktarıp “böyle yapılmalıymış” dediğinde, açıkçası doğrudan “bunu yapar mısın” demesi çok daha iyi. Hatta biraz hakaret gibi geliyor
  • Yönettiğim tüm açık kaynak projelerine DCO(Developer Certificate of Origin) eklemeye başladım ve CONTRIBUTING.md dosyasına şu LLM kod katkı politikasını koymayı planlıyorum

  ---

  LLM-Generated Contribution Policy
  Color kütüphanesi, karmaşık matematik ve incelikli kararlarla dolu bir kütüphanedir. Tüm issue ve PR’ler, gönderen kişinin kendi derin anlayışıyla hazırlanmalıdır; özellikle PR’lerde geliştirici her commit için DCO beyanı yapmalıdır. Eğer PR, LLM yardımıyla yazıldıysa commit mesajında ve PR içinde açıkça belirtilmelidir. Kanıt sunulmadan LLM yardımı tespit edilirse PR reddedilir. LLM tarafından üretilen içeriğin review edilmeden gönderilmesi koşulsuz reddedilir

  SECURITY.md içinde de LLM-Generated Security Report Policy ekleyerek, LLM tarafından üretilen güvenlik bildirimlerini hiçbir koşulda kabul etmemeyi planlıyorum

  Projeyi tek başına sırtlanan biri olarak denge kurmaya çalışıyorum ama kişisel olarak LLM kod katkılarını tercih etmiyorum
  • Kişisel projelerimde GitHub Copilot kullanıyorum. Ama bunu “akıllı autocomplete” dışındaki bir biçimde kullanmıyorum. Yazmayı düşündüğüm koda yeterince benziyorsa ancak o zaman kabul ediyorum. Bu sayede kodumu %100 ben anlamış oluyorum ve dikkatsizlik kaynaklı bug’lardan ya da telif tartışmalarından kaçınabiliyorum. Copilot’u bu şekilde kullanmak geliştirmeyi hızlandırıyor. Aslında mesele yavaş yazmam değil; daha çok aklımın dağılması ya da sıkılmam. Copilot sayesinde bir sonraki düşünme veya debug aşamasına daha hızlı geçiyorum.
    Başkasının kendi kodunu bile anlamadan PR gönderebilmesi bana gerçekten hayal etmesi zor bir şey gibi geliyor. Bu yüzden, başkaları yüzünden benim de LLM’leri sadece autocomplete düzeyinde kullansam bile politikalarla kısıtlanıyor olmam biraz can sıkıcı.
    Basit otomatik refactor işlerini Copilot’a yaptırmak isterdim ama denediğimde çoğu zaman her şeyi berbat ediyor ve tüm blokları baştan üretmeye yöneldiği için elle yapmaktan daha yavaş oluyor.
    İlginç olan şu ki, eğer yazarken bir bug giriyorsam Copilot çoğu zaman o bug’ı da aynen tamamlıyor. Değişken adı yazım hataları gibi bağlama göre bariz hataları bile olduğu gibi autocomplete ediyor
  • LLM’leri kodlama işlerinde kullanırken örneğin “bu YAML içeriğini struct’a dönüştür ve tekrar eden kalıpları değişkenlere çıkar” gibi istekler veriyorum. Bunu deterministik araçlarla da yapmak mümkün ama AI bunu 30 saniyede temiz biçimde yapıyor ve sonucun girdiyle aynı olduğunu test etmek de kolay oluyor
    Yaptığım yüksek seviye işleri asla AI’a bırakmam ama tekrarlayan ve önemi daha düşük işleri AI devralıp hız kazandırıyor. Örneğin Claude Code’a veritabanı benchmark sonuçlarının CSV dosyalarını verip çeşitli grafiklerle aykırı değer analizlerini birbirine bağlamasını istediğimde, kavramsal olarak kolay ama kütüphane bulma ya da kurulumla zaman harcatan işleri hızlıca tamamlıyor
  • Yazarın kendi kodunu anlamıyorsa review etmeyeceğini söyleyen tavrını tamamen anlıyorum. Ama yetkin bir insan doğru yönlendirirse AI araçları da oldukça gelişmiş kod üretebiliyor. Son aylarda her birkaç ayda bir daha da güçlendiklerini görüyoruz ve çoğu zaman yalnızca doğal dil talimatlarıyla sonuç verebiliyorlar
    “Kodu anlamak” derken neyi kastettiğimizi düşünüyorum. Benim üzerinde çalıştığım bir projede mevcut VM orkestrasyon sistemine tamamen yeni bir storage backend ekleniyor. Mevcut kod tabanını bilmiyorum; bunu baştan yazacak vaktim de yok. Ama bir test cluster’ı kurup farklı senaryoları çalıştırarak tasarım ve test açısından genel resmi yeterince kavrıyorum
    Ben de bir açık kaynak maintainer’ı olarak düşük kaliteli LLM “slop” PR’lerinin ne kadar büyük stres yarattığını tahmin edebiliyorum. Sonuçta yazar kodu anlıyor olsun ya da olmasın, maintainer her durumda kodu review etmek zorunda.
    Bence bundan sonra bu araçları nasıl uygun şekilde kullanacağımızı ve gönderilen kodun kalite düzeyini diğer geliştiricilere nasıl sinyalleyebileceğimizi düşünmemiz gerekecek. İlk Linux ZFS portunda bulunan ince bug’lardan çıkardığım ders, insanların satır satır review edip yazması kadar kapsamlı testlerin de son derece önemli olduğuydu
• Blogum “yes i will judge you for using AI”da öngördüğüm şey gerçek oldu. Açık kaynak geleneksel olarak katkı yapanların gizli yeterlilik işaretlerine (competency markers) çok dayanıyordu; LLM’ler ise hiç deneyimi olmayan kişilerin bile yetkin görünür kod üretmesini sağlıyor. Deneyimli insanlar için bu gerçekten kafa karıştırıcı bir şok. İleride büyük projelere girmek için, gerçek PR’den bağımsız sosyal kanıtların (çevrim içi ya da yüz yüze görüşmeler gibi) giderek daha gerekli hale geleceğini düşünüyorum
  • Şirkette de aynı şeyi yaşıyoruz. İş arkadaşları LLM ile code review yorumları üretiyor ve seviye o kadar yüksek görünüyor ki kısa süreliğine inanıyorsunuz. Sonra yorumların doğru olup olmadığını doğrulamak için çok zaman harcıyorsunuz ve sonunda yapıştır-kopyala yapan kişinin harcadığından çok daha fazla enerjiyi siz tüketmiş oluyorsunuz
  • Blog bağlantısı isteniyor
• Bu, RedHat merkezli ve imzalanmış bir politika. RedHat oldukça ciddi ve kurumsal odaklı. RedHat’in derdi muhtemelen “AI üretiminin telif hakkı kime ait” sorusundan çok, AI’ın eğitim sırasında aldığı başka proje kodlarını fark etmeden dışarı kusmasıdır. Çoğu hypervisor kapalı kaynak ve dava açmayı seven şirketler de çok
  • Eğer risk, AI’ın eğitim verisindeki “başka proje kodunu” aynen dışarı vermesiyse, bu aslında AI’ın ürettiği neredeyse tüm kodlar için geçerli bir problem gibi geliyor bana
  • Dil modelleri çoğu zaman ince mantık hatalarını daha kolay üretme riski taşır ve bu hatalar hypervisor’ın güvenlik sınırlarını bile ihlal edebilir. AI yardımını çok kullanan kullanıcılar bu tür hataları yakalamaya yeterince hazırlıklı olmadıkları için daha da tehlikeli olabilir
• IBM tarafından satın alınan RedHat ekibinden kişilerin bu politikayı ağırlıklı olarak imzaladığına dikkat çekiliyor. IBM, Watson’ı yaptı ve 2011’de Jeopardy’yi de kazandı. “Henüz başlangıç aşamasındayız” şeklindeki AI yazılım geliştirme anlatısının gerçekten samimi mi olduğu, yoksa bunun IBM tarzı bir satın alma-yıkım sahnesi mi olduğu sorgulanıyor.
  Dotnet Runtime ise AI’ı aktif biçimde benimsiyor. Dışarıdan alay edilebilir ama Stephen Toub, David Fowler gibi çok güçlü mühendislerin bunu desteklediğine dikkat edilmeli.
  Şirketlere, bir dahaki sefere IBM AI hizmeti satmaya geldiğinde gerçekten gelecek odaklı ortaklar aramalarını tavsiye ediyor.
  North Carolina’lı biri olarak IBM ve RedHat’in doğru yönü bulmasını umduğunu söylüyor
• Gerçekten hukuki gerekçelerle mi yapıldığını merak ediyorum. Bazı projeler sanki yalnızca AI’ın ürettiği düşük kaliteli code review’lardan bıkmış gibi görünüyor
  • QEMU, endüstride son derece kritik bir yazılım. Masaüstü VM’lerde, bulutta, build sunucularında, güvenlik sandbox’larında, çapraz platform ortamlarında ve daha pek çok yerde kullanılıyor. Çok küçük bir hukuki risk bile sektör üzerinde ciddi etki yaratabilir
  • Politika açık ve sınırlı. Algoritmik olarak üretilmiş kodun telif hakkı sahipliğini güvence altına almanın mümkün olmadığını vurguluyor gibi görünüyor. Özellikle “algoritmik olarak” ifadesini seçmişler. Mevcut politika da bu niyeti taşıyor gibi; “bugün mümkün olan en sıkı ve en güvenli yerden başlarız, sonra gevşetiriz” cümlesiyle başladığı için baştan makul görünüyor. Elbette sözde “tonla slop”u da reddediyorlar ama asıl strateji önce hukuki risk ve mülkiyet sorunlarını çözmek. Bana curl’ün politikasından çok daha iyi görünüyor
  • Monsanto’nun tohum haklarını agresif biçimde uygulama örneği verilerek uyarıda bulunuluyor
  • AI’ın orta seviye kod kalitesini nasıl değiştireceğinden açıkçası emin değilim ama insanlar da çoğu zaman işe yaramaz kod çıkarıyor. Commit sayısı aşırı artıp yönetilemez hale gelirse, proje bazında triage ekipleri gerekip gerekmediğini düşünüyorum. Çoğu katkının iyi niyetle yapıldığına inanıyorum.
    Hukuki risk yüzünden AI’dan kaçınanları anlıyorum ama aşırı kaygılanmak da bana biraz tuhaf geliyor. Bir ihtimali gerçekten sıfırladığını düşünen birinin, bence konuyu yeterince düşünmemiş olması muhtemel
  • Bu gidişle açık kaynak zarar görebilir. Kopyala-yapıştır kod üretmek çok kolay, inceleyip reddetmek ise çok zaman alıyor. Daha fazla projenin, “herkes kaynak kodu indirebilir ama dışarıdan birinin gerçekten katkı yapması neredeyse imkânsızdır” türü Android benzeri modele kayacağını düşünüyorum
• LLM’leri IDE içinde akıllı autocomplete aracı olarak kullanmakla, yüksek seviyeli talimatlar verip tüm kodu topluca ürettirmek arasında ayrım yapılmasını umuyorum. Bunun gri alan olduğunu kabul ediyorum ama Copilot tarzı autocomplete kullanımından telif riski doğmadan yararlanabilsek keşke. Örneğin bir dizi case ifadesi yazarken Copilot kalıbı fark edip yazma yükünü büyük ölçüde azaltabiliyor
  • Hatta gelecekte AI gözlüklerinin düşünceme ve bedenime eklemlenmiş bir parça gibi olmasını hayal ediyorum. Nasıl normal gözlük görmeyi destekliyorsa, akıllı gözlükler de düşünmeyi destekleyebilir.
    Benim beynim de aslında bol miktarda kapalı kaynak kod öğrenmiş durumda; bu yüzden AI telif hakkı tartışmalarını Batı tarzı bir NIMBY tavrı olarak eleştiriyor. Böyle hukuki “ya olursa” senaryolarını bahane edip harika teknolojileri reddetmeye devam edersek Batı uygarlığının bile çözülebileceğinden endişe ediyor
• Bu tür bir politikanın neden ortaya çıktığını anlıyorum ama yine de hata olduğunu düşünüyorum. AI ve telif hakkı konularında hukuki değerlendirmelerin net olmadığını ve yasama tarafında da neredeyse hiçbir şey bulunmadığını düşünüyorum.
  AI katkılarını yasaklamanın yanında, tersine “şu alanlarda AI kullanılabilir” diye açık sınırlar koymak da gerekli olabilir. Örneğin QEMU’nun CI kurulumu, güvenliğin korunması gereken çekirdek alanlardan biri değil. İlginç ve yeni test senaryoları ya da ortamlar için AI katkılarının belli şartlarla kabul edilmesi gayet mümkün olabilir
  • Bu politikanın uygulanmaması halinde ne risk doğacağını düşünüyorum. Kod biraz daha yavaş üretilebilir ama daha iyi olur; hızdan feragat etme pahasına bile olsa, QEMU gibi kritik bir projede bu riskin alınması gerektiğini düşünüyorum. Yazarların GenAI’ın kendisine ideolojik olarak karşı olmaktan çok, bir kez girildi mi geri alınamayacak bir duruma karşı temkinli davrandıkları izlenimini alıyorum
  • En kolay çözüm basitçe “hukuki durum netleşene kadar beklemek”. QEMU’nun kodunun neredeyse tamamı GPL 2.0 ve eğer GenAI kodu yanlış biçimde içeri alınır, sonra da mahkemeler “orijinal kodun lisansına mutlaka uyulmalı” yönünde karar verirse, ilgili kodu geri almak ve tüm downstream ekosistemi düzeltmek ciddi yük yaratır. Başta “burası AI, yeniden kullanım yok” gibi etiketler koysak bile sonra topyekûn yeniden yazım sorunu ortada kalır.
    Sonuçta “şimdilik hiç kabul etmemek” herkes için daha az karmaşık ve daha az dramatik bir seçenek
    İlgili materyal olarak QEMU lisansı ve özgür olmayan lisanslar listesi bağlantıları veriliyor
  • Bu mesele onlarca yıl sürecek bir hukuk tartışması değil; zaten bununla ilgili onlarca dava mahkemelerde ve birkaç yıl içinde emsal kararların gelmesi bekleniyor. QEMU 22 yıldır AI olmadan gayet iyi büyüdü; birkaç yıl daha beklemek hiç de kötü olmaz
  • Bu politikanın satır aralarını iyi okumak gerektiği söyleniyor. Her davranışın hukuki riski var ama küresel büyük şirketler çoğu zaman bu tür riskleri de göze alıyor. QEMU’nun tavrı sıra dışı değil; asıl mesele muhtemelen gerçekten LLM kodu istememeleri. “Avukata soralım → hukuki risk var → kullanamayız” çizgisiyle tartışmayı tamamen kapatma stratejisi gibi okunuyor. Şirketlerde de bunun aynısı yaşanıyor
  • Bilişim dünyasında “kodu intihal etmemek” şeklinde uzun süredir var olan bir teamül bulunuyor. Kod çok kısa olsa, hatta hukuken ‘fair use’ sayılsa bile, kaynak kodu birebir kopyalamama kültürü var
• “Sıkı ve güvenli başlayıp zamanla gevşetmek” gerekçesi gerçekten makul geliyor
  Ama AI üretimi kodla, bir insanın bir yerlerden kopyaladığı kodu pratikte ayırmanın gerçekten mümkün olup olmadığını merak ediyorum. Açık kaynakta herkes katkı yapabildiği için, insanın da kod yazarken başka kaynaklardan etkilenmesi aynı derecede mümkün
  Şu anki bakış açımla, AI üretimi kodu başlı başına bağımsız bir kimlikten çok, insanın elindeki bir araç olarak görüyorum
  • “AI üretimi kod, insanın elindeki güçlü bir elektrikli testere gibidir” benzetmesi yapılıyor. Güçlü bir araçtır; insan yüzünden tehlikeli hale gelebilir.
    Ama bu benzetmenin artık gereğinden fazla uzadığını, daha fazla kullanmaya gerek kalmadığını düşünüyor
• Böyle bir politikanın pratikte hiç uygulanabilir görünmediğini düşünüyorum. Zed, Cursor, VS Code gibi editörlerin hepsi AI tabanlı autocomplete sunuyor ve benim yazdığım kodla AI’ın önerdiği kodu ayırmak imkânsız.
  Bu, benim bir çöp adam çizip sonra birinin “o çizimi teslim etme hakkın yok çünkü belki başkasının çöp adamını kopyaladın” demesine benziyor
  Politikanın gerçek amacının, sonunda bir gün biri AI koduyla karışık bir şey gönderdiğinde “elimizden geleni yaptık” diyebilmek için şimdiden pozisyon almak olduğunu düşünüyorum. Politika yazarlarının da bu kuralın anlamsız olduğunun farkında olmaması mümkün değil
  • Bu tür politikalar, “politik olarak şüpheli bir kod geldiyse bizim de yapabileceğimiz bir şey yoktu” diyebilmek için açık bir sorumluluktan kaçınma zemini hazırlıyor. Commit mesajlarında ya da patch’lerde “kod üreticilerinin lisans sorunları hukuken netleşmedi” gibi ifadeler de bu yüzden yer alıyor.
    Hukuki meselelerin dışında da, AI kodu kullanmanın beraberinde getirdiği çeşitli başka sorunlar olduğu açık
  • Neovim AI’ı zorunlu kılmıyor. Çalışması için onu sizin özellikle kurmanız gerekiyor. Eğer bir editör AI’ı kapatmayı imkânsız hale getiriyorsa, asıl büyük sorun editörün kendisidir