Açık Kaynak Kodlu Yazılımların Yanlış Kullanımında Doğan Hukuki Riskler

Açık kaynak yazılım kullanımı ücretsiz ve sınırsız değildir. GPL, AGPL, MPL, Apache gibi lisansların yanlış kullanımı; telif hakkı ihlali, tazminat, ceza, sözleşmesel sorumluluk ve şirket yöneticileri bakımından hukuki risk doğurabilir. Türk hukukunda açık kaynak lisans ihlallerinin sonuçlarını ayrıntılı biçimde inceleyin.

Açık kaynak yazılım, birçok şirketin düşündüğünün aksine “sahipsiz”, “kamunun malı” ya da “dilediğin gibi kullanabileceğin bedelsiz kod” anlamına gelmez. Open Source Initiative’e göre açık kaynak, sadece kaynak koda erişim demek değildir; yazılımın dağıtım şartlarının belirli kriterleri karşılaması gerekir. Aynı çerçevede OSI onaylı lisanslar, yazılımın kullanılmasına, değiştirilmesine ve paylaşılmasına izin verir; ancak bunu lisans koşulları içinde yapar. Yani açık kaynak dünyasında serbestlik vardır, ama başıboşluk yoktur. Tam da bu nedenle açık kaynak kodun yanlış kullanımı, Türk hukukunda telif, sözleşme, tazminat, veri güvenliği ve şirket sorumluluğu alanlarında ciddi sonuçlar doğurabilir.

Açık kaynak lisansları arasındaki farkları bilmeden hareket etmek, şirketler açısından en büyük hatalardan biridir. Çünkü GPL, AGPL, MPL ve Apache gibi lisanslar aynı sonucu doğurmaz. Örneğin GPL v3, yazılımın kaynak kod kopyalarını veya değiştirilmiş sürümlerini aktarırken telif bildirimlerinin korunmasını, lisans metninin verilmesini ve değiştirilmiş çalışmanın bütün olarak yine aynı lisans altında sunulmasını şart koşar. AGPL ise buna ek olarak, ağ üzerinden herkese açık şekilde çalışan değiştirilmiş sürümlerde ilgili kaynak kodun kullanıcılara sunulmasını hedefler. MPL 2.0 ise “file-level copyleft” mantığıyla, özellikle MPL’li dosyalardaki değişikliklerin paylaşılmasına odaklanır; Apache 2.0 ise daha gevşek bir model sunar ama lisans metninin ve tipik olarak NOTICE bilgisinin korunmasını ister. Dolayısıyla “açık kaynak kullandım” demek tek başına hukuken yeterli değildir; hangi lisansın kullanıldığı ve o lisansın hangi yükümlülükleri doğurduğu belirleyicidir.

Türk hukukunda bu meselenin temel dayanağı 5846 sayılı Fikir ve Sanat Eserleri Kanunu’dur. FSEK’te “bilgisayar programı”, bilgisayarın belirli bir işlem veya görevi yapmasını sağlayan emir dizgesi ve buna ilişkin hazırlık çalışmaları olarak tanımlanır. Aynı Kanun’da bilgisayar programları, “ilim ve edebiyat eserleri” arasında açıkça sayılmıştır. Ayrıca çoğaltma hakkı; bilgisayar programının yüklenmesi, görüntülenmesi, çalıştırılması, iletilmesi ve depolanması fiillerini de kapsar. Bu çerçevede bir açık kaynak kod parçasının yanlış lisansla ürün içine alınması, sadece “etiketleme hatası” sayılmaz; somut olayda doğrudan eser üzerindeki mali hak alanına müdahale olarak değerlendirilebilir.

Buradaki en kritik yanılgılardan biri, “kod GitHub’da duruyorsa serbesttir” düşüncesidir. Oysa Kültür ve Turizm Bakanlığı’nın açıklamalarına göre fikirler korunmaz; korunan şey, ortaya çıkmış eser niteliğindeki üründür. Bilgisayar programlarında eser sahibi kural olarak kaynak kodu yazan kişi ya da kişilerdir. Şirketler bakımından ise iş ilişkisi içinde üretilen eserler üzerinde mali hakların kim tarafından kullanılacağı ayrıca önem taşır. FSEK m.18 uyarınca, aksi sözleşmeden veya işin niteliğinden anlaşılmadıkça memur, hizmetli ve işçilerin işlerini görürken meydana getirdikleri eserler üzerindeki mali haklar bunları çalıştıranlarca kullanılır. Bakanlığın isteğe bağlı kayıt-tescil açıklamaları da, bilgisayar programlarında eser sahibinin kaynak kodunu yazan gerçek kişi olduğunu; şirketlerin ise belirli koşullarda hak sahibi veya mali hak kullanıcısı sıfatıyla hareket edebileceğini göstermektedir.

