Açık kaynak veya yapay zekâ kodu kullandım: Uygulamamı ücretli satabilir miyim?

Kısa cevap

Evet, açık kaynak kullanmak tek başına uygulamayı ücretli satmanıza engel değildir. Ancak kullandığınız lisansın koşullarını yerine getirmeniz gerekir. Bazı lisanslarda telif ve izin bildirimini korumak öne çıkar; bazılarında dağıttığınız yazılımın ilgili kaynak kodunu sağlama gibi daha kapsamlı yükümlülükler doğabilir. Yapay zekâ aracının yazdığı kodda ise araç koşulları, üçüncü kişi hakları ve çıktının kaynağı ayrıca önemlidir.

Asıl soru çoğu zaman şudur: “Bu paketi kullanırsam kendi kodumu da açmak zorunda kalır mıyım?” Bunun cevabı paketin lisansına, sürümüne, değiştirip değiştirmediğinize ve ürünü nasıl sunduğunuza bağlıdır. Telefonlara indirilen uygulama, müşteriye teslim edilen sunucu paketi ve yalnız kendi sunucunuzda çalışan hizmet aynı şekilde değerlendirilmez.

Bu yazı, açık kaynak veya yapay zekâ koduyla ticari ürün geliştirenlerin karşılaştığı bu soruları açıklıyor. Lisans isimlerini bir yasak listesi gibi ezberlemek yerine, hangi kullanımın neden sorun oluşturabileceğini ve seçeneklerin neler olduğunu ele alıyor.

GitHub’da herkese açık bir kodu kopyalayıp kullanabilir miyim?

Açık kaynak lisansları belirli özgürlük ve koşullar içerir. Open Source Initiative'ın tanımı, yalnız kodu görebilmeyi yeterli saymaz; yeniden dağıtım ve türev çalışmalara ilişkin ölçütler de getirir. Kaynağı erişilebilir bir yazılımın ticari kullanım veya hizmet olarak sunma kısıtı bulunabilir. Bu nedenle bir internet sayfasındaki “open” ifadesini lisans incelemesi yerine kullanmayın. Open Source Definition

Ücretsiz indirilen bir paket, kullanımın bazı türleri için ticari lisans gerektirebilir. Aynı ürünün topluluk sürümü ile ücretli sürümü farklı koşullara tabi olabilir. Çift lisanslama denilen modelde hak sahibi alternatif lisanslar sunabilir; seçilen yol ve sağlanan yetkinin kapsamı kaydedilmelidir.

Lisans dosyası bulunmaması da “hiçbir şart yok” anlamına gelmez. Kaynağı açık bir depoyu şirket ürününe kopyalamadan önce izin dayanağı bulunmalıdır. Paketin açıklama sayfası, dosya başlıkları ve yayımlanmış sürümün lisans metni çelişiyorsa bu belirsizlik çözülmeden geniş kullanım kararı verilmemelidir.

MIT, Apache, GPL ve AGPL arasında benim için ne fark var?

MIT ve Apache-2.0 gibi lisanslar ticari ürünlerde sık görülür. MIT metni geniş kullanım izni verirken telif ve izin bildiriminin ilgili kopyalarda veya önemli bölümlerde korunmasını ister. “MIT ise hiçbir şey yapmamıza gerek yok” yaklaşımı bu yükümlülüğü atlar. MIT lisansı

Apache-2.0, dağıtımda lisansın verilmesi, değiştirilen dosyaların belirtilmesi ve ilgili bildirimlerin korunması gibi koşullar içerir. Varsa NOTICE dosyasındaki uygun atıflar ayrıca ele alınır. Patent lisansı ve marka kullanımının sınırları da metinde ayrı düzenlenmiştir. Kütüphanenin adını reklamda kullanma hakkı, yazılımı kullanma izninden otomatik çıkarılmaz. Apache License 2.0, özellikle bölümler 3, 4 ve 6

GPL gibi karşılıklılık içeren lisanslarda, kapsanan yazılımın dağıtılması ve kaynak kodunun sağlanması önemli inceleme noktalarıdır. “Bir GPL paketi gördük, bütün şirket kodu mutlaka açılır” veya “ayrı klasörde duruyor, hiçbir etkisi yok” şeklinde otomatik karar verilmemelidir. Birleştirme, değişiklik ve dağıtımın somut yapısı belirlenmelidir. GPLv3 lisans metni

