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

Açık kaynak kodlu yazılımlar, modern yazılım geliştirme dünyasının en güçlü yapı taşlarından biridir. Start-up’lardan büyük sanayi şirketlerine, e-ticaret platformlarından finans ve sağlık teknolojilerine kadar çok geniş bir alanda açık kaynak bileşenler kullanılmaktadır. Ancak uygulamada en sık yapılan hata, “açık kaynak” kavramının “serbest, sahipsiz, koşulsuz ve sınırsız kullanım” ile karıştırılmasıdır. Oysa açık kaynak, telif hakkının ortadan kalktığı bir alan değil; tam tersine telif hakkı sahibinin belirli koşullarla verdiği lisanslı kullanım alanıdır. Bu nedenle açık kaynak kodun yanlış kullanımı, Türk hukukunda telif hakkı ihlali, sözleşmeye aykırılık, tazminat, ihtiyati tedbir, şirket içi sorumluluk ve bazı durumlarda ceza hukuku riskleri doğurabilir.

Open Source Initiative’nin Açık Kaynak Tanımı da bu gerçeği açık biçimde gösterir. Tanıma göre açık kaynak, yalnızca kaynak koda erişim anlamına gelmez; lisansın serbest yeniden dağıtıma izin vermesi, kaynak kodu içermesi, değişiklik ve türev eser oluşturulmasına imkân tanıması ve yazılımın ticari faaliyet dâhil belirli alanlarda kullanılmasını yasaklamaması gerekir. Yani açık kaynak yazılım, “bedava” olabilir; fakat “kuralsız” değildir. Lisansın verdiği yetki ne kadarsa, hukuken güvenli kullanım alanı da odur. Bu yetkinin aşılması veya lisans koşullarının ihlali hâlinde, açık kaynak kodun sağladığı izin zemini daralır ve kullanım telif hukuku bakımından tartışmalı hâle gelir.

Türk hukukunda bilgisayar programları Fikir ve Sanat Eserleri Kanunu kapsamında korunan eserler arasında yer alır. FSEK m.2, her biçim altında ifade edilen bilgisayar programlarını ve belirli koşullarda bunların hazırlık tasarımlarını ilim ve edebiyat eseri saymaktadır. Aynı maddede, programın herhangi bir ögesine temel oluşturan düşünce ve ilkelerin eser sayılmayacağı belirtilse de, ifade edilmiş kodun kendisi telif koruması altındadır. Ayrıca FSEK m.22’ye göre çoğaltma hakkı eser sahibine aittir ve bilgisayar programının yüklenmesi, görüntülenmesi, çalıştırılması, iletilmesi ve depolanması da çoğaltma hakkının kapsamına girer. Bu nedenle açık kaynak kodu yanlış kullanmak, çoğu zaman “sadece lisans şartını ihlal ettim” düzeyinde kalmaz; somut olaya göre telif hakkı sahibinin mali hak alanına müdahale sonucunu doğurabilir.

Buradaki temel kavram şudur: açık kaynak lisansı, telif hakkı sahibinin kullanım iznidir. Dolayısıyla lisans metni, yalnızca teknik topluluğa hitap eden bir etik belge değil; hukuki sonuç doğuran bir izin ve şartlar bütünü olarak görülmelidir. Türk Borçlar Kanunu bakımından borcun hiç veya gereği gibi ifa edilmemesi hâlinde borçlu, kusursuzluğunu ispat etmedikçe karşı tarafın zararını gidermekle yükümlüdür. Haksız fiil rejiminde de kusurlu ve hukuka aykırı bir fiille başkasına zarar veren kişi bu zararı tazmin etmek zorundadır. Bu iki temel eksen, açık kaynak lisans ihlallerinde hem sözleşmesel hem de haksız fiil sorumluluğu tartışmalarını mümkün kılar.

Açık kaynak yazılım neden “kamu malı” değildir?

