açık kaynak iş modeli: AGPL neden SaaS için işe yarar

Açık kaynaklı, uzaktan erişimle ilgili faydalı bir proje sürdürüyorsunuz ve bulut sağlayıcılarının kodunuzu kopyalayıp barındırılan bir hizmet olarak sunup geri katkıda bulunmayacağından endişe ediyorsunuz. Bu senaryo — sözde SaaS boşluğu — bazı ekiplerin AGPL seçmesinin nedenidir. Bu makale, AGPL'nin bir SaaS işletmecisine gerçekte ne sağladığını, para kazanma seçeneklerini nasıl şekillendirdiğini ve röle barındırma ile yönetilen ve kendi barındırdığınız kurulumlar arasındaki gerçek operasyonel takasları açıklar.

AGPL (Affero GPL v3) neyi değiştirir — sade ifadeyle

AGPLv3, ağa kullanım hükmü (çoğunlukla Bölüm 13 olarak anılır) eklenmiş GPLv3'tür; ağa üzerinden programa etkileşimde bulunan herkese kaynak sunmanızı zorunlu kılar. Pratikte bunun anlamı şudur: bir AGPL uygulamasının sunucu tarafını çalıştırıyorsanız ve kullanıcılar web veya API aracılığıyla etkileşiyorsa, değiştirilmiş kaynağınızı bu kullanıcılara sunmalısınız. Bu, bir şirketin kodu değiştirip barındırılan bir hizmet olarak çalıştırıp değişiklikleri hiç yayınlamamasına imkan veren klasik GPL 'SaaS boşluğu'nu kapatır.

Bu hukuki etki dar ve somuttur. Yazılımınızı barındırmalarını sihirli bir şekilde engellemez, ancak değişiklikleri paylaşma yükümlülüğü getirir ve üçüncü taraf kodunuzu mülkiyetçi bir barındırılan ürün olarak paketlediğinde lisans verenlere pazarlık gücü sağlar.

AGPL, SaaS iş modellerini nasıl destekler

AGPL'nin SaaS destekli bir ürün için mantıklı olduğu üç pratik iş modeli vardır:

• Çift lisanslama: Topluluk için kodu AGPL ile yayınlayın ve AGPL yükümlülüklerini istemeyen müşterilere gömme veya genişletme hakkı veren ticari (mülkiyetçi) lisanslar satın. Bu, veritabanı ve middleware sağlayıcıları için klasik açık kaynak iş modelidir.
• Barındırılan eklentiler ve yönetilen altyapı: Çekirdek protokol/kodu AGPL altında açık tutun, sonra operasyonel olarak ucuzca kopyalanması zor olan barındırılan hizmetleri satın; çok bölgeli röleler, analiz, yedeklemeler veya orkestrasyon gibi. Müşteriler kolaylık, SLAs ve azalan operasyon yükü için ödeme yapar.
• Destek, SLAs ve kurumsal özellikler: AGPL kodu açık kalır, ancak ücretli destek, eğitim, özel entegrasyonlar veya ayrı bir hizmet sınırından sunulan mülkiyetçi kurumsal eklentiler ile para kazanırsınız.

Uzak masaüstü yazılımı özelinde, barındırılan röle doğal bir üründür: röleler bant genişliği taşır ve düşük gecikme için küresel varlık gerektirir. İstemci ve sunucu kodu AGPL olarak kaldığı sürece yönetilen bir röleyi satmak ticari açıdan mantıklıdır.

Çift lisanslama: mekanikler ve gerçekler

Çift lisanslama kavramsal olarak basittir: projeyi AGPL altında yayınlarsınız ve AGPL yükümlülüklerini istemeyen müşterilere ticari bir lisans da sunarsınız. İki ana uygulama noktası katkı kontrolü ve hukuki netliktir.