AGPLv3 bakımından ağ üzerinden kullanım ayrıca önem taşır. Değiştirilen programla uzaktan etkileşen kullanıcılara ilgili kaynak kodu edinme imkânı sunulmasına ilişkin 13. bölüm, “kod yalnız sunucumuzda, dolayısıyla lisans yükümlülüğü doğmaz” varsayımını sorunlu kılabilir. Kapsam, hangi programın değiştirildiği ve hangi parçaların ilgili kaynak sayıldığı üzerinden değerlendirilir. AGPLv3, bölüm 13

Bu kısa açıklamalar lisansların tam koşullarının yerine geçmez. Aynı lisans ailesinin farklı sürümleri, istisnaları veya ek izinleri farklı sonuç doğurabilir. Kayda yalnız “GPL” yazmak yerine tam tanımı ve varsa istisnayı ekleyin.

Kodu yalnız sunucumda çalıştırıyorsam yine yükümlülük doğar mı?

Bazı lisanslarda doğabilir. GPLv3'te, kullanıcıya programın bir kopyasını aktarmadan yalnız ağ üzerinden etkileşim kurulması, lisansın “conveying” olarak adlandırdığı kopya aktarımı sayılmaz. Buna karşılık değiştirilmiş AGPLv3 programıyla ağ üzerinden etkileşen kullanıcılara ilgili kaynak kodu edinme imkânı sunma şartı vardır. Bu nedenle sırf “SaaS” adı, bütün lisanslar için aynı sonucu vermez. GPLv3 tanımları, AGPLv3 bölüm 13

Aynı paket dört farklı yerde kullanılabilir: geliştiricinin bilgisayarındaki bir araçta, şirketin sunucusunda, tarayıcıya gönderilen dosyalarda veya müşteriye kurulan yazılım paketinde. Kullanım şekli değişince değerlendirme de değişebilir.

Bir bağımlılık geliştirme sırasında kullanılıyor fakat son ürüne girmiyorsa bunu doğrulayın. “Geliştirme bağımlılığı” etiketi tek başına yeterli değildir; aracın oluşturduğu çıktı başka kod veya dosya içerebilir. Tarayıcıya gönderilen JavaScript, mobil uygulama paketi ve müşteriye teslim edilen konteyner görüntüsü ayrıca incelenmelidir.

Teknik ekip kısa bir akış çıkarabilir: Paket nereden geliyor, derlemeye nasıl giriyor, kullanıcıya hangi dosyalar gidiyor, şirket paketi değiştirdi mi, hangi servislerle birleşiyor? Hukuki değerlendirme bu somut bilgi üzerinden yapılır.

Mimariyi sadece yükümlülükten kaçınmak için kâğıt üzerinde ayrı göstermeyin. “Mikroservis” adı verilmesi veya farklı sunucuda çalışması, bütün lisans sorularını kendiliğinden çözmez. Gerçek iletişim, işlevsel ilişki ve ilgili lisansın koşulları incelenmelidir. Gerekirse ticari lisans, alternatif bileşen veya farklı ürün tasarımı seçenekleri karşılaştırılır.

Uygulamada hangi lisanslar var, bunu nasıl öğrenebilirim?

SBOM, yazılımı oluşturan bileşenlerin listesi için kullanılan kısaltmadır. Şirket açısından ilk faydası, üründe ne bulunduğunu bilmek ve sürümler arasında değişeni görebilmektir. SPDX, bu tür bilgilerin ortak biçimde ifade edilmesine yönelik standartlar sunar. Böyle bir liste karar vermeyi destekler; kendi başına hukuki uygunluk belgesi değildir. SPDX belirtimleri

Bileşenin adı ve sürümünün yanında lisansın tam adı, alındığı kaynak ve üründe nerede kullanıldığı görülmelidir. Paketi değiştirdiyseniz bunu da belirtin. Böylece sadece “uygulamada GPL var” demek yerine, hangi dosyanın müşteriye hangi biçimde gittiği konuşulabilir.

Otomatik tarayıcılar burada yardımcıdır. Ancak yanlış veya eksik lisans etiketi, elle kopyalanmış kod, gömülü görseller ve derleme sırasında eklenen dosyalar tarama dışında kalabilir. “Bilinmeyen lisans” sonucunu sessizce “uygun”a çevirmek yerine inceleme işi açın.