Uygulamada en tehlikeli yanılgılardan biri, GitHub veya benzeri platformlarda yayınlanan kodun otomatik olarak herkese sınırsız açıldığı düşüncesidir. Oysa açık kaynak tanımı bile kullanımın lisans koşullarıyla çevrili olduğunu kabul eder; kaynak kodun varlığı kadar dağıtım şartları da önemlidir. FSEK bakımından da mali haklar kural olarak eser sahibine aittir; eserden yararlanma hakkı eser sahibinin izin verdiği ölçüde kullanılabilir. Bu nedenle “internette buldum, demek ki serbest” yaklaşımı hukuken güvenli değildir. Açık kaynak kodun sahibinin telif hakkı devam eder; sadece belirli lisans hükümleri çerçevesinde kullanım yetkisi tanınır.

Örneğin MIT lisansı, yazılımı kullanma, kopyalama, değiştirme, birleştirme, yayımlama, dağıtma, alt lisans verme ve satma konusunda geniş bir izin verir; ancak bunun temel şartı telif bildiriminin ve izin metninin kopyalarda veya yazılımın esaslı bölümlerinde korunmasıdır. Bu nedenle MIT lisanslı bir kütüphaneyi ürüne alıp lisans ve telif bildirimlerini tamamen kaldırmak, “nasıl olsa MIT çok serbest” diyerek hukuken önemsiz görülemez. Bu tür lisanslarda risk daha çok bildirim, atıf ve lisans metninin korunması ekseninde doğar.

Apache License 2.0 da geniş haklar tanır; ancak lisans metninin verilmesi, değiştirilen dosyaların belirgin şekilde işaretlenmesi ve kaynak formundaki telif, patent, marka ve atıf bildirimlerinin korunması gibi açık koşullar içerir. Ayrıca katkı sahipleri patent lisansı da tanır; fakat lisansa konu eser veya katkı için patent ihlali davası açan tarafın patent lisansı sona erebilir. Bu nedenle Apache 2.0 kapsamındaki yanlış kullanım yalnızca telif değil, patent ve bildirim yükümlülükleri bakımından da şirketleri riske sokabilir. Özellikle kurumsal ürünlerde NOTICE dosyalarının ve değişiklik bildirimlerinin unutulması, çoğu zaman küçümsenen ama hukuken ciddi sonuç doğurabilecek bir ihlaldir.

Copyleft lisansların yanlış kullanımı neden daha tehlikelidir?

Açık kaynak lisansları aynı yoğunlukta yükümlülük doğurmaz. En basit ayrım, “permissive” lisanslarla “copyleft” lisanslar arasındadır. MIT ve Apache gibi lisanslar daha esnek yapılarken, GPL, AGPL, LGPL ve MPL gibi lisanslar belirli paylaşım ve bildirim şartlarını daha sıkı kurar. Bu noktada şirketlerin en sık düştüğü hata, bütün açık kaynak lisanslarını aynı kefeye koymalarıdır. Oysa ürününüze eklediğiniz tek bir bileşen, dağıtım modelinize göre kaynak kod açıklama, aynı lisansla dağıtım, kullanıcıya kaynak erişimi sağlama veya yeniden bağlanabilirlik imkânı sunma yükümlülüğü doğurabilir.

GPLv3 özellikle dağıtım ve iletim hâllerinde sert sonuçlar doğurur. Resmî GPL metnine göre değiştirilmiş kaynak sürümleri devredilirken değişikliklerin belirtilmesi, eserin GPL altında lisanslanması ve belirli hukuki bildirimlerin korunması gerekir. Nesne kodu biçiminde dağıtımda ise buna karşılık gelen kaynak kodun da lisans şartlarına uygun biçimde sunulması gerekir. GPL ayrıca bir “aggregate” yani yalnızca aynı ortamda yan yana bulunma ile daha büyük program içinde lisansın bütün esere yayılması arasına ayrım koyar; bu ayrım pratikte oldukça teknik ve uyuşmazlığa açık olabilir. Bu nedenle GPL kodu kapalı kaynak ticari ürüne kontrolsüz gömmek, şirket açısından en riskli yanlışlardan biridir.

