GitHub’da Marka ve Telif İhlali Nasıl Şikayet Edilir?

GitHub’da markanızı resmi hesapmış gibi gösteren ad, logo veya profil kullanımları için trademark policy süreci; kopyalanan kod, metin, görsel ve dokümanlar için ise DMCA süreci kullanılmalıdır. Aynı repoda iki sorun birlikte varsa delilleri ayırarak doğru kanala başvurmak gerekir.

GitHub’da bir hesap, organizasyon veya depo markanızı resmi kaynakmış gibi gösteriyorsa GitHub marka ihlali şikayeti yoluna gitmeniz gerekir. Kodunuz, dokümantasyonunuz, görselleriniz veya telifle korunan başka bir içeriğiniz izinsiz kopyalanmışsa doğru kanal GitHub’ın DMCA bildirimi rehberi ve DMCA kaldırma politikası tarafıdır; marka karışıklıkları içinse ayrı bir GitHub Trademark Policy süreci vardır.

Kısa sonuç şu: GitHub belgelerinde marka ve telif için ayrı süreçler bulunur. Aynı içerikte iki sorun birlikte yer alabilir; bu durumda hangi bölüm için hangi kanalı kullanacağınızı ayırarak ilerlemek gerekir.

Bu rehber, teknik ve operasyonel açıdan nasıl ilerleyeceğinizi sadeleştirir. Somut uyuşmazlıklarda ayrıca profesyonel hukuki değerlendirme gerekebileceğini de baştan akılda tutmak gerekir.

Kısa cevap: marka ve telif için ayrı kanallar var

GitHub’ın kendi belgeleri, DMCA sürecinin yalnızca telifle korunan eserler için kullanılabildiğini açıkça söyler. Yani marka adınızın, logonuzun veya kurumsal kimliğinizin kullanıcıları yanıltacak biçimde kullanılması telif başlığı altında değil, trademark policy çerçevesinde değerlendirilir.

Pratikte ayrım şöyle yapılır:

• Bir kullanıcı ya da organizasyon, şirket adınızı ve logonuzu kullanıp resmi hesabınızmış izlenimi veriyorsa bu marka tarafıdır.

• Bir repo içindeki kaynak kod, README, dökümantasyon, ekran görüntüsü, tasarım dosyası veya metin sizin eserinizden izinsiz kopyalanmışsa bu telif tarafıdır.

• Aynı repo hem markanızı taklit ediyor hem de kodunuzu kopyalıyorsa iki sorunu tek cümlede karıştırmak yerine delilleri iki ayrı başlık altında sunmak daha sağlıklıdır.

Bu ayrım önemlidir. Çünkü GitHub, kendi rolünü haklılık tartışmasını bütünüyle çözmekten çok, ilgili politika için asgari gereklilikleri kontrol etmek olarak konumlandırır.

Önce ihlalin türünü ayırın: marka ihlali mi, telif ihlali mi?

İlk bakışta her kötü kullanım marka ihlali gibi görünebilir. Oysa bazı vakalarda asıl sorun, kullanıcı adından çok repo içeriğidir; bazılarında ise koddan çok marka karışıklığı vardır.

Kendinize önce şu soruları sorun:

• Esas zarar, insanların karşı tarafı sizin resmi hesabınız sanması mı?

• Yoksa esas zarar, size ait korunan kodun ya da metnin izinsiz çoğaltılması mı?

• Sorun tek bir hesapta mı, birden fazla fork ve kopyada mı yayılıyor?

• Elinizde tescil belgesi, orijinal kaynak bağlantısı, commit geçmişi, lisans kaydı veya yayımlanma tarihi gibi dayanaklar var mı?

Marka ile telif arasındaki en pratik ayrım şudur: marka, kaynağın kim olduğu konusunda karışıklık yaratır; telif ise eserin kendisinin izinsiz kullanımıyla ilgilenir. Örneğin bir depo adı, profil görseli ve açıklama metni kullanıcıyı yanıltıyorsa trademark meselesi öne çıkar. Aynı depoda ayrıca özel kodunuz satır satır kopyalanmışsa bu kez telif iddiası da doğar. GitHub marka ihlali şikayeti ile GitHub DMCA bildirimi arasında seçim yaparken bu ayrım belirleyicidir.

