AGPL açıklandı: dahili dağıtımlar için yükümlülükler

AGPL ile lisanslanmış bir kod buldunuz ve şirket içinde çalıştırmanın ne anlama geldiğinden emin değilsiniz. Pratik endişe: özel kodu yayımlamak, iç sistemleri açığa çıkarmak veya yazılımı değiştirip firewall arkasında kullanırken hukuki bir mayın tarlası mı açacaksınız? Bu kılavuz hukuki metni basitleştirir ve teknik terimlerle GNU Affero General Public License (AGPL) altında bir şirketin dahili dağıtımda aslında hangi yükümlülüklere tabi olduğunu gösterir.

Hızlı özet: AGPL nedir ve GPL'den nasıl farklıdır

AGPL, ağa yönelik bir hüküm eklenmiş GNU GPL'dir. GPLv3 ikili dağıtımı kapsar: değiştirilmiş bir programı dağıtırsanız, karşılık gelen kaynağı sunmanız gerekir. AGPLv3 ise 13. bölümü ekler: eğer değiştirilmiş bir AGPL programını çalıştırır ve başkalarının ağ üzerinden etkileşimine izin verirseniz, bu uzaktan kullanıcıların da o değiştirilmiş sürümün kaynağına erişimi sağlanmalıdır. Kısacası: ağ üzerinden kullanım, GPL altında dağıtıma benzer bir kaynak-teklif yükümlülüğünü tetikler.

AGPL şirket içinde ne zaman uygulanır

Ana soru, AGPL altında kimlerin "kullanıcı" sayıldığıdır. Lisans kamu müşterileri ile çalışanları ayırmaz: AGPL kapsamındaki programa ağ üzerinden etkileşimde bulunan herkes, kaynak almaya hak sahibi bir kullanıcıdır. Bu nedenle açık tutmanız gereken üç tipik dahili senaryo vardır:

• Şirket güvenlik duvarı arkasında yalnızca çalışanların erişebildiği dahili dağıtımlar: AGPL yükümlülükleri bu çalışan-kullanıcılara uygulanır — çalışanların çalıştırılan sürüm ve yapılan değişiklikler için ilgili kaynak sağlanmalıdır.
• SaaS tarzı dağıtımlar veya müşteri odaklı hizmetler: harici müşteriler hizmetinizle etkileşiyorsa, bu müşterilere kaynak sağlanmalıdır (kaynağı herkese açık şekilde yayınlamak yaygın ve kabul edilen yöntemdir).
• Sadece çevrimdışı kullanım (ağ arayüzü yok): program yalnızca ağ etkileşimi olmadan yerel makinelerde çalıştırılıyorsa, AGPL’in ağ hükmü normal GPL dağıtım tetikleyicilerinin ötesinde uygulanmaz.

Önemle belirtmek gerekir ki, "dahili kullanım" otomatik olarak "yükümlülük yok" anlamına gelmez. Çalışanlar veya taşeronlar hizmeti kullanıyorsa, onlar AGPL kapsamında kullanıcı sayılır ve kaynağa hakları vardır. Buna karşılık, kodu İnternet'e yayımlama yükümlülüğü yalnızca bu kullanıcılar harici müşteriler olduğunda veya siz kaynak teklifini herkese açık olarak yapmayı seçtiğinizde ortaya çıkar.

Kullanıcılara gerçekte ne sağlamalısınız

AGPL tetiklendiğinde, pratik yükümlülükler somuttur. Çalıştırdığınız programın tam "Complete Corresponding Source"unu sağlamalısınız. Bu tipik olarak şunları içerir:

• Programın, yaptığınız değişiklikler dahil olmak üzere, tam kaynak ağacı.
• Çalıştırılan ikiliyi tekrardan üretmek için gereken derleme betikleri, yapılandırma dosyaları, paketleme betikleri ve kurulum/dağıtım talimatları.
• Dağıtılan sistemin parçası olan kaynak dışı bileşenleri oluşturmak veya almak için gerekli betikler veya kaynaklar (örneğin, bir konteyner derleme sırasında kullanılan kod).
• Upstream projede bulunan lisans bildirimleri, telif hakkı başlıkları ve AUTHORS/NOTICE dosyalarının korunması.