AGPL riski ise özellikle SaaS ve bulut hizmetlerinde büyür. AGPL’nin resmî metni, ağ üzerinden etkileşime açık değiştirilmiş sürümlerde ilgili kullanıcıların kaynak koda erişimini sağlamayı hedefler. Yani şirket “biz ürünü müşteriye kopya olarak dağıtmıyoruz, sadece sunucuda çalıştırıyoruz” diye düşünse bile, kullanılan bileşen AGPL ise ağ üzerinden sunulan değiştirilmiş sürüm için ek yükümlülükler gündeme gelebilir. SaaS şirketlerinin en pahalı hatalarından biri, GPL ile AGPL farkını önemsememeleridir. Özellikle müşteri portalı, bulut ERP, online tasarım aracı veya yapay zekâ tabanlı web servislerinde bu ayrım kritik önem taşır.

LGPL ise çoğu zaman “GPL kadar sert değil” denilerek yanlış anlaşılır. Oysa LGPL de belirli durumlarda birleşik eser ve bağlama modeline göre yükümlülük doğurur. Resmî LGPL metni, “Combined Work” kavramını tanımlar ve belirli şartlarla farklı lisanslı uygulamaların kütüphaneyle birlikte dağıtılmasına izin verir; ancak kullanıcıya belirli uyarılar yapılması, lisans belgelerinin verilmesi ve bazı durumlarda yeniden bağlama veya yeniden üretime imkân tanıyacak yapıların korunması gerekir. Statik bağlama, tersine mühendislik yasağı içeren son kullanıcı sözleşmeleri veya relink imkânını fiilen ortadan kaldıran tasarımlar, LGPL uyumunu karmaşıklaştırabilir.

MPL 2.0 ise dosya bazlı copyleft mantığıyla daha orta yolcu bir model sunar. Mozilla’nın kendi SSS sayfası MPL’yi “file-level copyleft” olarak tanımlamakta; lisans metni de Covered Software’in kaynak formunun MPL şartları altında dağıtılmasını, executable form dağıtımında kaynak formun makul şekilde erişilebilir olmasını ve lisans/telif bildirimlerinin korunmasını zorunlu kılmaktadır. MPL ayrıca Larger Work yapılmasına izin verir; fakat Covered Software yönünden lisans şartlarının ihlali hâlinde hakların otomatik sona ermesi ve sonradan belirli cure mekanizmalarıyla geri gelmesi mümkündür. Bu nedenle MPL kodunu kapalı kaynak ürün içine almak çoğu kez mümkündür; ancak dosya bazlı yükümlülükler ihmal edilirse ciddi uyumsuzluk doğar.

Açık kaynak kodun yanlış kullanımında en sık görülen hatalar

Birinci büyük hata, lisans metnini hiç okumadan kodu projeye dâhil etmektir. Özellikle geliştiriciler kısa vadeli teslim baskısı altında paket yöneticisi üzerinden kütüphane ekleyip, lisans sınıfını, telif bildirimlerini, NOTICE dosyalarını ve kaynak kod yükümlülüklerini incelemeyebilmektedir. Bu yaklaşım başlangıçta küçük görünür; fakat ürün ticari dağıtıma çıktığında, yatırım turuna girdiğinde ya da devralma incelemesinden geçtiğinde ciddi bir red flag’e dönüşür. Çünkü lisans uyumu yazılım mimarisinin son aşamada makyajla çözülebilecek bir ayrıntısı değil, ürün tasarımının parçasıdır. Bu tespit, GPL, LGPL, MPL ve Apache metinlerinde açıkça görülen dağıtım, bildirim ve kaynak erişimi yükümlülüklerinin doğrudan sonucudur.