Listeyi her defasında sıfırdan yazmak gerekmez. Sürüm değişiklikleri karşılaştırılabilir. Yeni paket, lisans değişikliği, kullanımın sunucudan mobil uygulamaya taşınması veya müşteri sunucusuna teslim kararı yeniden kontrolü tetikleyen olaylar olsun.

Yapay zekâ yazdıysa kodun kaynağını araştırmam gerekir mi?

İlk katman girdidir. Araca müşteri kodu, kişisel veri, erişim anahtarı veya gizli iş bilgisi gönderildi mi? Şirketin bu bilgiyi paylaşmaya yetkisi var mı? Kullanılan hesap ve ürün sürümünün saklama, eğitimde kullanım ve erişim ayarları nedir? “Kurumsal araç kullanıyoruz” ifadesi bütün veri akışını açıklamaz.

İkinci katman araçla yapılan sözleşmedir. Çıktı kullanımına ilişkin koşullar, hesap türü, lisans sınırları ve varsa koruma taahhütlerinin istisnaları incelenir. Sağlayıcının kullanıcıya belirli kullanım yetkisi vermesi, üçüncü kişilerin haklarının bulunmadığına dair evrensel güvence değildir.

Üçüncü katman çıktının kendisidir. Kod bilinen bir projeyle eşleşiyor mu, lisans bildirimi veya açıklama içeriyor mu, hayalî paket adı öneriyor mu, güvenlik açısından incelendi mi? Geliştiricinin çıktıyı okuyup değiştirmesi önemlidir; birkaç değişkenin adını değiştirmek olası kaynak ilişkisini otomatik ortadan kaldırmaz.

Örneğin GitHub, Copilot'un bazı kod eşleşmelerinde kaynak ve lisans bilgisi gösterebildiğini, kapsam ve indeks sınırlamaları bulunduğunu açıklıyor. Bu özellik araştırmaya yardımcı olur; eşleşme uyarısı çıkmaması bütün hak risklerinin yokluğu olarak yorumlanmamalıdır. Kullanılan araçta hangi korumanın gerçekten etkin olduğu doğrulanmalıdır. GitHub Copilot kod referansları

Yapay zekâyla üretilen kodun telifi bana mı ait?

Bu soru için bütün ülkelerde ve bütün üretim biçimlerinde geçerli tek cevap yoktur. Türkiye bakımından FSEK'in eser, hususiyet ve eser sahipliği ölçütleri; somut insan katkısı ve üretim süreciyle birlikte değerlendirilir. Yalnız ücretli bir yapay zekâ hesabı kullanılmış olması veya istemi şirket çalışanının yazması, bütün çıktının tartışmasız biçimde şirketin özgün eseri olduğunu kanıtlamaz. FSEK, m.1/B, 2 ve 8

Yabancı kaynaklar aktarılırken ülke ayrımına dikkat edilmelidir. ABD Telif Hakları Ofisinin yapay zekâya ilişkin raporları ABD hukukuna ilişkindir; Türk mahkemeleri için doğrudan uygulanacak kural değildir. Bu raporlardan alınan bir cümleyi “Türkiye'de yapay zekâ kodunun telifi kesinlikle vardır/yoktur” şeklinde sunmak yanıltıcı olabilir. ABD Telif Hakları Ofisi yapay zekâ çalışmaları

Şirketin yapabileceği somut iş, üretim kaydı tutmaktır. Kullanılan araç ve tarih, görevin amacı, kaynak uyarıları, geliştiricinin anlamlı değişiklikleri ve son inceleme kaydı saklanabilir. Her istemi sınırsız süreyle saklamak gerekmez; gizlilik ve kişisel veri riskleri gözetilerek ölçülü kayıt seçilmelidir.

Müşteri yazılımı kendi sunucusuna kurmak isterse ne değişir?

Varsayımsal bir örnekte SaaS şirketi, raporlama özelliğini kendi sunucusunda çalıştırıyor. Büyük müşteri aynı yazılımın kendi veri merkezine kurulmasını istiyor. Satış ekibi bunu sadece farklı bir fiyat planı olarak görüyor.

