Ürünümüzün içinde GPL kod çıktı: açık kaynak lisansları sizi neye mecbur bırakır?

Açık kaynak bir kütüphaneyi kullanmak ücretsizdir ama koşulsuz değildir. Her lisans bir izin metnidir: koşullarını yerine getirdiğiniz sürece kodu kullanma, değiştirme ve dağıtma hakkınız vardır, yerine getirmediğinizde o izin düşer ve geriye sıradan bir telif ihlali kalır. Pratikte üç aileyle uğraşıyorsunuz. İzin verici lisanslar (MIT, BSD, ISC, Apache 2.0) sizden neredeyse yalnızca atıf ister. Copyleft lisanslar (GPL, LGPL, MPL, AGPL) türettiğiniz çalışmanın kaynağını da aynı şartlarla açmanızı ister. Üçüncü grup, SSPL ve BUSL gibi kaynağı açık olan ama açık kaynak sayılmayan lisanslar, belirli kullanım biçimlerini doğrudan yasaklar. Kritik ayrım şu: copyleft yükümlülüklerinin büyük kısmı yazılımı başkasına verdiğinizde doğar, sadece içeride çalıştırdığınızda değil. Bu kuralın istisnası AGPL ve SaaS ürünü olan şirketlerin asıl dikkat etmesi gereken lisans o.

Sorunun ölçeği tahmin ettiğinizden büyük. Black Duck'ın 947 ticari kod tabanını ve 17 sektörü inceleyen 2026 OSSRA raporunda kod tabanlarının %98'i açık kaynak bileşen içeriyor ve %68'inde en az bir lisans çakışması bulundu. Bir önceki yıl bu oran %56'ydı; rapor bunu kendi tarihindeki en büyük yıllık artış olarak kaydediyor. Tek bir kod tabanında 2.675 ayrı çakışma sayılmış. Bu rakamlar denetimden geçmiş, yani satın alma veya yatırım öncesi masaya yatırılmış kod tabanlarından geliyor. Çoğu şirket bu tabloyu kendi ürününe bakarken değil, karşı taraf bakarken öğreniyor.

"Dağıtım" kelimesi neyi açar, neyi kapatır

GPL ailesinde yükümlülük, yazılımı şirketinizin dışına verdiğinizde doğar. Şirket içinde çalıştırmak dağıtım değildir. GPL lisanslı bir kütüphaneyi alıp değiştirebilir, kendi iç sisteminizde yıllarca kullanabilir ve tek satır kaynak kod yayınlamak zorunda kalmazsınız. Bunu bilmeyen ekipler gereksiz yere panikliyor.

Dağıtım sayılan durumlar ise net: mağazaya yüklediğiniz mobil uygulama, müşteriye gönderdiğiniz kurulum paketi, cihaza gömdüğünüz firmware, müşterinin kendi sunucusuna kurulan sürüm. Bunların hepsi copyleft yükümlülüğünü tetikler ve "tam karşılık gelen kaynak kod" ile birlikte derleme betiklerini de vermeniz gerekir.

Klasik GPL açısından SaaS dağıtım sayılmaz. Ürününüz tarayıcıdan kullanılır, kod kimsenin bilgisayarına geçmez, dolayısıyla kaynak sunma yükümlülüğü doğmaz. AGPL tam olarak bu boşluğu kapatmak için yazıldı. 13. maddesi, yazılımı ağ üzerinden kullanan kişiye de kaynak kodu sunmanızı şart koşuyor. SaaS ürününüzün derlemesine giren AGPL bir bileşen, o ürünün tamamı için soru işareti yaratır. Bağımlılık listenizde AGPL görürseniz o satırı tesadüfe bırakmayın.

Üç aile, üç ayrı fatura

İzin verici lisanslar. MIT ve BSD pratikte tek şey ister: telif notunu ve lisans metnini dağıttığınız her kopyada taşımak. Apache 2.0 biraz daha ayrıntılı. Lisans kopyasını vermenizi, değiştirdiğiniz dosyaları değiştirdiğinizi belirtmenizi ve varsa NOTICE dosyasının içeriğini kendi ürününüze taşımanızı ister. Karşılığında açık bir patent lisansı verir, ama o patent yüzünden dava açarsanız size verilen patent izni düşer.