İkinci büyük hata, “biz sadece şirket içinde kullanıyoruz” savunmasına aşırı güvenmektir. Bazı lisanslarda salt iç kullanım ile dağıtım arasında gerçekten önemli farklar vardır; örneğin GPL’de kamuyla paylaşılmayan özel kullanım ile dış dünyaya convey edilen sürümler aynı sonuçları doğurmaz. Ancak şirketler çoğu zaman neyin gerçekten “internal use”, neyin müşteri, bayi, iştirak, tedarikçi veya bulut kullanıcısına fiilî dağıtım sayılacağı konusunda yanılır. Özellikle grup şirketleri, franchise yapıları ve SaaS modellerinde bu sınır muğlaktır. AGPL bakımından uzaktan etkileşim zaten doğrudan önem taşır. Bu yüzden “dağıtım yok” savunması, lisans metni ve somut teknik mimari incelenmeden güvenilir kabul edilemez.

Üçüncü büyük hata, açık kaynak bileşenleri değiştirip bunu işaretlememektir. Apache 2.0 değiştirilmiş dosyaların belirgin biçimde işaretlenmesini ister. GPL değiştirilmiş sürümlerde değişiklik ve tarih bildirimleri öngörür. MPL ise kaynak formdaki lisans ve telif bildirimlerinin özünü kaldırmaya izin vermez ve kaynak erişimine ilişkin sorumluluk yükler. Şirketler, geliştirici ekibin yaptığı değişiklikleri ayrı tutmazsa sonradan hangi dosyanın üçüncü taraf koda, hangisinin şirket koduna ait olduğunu ayıramaz. Bu da hem lisans uyumu hem de ticari sırların sınırlandırılması bakımından büyük sorun yaratır.

Dördüncü büyük hata, lisans uyumunu sadece yazılımcılara bırakmaktır. Oysa Türk Ticaret Kanunu’na göre anonim şirketlerde yönetim kurulu üyeleri ve yönetimle görevli üçüncü kişiler görevlerini tedbirli bir yöneticinin özeniyle yerine getirmek ve şirket menfaatlerini dürüstlük kurallarına uyarak gözetmek zorundadır. Aynı Kanun, yükümlülük ihlali hâlinde kusursuzluğunu ispat edemeyen yönetim kurulu üyeleri ve yöneticilerin şirkete, pay sahiplerine ve alacaklılara karşı sorumlu olabileceğini düzenler. Limited şirket müdürleri için de benzer bir özen ve bağlılık yükümü öngörülmüştür. Açık kaynak uyumu bu nedenle yalnızca teknik ekip meselesi değil, kurumsal yönetim ve risk yönetimi meselesidir.

Türk hukukunda doğabilecek başlıca hukuki sonuçlar

Açık kaynak lisans ihlali çoğu zaman önce özel hukuk uyuşmazlığı olarak görünür. FSEK m.68’e göre hak sahibinden Kanuna uygun yazılı izin almadan eseri işleyen, çoğaltan, yayan, temsil eden veya umuma iletenlerden, hak sahibi sözleşme yapılmış olması hâlinde isteyebileceği bedelin veya rayiç bedelin en çok üç kat fazlasını isteyebilir. Bu hüküm, yazılım lisans uyuşmazlıklarında son derece önemlidir. Çünkü zararın tam hesaplanamadığı durumlarda bile hak sahibi, lisans bedeli veya rayiç bedel üzerinden güçlü bir talep zemini kurabilir. Açık kaynak lisans ihlalinde, özellikle dağıtım modeli lisans sınırını aşmışsa bu madde somut olayda ciddi mali sonuç doğurabilir.