Katkı kontrolü: ticari lisans satabilmek için katkıda bulunan kodu yeniden lisanslamanıza izin veren temiz bir devir veya Contributor License Agreement (CLA) gerekir. Bun olmadan, üçüncü taraf katkılarını içeren mülkiyetçi bir lisansı hukuka uygun şekilde satamazsınız.

Ticari fiyatlandırma: erken aşama ticari lisansların listelenmiş olmaktan ziyade pazarlıkla belirlenmesini bekleyin. Birçok proje mütevazı bir barındırılan ürünle başlar (örneğin bir röle servisi) ve bunu şeffaf fiyatlandırma ile sunar — Tenvo's managed relay offering bu operasyonel parçayı paketlerken protokol kodunu açık tutma örneğidir — daha derin entegrasyonlar veya kurum içi kurulumlar için pazarlıklı fiyatlandırma saklanır.

Neden yönetilen bir röle genellikle varsayılan öneridir

Operasyonel karmaşıklık kendi içinde gizli bir maliyettir. Bir röle kümesi TLS sertifika yönetimi, izleme, DDoS koruması, çok bölgeli devreye alma, bant genişliği faturalaması ve nöbetçi mühendisleri gerektirir. Çoğu ticari müşteri için yönetilen bir röle satın almak zaman içinde değere ulaşmayı ve maliyeti öngörülebilir kılmayı sağlar.

Tenvo's managed relay varsayılan olarak çok bölgeli sunulur ve ticari planlarımıza paketlenmiştir: Free $0, Lite $2.99/mo and Pro $7.99/mo. Basitlik ve SLA isteyen ekipler için yönetilen bir röle, yama yönetimi, olay müdahalesi ve sertifika yaşam döngüsü hesaplandığında tam zamanlı bir operasyon personeli işe almaktan genellikle daha ucuz olur.

Kendi barındırma: ne zaman doğru tercih

Yazılı bir zorunluluk bunu gerektirdiğinde kendi barındırma kesinlikle doğru tercihtir: üçüncü taraf altyapısını yasaklayan düzenlemeler, internete çıkışı olmayan izole bir ağ veya yönetilen rölenizin karşılayamayacağı sıkı veri yerleşim gereksinimleri. Bu durumlarda AGPL yine işe yarar — hatta tercih edilebilir — ama operasyon maliyetlerini kabul etmelisiniz: sağlama, HA, olay müdahalesi, anahtar saklama ve TLS sertifika yenileme.

Kendi barındırmayı değerlendiriyorsanız, DNS, sertifika otomasyonu ve atlanamaz temel izlemeyi anlatan pratik takasları Kendi barındırdığınız uzak masaüstü: dürüst 2026 rehberi yazımızda okuyun.

Güvenlik ve şifreleme: lisansın değiştirmediği şeyler

Lisanslama taşıma güvenliğini değiştirmez. Mimari olarak, doğrudan eşler arası bağlantı iki cihaz arasında uçtan uca olur. Bir oturum röleye geri dönerse, TLS o rölede sonlanmak zorundadır; bu nedenle röle operatörü oturum trafiğini gözlemleme pozisyonunda olur. Bu, barındırılan altyapı satarken veya müşteriler veri maruziyeti hakkında soru sorduğunda hesaba katmanız gereken operasyonel bir gerçektir.

Ürün dokümantasyonunuzda bunun açıkça belirtilmesi gerekir: doğrudan bağlantıların ne zaman mümkün olduğunu, röleye düşmenin ne anlama geldiğini ve röle operatörünün neye erişip neye erişemeyeceğini açıklayın. Uzak masaüstü tehditlerinin daha derin bir incelemesi için bkz. Uzak Masaüstü Güvenliği: Bilmeniz Gerekenler.

Pratik mimari: gelire dönüştürülebilecek parçaları ayrı tutun

AGPL'yi seçtiğinizde, projeyi para kazanmayı planladığınız bileşenleri AGPL lisanslı çekirdekten ayıracak şekilde yapılandırın. Tipik bölünme desenleri:

• Açık çekirdek: Çekirdek istemci ve protokol AGPL altında; isteğe bağlı mülkiyetçi sunucu bileşenleri (örneğin gelişmiş bir orkestrasyon API'si) ticari lisans veya SaaS olarak sunulur.
• Hizmet sınırı: Barındırılan röleyi ve operasyonel hizmetleri, açık çekirdek ile belgelenmiş API'ler üzerinden etkileşen ayrı bir hizmet içine koyun. Röle mülkiyetçi olabilir veya hizmet olarak ücretlendirilebilir; çekirdek AGPL olarak kalır.
• Eklentiler vs çekirdek: Çalışma zamanı, protokol ve düşük seviyeli taşıma AGPL'de kalsın; kurumsal eklentilerin (ticari lisanslı) kontrollü bir ortamda çalışabileceği uzatma noktalarını açın.

Mimari ayrım hukuki belirsizliği azaltır ve müşterilere hangi parçaların açık, hangilerinin ticari hizmetler olduğunu açıklamayı kolaylaştırır.

Geliştirici ve topluluk takasları

AGPL güçlü copyleft ve topluluk iyileştirmelerini isteyen katkıcıları çeker, ancak ağ kullanım yükümlülüğünü kabul etmeyen şirketleri uzaklaştırabilir. Mülkiyetçi SaaS inşa eden şirketlerden gelen gelen pull request sayısının daha az olmasını bekleyin — ama bireysel geliştiriciler ve kurumlar, kodun açık kalacağını gördükleri için genellikle daha fazla katkıda bulunurlar.

Katkıları sağlıklı tutmak için açık katkı belgeleri, çift lisanslamayı planlıyorsanız bir CLA ve şeffaf yönetişim sağlayın. Birçok proje Şeffaf Yönetişim politikası, düzenli sürüm takvimi (örn. aylık kararlı + gece derlemeleri) ve net güvenlik açığı bildirim süreçleri benimser; bu da kurumsal kullanıcılar için sürtüşmeyi azaltır.

Uygulama ve itibar — yumuşak kaldıraç

Lisanslar, onları uygulayabildiğiniz ölçüde faydalıdır. Uygulama hukuki olabilir, ancak çoğu zaman itibar temellidir: kamuya duyurular, nazik erişimler ve topluluk baskısı etkilidir. Açık kaynak ekosistemindeki yüksek profilli değişiklikler (örneğin veritabanı sağlayıcılarının SSPL'e veya source‑available lisanslara geçişi) lisans seçimlerinin davranışı şekillendirdiğini gösterir — ama uygulama kaynak ve dava veya dava benzeri eylemler gerektirir.

Eğer uygulama modelinizin merkezindeyse, hazırlıklı olun: katkı geçmişlerini tutun, dağıtıcılaları (hukuken yapabildiğiniz ölçüde) takip edin ve hukuki destek için bütçe ayırın. Birçok proje için AGPL'nin pratik değeri caydırıcılık ve pazarlık için net bir yol sunmaktır; sık dava tecrübeleri değildir.

Fiyat ve maliyet örnekleri: gerçekçi muhasebe

Gerçek rakamlar değişir, ama yönetilen ve kendi barındırdığınız röle modelleri arasında seçim yaparken şu kabaca örnekleri düşünün:

• Küçük bir ekip, hafif bant genişliğiyle tek bir röle bölgesi kullanıyorsa: <$100/month seviyesindeki yönetilen röle, onu çalıştırmak ve güvenliğini sağlamak için gereken operasyonel zamanı işe almaktan genellikle daha ucuzdur.
• Üretim hizmeti için çok bölgeli HA ve 7/24 nöbet gerekiyorsa: replikasyon, DDoS koruması ve çıkış (egress) bant genişliği kendi barındırma maliyetlerini ayda yüzlerce veya düşük binlerce dolara çıkarabilir. SLA'lı yönetilen bir röle, personel maliyetleri dahil edildiğinde daha maliyet‑etkin olabilir.

Bunlar kabaca aralıklardır — kapasite, çıkış hacimleri ve uyumluluk gereksinimleri hesapları hızla değiştirir — ama nokta şudur: güvenilir küresel bir rölenin operasyonel maliyeti ihmal edilecek kadar düşük değildir; bu nedenle bunu ücretli bir hizmet olarak paketlemek ekonomik açıdan mantıklıdır.

Kontrol listesi: AGPL tabanlı bir SaaS'ı sorumlu şekilde dağıtmak

• Lisans versiyonunu açık seçin (çoğu ekip için AGPLv3 önerilir) ve neyi kapsadığını belgeleyin.
• Çift lisanslamayı planlıyorsanız bir CLA veya katkı devri kullanın.
• Gelire dönüştürülebilecek altyapıyı (röleler, orkestrasyon, analiz) net bir hizmet sınırı arkasına ayırın.
• Oturumların rölelerden geçtiği durumları ve güvenlik etkilerini (TLS sonlanması rölede) belgeleyin.
• Kendi barındıranlar için sürtüşmeyi azaltmak amacıyla açık yükseltme, kurulum ve sertleştirme belgeleri yayınlayın.
• Uygulama duruşunuzu belirleyin ve hukuki kaynaklara veya arabuluculuk politikasına bütçe ayırın.
• Barındırılan hizmetleri şeffaf katmanlarla fiyatlandırın; Tenvo’s Free $0 / Lite $2.99/mo / Pro $7.99/mo modeli, SLA'lı kurumsal planlara ölçeklenen basit bir giriş hunisi örneğidir.

Ne zaman başka bir şey seçilmeli

AGPL, üçüncü taraf SaaS sağlayıcıları tarafından maksimum benimsenmeyi hedefliyorsanız ya da pazarlık olmadan kapalı sistemlerde hoşgörülü yeniden kullanıma izin vermek istiyorsanız doğru seçim değildir. Mülkiyetçi ürünlere gömülmesi amaçlanan kütüphaneler için açık lisanslar (MIT/BSD/Apache 2.0) genellikle daha uygundur.

Ayrıca hibrit yaklaşımları düşünün: müsamahalı bir istemci kütüphanesi ile bir AGPL sunucusu veya müsamahalı çekirdek ile AGPL referans sunucusu. Her seçim, teşvik etmek veya engellemek istediğiniz yeniden kullanım türleri hakkında net bir sinyal gönderir.

İleri okumalar ve karşılaştırmalar

Uzak masaüstü projeleri için takasları karşılaştırmak istiyorsanız, fork ve barındırma karşılaştırmamız faydalıdır: RustDesk vs Tenvo: kendi barındıranlar için fork karşılaştırması. Ve kendi barındırma maliyet/fayda kararını veriyorsanız, operasyonel adımları Kendi barındırdığınız uzak masaüstü: dürüst 2026 rehberi içinde tekrar gözden geçirin.

Lisanslama birçok kaldıraçtan sadece biridir. Ağ kullanıcılarının kaynağa erişebilmesi konusunda hukuki teminat gerektiğinde ve operasyonel hizmetleri paraya çevirmeyi amaçladığınızda AGPL'yi seçin; ancak müşterilere AGPL'in neyi çözüp neyi çözmediğini açıkça söyleyin: kod katkıları ve açıklama yükümlülüğünü ele alır, taşıma güvenliği veya yapılandırma hatalarını çözmez.

AGPL destekli bir uzak erişim yığını ile yönetilen röle seçeneğini denemeye hazır mısınız? İstemciyi indirip deneyin veya fiyat detayları ve yönetilen planlar için fiyat sayfamıza bakın. Uygulamayı elinizle test etmek isterseniz, indir ve röle destekli bir kurulumu dakikalar içinde test edin.