Burada sık yapılan hata, her şeyi tek formda çözmeye çalışmaktır. GitHub’ın belgeleri marka kötüye kullanımı için trademark politikasına, telif içinse DMCA sürecine yönlendirdiği için başvuruyu problem türüne göre ayırmak daha net bir çerçeve sunar.

GitHub marka ihlali şikayeti hangi durumlarda yapılır?

GitHub Trademark Policy sayfasına göre şirket adı, işletme adı, logo veya başka marka koruması altındaki unsurların, kullanıcıları marka ya da ticari bağlantı konusunda yanıltabilecek şekilde kullanılması ihlal sayılabilir. Buradaki ana ölçüt, karışıklık yaratma ihtimalidir.

Bu nedenle her benzerlik otomatik olarak ihlal değildir. GitHub, bir kullanıcı adının tescilli markayla aynı olmasının tek başına mutlaka ihlal anlamına gelmediğini de ayrıca belirtir. Yani sadece benzer bir kullanıcı adı gördüğünüz için değil, bu kullanımın gerçekten resmi bağlantı izlenimi yaratıp yaratmadığı için şikayet hazırlamalısınız.

Güçlü bir marka başvurusunda genellikle şu unsurlar olur:

• Hesap adı, organizasyon adı veya repo adı

• Profilde kullanılan logo, kapak görseli veya açıklama

• README içindeki kurumsal dil ya da sahte yetkili görünümü

• Kullanıcıların yanlış yönlendirildiğini gösteren somut örnekler

• Varsa markayı sulandıran, zedeleyen veya resmi bağlantı varmış gibi gösteren kullanım açıklaması

Buradaki sınır da önemlidir. GitHub, marka ihlali bildiriminde federal veya uluslararası marka tescil numarası ister. Politika metni, bildirilen isim kayıtlı bir marka değilse, örneğin bir kamu kurumu veya kâr amacı gütmeyen kuruluş adıysa, bunu ayrıca belirtmenizi ve ilk-soyad, unvan, adres, telefon ve şirket alan adlı e-posta bilgilerinizi paylaşmanızı söyler.

GitHub marka ihlali şikayeti nasıl yapılır?

GitHub marka ihlali şikayeti hazırlarken en iyi yaklaşım, önce kısa ama somut bir dosya toplamaktır. Ardından kayıtlı marka sahipleri, GitHub Trademark Policy sayfasında yönlendirilen Submit a Trademark Policy Violation Report iletişim formu üzerinden olası ihlali bildirir.

Amaç, GitHub’a uzun bir hikâye anlatmak değil; hangi hesabın, hangi unsurla, neden karışıklık yarattığını açıkça göstermektir. Şirket e-posta adresi de ayrı bir başvuru kanalı gibi değil, formda kullanılması beklenen kurumsal iletişim bilgisi olarak düşünülmelidir.

Marka başvurusu için pratik kontrol listesi

• Raporlanan hesabı net tanımlayın. Kullanıcı adı, organizasyon adı ve ilgili depo bağlantılarını bir listede toplayın.

• Hak sahibi tarafı netleştirin. Şirket adınızı, resmi web sitenizi ve varsa kurumsal GitHub hesabınızı ekleyin.

• Marka unsurunu yazın. Kelime markası, logo ya da diğer işaretin ne olduğunu açıkça belirtin.

• Tescil bilgisini ekleyin. GitHub, marka kaydı numarası ve tescil ofisi bilgisini ister. Bu nedenle başvuruda bu veriler açık biçimde yer almalıdır.

• Karışıklığı açıklayın. Sadece benziyor demek yerine, resmi destek hesabıymış gibi görünme, şirket adına dağıtım yapıyormuş izlenimi verme veya müşterileri yanlış yönlendirme gibi etkileri somutlaştırın.

• İstenen aksiyonu belirtin. Hesabın kaldırılması, kullanımın durdurulması veya uygun koşullarda kullanıcı adının mevcut şirket hesabınıza bırakılması gibi talebinizi net yazın.

