Açık Kaynak Katkısında DCO ve CLA: Telif Hakkı Devri mi, Yetki Beyanı mı?
DCO beyanı ile CLA sözleşmesi aynı hukuki işlemi anlatmaz; ikisi de başlığından hareketle bütün telif haklarının devri sayılmaz. DCO, katkıyı sunma yetkisine ve katkının kaynağına ilişkin beyan içerir. CLA’nın verdiği lisans veya devrettiği hak ise kendi metninden belirlenir. Bir kod değişikliğinin depoya kabul edilmesi, katkıyı yapan kişinin sahip olmadığı izni kendiliğinden yaratmaz. Türk hukuku uygulanıyorsa FSEK m.18, m.48, m.52 ve m.54 farklı sorulara cevap verir.
Açık kaynak projeye katkı yapan geliştirici, şirket ve proje yöneticisi için temel inceleme dört parçalıdır: Hangi kod gönderildi, bu kodun haklarını kim kullanabiliyor, hangi beyan veya sözleşme kabul edildi ve hangi kapsamda izin verildi? Git kaydı bunların bir bölümünü belgeleyebilir; tamamının yerine geçmez. Bu yazı çalışan yazılımının genel hak sahipliğini yeniden anlatmak yerine, katkı kabulünde DCO ve CLA’nın hangi boşlukları doldurduğunu ve hangilerini doldurmadığını açıklamaktadır.
DCO 1.1 hangi beyanları içerir?
Developer Certificate of Origin 1.1 üç alternatif kaynak durumunu düzenler: katkıyı kısmen veya tamamen üretip ilgili lisansla sunma hakkına sahip olmak; uygun açık kaynak lisansına dayanan önceki çalışmayı o izin kapsamında değiştirmek; yahut gerekli beyanı veren başka kişiden alınan katkıyı değiştirmeden iletmek. Ayrıca katkının ve gönderilen kişisel bilgiler dahil kaydın açık tutulması ve ilgili lisansla yeniden dağıtılması kabul edilir. Bu alternatiflerin hangisine dayanıldığı anlaşılmalıdır.
Bu beyan, yalnız “kodu ben yazdım” cümlesinden daha geniştir. Önceki çalışmaya dayanan katkıda, o çalışmayı kullanma ve değişikliği sunma yetkisi de önemlidir. Ancak DCO satırının bulunması, beyanın maddi olarak doğru olduğunu kanıtlayan bağımsız bir hak araştırması değildir. Uyuşmazlıkta kaynak dosya, lisans metni ve katkı yapanın yetkisi yine incelenir. Belgelenmesi gereken şey yalnız beyanın verilmesi değil, gerektiğinde beyanın dayanağıdır.
CLA her zaman telif hakkı devri midir?
Hayır. CLA adı altında farklı sözleşmeler bulunur. Apache ICLA V2.2 örneğinde m.2, katkılar üzerinde belirli mali kullanımlara yönelik münhasır olmayan, bedelsiz ve geniş kapsamlı lisans verir; metin katkı sahibinin diğer amaçlarla kullanma haklarını koruduğunu belirtir. Bu yapı “bütün telif mülkiyeti vakfa geçti” biçiminde özetlenemez. Başka bir kuruluşun CLA’sında farklı hükümler varsa onun metni ayrıca okunmalıdır.
FSEK m.48 bakımından mali hakkın devri ile yalnız kullanma yetkisi veren ruhsat farklıdır. FSEK m.56 da basit ve tam ruhsat ayrımını düzenler; aksi anlaşılmadıkça ruhsat basit sayılır. İncelemede çoğaltma, işleme, dağıtım ve diğer mali yetkilerin kapsamı; süre, bölge ve alt lisans izni belirlenir. Belgenin İngilizce adını Türkçe bir sözleşme tipine çevirmek, bütün hükümlerini değerlendirmiş olmak anlamına gelmez.
Signed-off-by satırı güvenli elektronik imza mı?
Git’in resmî commit belgesi, sign-off işlemiyle mesajın sonuna bir beyan satırı eklenmesini; kriptografik imza işlemini ayrı seçenekler olarak açıklar. Sign-off’un anlamı ilgili projenin kuralına bağlıdır. Dolayısıyla aynı satırın farklı projelerde mutlaka aynı DCO’ya atıf yaptığı varsayılamaz. Katkının gönderildiği tarihteki katkı politikası ve kabul edilen beyan metni kaydedilmelidir.
5070 sayılı Kanun m.4–5 güvenli elektronik imzanın unsurlarını ve elle atılan imzayla aynı hukuki sonucunu düzenler. Bir Git satırı veya platformdaki doğrulanmış imza işareti, yalnız adı nedeniyle bu kanundaki güvenli elektronik imza sayılmaz. İmzanın teknik doğrulaması, sertifika niteliği ve hukuki şekil ayrı konulardır. Bunun karşılığında güvenli elektronik imza olmaması, bütün elektronik kayıtların delil değerini otomatik olarak ortadan kaldırmaz.
HMK m.199 elektronik ortamdaki verileri belge kapsamında değerlendirir. Bu nedenle katkı mesajı, hesap kaydı, kabul ekranı ve e-posta yazışmaları uyuşmazlıkta önem taşır. Ancak bir kaydın delil olmasıyla kanunun aradığı geçerlilik şeklinin yerine gelmesi aynı değildir. Türk hukuku bakımından FSEK m.52’deki yazılı şekil ve hakların ayrı gösterilmesi gerektiğinde, bunların karşılanıp karşılanmadığı ayrıca değerlendirilir. Telif sözleşmelerinde FSEK m.52 açıklaması bu ayrımı ele alır.
Katkıyı yazan kişi her zaman izin verebilir mi?
Kodu fiilen yazmak, mali hakları her durumda tek başına kullanabilmek anlamına gelmez. Çalışma ilişkisi, önceden verilmiş haklar ve üçüncü taraf kodu ayrı kontrol edilir. FSEK m.18’in iş görülürken meydana getirilen eserler için düzenlediği kullanım yetkisi, katkı verecek kişinin iş sözleşmesiyle birlikte değerlendirilir. Bu nedenle kişisel hesap kullanılması veya katkının mesai dışında gönderilmesi, şirketin hakları bulunmadığını tek başına kanıtlamaz.
Çalışanla işveren arasındaki ana ayrıntılar çalışanın yazdığı yazılımın mali hakları rehberinde incelenmektedir. Katkı kabulündeki özel soru ise o hak sahibinin bu projeye, bu sürüme ve bu lisans koşullarıyla gönderime izin verip vermediğidir. Genel bir “açık kaynak çalışmalarına destek veriyoruz” açıklaması, her müşteri projesindeki her dosyanın yayımlanmasına izin anlamına gelmez. Yetki, katkının somut içeriğiyle eşleştirilmelidir.
Apache ICLA m.4 işverenin ilgili fikrî hakları bulunduğunda izin, haklardan vazgeçme veya kurumsal CLA gibi dayanakları öngörür. Apache’nin CLA açıklaması her işverenin mutlaka kurumsal CLA imzalaması gerektiğini söylemez; istihdam ve yetki durumunu esas alır. Kurumsal belge gerekiyorsa şirketi bağlama yetkisi bulunan kişi devreye girmelidir. Teknik ekip liderinin kodu inceleme yetkisi ile şirket adına fikrî hak sözleşmesi yapma yetkisi karıştırılmamalıdır.
Şirket CLA’sı bireysel beyanın yerine geçer mi?
Apache katkı sözleşmeleri politikası kapsamında kurumsal CLA, geliştiricinin bireysel ICLA gerekliliğini kaldırmaz. Bunun nedeni iki belgenin farklı tarafların hak ve beyanlarını ele almasıdır. Bu politika bütün projeler için evrensel bir kanun kuralı değildir; başka projede farklı kabul düzeni bulunabilir. İlk adım, projenin gerçekten hangi belgeyi istediğini belirlemek; ikinci adım, o belgeyi verecek kişinin yetkisini kontrol etmektir.
Şirket adına imzalanan belgenin çalışan listesini, proje kapsamını veya katkı türünü sınırlayıp sınırlamadığı da okunmalıdır. Bir personele tanınan gönderim yetkisinin bütün bağlı şirketlere yayılması kendiliğinden kabul edilemez. Şirket birleşmesi, görev değişikliği veya çalışanın ayrılması durumunda önceki belgenin kapsadığı katkılar ile sonraki gönderimler ayrılır. Önceki işlem tarihindeki yetkiyi gösteren kayıtlar, yeni yetkilendirmeyle birlikte korunmalıdır.
Başka projeden alınan kod için DCO yeterli mi?
Katkı başka kaynaktan alınmış dosya içeriyorsa, o kaynağın lisansı ve gönderilecek projenin dağıtım koşulları karşılaştırılır. İsim ve telif bildirimini silmek veya dosyaya yeni proje lisansı eklemek, önceki hak sahibinin iznini değiştirmez. FSEK m.54, yetkisiz kişiden hak edinimde iyi niyeti tek başına korumaz. Proje yöneticisinin katkı beyanına güvenmesi, eksik üçüncü kişi iznini hukuken tamamlayan bir işlem değildir.
İnceleme bütün kodun aynı kişiden geldiği varsayımıyla yürütülmemelidir. Değişikliğin özgün kısmı, taşınan dosya, otomatik üretilen bölüm ve dış bağımlılık ayrılır. Kaynak URL’si tek başına yeterli olmayabilir; ilgili sürüm, lisans dosyası ve alınan bölümün kapsamı saklanmalıdır. Katkı dosyasında hangi kısmın üçüncü kişiye ait olduğunun açık belirtilmesi, projenin hangi hakları aldığı ve hangi koşulları koruması gerektiğini görmesini sağlar.
Gelecekteki bütün kodlar bugünden devredilmiş olur mu?
Türk hukuku uygulanıyorsa FSEK m.48, henüz meydana getirilmemiş veya tamamlanacak eser üzerindeki tasarruf işlemi bakımından sınır koyar. FSEK m.50 ise böyle tasarruflara ilişkin taahhütlerin eser oluşmadan önce yapılabilmesini ayrı düzenler. Bu nedenle gelecekteki katkıları kapsayan bir çerçeve sözleşmenin her satırı, henüz yazılmamış bütün eserlerin tamamlanmış devri gibi açıklanamaz. Taahhüt ile fiilen meydana gelmiş katkıya ilişkin izin işlemi ayrılmalıdır.
Bu ayrım, geleceğe ilişkin her sözleşmenin geçersiz olduğu anlamına da gelmez. Hangi katkının ne zaman ortaya çıktığı, çerçeve sözleşmedeki mekanizma ve o katkının sunulması sırasında verilen irade açıklaması incelenir. Ayrıca m.50’de bütün gelecekteki eserler veya belirli türleri için taahhütlerde özel fesih düzeni bulunur. Tek bir katkının geçmişteki kullanım izniyle ileriye dönük katkı verme yükümlülüğü aynı sonuçlara bağlanmamalıdır.
Yabancı projede yalnız Türk şekil kuralları mı uygulanır?
Yabancı unsurlu katkı ilişkisinde MÖHUK m.28 fikrî mülkiyet sözleşmesine uygulanacak hukuku düzenler. Hukuk seçimi, seçimin bulunmaması hâlindeki bağlantı ve daha sıkı ilişki kuralı incelenir. MÖHUK m.7 hukuki işlemin şekline ilişkin ayrıca kural koyar; m.23 ise koruma talep edilen ülkenin fikrî mülkiyet hukukunu esas alır. Bir projenin yabancı ülkede bulunması bu soruların tamamını tek ülke hukukuyla otomatik cevaplamaz.
Bu nedenle Türkiye’de yaşayan geliştiricinin her çevrim içi katkısını aynı gerekçeyle geçersiz saymak da, yabancı platform kabul etti diye bütün Türk hukuku sorunlarının çözüldüğünü söylemek de doğru değildir. Sözleşme borcu, hakkın korunması, işçi–işveren ilişkisi ve işlem şekli ayrı bağlantılarla incelenir. Yurt dışı yazılım ve telif lisanslarında uygulanacak hukuk rehberi ayrıntılı çerçeveyi sunar. Uyuşmazlık dosyasına kabul edilen sözleşmenin o tarihteki sürümü eklenmelidir.
Açık katkı, gizli müşteri kodunu açıklama izni verir mi?
Katkı hakkı ile gizli bilgiyi açıklama yetkisi farklıdır. Bir dosyanın telif hakları üzerinde yetki bulunması, içindeki müşteri verisini, erişim anahtarını veya sözleşmeyle korunmuş ticari bilgiyi serbestçe yayımlama izni vermez. Gönderim öncesinde kodun yanında yapılandırma, test verisi ve açıklama metinleri de incelenmelidir. DCO veya CLA, katkıya eşlik eden bütün başka hukuki yükümlülükleri kaldıran genel bir sorumsuzluk belgesi değildir.
Gizli bölüm açık depoya girdiyse yalnız katkı satırını silmekle olayın bütün sonuçlarının giderildiği varsayılamaz. Erişim anahtarlarının değiştirilmesi, gerekli bildirimlerin yapılması ve eldeki kopyaların durumu ayrıca ele alınır. Yazılım kaynak kodunun ticari sır olarak korunması konusu bu yüzden katkı izinlerinden ayrı tutulmalıdır. Kamusal katkı kaydında hangi kişisel bilginin yer alacağı da gönderimden önce görülmeli; gerekli olmayan bilgi sırf forma eklenebildiği için yayımlanmamalıdır.
Uyuşmazlıkta hangi katkı dosyası hazırlanmalı?
- İncelenen değişikliğin kimliği, ilgili dosyalar ve katkıdan önceki ile sonraki içerik.
- Katkı tarihindeki proje lisansı, DCO veya CLA sürümü ve kabul politikası.
- Katkı sahibinin kabul kaydı, kurumsal izin ve gerekiyorsa temsil yetkisi belgeleri.
- Üçüncü taraf kaynakların sürümleri, lisans metinleri ve korunması gereken bildirimler.
- Katkının hangi ürün sürümlerine veya dağıtımlarına girdiğini gösteren sürüm kayıtları.
Kod incelemesinin onaylanmasıyla hukuki izin denetiminin yapılması farklı kayıtlarda yer alabilir. Teknik incelemeyi yapan kişi değişikliğin çalıştığını doğrulamış, fakat kaynak lisansını hiç incelememiş olabilir. Bu nedenle kabul işaretine tek başına hukuki uygunluk garantisi yüklenmemelidir. Hangi kontrolün kim tarafından yapıldığı ve hangi belgelerin görüldüğü anlaşılırsa uyuşmazlıkta sorumluluk ve çözüm yolu daha somut belirlenir.
Kayıtlar sonradan düzenlenirken ilk beyanın izi kaybolmamalıdır. Hem gönderilen içeriğin hem kabul metninin tarihleri muhafaza edilmelidir. Yanlış adın düzeltilmesi, eksik yetki belgesinin eklenmesi ve geçmişte izin bulunmadığının anlaşılması farklı olaylardır. Yeni bir onayın geçmiş kullanımları kapsayıp kapsamadığı kendi metninden belirlenir. Sonradan dosya yüklenmesi, önceki tarihte de aynı iznin verilmiş olduğunu kendiliğinden ispatlamaz. Tarihler ve hangi kullanımların kapsandığı açık tutulmalıdır.
Yetki eksikliği ortaya çıkarsa nasıl giderilir?
Önce tartışmalı katkı belirlenir; bütün projeyi aynı isnat altında bırakmak yerine ilgili dosya ve kullanım haritası çıkarılır. Hak sahibi, katkıyı yapan kişi ve projeyi dağıtan tarafın konumu ayrılır. Çözüm geçerli izin alınması, ilgili bölümün kaldırılması veya bağımsız yeni içerikle değiştirilmesi olabilir. Her yolun gerçekten hangi kullanımı hukuka uygun hâle getirdiği incelenir; yalnız beyan satırının değiştirilmesi eksik hakkı yaratmaz.
Geçmiş dağıtımlar ayrıca ele alınır. Gelecek sürümden bir dosyanın çıkarılması geçmişte gönderilmiş kopyaları yok etmez ve doğmuş talepleri otomatik olarak sona erdirmez. Buna karşılık bütün taleplerin varlığı ve kapsamı da yalnız dosyanın bir kez depoya girmesinden çıkarılamaz. Hangi mali hakkın kullanıldığı, iznin bulunmadığı dönem ve dağıtımın gerçek kapsamı delille belirlenmelidir. İzin ile geçmiş taleplerin çözüme bağlanması farklı sözleşme hükümleri gerektirir.
Yanlış katkı beyanı kime karşı hangi sorumluluğu doğurur?
Bağlayıcı bir sözleşmesel beyanın ihlalinde Türk hukuku uygulanıyorsa TBK m.112 çerçevesinde borç, aykırılık, zarar ve nedensellik değerlendirilir. Her DCO kaydı sınırsız tazminat garantisi içeriyormuş gibi yorumlanamaz. CLA’da ayrıca garanti, sorumluluk sınırı veya bildirim borcu varsa kendi koşulları incelenir. Zarar hesabında teknik temizlik gideri, kullanımın durdurulması ve üçüncü kişi talepleri ayrı belgelenmelidir.
Telif hakkı sahibiyle proje arasındaki ilişki ise yalnız katkı verenin sözleşmesine indirgenmez. FSEK m.54 ve ilgili ihlal hükümleri uyarınca yetki zinciri değerlendirilir. Projenin katkı sahibine dönme imkânı bulunması, hak sahibinin iznini gereksiz kılmaz. Düzeltme sırasında sorunu öğrenen tarafların sonraki davranışları da önem taşır; araştırılmamış katkının yeni sürümlere aynı şekilde taşınması ile kullanımın sınırlandırılması aynı olgu değildir.
Süreler ve katkı politikasındaki temel kararlar
DCO 1.1 bütün ihtilaflar için tek bir düzeltme veya dava süresi belirlemez. Sözleşme süresi, uygulanacak hukuk ve ileri sürülen talep ayrı saptanır. Türk hukukunda sözleşmesel alacaklarda TBK m.146 ve özel süreler; gelecekteki eserlere ilişkin taahhütlerde FSEK m.50’nin özel düzeni gündeme gelebilir. Destek kaydının açılması bütün yasal süreleri kendiliğinden durdurmaz. Öğrenme, bildirim, dağıtım ve düzeltme tarihleri ayrı kaydedilmelidir.
Katkı politikası hazırlanırken beyanı verecek kişi, hukuki metnin sürümü, şirket izninin gerekli olduğu hâller ve üçüncü taraf kodunun açıklanma yöntemi belirlenmelidir. Küçük değişiklikler için seçilen kabul yöntemiyle daha büyük katkılara uygulanan yöntem açık olmalıdır. Ancak işlem kolaylığı uğruna hakların kimde bulunduğu sorusu atlanmamalıdır. Kullanılacak politika, projenin gerçek dağıtım ve lisanslama modeline uygun tasarlanmalıdır.
Sık sorulan sorular
DCO bütün telif haklarını projeye devreder mi?
DCO 1.1 katkının kaynağı ve sunma yetkisi hakkında beyan içerir. Bütün mali hakların devri sonucu yalnız bu başlıktan çıkarılamaz. Proje lisansı, diğer sözleşmeler ve uygulanacak hukuk ayrıca incelenir.
Her CLA telif hakkı devri sözleşmesi midir?
Hayır. CLA metni farklı izinler düzenleyebilir. Apache ICLA örneği münhasır olmayan lisans verir ve katkı sahibinin diğer kullanımlarını korur. Başka bir CLA’nın kapsamı kendi hükümlerinden belirlenir.
Signed-off-by satırı güvenli elektronik imza sayılır mı?
Satır eklenmesi tek başına 5070 m.4’teki güvenli elektronik imza koşullarını sağlamaz. Git’te sign-off ile kriptografik imza ayrı işlemlerdir. Elektronik kaydın delil değeri ve geçerlilik şekli de ayrı incelenir.
Şirket bilgisayarından katkı yapılınca şirket izin vermiş olur mu?
Cihazın şirketin olması veya hesabın açık olması tek başına yetki belgesi değildir. İş ilişkisi, hak kullanım düzeni, görevlendirme ve katkının kapsamı incelenir. Şirket adına izin veren kişinin yetkisi belirlenmelidir.
Apache’ye katkıda her işveren kurumsal CLA imzalamalı mı?
Apache açıklaması bunu her işveren için zorunlu saymaz. İşverenin hakları ve bireysel beyanın dayanağı incelenir. Kurumsal CLA, ilgili durumdaki yetki belirsizliğini giderebilir; bireysel ICLA’nın yerine geçmez.
Başka projeden alınan dosyaya DCO eklemek yeterli mi?
Hayır. Önceki lisansın izin verdiği kullanımlar ve korunacak şartlar ayrıca incelenir. Kaynağın ve izin zincirinin açıklanması gerekir. Yetkisiz bir beyan, asıl hak sahibinin eksik iznini yaratmaz.
Katkıyı birleştiren yönetici bütün hakları doğrulamış sayılır mı?
Teknik kabul işareti tek başına kapsamlı hukuki denetim garantisi değildir. Hangi kontrolün yapıldığı, kim tarafından onaylandığı ve görülen belgeler belirlenir. Kabul süreciyle kullanım izninin varlığı ayrı konulardır.
Gelecekte yazılacak bütün kodlar bugünden devredilebilir mi?
Türk hukuku uygulanıyorsa FSEK m.48’deki tasarruf sınırı ile m.50’deki taahhüt düzeni ayrılır. Çerçeve sözleşme, henüz oluşmamış her eser üzerinde tamamlanmış devir gibi yorumlanamaz.
Yanlış katkı depodan silinince geçmiş talepler biter mi?
Silme gelecekteki kullanımı etkileyebilir; geçmiş dağıtımları ve doğmuş talepleri otomatik olarak sona erdirmez. Geçerli izin, kullanım kapsamı ve geçmiş taleplerin ayrıca çözüme bağlanması değerlendirilir.
Katkı dosyasında hangi belge mutlaka eşleştirilmeli?
İlgili kod değişikliği, o tarihteki lisans ve katkı politikası, kabul edilen DCO veya CLA ile yetki belgesi birlikte eşleştirilmelidir. Sonradan değişen internet sayfası geçmiş koşulları tek başına kanıtlamaz.
İstanbul ve Mersin ofisleri
İstanbul · Polaris Plaza
Maslak Ahi Evran Caddesi, Polaris Plaza No:21, Kat:9, 34475 Sarıyer/İstanbulMersin · Profit İş Merkezi
İhsaniye Mahallesi, 4903. Sokak, Profit İş Merkezi No:23, Kat:3, Daire:14, 33070 Akdeniz/MersinHukuki konu hakkında iletişim
İlk iletişimde konuyu, bulunduğunuz ülke veya ili ve varsa tebliğ ya da son işlem tarihini kısaca belirtebilirsiniz. T.C. kimlik numarası, sağlık verisi veya kişisel belge göndermeyiniz. Mesajlaşma tek başına hukuki görüş veya avukatlık ilişkisi oluşturmaz.