Güçlü copyleft. GPLv2, GPLv3 ve AGPL, türev çalışmanın tamamının aynı lisansla dağıtılmasını ister. "Türev çalışma"nın sınırı hukukun en tartışmalı kısımlarından biri, ama pratik kural işe yarar: kütüphaneyi kendi süreciniz içinde bağlıyorsanız risk yüksektir, ayrı bir süreç olarak çağırıp aranızda tanımlı bir arayüz varsa daha savunulabilir bir konumdasınız. GPLv3 ayrıca tüketici cihazlarında kurulum bilgisi (installation information) istiyor, yani kullanıcının kendi derlediği sürümü cihaza kurabilmesini.

Dosya düzeyinde copyleft. MPL 2.0 ve EPL 2.0 bu grupta ve çok daha yönetilebilir. Yükümlülük yalnızca değiştirdiğiniz dosyalarla sınırlıdır, kendi kodunuz kapalı kalabilir. LGPL de bu aralıkta: kütüphaneyi dinamik olarak bağladığınız ve kullanıcının kütüphaneyi kendi sürümüyle değiştirebilmesine izin verdiğiniz sürece ürününüzün kaynağını açmanız gerekmez.

Lisansların birbiriyle uyumu da ayrı bir konu. En bilinen örnek Apache 2.0 ile GPLv2'nin uyumsuz olması. İki lisansın da geçtiği bir derleme kurup yıllarca fark etmeyebilirsiniz; bu tam olarak denetimlerde çıkan "çakışma" tipidir.

En sık yapılan ihlal büyük değil, küçük

Şirketlerin başını ağrıtan şey genelde gizlice kopyalanmış GPL kodu değil. MIT'in tek şartını yerine getirmemek. Yani ürüne giren yüzlerce izin verici lisanslı kütüphanenin telif notlarını ve lisans metinlerini dağıtılan pakete koymamak.

Mobil ve masaüstü ürünlerde bunun standart çözümü, uygulamanın içinde bir açık kaynak lisansları ekranı bulundurmak. Web'de bir metin dosyası ya da sayfa yeterli. Bu işi elle yapmayın; paket yöneticinizin lisans dökümünden derlemede otomatik üretilsin, yoksa ilk bağımlılık güncellemesinde sessizce eksik kalır.

İhlalin yaptırımı ne? Vizio davasının gösterdiği şey

Copyleft'in kâğıt üstünde kaldığını düşünenler için son beş yılın en dikkat çekici dosyası Software Freedom Conservancy'nin Vizio'ya açtığı dava. Ekim 2021'de açılan davada SFC, telif hakkı sahibi olarak değil, GPL'li yazılım içeren bir televizyon satın almış kullanıcı olarak sözleşmenin üçüncü kişi lehtarı sıfatıyla kaynak kod talep ediyor. Vizio'nun davayı düşürme talebi 29 Aralık 2023'te reddedildi ve dosya esastan görülmeye devam etti. Duruşma takvimi 2026'nın sonunu gösteriyor, nihai karar henüz yok. Sonucu ne olursa olsun tabloyu değiştiren nokta şu: bir ürünü satın alan taraf da uyum talep edebiliyor.

İhlalin doğrudan sonucu ise lisansın kendisinde yazılı. GPLv2'de ihlal anında lisans kendiliğinden sona erer ve yeniden kazanmanın yolu telif sahibinden izin almaktır. GPLv3 bunu yumuşattı ve bildirimden sonra 30 gün içinde düzeltme hakkı getirdi. 2017 ve 2018'de Linux çekirdeği geliştiricileri ile Red Hat, IBM, Google ve Facebook, GPLv2 lisanslı kendi kodları için de aynı düzeltme süresini taahhüt ettiler. Yine de bu bir garanti değil, yalnızca taahhüde katılan hak sahipleri için geçerli.

Bugün gördüğünüz lisans yarın aynı kalmayabilir

Son üç yılın en pahalı sürprizleri açıklardan değil, lisans değişikliklerinden çıktı.