• Gerekli beyan ve imzayı unutmayın. GitHub, iyi niyet beyanı, yalan beyanda bulunulmadığına ilişkin yemin ve fiziksel ya da elektronik imza ister.

GitHub’ın politika metninde saydığı çekirdek bilgiler; raporlanan kullanıcı adı, şirket bilgisi, varsa şirket GitHub hesabı, şirket web sitesi, marka unsuru, tescil numarası ve ofisi, karışıklığın açıklaması, talep edilen aksiyon, beyanlar ve imzadır. Kayıtlı marka sahipleri için bu bilgilerin ilgili iletişim formuna mümkün olduğunca eksiksiz girilmesi beklenir.

GitHub’ın politikası, aldatma niyeti açık görünüyorsa hesabın askıya alınabileceğini; karışıklık var ama açık bir resmi hesapmış gibi sunma çabası yoksa hesap sahibine durumu netleştirme fırsatı verilebileceğini söyler. Bu yüzden marka başvurusunda, platformun politika metninde sayılan seçeneklerden biriyle hareket edebileceğini hesaba katmak gerekir.

GitHub DMCA bildirimi ne zaman gerekir?

GitHub DMCA bildirimi, telifle korunan bir eserin izinsiz kullanımını hedefler. DMCA rehberinde açıkça belirtildiği gibi, platform yalnızca telif koruması altındaki eserler ve belirli bir korunan işi tanımlayan başvuruları kabul eder.

Bu noktada yazılım projeleri için önemli bir nüans var. GitHub, kodun fotoğraf, müzik veya videodan farklı olduğunu; işbirliğine açık yapısı nedeniyle telif değerlendirmesinin daha karmaşık olabildiğini vurgular. Yani her benzer kod bloğu otomatik olarak aynı sonuca götürmez; lisans, yetki ve fair use ihtimali önce değerlendirilmelidir.

Bu yüzden GitHub DMCA bildirimi göndermeden önce şu kontrolleri yapın:

• Eser gerçekten size mi ait, yoksa ekip, müşteri ya da lisans zinciri içinde mi?

• İçerik zaten açık kaynak lisansıyla yetkilendirilmiş olabilir mi?

• Karşı tarafın kullanımını sözleşme, lisans veya izin kapsıyor olabilir mi?

• Şikayet edeceğiniz bölüm tüm repo mu, belirli dosyalar mı?

GitHub, mümkünse kullanıcıyla önce doğrudan iletişim kurmayı iyi bir ilk adım olarak da önerir. Bu zorunlu değildir, ancak özellikle lisans yanlış anlaşılması, eksik atıf veya kaldırılabilir bir README kopyası gibi durumlarda sürecin daha net başlamasına yardımcı olabilir.

Bir başka önemli sınır da şudur: GitHub’ın rehberi, kısa ifadeler, URL’ler ve alan adlarının genel olarak telif korumasına girmeyebileceğini hatırlatır. Bu nedenle yalnızca isim benzerliği ya da kısa slogan kopyası görüyorsanız, otomatik olarak DMCA yoluna gitmek doğru olmayabilir.

GitHub telif ihlali nasıl şikayet edilir?

GitHub telif ihlali başvurusunda başarının anahtarı, teknik spesifikliktir. GitHub’ın belgeleri, mümkün olduğu kadar belirli olmanızı ister; çünkü platformun asıl ihtiyacı, hangi içeriğin nerede bulunduğunu makul biçimde saptayabilmektir.

DMCA başvurusu için pratik kontrol listesi

• Ön araştırmayı tamamlayın. Hak sahipliğinizi, yetkisiz kullanımı ve olası lisans veya fair use savunmalarını makul ölçüde inceleyin.

• Orijinal eseri tanımlayın. Orijinal repo, web sayfası, belge, tasarım ya da özel kod tabanını açıkça belirtin. Yayımlanmışsa kaynak bağlantı verin; yayımlanmamışsa bunun size ait özel içerik olduğunu net yazın.

• İhlal iddiası taşıyan içeriği tam URL ile gösterin. Tüm depo yerine sadece belli dosyalar sorunluysa, dosya bağlantılarını ve mümkünse satır aralıklarını ekleyin.