Bu nedenle açık kaynak lisans ihlali çoğu olayda iki katmanlı bir sorun yaratır. İlk katman, lisans koşullarının ihlal edilmesidir. İkinci katman ise, lisans şartlarının dışına çıkıldığı anda kullanımın artık izinsiz hâle gelip gelmediği tartışmasıdır. Örneğin MPL 2.0, lisans şartlarına uyulmazsa hakların otomatik olarak sona ereceğini; sonradan uyum sağlanırsa belirli koşullarda yeniden canlanabileceğini düzenler. GPL de, yazılımı dağıtırken alıcılara aynı özgürlüklerin aktarılmasını ve kaynak koda erişim imkânının korunmasını ister. Bu yüzden lisans uyumu bozulduğunda, dosya artık yalnızca “open source compliance” meselesi olmaktan çıkar; FSEK bakımından izinsiz kullanım iddiasını gündeme getirebilir. Bu, her olayda otomatik sonuç doğuran mekanik bir formül değildir; fakat lisans şartı ihlali ile FSEK koruması arasındaki bağ uygulamada çok güçlüdür.

Açık kaynak yazılımların yanlış kullanımında en sık karşılaşılan ihlallerin başında, lisans ve telif bildirimlerinin kaldırılması gelir. GPL v3, kopyalarda uygun telif bildirimlerinin ve lisansa ilişkin uyarıların korunmasını şart koşar. MPL 2.0 da kaynak koddaki bildirimlerin kaldırılmasına veya değiştirilmesine ilişkin sınırlamalar getirir. Apache 2.0 bakımından ise lisans kopyasının esere eklenmesi ve tipik olarak NOTICE bilgisinin korunması beklenir. Şirketlerin üçüncü taraf paketleri projeye dahil ederken bu metinleri “gereksiz kalabalık” gibi görüp silmesi, özellikle dağıtım yapılan ürünlerde doğrudan lisans ihlaline dönüşebilir. Bu tür ihlaller yazılımın teknik işleyişini bozmasa da hukuki pozisyonu ciddi biçimde bozar.

İkinci büyük risk, copyleft etkisinin yanlış okunmasıdır. MPL bakımından copyleft dosya bazlıdır; Mozilla’nın kendi açıklamasına göre MPL, MPL’li kod içeren dosyalara uygulanır ve yeni, ayrı dosyalar otomatik olarak MPL’ye çekilmez. Buna karşılık GPL için aynı açıklama, copyleft etkisinin “GPL’li koda dayanan tüm yazılıma” daha geniş şekilde yayıldığını vurgular. Uygulamada şirketler çoğu zaman bu farkı gözden kaçırır; bir GPL bileşenini kapalı kaynak ticari ürüne gömüp yalnızca ilgili klasörü yayımlamanın yeterli olacağını sanır. Oysa lisans kapsamı yanlış analiz edilirse, ürünün tamamına yayılan bir uyum sorunu doğabilir. Bu nedenle açık kaynak riskinin merkezinde teknik entegrasyon kadar lisans mimarisinin doğru okunması yer alır.

Üçüncü önemli risk, SaaS ve bulut hizmetlerinde AGPL’nin hafife alınmasıdır. Pek çok şirket, klasik dağıtım yapmadığı için kaynak kodu açma yükümlülüğü doğmadığını varsayar. Oysa GNU AGPL’nin amacı tam da burada devreye girer: herkese açık bir sunucuda çalışan değiştirilmiş sürümün kaynak kodunun, o servisle ağ üzerinden etkileşen kullanıcılara sunulmasını hedefler. Bu yüzden özellikle yapay zekâ servisleri, yönetim panelleri, CRM araçları, veri analizi panelleri ve müşteri portalları geliştiren şirketler bakımından AGPL uyumu kritik önemdedir. “Biz programı müşteriye dosya olarak vermiyoruz” savunması, AGPL kullanılan senaryolarda tek başına güvenli değildir.