HashiCorp 10 Ağustos 2023'te Terraform dahil tüm ürünlerini MPL'den BUSL 1.1'e geçirdi. Topluluk son sürümü çatalladı, OpenTofu 20 Eylül 2023'te Linux Foundation'a kabul edildi ve MPL 2.0 ile yoluna devam etti. Redis Mart 2024'te 7.4 sürümüyle BSD'den RSALv2 ve SSPLv1 ikilisine geçti; günler içinde Linux Foundation altında Valkey çatalı doğdu ve Redis 1 Mayıs 2025'te Redis 8 ile AGPLv3 seçeneğini geri ekledi. Elastic 2021'de SSPL ve Elastic License 2.0'a geçmişti, 29 Ağustos 2024'te AGPLv3'ü seçenek olarak ekleyip açık kaynak tarafına döndü.

Buradan çıkan iş kuralı basit: bağımlılık seçimi bir kez verilen karar değil. Sürüm yükseltirken lisans satırına da bakın, çünkü lisans değişiklikleri yeni sürümle birlikte gelir, eski sürüm eski lisansta kalır. Bu, sürümleri sabitlemenin ve neyin hangi sürümde olduğunu bilmenin güvenlikten bağımsız ikinci gerekçesi. Yazılım tedarik zinciri güvenliği yazımızdaki envanter alışkanlığı burada da aynen işe yarıyor.

"Kaynağı açık" ile "açık kaynak" aynı şey değil

SSPL ve BUSL'nin ortak özelliği, Open Source Initiative tarafından onaylanmamış olmaları. MongoDB SSPL için yaptığı başvuruyu geri çekti. Bu lisanslar kaynağı okumanıza ve çoğu durumda kullanmanıza izin verir, ama açık kaynak tanımını karşılamaz.

BUSL'de sınırı lisansı veren şirket çiziyor. Standart metin üretim kullanımını kapatıyor, şirketler "ek kullanım izni" parametresiyle bunu gevşetiyor. HashiCorp'un izni üretim kullanımına açıkken kendi ürünleriyle rekabet eden barındırılmış hizmet sunmayı dışarıda bırakıyor. Ayrıca BUSL her sürüm için en fazla dört yıllık bir değişim tarihi koymayı ve o tarihte GPL uyumlu bir lisansa dönmeyi şart koşuyor. Terraform'un dönüş lisansı MPL 2.0.

Pratik sonuç: çoğu şirket için bu lisanslar günlük kullanımda sorun çıkarmaz. Sorun sözleşmelerde çıkar. İhale şartnamesine ya da müşteri sözleşmesine "yalnızca açık kaynak bileşen kullanılmıştır" diye yazdıysanız, SSPL veya BUSL lisanslı bir bileşen o taahhüdü karşılamaz.

Yapay zekânın ürettiği kodun lisansı ne?

OSSRA raporunun lisans çakışmalarındaki sıçramayı açıklarken kullandığı terim "lisans aklama": yapay zekâ asistanları copyleft kaynaklardan türeyen kod parçalarını, kaynağındaki lisans bilgisini taşımadan üretiyor. Aynı rapordaki ankette şirketlerin %76'sı yapay zekâ ürünü kodu güvenlik açısından inceliyor, fikri mülkiyet ve lisans açısından inceleyenlerin oranı %54'te kalıyor, dört kategorinin hepsini birden kontrol edenler ise %24. Kod incelemesi kontrol listenize lisans maddesi eklemek bugün ölçülebilir bir boşluğu kapatıyor. Konunun tamamını AI ile yazılan kodu gözden geçirme yazısında ele almıştık.

Aynı kural insan kaynaklı kopyalar için de geçerli. Soru cevap sitelerinden alınan kod parçaları çoğunlukla atıf isteyen bir Creative Commons lisansı altındadır. Lisansı hiç belirtilmemiş bir depodan alınan kod ise serbest değildir, aksine tüm hakları saklıdır.

Envanteriniz yoksa uyumunuz da yok