• Giderim talebini açıklayın. Hangi dosyaların silinmesi, hangi satırların çıkarılması veya hangi içeriğin kaldırılması gerektiğini somutlaştırın.

• İletişim bilgilerini tam verin. Ad, fiziksel adres, telefon ve e-posta eksik olmamalıdır.

• Gerekli beyanları ekleyin. GitHub, iyi niyet beyanı, fair use dikkate alındığı beyanı, doğruluk ve yetki yeminini ve imzayı ister.

• Doğru kanaldan iletin. GitHub, en hızlı dönüş için telif başvuru formunu önerir; alternatif olarak [email protected] adresine e-posta da gönderilebilir. Rehber, e-posta gövdesinde düz metin sürümünün bulunmasının önemli olduğunu söyler.

Burada en kritik konu, belirsizlikten kaçınmaktır. Sadece bu repo benim içeriğimi kopyalıyor demek çoğu zaman yeterli değildir. Bunun yerine şu tür bir yapı daha güçlüdür: orijinal kaynak şu, ihlal edilen dosya şu URL’de, sorunlu bölüm şu satırlar, giderim için şu dosyaların kaldırılması gerekir.

Kısmi ihlallerde bütün repoyu hedef almak da her zaman iyi strateji değildir. GitHub, bir deponun tamamı yerine belirli dosya veya satır düzeyinde şikayetleri değerlendirebildiği için fazla geniş yazılmış bir bildirim, tam olarak hangi içeriğe itiraz ettiğinizi belirsiz bırakabilir.

Açık kaynak projelerde de DMCA öncesinde lisansları ve kullanım yetkisini kontrol etmek gerekir. GitHub, hak sahiplerinin önce kendi lisanslarını ve anlaşmalarını gözden geçirerek kullanımın gerçekten yetkisiz olup olmadığını doğrulamasını önerir. Bu yüzden şikayet metninde sadece kopyayı değil, kullanımın neden yetkisiz görüldüğünü de açıkça belirtmek önemlidir.

Şikayet sonrası ne olur?

Başvuru gönderildiğinde birçok kişi tek sorunun formu doldurmak olduğunu sanır. Oysa süreç, başvurunun gönderilmesinden sonra başlar. GitHub, bildirimin yeterince açık ve işlenebilir olup olmadığını kontrol eder; ardından karşı tarafa bildirim yapılması, değişiklik fırsatı veya devre dışı bırakma gibi adımlar gündeme gelebilir.

Repo, paket ve kısmi içerik farkı

DMCA kaldırma politikası, şikayet tüm deponun içeriğini hedefliyorsa GitHub’ın daha hızlı biçimde içeriği devre dışı bırakabileceğini söyler. Buna karşılık, sorun yalnızca repo içindeki belirli dosyalarsa platform kullanıcının bunları silmesi ya da değiştirmesi için yaklaşık bir iş günü kadar bir pencere tanıyabilir.

Bu ayrım önemlidir çünkü GitHub, belirli dosyalara teknik olarak doğrudan erişim kapatmak yerine genellikle depo düzeyinde hareket eder. Bu nedenle sizden hangi dosyaların sorunlu olduğunu netleştirmenizi istemesi şaşırtıcı değildir.

Fork’lar neden ayrı önem taşır?

GitHub’ın politikası, ebeveyn bir repository kapatılırken fork’ların otomatik olarak devre dışı bırakılmadığını açıkça belirtir. Bunun nedeni, fork’ların farklı kullanıcılara ait olması, anlamlı değişiklikler içerebilmesi ve ayrı lisans ya da kullanım savunmalarına dayanabilmesidir.

Bu yüzden ana depoyu bulmanız yeterli olmayabilir. Eğer ihlal edildiğini düşündüğünüz içeriğin çok sayıda çatala yayıldığını düşünüyorsanız, mümkünse bunları ayrıca listelemelisiniz. Tek bildirim her çatala kendiliğinden uygulanır varsayımı güvenli değildir.

Karşı bildirim gelirse ne olur?