Dördüncü risk, açık kaynak kodun şirket içinde “özel kullanım” ile dış dağıtım arasındaki fark gözetilmeden yönetilmesidir. Mozilla’nın MPL 2.0 rehberine göre, şirket veya organizasyon içindeki özel kullanım bakımından genellikle ayrı bir dağıtım yükümlülüğü doğmaz; asıl yükümlülükler organizasyon dışına dağıtım başladığında görünür hâle gelir. Ancak şirketler bu sınırı yanlış çizerse, örneğin grup şirketlerine, bayilere, dış yüklenicilere veya müşterilere teslim edilen yazılımları hâlâ “iç kullanım” sanırsa, aslında dış dağıtımın sonuçlarını gözetmeden hareket etmiş olur. Bu ayrım özellikle holding yapılarında, franchise sistemlerinde ve dış kaynak yazılım geliştirme süreçlerinde çok kritik hâle gelir.

Türk hukukundaki özel hukuk sonuçlarına bakıldığında, FSEK ihlal hâlinde oldukça güçlü araçlar sağlar. Kültür ve Turizm Bakanlığı’nın açıklamasına göre, FSEK m.68 uyarınca izni alınmamış eser sahibi, sözleşme yapılmış olsaydı isteyebileceği bedelin veya rayiç bedelin en çok üç kat fazlasını isteyebilir. Bunun yanında tecavüzün men’i ve maddi-manevi tazminat davaları da açılabilir. Aynı açıklamada, manevi ve mali haklara tecavüz hâlinde ihlal edenin elde ettiği kârın da ayrıca talep edilebileceği belirtilmektedir. Açık kaynak lisanslarında genellikle ilk izin bedelsiz görünse de, lisans şartı ihlali nedeniyle kullanım izinsiz hâle geldiği savunulduğunda FSEK taleplerinin devreye girmesi mümkündür. Somut olayda talebin kapsamı; lisans türüne, ihlalin ağırlığına, dağıtım biçimine ve zararın ispatına göre değişir.

Mesele yalnızca FSEK ile sınırlı da değildir. Türk Borçlar Kanunu bakımından lisans şartları, en azından taraflar arasında hukuki bağ kuran kullanım koşulları olarak çalışır. TBK’ya göre sözleşme, taraf iradelerinin uyuşmasıyla kurulur; borç hiç veya gereği gibi ifa edilmezse de borçlu, kusursuzluğunu ispat etmedikçe alacaklının zararını gidermekle yükümlüdür. Bu nedenle açık kaynak lisans ihlali, olayın niteliğine göre hem telif hakkı ihlali hem de sözleşmesel yükümlülüğe aykırılık tartışması yaratabilir. Özellikle kurumsal tedarik zincirinde; OEM teslimleri, yazılım geliştirme sözleşmeleri, bayi dağıtımı, SaaS sözleşmeleri veya yatırım öncesi due diligence süreçlerinde bu ikinci katman çoğu zaman gözden kaçırılır.

Şirket içi sorumluluk bakımından da tablo ciddidir. TBK m.66’ya göre adam çalıştıran, çalışanın işin yapılması sırasında başkalarına verdiği zararı gidermekle yükümlüdür; çalışanı seçerken, talimat verirken, gözetim ve denetimde bulunurken gerekli özeni gösterdiğini ispat ederse sorumluluktan kurtulabilir. Aynı maddede işletmenin çalışma düzeninin zararı önlemeye elverişli olup olmadığı da ayrıca önemsenmiştir. Yani bir yazılım geliştiricinin, DevOps çalışanının veya dış kaynak ekibin açık kaynak lisans ihlaline yol açan entegrasyonu “münferit çalışan hatası” diye basitçe dışarı itilemez. Şirketin lisans uyum süreci yoksa, bağımlılık taraması yapılmıyorsa, SBOM tutulmuyorsa, onay mekanizması yoksa ve hukuk-bilgi işlem koordinasyonu kurulmamışsa işverenin sorumluluğu doğabilir. Üstelik TBK m.116, borcun ifasının yardımcı kişilere bırakılmış olmasının, onların verdikleri zarar bakımından borçluyu otomatik olarak kurtarmadığını da açıkça düzenler.

Kurumsal yönetim açısından bakıldığında, açık kaynak lisans uyumu artık sadece teknik ekip işi değildir. TTK m.369, yönetim kurulu üyeleri ve yönetimle görevli üçüncü kişilerin görevlerini tedbirli bir yöneticinin özeniyle yerine getirmek ve şirket menfaatlerini dürüstlük kurallarına göre gözetmek zorunda olduğunu belirtir. TTK m.553 ise kurucuların, yönetim kurulu üyelerinin ve yöneticilerin kanundan ve esas sözleşmeden doğan yükümlülüklerini ihlal ettiklerinde hem şirkete hem pay sahiplerine hem de alacaklılara karşı verdikleri zarardan sorumlu olabileceğini düzenler. Bu nedenle özellikle teknoloji şirketlerinde, SaaS girişimlerinde, yatırım alan startuplarda ve yazılım ihraç eden firmalarda açık kaynak uyum politikası kurmamak, yalnızca ürün riski değil yönetici sorumluluğu riski de yaratır. Bu, somut olayda kusur, görev dağılımı ve özen standardına göre değerlendirilir.

