Yazılım, Kod ve Veritabanı Telif Hakkı Tescil Rehberi
1. Yazılım Kodları Hangi Kapsamda Korunur?
Yazılım geliştiren mühendisler, yazılımcılar ve girişimciler için kod deposunun izinsiz kopyalanması veya sızdırılması en büyük risklerden biridir. FSEK uyarınca:
- Kaynak Kod (Source Code): Yazdığınız tüm fonksiyonlar, algoritmik yapılar ve kod metinleri doğrudan korunur.
- Arayüz ve Grafik Öğeleri (UI/UX): Uygulamanızın özel tasarlanmış ikonları, teması ve görsel akışları "Güzel Sanat Eseri" veya "Tasarım" kapsamında korunur.
- Veritabanı Hakları (Database Rights): Özgün seçme, sıralama ve veri kurgulama içeren veritabanları telif hakkına sahiptir.
- API Tasarımı: API'nin spesifik ifade biçimi (endpoint yapıları, dökümantasyon metinleri) telif koruması altındadır. Ancak genel fonksiyonel fikirler korunmaz.
2. Yazılıma Telif Alma Adımları
Kaynak Kod Çıktısı ve Dokümantasyon
Yazılımınızın kaynak kodlarını, mimari şemasını ve README / teknik açıklama dokümanını düzenleyin.
e-Devlet Kayıt Tescil Başvurusu
Kültür Bakanlığı İsteğe Bağlı Kayıt Tescil portalında "Bilgisayar Programları" sekmesinden başvurunuzu yapın.
Zaman Damgası (Timestamp) İle Kod Deposu İmzalama
Git commit veya release paketlerinizi 5070 Sayılı Zaman Damgası hizmet sağlayıcıları üzerinden dijital olarak mühürleyin.
3. Açık Kaynak Lisansları ve FSEK Karşılığı (MIT, GPL, Apache)
Açık kaynaklı (Open Source) kod veya kütüphaneler kullanmak, kendi yazılımınızın "özgün" kısımlarının telif hakkını ortadan kaldırmaz. Ancak kullandığınız lisans türünün şartlarına uymanız hukuki bir zorunluluktur. Lisans şartlarının ihlali (örneğin GPL koda çöküp kapalı kaynak satmak), doğrudan FSEK Madde 68 ve 71 kapsamında telif hakkına tecavüz davasına konu olur.
En yaygın lisansların Türk hukuku ve FSEK açısından etkileri şunlardır:
- MIT Lisansı: En esnek ve ticari kullanıma en uygun lisanstır. Orijinal yazarların isimlerini ve telif bildirimini (copyright notice) kodun içinde tuttuğunuz sürece yazılımı alıp satabilir, kapalı kaynak yapabilirsiniz. FSEK açısından "Mali hakların şartsız devri / kullanım ruhsatı" gibidir.
- GPL (GNU General Public License): En tehlikeli ve bulaşıcı lisanstır (Copyleft). Eğer projenize GPL lisanslı tek bir satır kod bile dahil ederseniz, tüm projenizi (türev eser) açık kaynak (GPL) olarak yayınlamak zorunda kalırsınız. Aksi halde orijinal yazar size Türkiye mahkemelerinde tecavüzün ref'i ve tazminat davası açabilir.
- Apache 2.0: MIT'ye benzer şekilde ticari kullanıma izin verir ancak ek olarak Patent Hakları konusunda net bir koruma sağlar. Orijinal koda yaptığınız değişiklikleri (modified files) dosyaların içinde açıkça belirtmeniz FSEK Madde 15 (Adın Belirtilmesi Hakkı) açısından zorunludur.
4. SaaS ve Bulut Yazılımlarında Telif Koruması
SaaS (Software as a Service) modelinde kullanıcılara kaynak kod verilmese de, sunucu tarafı kodları tam telif koruması altındadır. Ancak dikkat edilmesi gerekenler:
- Kullanıcı sözleşmelerinde (ToS) fikri mülkiyet haklarınızı açıkça belirtin.
- API'lerinizin izinsiz tersine mühendislik ile kopyalanması FSEK ihlali oluşturur.
- Veritabanı içeriklerinin toplu olarak çekilmesi (scraping) durumunda da telif hakkı devreye girer.
5. Freelance ve İş İlişkisinde Kod Sahipliği (FSEK Madde 18)
Yazılım projelerinde en çok ihtilaf yaşanan konulardan biri, yazılan kodun kime ait olduğu sorusudur. FSEK'e göre eser sahibi eseri meydana getiren gerçek kişidir. Ancak iş ilişkisinin türüne göre mali hakların sahipliği farklılık gösterir:
- Tam Zamanlı Çalışan (İş Sözleşmesi): FSEK Madde 18/2 uyarınca, iş sözleşmesi kapsamında meydana getirilen eserlerde mali hakların kullanımı, sözleşmede aksi kararlaştırılmamışsa işverene aittir. Ancak manevi haklar (yazılımcının adının belirtilmesi) her zaman çalışanda kalır.
- Freelance / Serbest Çalışan: Freelance yazılımcı, açık bir devir sözleşmesi olmaksızın kod teslim ettiğinde, mali haklar yazılımcıda kalır. Müşteri yalnızca "kullanım hakkı" elde eder. Bu nedenle Eser Sipariş Sözleşmesi yapılması kritik öneme sahiptir.
- Ortak Geliştirme (Kolaborasyon): Birden fazla kişinin katkı sağladığı projelerde, her bir katkı sahibi yaptığı özgün katkının eser sahibidir. Ortaklık sözleşmesi ile hakların nasıl paylaşılacağı belirlenmelidir.
- Stajyerler ve Gönüllüler: Stajyerlerin ve gönüllü katkı sunanların yazdığı kodlarda da eser sahibi gerçek kişidir. Devir için yazılı sözleşme şarttır.
6. Algoritma ve Veritabanı Koruması: Patent mi Telif mi?
Yazılım dünyasında sıkça karıştırılan bir konu, algoritmaların hangi hukuki mekanizma ile korunacağıdır:
- Algoritmanın Soyut Mantığı: Bir algoritmanın arkasındaki matematik veya mantık, ne telif ne de patent ile korunabilir. Soyut fikirler FSEK kapsamı dışındadır.
- Algoritmanın Kod İfadesi: Algoritmanın somut kod olarak yazılmış hali (implementation) telif hakkı ile korunur. Yani aynı algoritmayı farklı biçimde yazarsanız telif ihlali olmaz, ancak kodu birebir kopyalarsanız ihlal oluşur.
- Teknik Buluş Niteliği: Algoritma yenilikçi bir teknik problem çözüyorsa (örneğin yeni bir sıkıştırma yöntemi), bu buluş için TÜRKPATENT'e patent başvurusu yapılabilir. Patent, 20 yıl süreyle korunur.
- Veritabanı Koruması: Veritabanındaki verilerin seçimi, düzenlenmesi veya sunumu özgünlük taşıyorsa, veritabanının kendisi de telif hakkı ile korunur. Ayrıca AB Veritabanı Direktifi benzeri düzenlemeler kapsamında sui generis veritabanı hakkı da bulunmaktadır.
En güçlü koruma stratejisi, telif + patent + ticari sır üçlüsünü birlikte kullanmaktır. Kaynak kodunuz telif ile, buluşunuz patent ile, ticari değeri olan bilgileriniz (API key'ler, özel algoritmik parametreler) ise ticari sır olarak korunur.
7. Yazılımda Tam Olarak Ne Korunur, Ne Korunmaz?
Bu ayrım, yazılım telifinin tamamının üzerine kurulduğu temeldir: telif hakkı fikri değil, fikrin ifade edilmiş hâlini korur. Yazılımda bunun anlamı şudur:
| Korunur | Korunmaz |
|---|---|
| Kaynak kodun kendisi (yazılış biçimi) | Algoritmanın matematiksel özü |
| Derlenmiş nesne kodu | Programlama dili ve söz dizimi |
| Kodun yapısı, modül düzeni ve organizasyonu (özgün olduğu ölçüde) | Programın ne yaptığı — yani işlevselliğin kendisi |
| Hazırlık tasarımları ve teknik dokümantasyon | Standart, zorunlu veya tek çözümü olan kodlama biçimleri |
| Arayüzün grafik tasarımı (ayrı bir eser olarak) | Genel iş fikri ve iş modeli |
| Veri tabanının özgün seçim ve düzenlemesi | Veri tabanındaki bireysel veriler |
Fikri ve işlevselliği korumak istiyorsanız telif yeterli değildir: gizlilik sözleşmesi ve teknik yenilik varsa patent yollarını değerlendirmeniz gerekir.
8. Açık Kaynak Lisans Uyumluluğu: Projenizi Riske Atan Sessiz Sorun
Modern bir projede yüzlerce bağımlılık bulunur ve her birinin kendi lisansı vardır. Sorun genellikle "lisans yok"tan değil, birbiriyle bağdaşmayan lisansların bir araya gelmesinden doğar.
| Lisans ailesi | Örnek | Ticari kapalı kaynak üründe kullanım | Ana yükümlülük |
|---|---|---|---|
| İzin verici | MIT, BSD, Apache 2.0 | Rahat | Telif bildirimini ve lisans metnini koruyun. Apache 2.0 ayrıca değişiklik bildirimi ister ve patent lisansı içerir. |
| Zayıf copyleft | LGPL, MPL 2.0 | Genellikle mümkün | Değiştirdiğiniz o bileşenin kaynağını paylaşmanız gerekir; kendi kodunuz kapalı kalabilir. Bağlama biçimi (statik/dinamik) önemlidir. |
| Güçlü copyleft | GPL v2 / v3 | Riskli | Dağıttığınız türev çalışmanın tamamını aynı lisansla ve kaynak koduyla yayımlamanız gerekebilir. |
| Ağ copyleft | AGPL v3 | SaaS için özellikle riskli | Yazılımı yalnızca ağ üzerinden hizmet olarak sunmanız bile kaynak kodu paylaşma yükümlülüğü doğurabilir. SaaS ürünlerinde en çok gözden kaçan tuzaktır. |
| Kaynağı açık ama özgür olmayan | BSL, SSPL, "source-available" | Şarta bağlı | Açık kaynak değildir. Rakip hizmet sunmayı yasaklayabilir. Mutlaka metni okuyun. |
Yapmanız gerekenler:
- Bağımlılık lisans envanteri çıkarın. Otomatik lisans tarama araçları bunu derleme sürecinize ekleyebilir.
- Yasak liste tanımlayın. Kapalı kaynak ürün geliştiriyorsanız, GPL ve AGPL bağımlılıklarını derleme aşamasında engelleyin.
- Üçüncü taraf bildirimlerini ürüne ekleyin. Çoğu izin verici lisans bunu zorunlu tutar; atlanması en sık görülen ihlaldir.
- Kod parçacığı kopyalarken de lisans vardır. Forum ve soru-cevap sitelerinden alınan kod parçaları o platformun lisansına tabidir; "internetten aldım" bir savunma değildir.
9. Yatırım ve Satın Almada Kod Sahipliği İncelemesi
Bir yatırım turunda veya şirket satışında en çok takılınan konu, kodun gerçekten şirkete ait olduğunun belgelenememesidir. Yatırımcı avukatları şunları ister:
- Kurucular arasında hak dağılımı sözleşmesi. Şirket kurulmadan önce yazılan kodun şirkete devredildiğini gösteren belge.
- Her çalışan için imzalı fikri mülkiyet protokolü. Şablonumuz bu amaçla hazırlanmıştır.
- Her serbest çalışan için imzalı devir sözleşmesi. Bu, en sık eksik çıkan belgedir — çünkü FSEK'in işveren lehine kuralı serbest çalışanlara uygulanmaz.
- Açık kaynak lisans envanteri ve uyumluluk raporu.
- Sürüm kontrol geçmişi. Kodun kim tarafından ne zaman yazıldığını gösteren commit geçmişi, güçlü bir ispat aracıdır.
- Üçüncü taraf servis sözleşmeleri ve ticari lisanslar.
Bunu şirket kurulurken yapmak, yatırım görüşmesi sırasında geriye dönük toplamaya çalışmaktan çok daha kolaydır. Ayrılmış bir geliştiriciden yıllar sonra imza almak çoğu zaman mümkün olmaz ve süreç bu yüzden tıkanır.
10. Yapay Zeka Kod Asistanları ve Lisans Riski
- Üretilen kodun sahipliği tartışmalıdır. Telif koruması hususiyet gerektirir; tamamen asistan tarafından üretilmiş kod bloklarının korunup korunmadığı netleşmemiştir. Bu, kodunuzu başkasının kopyalamasına karşı zayıflatabilir.
- Eğitim verisi kaynaklı risk. Asistanların telifli veya copyleft lisanslı kodlarla eğitilmiş olması, çıktının bu kodlara benzemesi ihtimalini doğurur. Uzun ve karakteristik blokları olduğu gibi kabul etmeden önce dikkatli olun.
- Kurumsal politika belirleyin. Hangi araçların kullanılabileceğini, hangi kod tabanlarında kullanılamayacağını ve üretilen kodun nasıl gözden geçirileceğini yazılı hâle getirin.
- Gizlilik boyutu. Müşterinizin özel kod tabanını bir asistana göndermek, gizlilik sözleşmenizi ihlal edebilir. Aracın verilerinizi eğitimde kullanıp kullanmadığını ve kurumsal planların bu konuda ne taahhüt ettiğini kontrol edin.
11. Kaynak Kod Emaneti (Escrow)
Kurumsal müşteriler, kaynak kodu teslim edilmeyen bir yazılıma bağımlı kalmaktan çekinir: geliştirici firma kapanırsa ne olacak? Kaynak kod emaneti bu sorunu çözer.
- Kaynak kod, güvenilir bir üçüncü tarafa emanet edilir.
- Sözleşmede belirlenen tetikleyici olaylar (firmanın iflası, bakım yükümlülüğünü yerine getirmemesi) gerçekleşirse kod müşteriye açılır.
- Geliştirici kaynak kodunu teslim etmez, müşteri de sürekliliğini garantiler. İki taraf için de dengeli bir çözümdür.
- Emanet sözleşmesinde hangi olayların tetikleyici sayılacağı ve kodun hangi kapsamda kullanılabileceği açıkça yazılmalıdır.
12. Geliştiriciler İçin Kontrol Listesi
- Kodunuzu bir sürüm kontrol sisteminde tutun. Commit geçmişi, hem geliştirme aracı hem güçlü bir tarih delilidir.
- Önemli sürümlerde zaman damgası alın. Deponun bir arşivinin özetine (hash) zaman damgası vurmak, tüm kodu ifşa etmeden tarih sabitler.
- Her müşteri işine yazılı sözleşmeyle başlayın. Yazılım geliştirme sözleşmesi şablonumuz hazırdır.
- Kendi hazır bileşenlerinizi sözleşmede ayırın. Yıllardır kullandığınız kütüphaneleri her müşteriye devretmeyin; lisanslayın.
- Açık kaynak bağımlılıklarınızı listeleyin ve müşteriye teslim edin.
- Kaynak kod teslimi sözleşmede net olsun. Teslim edilip edilmeyeceği sonradan tartışılmasın.
- Ödeme ile hak geçişini bağlayın.
- Ekip çalışıyorsanız her ekip üyesiyle fikri mülkiyet protokolü imzalayın.