GitHub telif ihlali nedeniyle kaldırılan içerikler için karşı bildirim mekanizması tanır. DMCA rehberi ve politika sayfası, geçerli bir karşı bildirim gelmesi hâlinde hak sahibi ilgili faaliyetleri durdurmaya yönelik bir dava açtığını bildirmezse içeriğin 10 ila 14 gün içinde yeniden etkinleştirilebileceğini söyler.

Bu da şu anlama gelir: şikayet göndermek, içeriğin kesin olarak sonsuza kadar kapalı kalacağı anlamına gelmez. Özellikle sınırları tartışmalı, lisans ilişkisi belirsiz veya kısmi kopyalama içeren teknik vakalarda bu ihtimali baştan hesaba katmak gerekir.

GitHub’da şeffaflık ve görünürlük ne anlama gelir?

DMCA sürecinde en çok atlanan noktalardan biri kamusal görünürlüktür. GitHub, tam ve işleme alınabilir kaldırma bildirimlerini kişisel bilgileri redakte ederek kamuya açık biçimde yayımladığını hem rehberinde hem de politikasında açıkça anlatır.

Bu nedenle başvuru yazarken yalnızca hukuki veya teknik doğruluğu değil, kamusal görünürlük ihtimalini de düşünmelisiniz. Gereksiz kişisel veri eklememek ve iddianızı mümkün olduğunca somut kurmak önemlidir.

GitHub’ın 2022 şeffaflık raporu, platformun o yıl 2.321 geçerli DMCA kaldırma bildirimi ve 36 geçerli karşı bildirim işlediğini aktarıyor. Bu veri iki şeyi hatırlatır: süreç istisnai değildir ve geri yükleme mekanizması da sistemin parçasıdır.

Sık yapılan hatalar

GitHub marka ihlali şikayeti veya telif başvurusu hazırlarken en sık görülen hatalar şunlardır:

• Marka sorununu DMCA ile anlatmak veya telif kopyasını trademark başvurusuna sıkıştırmak

• Repo URL’si vermeden yalnızca ekran görüntüsü paylaşmak

• Tüm depoyu ihlal diye işaretleyip sorunlu dosyaları göstermemek

• Fork ağını hiç incelememek

• Açık kaynak lisansını, yetkiyi veya sözleşmesel izni kontrol etmeden başvuru göndermek

• Yalnızca aynı kullanıcı adı var diye otomatik marka ihlali varsaymak

• DMCA başvurusunun yayımlanabileceğini hesaba katmamak

• Karşı bildirim riskini ve geri açılma ihtimalini hiç planlamamak

• Zorunlu beyanları, iletişim bilgilerini veya imzayı eksik bırakmak

GitHub’ın belgelerindeki ortak beklenti, ihlal edildiği ileri sürülen eserin ve ilgili içeriğin makul biçimde bulunabilecek kadar spesifik tanımlanmasıdır. Bu nedenle başvurunuzda tam URL, gerekiyorsa dosya ve satır bilgisi, hangi içeriğin kaldırılmasını istediğiniz ve zorunlu beyanlar açık biçimde yer almalıdır.

Ne zaman ek destek düşünülmeli?

Marka taklidi, lisans yetkisi, çoklu fork, birden fazla organizasyon hesabı veya özel kodun kamuya açıldığı iddiaları aynı vakada birleştiğinde delilleri sınıflandırmak zorlaşabilir. Böyle durumlarda platform sürecini, delil listesini ve başvuru metnini ayrı ayrı planlamak gerekebilir.

Platform bazlı benzer müdahale örneklerini karşılaştırmak isterseniz Trendyol üzerindeki marka ihlallerine müdahale, Facebook’ta sahte sayfa ve yorumları kaldırma ve internetten kaldırılmak istenen içerikler başlıkları da fikir verebilir.

Son olarak beklentiyi gerçekçi tutun. GitHub marka ihlali şikayeti ile GitHub DMCA bildirimi, GitHub’ın farklı politika kanallarıdır; her dosya, her hesap ve her lisans ilişkisi aynı netlikte değildir. Bu yüzden doğru kanal seçimi, spesifik delil ve ölçülü bir anlatım önemlidir.