Elasticsearch etrafında AWS ile Elastic arasındaki çatışma
(blog.opsnow.com)Son dönemde Elasticsearch’ün açık kaynaktan vazgeçmesi, SSPL ilanı ve AWS’nin ayrı bir fork oluşturup Apache License 2.0 altında açık kaynak topluluğunu sürdürmek istediğine dair haberlerle karşılaşınca, geçmişten beri iki taraf arasında yaşanan çatışmayı özetlemeye çalıştım.
Arada eksik ya da hatalı kısımlar varsa yorum bırakırsanız yansıtılacaktır.
10 yorum
Ben şahsen OSI'nin SSPL'yi neden açık kaynak lisansı kaydından çıkardığını pek anlayamıyorum. AGPL'nin biraz daha somutlaştırılmış bir lisansı gibi duruyor; benim anladığım, SaaS sağlayıcılarının tüm kaynak kodunu açıklamasını şart koşuyor. Ama OSI'nin bunu SaaS'ı "kısıtlamak" olarak yorumlamasını pek anlayamıyorum.
OSI'nin görüş yazısı 1'e bakınca da Elastic'in SSPL'yi benimseme niyetini eleştiriyor ama SSPL'nin hangi maddesinin kullanımı "kısıtladığını" açıklamıyor.
İçeriği okuyunca AGPL'ye kıyasla bir "kısıtlama" getirip getirmediği bana çok net gelmiyor. Acaba lisansı yanlış mı yorumluyorum...
Lisans konusunda geri adım atan taraf MongoDB'ydi. Reddeden OSI değildi. Elbette OSI da tartışmalı kısımlar nedeniyle bunun açık kaynak olarak kabul edilmesinin zor olduğuna dair bir tutum sergiliyordu, ancak MongoDB tarafı bu durumu önceden fark edip başvuruyu geri çekmişti.
Düzeltme için teşekkürler. Benim anlatımım biraz hatalıymış. Yine de önce geri çeken tarafın MongoDB olduğu doğru, ama bağlantıda verilen OSI gönderisine bakınca da OSI'nin SSPL'nin mevcut sürümünü kabul etme niyetinde olmadığı açıkça görülüyor... bu yüzden olayların hangi sırayla gerçekleştiği pek de önemli görünmüyor.
Katılıyorum. ^^
Ben de biraz şüphe duyuyorum ve araştırırken bunu buldum, o yüzden bağlantıyı paylaşayım.
https://ceart.kr/component/file/…
Alıntı
Öncelikle SSPL'nin AGPL'den farkı şudur. Önceki AGPL'de, bir yazılım dağıtılmasa ve sunucu tarafında çalıştırılsa bile, GPL'de olduğu gibi hizmet sağlayıcının o yazılım üzerinde yaptığı değişiklikler ve eklenen kısımların tüm kaynak kodunu açıklaması gerekir; bu, sunucunun kendisiyle sınırlıdır.
Buna karşılık SSPL, yalnızca ilgili kodun değil, aynı zamanda As-a-Service biçiminde sunulurken yan olarak gereken yönetim yazılımı, kullanıcı arayüzü, API, otomasyon yazılımı, izleme yazılımı, yedekleme ve depolama yazılımı gibi As-a-Service kullanıcısının çalıştırdığı tüm yazılımların kodunun da açıklanmasını şart koşar. Başka bir deyişle, bulut sağlayıcıları MongoDB'yi hizmet olarak sunduğunda, kendi hizmetlerindeki rekabet avantajını korumak için geliştirdikleri tüm yazılımların kaynak kodunu da tamamen açıklamak zorunda kalacakları anlamına gelir.
MongoDB ve Redis hakkında da araştırma yapmayı düşünmüştüm... burada çok iyi açıklanmışmış!
Ek olarak PDF'ye bakarsanız, OSI ile uyumlu olmayan kısımların ne olduğuna dair bir açıklama da var. Bunun, özgürlüğün kısıtlanması ve ayrı eserlerin sınırlandırılması meselesi olduğu söyleniyor.
Oo... genel olarak harika şekilde yazılmış bir PDF'miş. Link için teşekkürler.
Böyle bakınca AGPL'den hangi yönleriyle farklı olduğunu ve neden SSPL'nin kabul edilmediğini anlıyorum, ama OSI'nin biraz fazla permissive tarafa yatkın olup olmadığını da düşündürüyor.
Tüm geçmiş çok iyi derlenmiş, rahatça okudum. Teşekkürler!
İlgili yazılara göz atın
https://tr.news.hada.io/topic?id=3620 - AWS, Elasticsearch ve Kibana'nın açık kaynak fork'unu duyurdu
https://tr.news.hada.io/topic?id=3606 - Elastic, AWS'nin kullanamaması için lisansı değiştirdi