FSEK m.70 de ayrıca önemlidir. Bu madde çerçevesinde mali hakları haleldar edilen kişi, kusur varsa haksız fiillere ilişkin hükümler uyarınca tazminat isteyebilir; ayrıca elde edilen kârın kendisine verilmesini talep edebilir. TBK m.49’daki genel haksız fiil sorumluluğu ve TBK m.112’deki sözleşmeye aykırılıktan doğan zarar giderimi hükümleriyle birlikte düşünüldüğünde, açık kaynak kodun yanlış kullanımında birden fazla hukuki talep aynı dosyada yan yana gelebilir. Özellikle müşteri sözleşmesinde “ürün üçüncü kişi haklarını ihlal etmez” gibi taahhütler varsa, sorun yalnızca hak sahibiyle değil, müşteriye karşı garanti ve tazmin yükümlülüğü bakımından da büyüyebilir.

Yardımcı kişiler ve çalışanlar üzerinden doğan sorumluluk da ayrıca gözden kaçırılmamalıdır. TBK m.116’ya göre borçlu, borcun ifasını veya borç ilişkisinden doğan hakkın kullanılmasını yardımcı kişilere bırakmış olsa bile, onların işi yürüttükleri sırada diğer tarafa verdikleri zararı gidermekle yükümlüdür. Bu nedenle dış kaynak geliştirici, freelancer, alt yüklenici veya çalışan ekip tarafından projeye uygunsuz açık kaynak kod eklenmesi, şirketi sorumluluktan otomatik olarak kurtarmaz. “Bunu stajyer eklemiş”, “eski yazılımcı böyle bırakmış”, “ajans yaptı” savunmaları, sözleşmesel sorumluluk bakımından her zaman koruyucu değildir.

Cezai risk var mı?

Bu sorunun cevabı, somut olaya göre değişir. FSEK m.71, hak sahibi kişilerin yazılı izni olmaksızın bir eseri işleyen, temsil eden, çoğaltan, değiştiren, dağıtan, umuma ileten, yayımlayan veya hukuka aykırı çoğaltılmış eserleri satışa arz eden, satan, kiralayan, yayan ya da kişisel kullanım dışında elinde bulunduran kişiler hakkında ceza yaptırımı öngörmektedir. Aynı Kanun m.75’e göre 71 ve 72. maddelerdeki suçlar şikâyete bağlıdır; savcılık süreci için hak sahiplerinin belge ve delillerle başvurması gerekir. Açık kaynak lisans ihlallerinde her dosya ceza davasına dönüşmez; fakat lisansın sağladığı izin sınırı aşılıp fiil açık biçimde izinsiz çoğaltma ve yayma boyutuna ulaşıyorsa, cezai risk teorik olmaktan çıkabilir. Özellikle lisans bildirimlerini bilinçli biçimde kaldırma, kapalı kaynak dağıtımda şartları tamamen yok sayma veya koruyucu programları etkisiz kılma gibi haller daha hassas değerlendirilir.

FSEK m.72 de bilgisayar programının hukuka aykırı çoğaltılmasını önlemek için oluşturulmuş ilave programları etkisiz kılmaya yönelik yazılım veya teknik donanımlar bakımından ayrıca ceza öngörmektedir. Açık kaynak bağlamında her ihtilaf m.72 kapsamına girmez; ancak lisans kısıtlarını atlatmak için koruma mekanizmalarını kıran araçların kullanılması, klasik lisans uyumsuzluğunun ötesine geçebilir. Bu yüzden açık kaynak kodla proprietary bileşenlerin birlikte kullanıldığı hibrit sistemlerde, lisans sınırının teknik araçlarla aşılması ayrıca incelenmelidir.

Delil, ispat ve dava süreci

Açık kaynak lisans uyuşmazlıkları teknik olarak karmaşık olduğu için ispat meselesi belirleyicidir. HMK m.199’a göre elektronik ortamdaki veriler ve benzeri bilgi taşıyıcıları belgedir. Bu nedenle repository kayıtları, commit geçmişi, CI/CD logları, build çıktıları, SBOM kayıtları, paket yöneticisi manifest dosyaları, lisans tarama raporları, e-posta zincirleri ve ürün dağıtım dosyaları delil niteliği taşıyabilir. Bununla birlikte HMK m.189/2 gereği hukuka aykırı elde edilen deliller mahkeme tarafından dikkate alınamaz. Dolayısıyla şirket içi inceleme yapılırken çalışan cihazlarına, özel hesaplara veya kişisel depolara hukuka aykırı müdahale edilmesi yeni bir usul sorunu yaratabilir.