Açık kaynak kodun yanlış kullanımı bazı olaylarda cezai boyuta da taşınabilir. Kültür ve Turizm Bakanlığı’nın telif ihlali rehberine göre; eserlerin hak sahibinin yazılı izni olmaksızın işlenmesi, çoğaltılması, dağıtılması, yayımlanması, ticarî amaçla satın alınması, ithal veya ihraç edilmesi, kişisel kullanım amacı dışında elde bulundurulması ya da depolanması ceza davasına konu olabilir. Aynı rehberde, bilgisayar programlarının hukuka aykırı olarak çoğaltılmasının önüne geçmek amacıyla oluşturulmuş ilave programları etkisiz kılmaya yönelik yazılım veya teknik donanım üretmek, satmak veya kişisel kullanım dışında elde bulundurmak da ayrıca sayılmıştır. Açık kaynak alanında bu risk özellikle lisans kontrolünü veya koruyucu modülü aşmak için yapılan müdahalelerde görünür olur. Her lisans ihlali otomatik olarak ceza mahkûmiyeti doğurmaz; ancak dosyanın ceza soruşturmasına dönüşmesi ihtimali küçümsenmemelidir.

Veri koruma boyutu da gözden kaçırılmamalıdır. Şirketler açık kaynak uyumu için kod depolarını, geliştirici aktivitelerini, erişim kayıtlarını, build loglarını ve zaman zaman çalışan cihazlarını izlerken KVKK sınırları içinde kalmak zorundadır. KVKK m.10’a göre veri sorumlusu, veri toplama sırasında ilgili kişilere kimlik, işleme amacı, aktarım amaçları, veri toplamanın yöntemi ve hukuki sebebi hakkında bilgi vermelidir. KVKK m.12 ise veri sorumlusunun kişisel verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek, verileri muhafaza etmek için gerekli teknik ve idari tedbirleri alma ve denetim yapma yükümlülüğünü düzenler. Bu nedenle şirketler bir yandan açık kaynak lisans uyumu kurarken, diğer yandan geliştirici izleme ve uyum denetimlerinde kişisel veri hukukunu ihlal etmemelidir. Ayrıca güvensiz veya yanlış entegre edilmiş açık kaynak bileşenleri veri ihlaline yol açarsa, ayrı bir KVKK dosyası da doğabilir.

Peki en sık yapılan somut hatalar nelerdir? Birincisi, internette bulunan kod parçasını lisansına bakmadan ticari ürüne gömmektir. İkincisi, geliştiricinin GPL veya AGPL kodu kapalı kaynak ana ürünün parçası hâline getirip yalnızca binary dağıtmasıdır. Üçüncüsü, Apache veya MPL lisanslı bileşenlerde lisans metni, notice ve kaynak erişim yükümlülüklerini kaldırmaktır. Dördüncüsü, şirket içinde “yalnızca test amaçlı” alınan bileşeni müşteriye giden sürümde bırakmaktır. Beşincisi ise dış kaynak yazılımcıların veya ajansların projeye kattığı bağımlılıkların hiç denetlenmemesidir. Bu hataların ortak noktası, teknik kolaylık uğruna lisans metninin görmezden gelinmesidir; hukuki sonuç ise çoğu zaman ürün tesliminden, yatırım turundan veya ihtarnameden sonra fark edilir.

Açık kaynak lisans ihlali tespit edildiğinde yapılması gereken ilk iş, paniğe kapılıp geçmişi silmek değil; ihlalin kapsamını kontrollü biçimde belirlemektir. Hangi bileşen kullanıldı, hangi sürüm kullanıldı, hangi lisans altındaydı, sadece içeride mi kaldı yoksa müşteriye dağıtıldı mı, dosya düzeyinde mi tüm ürün düzeyinde mi uyum sorunu oluştu, bunlar hızla tespit edilmelidir. Sonra lisans metinleri, notice dosyaları, kaynak kod erişim mekanizması, dağıtım akışı ve müşteri sözleşmeleri birlikte incelenmelidir. Sorun AGPL ise ağ üzerinden etkileşim olup olmadığı; GPL ise dağıtımın nasıl yapıldığı; MPL ise hangi dosyalarda değişiklik olduğu dikkatle değerlendirilmelidir. Bu aşamada teknik, hukuk ve ürün ekiplerinin birlikte çalışması zorunludur.