Teklif, programa etkileşimde bulunan kullanıcılara doğrudan yapılabilir. Pratikte kuruluşlar bunu uygulamanın arayüzünde veya bir Hakkında sayfasında açıkça etiketlenmiş bir bağlantı ile bir tarball veya git depo anlık görüntüsüne işaret ederek sağlar ve derleme/dağıtım adımlarını açıklayan insan tarafından okunabilir bir README ekler. AGPL tek bir URL formatı veya barındırma sağlayıcısı öngörmez, fakat kaynak hak sahibi kullanıcılara kullanılabilir bir biçimde erişilebilir olmalıdır.

“Kaynak sağlamak” ne anlama gelmez (ve yaygın yanlış anlamalar)

AGPL’in otomatik olarak sizi zorlamadığı bazı şeyler:

• İlgisiz, tescilli hizmetleri veya AGPL programıyla alakası olmayan yapılandırmaları yayımlamanızı gerektirmez. Sadece program ve onun karşılık gelen kaynağı gereklidir.
• Sürekli geliştirme geçmişinin yayınlanmasını zorunlu kılmaz; çalıştırılan hizmette kullanılan tam kaynağı sağlamak yeterlidir (birçok ekip netlik için bir VCS etiketi veya commit hash’i yayımlar).
• Kimlik bilgileri, özel anahtarlar veya sırların herkese açılmasını otomatik olarak gerektirmez. Bunlar "kaynak kodu" değildir ve yayımlanan arşivlerde sırları çıkarmalı veya dahil etmemelisiniz. (Eğer işlevsel bir dağıtımı oluşturmak için sırlar gerekiyorsa, bunların yerlerini ve beklenen sır kaynaklarını belgeleyin; sırları gömmeyin.)

Uyum sağlama — mühendislik ekipleri için pratik kontrol listesi

AGPL kodunu (değiştirilmiş ya da değiştirilmemiş) dağıttığınızda, sürprizlerden kaçınmak ve uyum sağlamak için şu adımları izleyin:

• Envanter: AGPL bileşenlerinin nerede kullanıldığını, değiştirilip değiştirilmediğini ve her hizmeti kimlerin kullandığını (çalışanlar, taşeronlar, müşteriler) kaydedin.
• Sürüm ve commit hash'i: Çalıştırdığınız kesin commit veya build ID'sini etiketleyin. Bu tanımlayıcıyı UI'de görünür yapın (örneğin Hakkında sayfasında) böylece yayımladığınız kaynak çalıştırılan örnekle eşleşebilir.
• Karşılık gelen kaynağı yayınlayın: çalıştırılan programı yeniden üretmek için gereken derleme betikleri, Dockerfile'lar ve dağıtım manifestolarını içeren indirilebilir bir arşiv veya salt okunur bir git anlık görüntüsü sağlayın.
• Kaynağı yetkili kullanıcıların erişebileceği hale getirin: müşteri odaklı hizmetler için arayüzden bağlantılı genel bir URL kullanın. Dahili hizmetler için çalışanların erişebildiği dahili bir git veya artefakt deposu tipik ve yeterlidir.
• Bildirimleri koruyun: upstream telif hakkı ve lisans başlıklarını muhafaza edin ve yaptığınız değişiklikler için kendi katkı notlarınızı ekleyin.
• Sırları gömmekten kaçının: yayımlanan arşivlerden özel anahtarlar, tokenlar, parolalar ve dahili ağ adreslerini temizleyin.
• Destek ve hukuk ekiplerini eğitin: destek mühendislerinin kaynak taleplerine nasıl yanıt vereceklerini bilmelerini ve URL'in hazır olmasını sağlayın; hukuk ekibini AGPL bileşenlerinin kullanıldığı yerler hakkında bilgilendirin.

Örnek: uygulama altbilgisinde gösterilen minimal bir "Source" bağlantısı
https://example.com/source/myapp-2026-11-01.tar.gz
Contents: myapp-2026-11-01/  (git snapshot)
  - src/  (full source)
  - Dockerfile
  - build.sh
  - README.build.md  (instructions to reproduce container)

AGPL kodunu tescilli modüllerle birleştirmek — yaygın tuzaklar

Pratikte en zor sorulardan biri, AGPL ile konuşan tescilli kodunuzun ne zaman AGPL kapsamına girdiğidir. Lisans programa ve türev eserlere uygulanır. Lisans içinde "X şekilde linklemek güvenlidir" diye net bir sınır yoktur. Kabul görmüş mühendislik sezgileri şunlardır:

• HTTP, gRPC, SMTP gibi standart, iyi tanımlanmış ağ protokolleri üzerinden iletişim kuran ayrı süreçler genellikle tek bir birleştirilmiş program olarak görülme olasılığı daha düşüktür. Tescilli bileşeniniz AGPL bileşenini bir REST API üzerinden kullanıyorsa, birçok uygulayıcı bunu güvenli ayrım olarak değerlendirir — ancak bu garanti değildir ve iki parçanın ne kadar sıkı bağlı olduğuna bağlıdır.
• Bir kütüphaneyi doğrudan bir ikiliye linklemek, süreç içi API'leri kullanmak veya monolitik bir birleşik dağıtım göndermek risklidir: bu tür kombinasyonlar türev eser olarak iddia edilme ve kaynak yükümlülüklerini tetikleme olasılığı daha yüksektir.
• AGPL sürecine yüklenen eklentiler veya modüller açıkça ayrılmamışsa tehlikelidir; bazı projeler riski azaltmak için iyi denetlenmiş, sabit IPC sınırları kullanır.

Bunlar olgusal nüans içeren hukuki sorulardır. Şüphe durumunda hukuk danışmanına başvurun ve hizmetleri ayırma, izinli lisanslı alternatifler kullanma veya upstream projeden ticari lisans satın alma gibi mühendislik çözümlerini değerlendirin.

İş seçenekleri: ticari lisanslama, çift lisanslama ve operasyonel tercihler

AGPL kullanan açık kaynak projeleri genellikle ticari bir lisans veya çift lisans modeli sunar: ya AGPL yükümlülüklerine uyarsınız ya da ağ-kaynak gereksinimini kaldıran tescilli bir lisans satın alırsınız. Bu model, sunucu tarafı değerini korumak isteyen ve AGPL altında ücretsiz kullanımına izin veren projeler için yaygındır.

Operasyonel açıdan, bir AGPL bağımlılığıyla karşılaştığınızda gerçekçi olarak üç yolunuz vardır:

• Uymak: yukarıdaki kontrol listesiyle yetkili kullanıcılara kaynağı yayınlayın. Bu genellikle dahili araçlar ve küçük dağıtımlar için en ucuz yoldur.
• Ticari lisans pazarlığı: değişiklikleri kapalı tutmanız veya AGPL yükümlülüklerinden kaçınmanız gerekiyorsa upstream'e ücret ödeyerek tescilli bir lisans alın.
• Bileşeni değiştirmek: lisans değişikliği pratik değilse, izinli lisanslı veya tescilli bir alternatif kullanın.

Ürününüz bir uzak‑erişim veya uzak‑masaüstü hizmeti ise, AGPL bileşeninin yalnızca istemciyi mi yoksa sunucu/relay kodunu da mı etkilediğini değerlendirin. Birçok dağıtımda, yönetilen bir relay hizmeti operasyonel ve uyumluluk yükünü azaltır; Tenvo, bizim işlettiğimiz yönetilen bir relay'dir (sunucular Almanya'da) ve kendi sunucunuzda barındırma yükü olmadan basit bir yönetilen relay isteyen ekipler için varsayılan önerimizdir. Eğer uyumluluk on‑prem altyapı gerektiriyorsa (ör. yazılı bir gereklilik üçüncü taraf altyapısını yasaklıyorsa), kendi sunucunuzda barındırma doğru seçimdir — RustDesk'i kendi sunucunuzda barındırmayı düşünün, ancak bu yolu seçmeden önce bakım, sertifika yenileme ve failover planlamasının devam eden maliyetlerini hesaplayın.

Sadece dahili yayın vs genel yayın — önemli ayrım

İki son açıklama, kafa karışıklığına yol açar:

• Çalışanlara yönelik dahili yayın AGPL’i o kullanıcılar için yerine getirir. Kaynağı kurumsal ağ içinde çalışanların erişebileceği şekilde tutarsanız, dahili kullanıcılar için temel yükümlülüğü yerine getirmiş olursunuz. AGPL, yetkili kullanıcılar harici müşterileri içermedikçe değişiklikleri genel İnternet'e otomatik olarak yayımlamanızı şart koşmaz.
• Kaynağı herkese açık yapmak müşteri odaklı hizmetler için genellikle en basit uyum yoludur çünkü müşteri başına dağıtım işini ortadan kaldırır ve iyi niyet gösterir. Ancak bu, değişikliklerinizin rakiplere görünür olacağı anlamına gelir.