FSEK m.76 ise hak sahibine önemli bir ispat kolaylığı sağlar. Mahkeme, davacının iddiasının doğruluğu hakkında kuvvetli kanaat oluşturmaya yeterli delil sunması hâlinde, kullanan taraftan Kanunda öngörülen izin ve yetkileri aldığını gösteren belgeleri veya yararlanılan eserlerin listelerini sunmasını isteyebilir; bunların sunulamaması haksız kullanıma karine teşkil eder. Yazılım dünyasında bunun anlamı şudur: lisans dosyalarını, NOTICE kayıtlarını, kaynak kod ayrıştırmasını ve bileşen envanterini tutmayan şirket, dava geldiğinde “aslında uyumluyduk” savunmasını teknik olarak kanıtlamakta çok zorlanır. Üstelik FSEK m.77 uyarınca kuvvetli ihtimal ve esaslı zarar şartlarında ihtiyati tedbir de gündeme gelebilir.

KVKK ve veri güvenliği boyutu

Açık kaynak yazılımın yanlış kullanımı bazen doğrudan telif değil, veri güvenliği üzerinden risk üretir. Özellikle harici paketler, telemetry modülleri, analitik kütüphaneler, bulut bağımlı bileşenler ve uzak sunucuya veri gönderen açık kaynak araçlar kullanılıyorsa, şirket aynı anda KVKK riskleriyle de karşı karşıya kalabilir. KVKK m.10 veri sorumlusuna aydınlatma yükümlülüğü yükler; m.12 ise veri sorumlusunun kişisel verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek, verilerin muhafazasını sağlamak için gerekli teknik ve idari tedbirleri alma ve gerekli denetimleri yapma yükümlülüğünü düzenler. Yurt dışına veri aktarımı boyutunda m.8 ve m.9 hükümleri ayrıca önem taşır. Açık kaynak bir bileşenin lisansını değil ama veri akışını yanlış okumak, şirketi telif dosyasının yanında KVKK dosyasıyla da karşı karşıya bırakabilir.

Şirketler bu riskleri nasıl önlemeli?

En doğru yaklaşım, açık kaynak kodu yasaklamak değil; kontrollü ve belgeli kullanmaktır. Her şirketin en azından bir açık kaynak kullanım politikası, bileşen envanteri, lisans sınıflandırması, onay mekanizması ve ürün dağıtım öncesi uyum kontrolü bulunmalıdır. GPL, AGPL, LGPL, MPL, Apache, MIT ve benzeri lisanslar için ayrı risk matrisi oluşturulmalı; özellikle kaynak kod açıklama, notice, patent, relink, network disclosure ve cure mekanizmaları bakımından teknik ekip ile hukuk ekibi birlikte çalışmalıdır. Bu yaklaşım yalnızca FSEK ve TBK risklerini azaltmaz; TTK’daki özen borcu ve yönetici sorumluluğu bakımından da güçlü bir savunma zemini sağlar.

Pratikte en yararlı araçlardan biri SBOM yani yazılım bileşen envanteridir. Ancak tek başına liste tutmak yetmez; her bileşenin lisans türü, hangi dosyalara dokunduğu, statik mi dinamik mi bağlandığı, ürüne dağıtılıp dağıtılmadığı, müşteriye hangi biçimde ulaştığı ve şirketin hangi değişiklikleri yaptığı da kayıt altına alınmalıdır. Aksi halde teknik envanter hukuki uyum envanteri hâline gelmez. Özellikle yatırım, birleşme-devralma veya büyük kurumsal satış süreçlerinde açık kaynak uyumu eksikliği, sadece hukuki tazminat riski değil; değerleme indirimi ve işlem gecikmesi sebebi de olabilir. Bu sonucun temeli, lisansların farklı koşullar içermesi ve şirket yönetiminin özen yükümlülüğüne tabi olmasıdır.