Önleyici yaklaşım bakımından en doğru yöntem, her şirkette yazılı bir open source compliance politikası bulunmasıdır. Bu politika; hangi depolardan kod alınabileceğini, lisans onay sürecini, bağımlılık taramasını, SBOM üretimini, dış kaynak ekiplerin sorumluluğunu, müşteriye dağıtım sırasında hangi belgelerin ekleneceğini ve ihlal halinde kimlerin karar vereceğini göstermelidir. Özellikle yatırım arayan girişimlerde, birleşme-devralma süreçlerinde ve yurt dışına yazılım satan şirketlerde açık kaynak envanteri artık lüks değil zorunluluktur. Çünkü yanlış kullanılan açık kaynak kod, yalnızca bir hukuk davası değil; ürün geri çağırma, dağıtımın durması, müşteri kaybı, yatırımcı soruları ve yönetici sorumluluğu anlamına da gelebilir. TTK’daki özen borcu ve TBK’daki organizasyon sorumluluğu bu kurumsal yaklaşımı hukuken de destekler.

Sonuç

Açık kaynak kodlu yazılımlar, modern yazılım geliştirme dünyasının vazgeçilmez parçasıdır; ancak “açık kaynak” ibaresi hukuki riskin ortadan kalktığı anlamına gelmez. Tam tersine, açık kaynak lisanslarının yanlış kullanımı çoğu zaman klasik lisanssız yazılım kullanımından daha karmaşık sonuçlar doğurur. Çünkü burada izin vardır; fakat o izin belirli şartlara bağlıdır. Şart ihlal edildiğinde ise telif hakkı ihlali, sözleşmeye aykırılık, tazminat, ceza, KVKK ve şirket yöneticilerinin sorumluluğu aynı dosyada birleşebilir. Türk hukukunda bilgisayar programları FSEK kapsamında korunur; hak sahibi ihlal hâlinde üç kata kadar bedel, men ve tazminat taleplerinde bulunabilir. Şirket içinde çalışanların ve dış ekiplerin fiilleri de TBK ve TTK bakımından ayrıca sonuç doğurabilir.

Bu yüzden doğru yaklaşım şudur: Açık kaynak kodu “ücretsiz kod” gibi değil, lisansla verilen bir fikrî hak kullanım izni gibi yönetmek gerekir. Lisansı okumadan kod almak, lisans uyumu kurmadan ürün dağıtmak ve geliştirici alışkanlıklarını hukuki denetimden uzak bırakmak, büyüyen her teknoloji şirketi için ciddi bir kırılganlık yaratır. Açık kaynak doğru kullanıldığında büyük avantaj sağlar; yanlış kullanıldığında ise ürünün en değerli kısmını hukuki uyuşmazlığın konusu hâline getirebilir.

Sık Sorulan Sorular

Açık kaynak yazılım ücretsizse neden hukuki risk doğurur?
Çünkü açık kaynak “koşulsuz serbest kullanım” demek değildir. OSI tanımı, açık kaynak lisanslarının belirli dağıtım ve kullanım şartlarına bağlı olduğunu açıkça ortaya koyar.

Açık kaynak kodu ticari üründe kullanmak yasak mıdır?
Hayır. Ancak hangi lisansın kullanıldığına göre telif bildirimi, kaynak koda erişim, aynı lisansla dağıtım veya notice yükümlülükleri doğabilir. GPL, AGPL, MPL ve Apache aynı sonucu doğurmaz.

Açık kaynak lisans ihlali doğrudan telif ihlaline dönüşür mü?
Her somut olay ayrıca değerlendirilir. Ancak lisans şartlarının dışına çıkılması, kullanımın artık izinsiz hâle geldiği iddiasını güçlendirebilir ve FSEK kapsamındaki talepleri gündeme getirebilir.

Şirkette geliştirici hata yaptıysa yalnızca çalışan mı sorumlu olur?
Hayır. TBK m.66 ve m.116 çerçevesinde işveren ve borçlu şirket bakımından da sorumluluk tartışılabilir. Şirketin seçim, talimat, gözetim, denetim ve organizasyon yapısı önem taşır.

Şirket yöneticileri açık kaynak lisans uyumsuzluğundan etkilenir mi?
Evet, etkilenebilir. TTK m.369’daki özen borcu ve m.553’teki kusurlu ihlal sorumluluğu, kurumsal uyum sisteminin hiç kurulmaması veya bariz risklerin görmezden gelinmesi halinde tartışma yaratabilir.