Oysa teknik teslim değişmektedir. Müşteriye verilecek paket içinde hangi açık kaynak bileşenlerinin bulunduğu, hangi lisansların dağıtımla ilgili yükümlülük getirdiği ve şirketin müşteriye hangi kullanım haklarını vaat ettiği yeniden incelenmelidir. Önceki “sunucuda kullanım” değerlendirmesi yeni teslim modelini otomatik karşılamaz.

Çalışma sırası şöyledir: Teslim paketinin bileşen listesi çıkarılır; lisanslar ve değişiklikler belirlenir; gerekli bildirim ve kaynak sağlama düzeni hazırlanır; müşteri sözleşmesi bu yapı ile karşılaştırılır. Ticari gizlilik taahhüdüyle lisans yükümlülüğü arasında çatışma varsa imzadan önce çözüm seçilir.

Seçenekler arasında uyumlu teslim paketi, gerekli kapsamda kaynak sağlama, uygun ticari lisans veya bileşen değişimi bulunabilir. Hangisinin doğru olduğu ticari beklenti ve hukuki incelemeye bağlıdır. Müşteriye “bütün kaynak kod kapalı kalacak” sözü verildikten sonra incelemeye başlamak seçenekleri daraltabilir.

Yapay zekânın verdiği kod GPL lisanslı bir projeye benzerse ne yapmalıyım?

İkinci varsayımsal örnekte mobil uygulama geliştiricisi, dosya dönüştürme işlevini yapay zekâ aracından alıyor. Kod incelemesinde belirli bir açık kaynak projeyle benzerlik görülüyor. Projede karşılıklılık içeren bir lisans var; geliştirici ise çıktıyı araçtan aldığı için lisansın artık önemli olmadığını düşünüyor.

İlk adım kodu gelişigüzel silip bütün kayıtları yok etmek değildir. İlgili sürüm, çıktı ve görülen eşleşme kontrollü biçimde korunur. Benzerliğin niteliği, kaynak dosya, lisans ve ürünün dağıtım biçimi incelenir. Basit ve yaygın bir işlev ile özgün ve kapsamlı bir bölüm aynı değerlendirmeyi gerektirmeyebilir.

Ekip, açıkça izin verilen kullanım koşullarını yerine getirme, hak sahibinden farklı lisans alma veya bağımsız çözüm geliştirme seçeneklerini değerlendirir. Bağımsız geliştirme seçiliyorsa yalnız adları değiştirerek aynı yapıyı korumak yeterli kabul edilmez; geliştirme sürecinin nasıl yürütüleceği belirlenir.

Olay ayrıca araç kullanım politikasına geri döner. Kaynak uyarılarının kaydedilmesi, kritik kodda ikinci geliştirici incelemesi ve belirsiz parçaların yayından önce ayrılması için kontrol eklenir. Hedef geliştiriciyi araç kullandığı için cezalandırmak değil, şirketin ürüne neyi kabul ettiğini açıklayabilmesidir.

Lisans uygun değilse ürünü tamamen baştan mı yazmalıyım?

Her zaman değil. Sorunun bildirim eksikliği mi, kaynak sağlama yükümlülüğü mü, ticari kullanım kısıtı mı yoksa farklı lisansların birlikte kullanımı mı olduğunu belirlemek gerekir. Çözüm buna göre değişir. Örneğin yalnız gerekli telif bildirimleri eksikse, uygun bildirimlerin son dağıtım paketine ve ilgili kullanıcı arayüzüne eklenmesi gündeme gelebilir. Geçmiş ihlalin etkisi ve lisansın yeniden işlerlik koşulları ayrıca kontrol edilir; sonradan dosya eklemek her geçmiş talebi otomatik ortadan kaldırmaz.

Hak sahibi aynı bileşeni ticari lisansla da sunuyorsa, uygun lisans almak kodu değiştirmeden çözüm sağlayabilir. Fakat lisansı satan kişinin bu yetkiye sahip olduğu, kapsamın mevcut ürün ve müşterileri içerdiği ve geçmiş kullanımın nasıl ele alındığı açık olmalıdır. Yalnız yeni sürüm için alınan lisansın eski dağıtımları da düzelttiği varsayılmamalıdır.