Lisans uyumu bir hukuk işi gibi görünür, aslında bir envanter işidir. Başlangıç noktası ürün derlemesinden otomatik üretilen bir yazılım bileşen listesi (SBOM). İki yaygın format var: lisans takibinden doğan SPDX (2.2.1 sürümü ISO/IEC 5962:2021 olarak standartlaştı) ve OWASP'ın güvenlik tarafına yatkın CycloneDX'i (ECMA-424). Hangisini seçtiğiniz, elle Excel tutmaktan daha az önemli.

Listeyi derlemede üretin, çünkü elle tutulan liste ilk haftadan sonra gerçeği yansıtmaz. Sonra bunu bir kapıya bağlayın: yeni bir bağımlılık politikanıza uymayan bir lisansla geldiğinde birleştirme isteği kırmızı dönsün. GitHub bu kontrolü 30 Haziran 2026'da Enterprise Cloud ve Advanced Security Code Security müşterileri için önizlemeye açtı, bağımsız araçlarla da yıllardır yapılabiliyor. CI/CD hattınız zaten varsa bu ek bir adımdan ibaret.

Politika bir sayfaya sığar

Uzun bir hukuk metni yerine üç kova yeterli.

• Serbest: MIT, BSD, ISC, Apache 2.0, Unlicense. Tek şart bildirimlerin pakete taşınması.
• İnceleme gerekir: LGPL, MPL 2.0, EPL 2.0. Dinamik bağlama ve dosya sınırı korunuyorsa çoğu durumda geçer.
• Varsayılan hayır: GPL, AGPL, SSPL, BUSL ve lisansı belirtilmemiş kod. Yazılı onay olmadan dağıtılan ürüne girmez.

Kovaları bağlamla birlikte okuyun. Sadece içeride çalışan bir araçta GPL sorun değildir. Müşteriye kurduğunuz bir üründe aynı bileşen ciddi bir karardır. SaaS ürününüzde AGPL, ürünün tamamını ilgilendirir.

Yazılımı dışarıya yaptırıyorsanız kabul şartına yazın

Özel yazılım teslim alan şirketlerin çoğu, teslim edilen kodun ne kadarının başkalarına ait olduğunu hiç sormuyor. Sözleşmeye üç madde koymak bu boşluğu kapatır: teslimle birlikte lisans bilgisini içeren bir bileşen listesi verilmesi, copyleft lisanslı bileşenlerin ancak yazılı onayla kullanılabilmesi, ve dağıtılan ürünün içinde gerekli bildirim dosyalarının bulunması. Bu maddeler kaynak kod mülkiyeti ve emanet tarafındaki sözleşme çalışmasının doğal devamı, kontrolü de kabul testi aşamasına koymak en kolayı.

Tartışmalı bir durumla karşılaşırsanız, örneğin türev çalışma sınırının nereden geçtiği konusunda, bunu ekip içinde yorumlamayın. Fikri mülkiyet tarafında çalışan bir hukukçuyla konuşmak, sonradan ürünü yeniden yazmaktan ucuzdur.

Bu hafta atabileceğiniz dört adım

1. Listeyi çıkarın. Üretim derlemenizden bileşen ve lisans dökümü alın. Çoğu paket yöneticisinde bu tek komut, değilse bir SBOM aracı yarım saatte kurulur.
2. Dört şeyi arayın. GPL, AGPL, SSPL veya BUSL lisanslı bileşenler ve lisansı hiç görünmeyen paketler. Genelde listedeki en kısa bölüm bu olur ve zaten karar vermeniz gereken her şey oradadır.
3. Bildirim dosyasını kontrol edin. Müşteriye dağıttığınız pakette lisans metinleri var mı? Yoksa bu, en hızlı kapatılabilecek eksik.
4. Üç kovayı yazın ve kapıya bağlayın. Politikanın tek sayfası bugün, birleştirme isteğindeki otomatik kontrol bu hafta.

İlk adımı atan ekiplerin büyük kısmı beklemedikleri bir bileşenle karşılaşıyor. Bunun sebebi dikkatsizlik değil, bağımlılığın bağımlılığının bağımlılığı olması. Listeyi bir kez çıkardıktan sonra iş, ayda birkaç dakikalık bir kontrole iniyor.