Sonuç

Açık kaynak kodlu yazılımlar, şirketler için maliyet avantajı, hız ve inovasyon sağlar; ancak “ücretsiz olduğu için hukuki risk taşımaz” düşüncesi yanlıştır. Açık kaynak yazılım, telif hakkının terk edildiği değil, lisansla yönetildiği bir alandır. Türk hukukunda bilgisayar programları eser olarak korunur; lisans şartlarına aykırı çoğaltma, dağıtım, çalıştırma ve ürünleştirme süreçleri FSEK, TBK, HMK, KVKK ve şirketler hukuku bakımından çok katmanlı sonuçlar doğurabilir. Özellikle GPL, AGPL, LGPL ve MPL gibi lisansların yanlış okunması; notice ve kaynak kod yükümlülüklerinin ihmal edilmesi; çalışan ve dış kaynak ekiplerin kontrolsüz entegrasyon yapması; şirket yönetiminin bu alanı yalnızca BT konusu sanması, yüksek maliyetli uyuşmazlıklara yol açabilir.

Doğru hukuki yaklaşım, açık kaynak kullanmaktan kaçınmak değil; lisans mimarisini ürün mimarisinin parçası hâline getirmektir. Şirket, hangi kodu hangi lisansla kullandığını, hangi dosyada neyi değiştirdiğini, müşteriye ne dağıttığını ve hangi yükümlülüğün hangi bileşenle doğduğunu biliyorsa risk yönetilebilir. Bilmiyorsa, açık kaynak avantajı kısa sürede telif, tazminat, dağıtım engeli ve kurumsal itibar sorununa dönüşebilir. Açık kaynak dünyasında asıl güvenlik, kodu indirmekte değil; lisansı doğru okumakta başlar.

Sık Sorulan Sorular

Açık kaynak kod kullanmak her zaman serbest midir?
Hayır. Açık kaynak kodun serbestliği, ilgili lisansın verdiği sınırlar içindedir. OSI tanımı açık kaynak lisanslarının yeniden dağıtım, kaynak kod, türev eser ve kullanım alanı gibi kriterlere dayanması gerektiğini söyler; bu da “koşulsuz serbestlik” anlamına gelmez.

Açık kaynak kod kullanımı telif hakkı ihlali doğurabilir mi?
Evet, doğurabilir. Çünkü bilgisayar programları Türk hukukunda eser sayılır ve FSEK m.22 programın yüklenmesi, çalıştırılması ve depolanmasını da mali hak alanına dâhil eder. Lisansın verdiği izin sınırı aşılırsa telif ihlali tartışması doğabilir.

GPL ile MIT arasındaki temel risk farkı nedir?
MIT lisansı daha geniş ve esnek bir kullanım izni verir; esas yükümlülük telif ve izin bildirimlerinin korunmasıdır. GPL ise değiştirilmiş sürümlerin aynı lisans altında iletilmesi ve nesne kodu dağıtımında karşılık gelen kaynak kodun sağlanması gibi daha ağır yükümlülükler içerir.

AGPL neden SaaS şirketleri için daha risklidir?
Çünkü AGPL, ağ üzerinden etkileşim kuran kullanıcılar bakımından değiştirilmiş sürümün kaynak koduna erişim sağlanmasını hedefleyen özel bir yapı kurar. Bu nedenle sadece sunucuda çalıştırma, her zaman yükümlülükten kaçış sağlamaz.

Şirket içinde uyum için en kritik adım nedir?
Bileşen envanteri ile lisans envanterini birleştirmektir. Yani sadece hangi kütüphanenin kullanıldığını değil, lisans türünü, yapılan değişiklikleri, dağıtım biçimini ve notice/source yükümlülüklerini de kayıt altına almak gerekir.