Kaynak sağlama veya diğer koşullar şirketin ürün modeliyle bağdaşmıyorsa farklı bileşen kullanmak bir seçenek olabilir. Değişiklikten sonra sadece paket adının silindiği değil, eski kod ve dosyaların gerçekten teslimden çıkarıldığı da kontrol edilir. Lisansın gerektirdiği kapsamı anlamadan bütün şirket deposunu kamuya açmak ise gereksiz ve tehlikeli olabilir; ticari sırları ve kişisel verileri açığa çıkarabilir.

“Müşteriye bütün kod bize ait” sözü verdik. Şimdi ne olacak?

Önce sözün ne olduğunu kesinleştirin. Şirketin kendi geliştirdiği bölümlerde hak sahibi olduğunu söylemek ile üründe hiçbir üçüncü kişi bileşeni bulunmadığını garanti etmek farklıdır. Üründe açık kaynak bulunması, şirketin kendi katkıları üzerindeki haklarını kendiliğinden yok etmez. Ancak verilen beyan gerçeğe uymuyorsa sözleşmesel sorumluluk doğabilir.

Müşteriye sunulacak açıklamada bilinen bileşenler ve bunların ürünü kullanmasına etkisi anlaşılır biçimde belirtilmelidir. Gereken izin, bildirim veya değişiklik tamamlanmalı; yeni bir beyan verilecekse teknik gerçekle uyumlu olmalıdır. “Paket geliştirici tarafından eklendi, yönetim bilmiyordu” açıklaması şirketin sözleşmedeki taahhüdünü kendiliğinden kaldırmaz.

Yeni sözleşmelerde üçüncü kişi bileşenleri ile şirkete özel kodun ayrılması, açık kaynak yükümlülükleriyle çelişmeyen kullanım hakkı verilmesi ve ihlal iddiasında izlenecek çözümün belirlenmesi daha gerçekçidir. Bir saldırı veya güvenlik açığı taahhüdüyle telif hakkı taahhüdünü aynı genel garanti cümlesine doldurmak yerine, her riskin neyi kapsadığı açıklanmalıdır.

Sık sorulan sorular

Kodu biraz değiştirirsem eski lisans ortadan kalkar mı?

Hayır. Değişiklik yapmak, temel aldığınız kod üzerindeki hakları veya lisans koşullarını kendiliğinden silmez. Sizin eklediğiniz özgün bölüm ile başkasının kodu ayırt edilir; bütünün hangi koşullarla kullanılabileceği ilgili lisansa göre belirlenir.

Ücretli lisans alınca bütün telif ve güvenlik sorunları çözülür mü?

Ücretli lisans, verdiği yetkiler ölçüsünde çözüm sağlar. Hangi ürün ve sürümü kapsadığı, geçmiş kullanımı içerip içermediği, destek ve garanti koşulları ayrıca okunmalıdır. Bedel ödemek, kodun güvenlik açısından kusursuz olduğuna dair genel güvence değildir.

Lisans bildirimini uygulamanın neresine koymalıyım?

Tek bir yer bütün lisanslar için yeterli olmayabilir. Lisansın kopyalara, dağıtılan dosyalara, dokümantasyona veya kullanıcı arayüzüne ilişkin şartı kontrol edilir. Sadece şirketin internet sitesine bağlantı koymanın mobil uygulama paketindeki yükümlülüğü her durumda karşıladığı varsayılmamalıdır.

Yayına çıkmadan önce cevabı belli olması gerekenler

Ücretli satış yapabilecek misiniz, müşteriye hangi kod veya bildirimleri vermeniz gerekecek ve yapay zekâ aracına hangi bilgileri gönderebileceksiniz? Bu üç cevap ürünün gerçek kullanımından ve ilgili koşullardan çıkmalıdır. Testlerin geçmesi önemlidir; lisans ve veri sorularını tek başına cevaplamaz. Belirsiz bir bileşen için uygun lisans almak, değiştirmek veya kullanım biçimini sınırlandırmak gibi somut bir çözüm seçilmelidir.

Daha geniş telif çerçevesi için yapay zekâ içeriklerinde telif ve kullanım belirsizlikleri ve yazılım lisans sözleşmeleri incelenebilir.

Bu yazı genel bilgilendirmedir. Belirli bir paketin lisansına uygunluk, yapay zekâ çıktısının hak sahipliği veya bir uyuşmazlığın sonucu hakkında somut inceleme yerine geçmez. Kaynak ve platform koşulları değişebileceğinden kullanılan sürümün belgeleri ayrıca kontrol edilmelidir.