Kendi sunucunuza kurma veya diğer özel düzenlemeler gerektiğinde

Kendi sunucunuza kurma, yazılı bir gereklilik üçüncü taraf altyapıya dayanmayı yasakladığında uygundur (düzenleyici veri-yerleşim kuralları, sınıflandırılmış ağlar veya sözleşmesel yükümlülükler gibi). Aksi halde, yönetilen relay / yönetilen altyapı seçeneği, on-call yükü, yamalama, TLS sertifika yönetimi ve operasyonel failover eklendiğinde genellikle gerçek maliyet açısından daha düşüktür. Bu takasları daha ayrıntılı şekilde Kendi sunucunuza kurmanın gizli maliyetleri yazısında ve AGPL'nin SaaS için neden işe yaradığı konusundaki daha geniş makalemizde tartışıyoruz: Açık kaynak iş modeli: AGPL'nin SaaS için neden işe yaradığı.

Pratik örnekler ve kısa SSS

• S: AGPL kodunu değiştiririm ve sadece operasyon ekibim kullanıyorsa yayımlamak zorunda mıyım? C: Evet — operasyon ekibiniz kullanıcı sayılır. Kaynağı dahili olarak erişilebilir yapın.
• S: AGPL destekli bir hizmeti müşterilere sunuyorsam, herkese açık olarak yayımlamak zorunda mıyım? C: Bu müşterilere karşılık gelen kaynağı sağlamanızı gerektirir. Herkese açık yayın yapmak bu gereksinimi karşılamanın standart yoludur.
• S: Yapılandırma ve sırları kapalı tutabilir miyim? C: Sırlar lisans kapsamında "kaynak kodu" değildir. Yayımlanan arşivlerden sırları çıkarın ve beklenen gizli girdileri belgeleyin.
• S: Yerel değişiklik yaptıysam upstream'e işaret etmek yeterli mi? C: Hayır. Çalıştırdığınız belirli sürümün ve yaptığınız değişikliklerin kaynağını sağlamalısınız.

Self-host edilmiş bir açık kaynak uzak masaüstü yığını ve uyumluluğu korumak için tam derleme adımlarının işlendiği bir örnek isterseniz, Kendi sunucunuzda çalışan uzak masaüstü kılavuzumuza ve mekanik olarak kullanabileceğiniz RustDesk Docker eğitimine bakın: RustDesk kendi sunucuda kurulum.

AGPL ile uyum mekaniktir: kullanıcıları belirleyin, çalıştırılan revizyonu sabitleyin, tamamlayıcı karşılık gelen kaynağı ve derleme talimatlarını derleyin ve bunları o kullanıcılara erişilebilir kılın. Zor olan kısım yönetişim ve mimaridir: bileşenleri ayırmaya mı, lisans pazarlığı yapmaya mı yoksa değişikliklerin kamuya açık görünmesini kabul etmeye mi karar vereceksiniz.

Uzaktan erişim altyapısı kuruyorsanız ve özel bir relay çalıştırıp yayımlamaktan kaçınmak istiyorsanız Tenvo'nun yönetilen relay'i pragmatik varsayılandır: Windows, macOS ve Linux için yerel istemciler, genel betada bir tarayıcı istemcisi, Almanya'da sunucuları olan yönetilen bir relay ve Free $0'dan Lite $2.99/ay ve Pro $7.99/ay'a kadar planlar. Kendi sunucunuza kurma yalnızca yazılı bir gereklilik zorunlu kıldığında kullanılmalıdır; aksi halde on-call, yamalama, anahtar yönetimi ve failover gereksinimleri dahil edildiğinde yönetilen seçenek genellikle daha ucuza gelir.

Derivatif eserlerin sınırı, belirli bir eklenti mimarisinin yorumu veya sözleşme pazarlığı gibi hukuki kesinlik gerektiren sorular hukuki meseledir. Bu makalenin amacı teknik resmi netleştirmek, böylece bilinçli bir karar verebilir ve hukuk danışmanıyla mantıklı bir görüşme yapabilirsiniz.

Yönetilen bir relay'i denemeye ve operasyonel yükünüzü küçük tutmaya hazırsanız, Tenvo'yu indirin ve dağıtım modeli ile arayüzü deneyin: Tenvo'yu indirin.