Redis, çift kaynak kullanımlı lisansı benimsedi

• Redis, Redis 7.4 ile birlikte BSD 3-Clause dağıtımını sonlandırıyor ve bundan sonra Redis’i RSALv2 veya SSPLv1 ile sunarak lisans sınırlarını büyük ölçüde değiştiriyor
• Kaynak kodu Redis Community Edition olarak ücretsiz sunulmaya devam edecek, ancak yeni lisanslar OSI tanımına göre açık kaynak sayılmıyor
• Redis, Core ve Stack’i birleştirerek arama, JSON, vektör, olasılıksal veri yapıları ve zaman serisi veri modelini tek bir ücretsiz pakette toplamayı planlıyor
• Dahili·kişisel kullanım, istemci kütüphaneleri, entegrasyon ortakları ve mevcut Redis Enterprise müşterileri etkilenmiyor, ancak rekabetçi yönetilen hizmetler yeni Redis kaynak kodunu ücretsiz kullanamayacak
• Redis 8 ile birlikte Redis Stack özelliklerinin Redis’in kendisine dahil edilmesi planlanıyor; ardından ayrı Redis Stack derlemesinin kullanım ömrü sonu süreci başlayacak

---

Redis lisans değişikliğinin kapsamı

• Redis, bundan sonra çıkacak tüm Redis sürümlerini source-available lisanslarla dağıtacak
• Redis 7.4’ten itibaren Redis Core yazılımı, Redis Source Available License v2 veya Server Side Public License v1 lisanslarından biriyle kullanılabilecek
• Artık BSD 3-Clause lisansı altında dağıtılmayacak
• Redis kaynak kodu, Redis GitHub deposu üzerinden Redis Community Edition olarak ücretsiz sunulmaya devam edecek
• RSALv2 ve SSPLv1’in ikisi de OSI onaylı lisanslar değil ve her birinin kendi kullanım kısıtları bulunuyor

Redis Stack entegrasyonu ve ürün yapısındaki değişiklikler

• Gelecekteki source-available sürümler, Redis Core ile Redis Stack’i birleştirecek
• Entegrasyon kapsamına arama, JSON, vektör, olasılıksal veri yapıları ve zaman serisi veri modeli giriyor
• Tek bir ücretsiz indirme paketi olarak sunulacak ve Redis şu amaçlarla kullanılabilecek:
  • yüksek performanslı anahtar/değer deposu
  • belge deposu
  • sorgu motoru
  • üretken yapay zeka uygulamaları için düşük gecikmeli vektör veritabanı
• Redis 8’den itibaren, mevcut Redis Stack’te RSALv2 veya SSPLv1 ile sunulan yeni veri tipleri ve işleme motorlarının varsayılan olarak dahil edilmesi planlanıyor
• Redis 8’in sunulmasından sonra ayrı Redis Stack derlemesine ihtiyaç kalmayacağı için Redis Stack için kullanım ömrü sonu süreci başlayacak

Değişikliğin arka planı ve Redis’in görüşü

• Redis, Redis Stack dağıtımındaki gelişmiş Redis modüllerinde zaten çift lisanslama uyguladığını ve Redis 6’dan bu yana redis.io indirmelerinin %50’den fazlasının Redis Stack’ten geldiğini belirtiyor
• Birden fazla dağıtımı aynı anda sürdürme yapısının, Redis’in gelecekteki geliştirme planlarıyla çeliştiğini düşünüyor
  • açık kaynak dağıtımı
  • source-available dağıtımı
  • şirket içi ve bulut platformlarına optimize edilmiş ticari yazılım
• Redis, büyük bulut hizmet sağlayıcılarının Redis’in yatırımlarını ve açık kaynak topluluğunu ticarileştirdiğini savunuyor
• Bu değişiklik, özellik açısından zengin ücretsiz yazılım ve kurumsal ürünlere yatırım yapmayı sürdürmek için ticari kullanımı yönetme amacı taşıyor
• Bu değişiklikle birlikte Redis, artık OSI tanımına göre açık kaynak değil

Kullanıcılar ve iş ortakları üzerindeki etkisi

• Redis’in mevcut açık kaynak sürümlerini veya yeni çift lisanslı sürümlerini dahili·kişisel amaçlarla kullanan son kullanıcılar etkilenmiyor
• Redis ile entegre çalışan istemci kütüphaneleri veya diğer entegrasyonları geliştiren iş ortakları için de bir değişiklik yok
• Redis’in sorumluluğundaki tüm Redis istemci kütüphaneleri açık kaynak lisanslı kalacak
• Mevcut Redis Enterprise müşterileri, ayrıca müzakere edilmiş lisans koşullarıyla teknolojiyi aldıkları için etkilenmiyor
• Redis Community Edition veya Enterprise’ı rekabetçi olmayan biçimde kullanan entegrasyon ve yönetilen hizmet ortakları, Redis ile ortaklıkları kapsamında çözüm geliştirmeye, işletmeye ve sunmaya devam edebilecek
• Partner Program, gelecekte Redis teknolojilerine, özelliklerine ve sürümlere özel erişim sağlayacak

Bulut hizmetleri ve rekabetçi ürün kısıtları

• Yeni lisanslar altında Redis barındırma hizmeti sunan bulut hizmet sağlayıcıları, Redis kaynak kodunu ücretsiz kullanamayacak
• Örneğin bir bulut hizmet sağlayıcısı, ancak Redis kod tabanının bakımından sorumlu olan Redis ile lisans koşullarında anlaşırsa Redis 7.4 sunabilecek
• Redis’in “rekabetçi sunum” tanımı; Redis kod tabanından türeyen, Redis’in ticari ürünlerinin işlevleriyle büyük ölçüde örtüşen ve üçüncü taraflara satılan ürünleri ifade ediyor
  • ücretli destek sözleşmeleriyle yapılan satışlar da buna dahil
  • Redis Enterprise Software veya Redis Cloud ile rekabet edecek biçimde Redis’i barındıran ya da içine gömen çözümler buna örnek gösteriliyor
• Redis’ten yararlansa da Redis’in kendisiyle doğrudan rekabet etmeyen çözümler etkilenmeyecek
• Belirli kullanım senaryolarına ilişkin sorular için [e-mail] adresine yönlendirme yapılıyor

RSALv2 ve SSPLv1 koşulları

• RSALv2, copyleft olmayan, izin verici nitelikte bir lisans olup yazılımı kullanma, kopyalama, dağıtma, sunma ve türev çalışmalar hazırlama haklarını veriyor
• RSALv2’nin iki temel kısıtı var
  • yazılım ticarileştirilemez veya yönetilen hizmet olarak başkalarına sunulamaz
  • lisans, telif hakkı ve diğer bildirimler kaldırılamaz ya da gizlenemez
• SSPLv1, AGPL tabanlıdır ve bir hizmet olarak sunulması durumunda hizmetin tamamının kaynak kodunun SSPL ile yayımlanmasını gerektirir
  • buna yönetim yazılımı, kullanıcı arayüzleri, API’ler, otomasyon yazılımı, izleme, yedekleme, depolama ve barındırma yazılımı dahildir
  • bu lisansın yayımlayıcısı MongoDB’dir
• SSPL ile lisanslanan yazılımın değiştirilmiş sürümleri başka bir lisansla yeniden dağıtılamaz
• Çift lisans yapısında RSALv2 seçilirse, üçüncü taraflara hizmet olarak işlev sunmamak gibi RSALv2 kısıtlarına uyulduğu sürece değişiklik ve yeniden dağıtım mümkündür

Mevcut BSD sürümleri ve güvenlik yamaları

• Lisans değişikliği geriye dönük uygulanmayacak
• Değişiklikten önceki tüm kaynak kodları ve sürümler BSD 3-Clause lisansı altında kalacak
• Kullanıcılar, ilgili lisans şartlarına uydukları sürece mevcut BSD sürümlerini süresiz olarak kullanmaya devam edebilecek
• Redis, Redis Community Edition sunulduğu sürece mevcut güvenlik politikası kapsamında ilgili sürümlere güvenlik güncellemeleri ve kritik hata düzeltmeleri sağlamayı sürdürmeyi planlıyor
• Mevcut BSD 3-Clause sürümleri için kritik güvenlik yamalarının geri taşınması, Redis Community Edition 9.0 yayınlanana kadar sağlanacak; sonrasındaki yamalar yeni çift lisansla sunulacak

İsimlendirme, katkılar ve kod karıştırma koşulları

• Redis 7.2 ve önceki sürümler Redis OSS olarak anılmaya devam edecek
• Redis 7.4’ten itibaren kamuya açık ve ücretsiz sunulan sürüm Redis Community Edition olarak adlandırılacak
• Ürün adlarında artık “Redis” veya “for Redis” kullanılamayacak, ancak ürün açıklamalarında Redis uyumlu veya legacy-Redis tabanlı olduğu belirtilebilecek
• Topluluk katkıları alınmaya devam edecek, ancak katkı incelemesi için Contributor License Agreement onayı gerekecek
• RSALv2 veya SSPLv1 kodu ile farklı lisanslı kodlar, her bileşenin kendi lisansını koruması ve GPL gibi güçlü copyleft kodlarla karıştırılmaması koşuluyla birlikte kullanılabilecek
• Kurum içinde Redis’i hizmet olarak barındırmak serbest; kurum tanımına bağlı şirketler ve iştirakler de dahil

[GN⁺]

Hacker News yorumları

• Bu, Hashicorp'un zorlanıp bir alıcı aramasına benzer şekilde Redis Labs'i de mahvetme ihtimali yüksek bir hamle ve Redis Labs'i kopyalamak isteyenleri de engelleyemeyecek gibi görünüyor.
  Asıl zarar görecek olanlar, hukuki baş ağrısı olmadan Redis önbelleği kullanmak isteyen küçük startup'lar. AWS Redis'i fork'layabilir; hatta bu fork'u izin verici bir lisansla yayımlarsa, Redis Labs lisans açısından daha kötü seçenek haline gelebilir.
  Zor bir tercih ama bence ya kodu kapalı tutmak ya da Apache veya MIT'ye bağlı kalmak daha iyi olurdu. Yolun ortasında lisans değiştirmek gerçekten kötü ve ters tepmeye mahkûm görünüyor.
  Açık kaynak, kullanıcıların yazılım üzerinde söz sahibi olabilmesini sağlar. Para kazanmak için hukuki numaralarla bunun etrafından dolaşmaya çalışırsanız, zarar gören büyük şirket ekipleri değil kullanıcılar olur. Redis her zaman izin verici bir açık kaynak projesiydi ve tam da bu yüzden başarılı oldu. Bu koşulu değiştirirseniz geleceğin hesabı da değişir ve ilgili herkes için kötü sonuçların habercisi olur.

  • Bu olay, uzun vadede şirketlerin açık kaynak kullanıcı ihtiyaçlarının iyi bir emanetçisi olabileceği fikrini neredeyse bitiriyor gibi.
    PostgreSQL gibi bir vakfın sahip olduğu yazılım ile şirketlerin sahip olduğu açık kaynak arasındaki farkı daha net görmemiz gerekiyor. “Hissedar değerini maksimize etmeye” odaklanınca, kullanıcı özgürlüklerini koruma hedefi eninde sonunda geri plana itilmek zorunda kalıyor.
    Redis topluluğu açısından Antirez'in istihdam ilişkisi ile proje sahipliğini ayırıp bunu kâr amacı gütmeyen bir yapıya bırakması çok daha iyi olurdu. Apache Redis benzeri bir yapı topluluk için daha iyi olurdu; Redis Labs de bunun etrafında kapalı uzantılar ve bulut işi kurabilirdi.
  • Zamanla bu görüşe katılır oldum ve bunu şöyle özetliyorum: hedef kâr ise çekirdek ürününüzü açık kaynak olarak yayımlamayın.
    Bir şirket çekirdek yazılımını izin verici bir lisansla yayımladığında, daha büyük bir rakibin gelip o yazılımı yeniden dağıtan bir çözümü sattığını defalarca gördük.
    Şirketin merkezi hedefi kârsa bu varoluşsal bir tehdit. Buna karşılık şirketin hedefi, kâr amacı gütmeyen bir yönetici olarak yazılımın varlığını sürdürmesini sağlamaksa bu büyük bir başarıdır.
    Bu mantık, çekirdek ürün olmayan yardımcı yazılımlar için geçerli değildir; örneğin doğrudan satıp para kazandığınız şey olmayan ama geliştirme sırasında ortaya çıkan faydalı araçlar gibi.
  • Açık kaynakta “siz yapın, biz satalım, teşekkürler” sorunu var.
    Bu lisans değişikliği tam da bu soruna, yani bulut hiper ölçekli şirketlerinin bedavacılık yapmasını engellemeye yönelik.
    Bana daha iyi bir AGPL gibi geliyor. Felsefi nüanslar ya da OSI onay listesi umurumda değil; sonuçta AGPL'den çok daha az kısıtlayıcı. Kaynak kodu var, yerelde çalıştırabiliyorum ve kendi projelerimde, ticari projelerde, işte, bare metal'de, VM'de, Docker'da, k8s'te, Azure'da aynı şekilde kullanabiliyorum.
    Microsoft'un zaten aldığı primin bir kısmını paylaşmak zorunda olması beni ilgilendirmiyor. Hatta sürdürülebilir bir iş modeli bulmuş olmaları alkışı hak ediyor.
  • “Açık kaynak, kullanıcının yazılım sahipliğidir” sözü yanlış.
    OSS geliştiricileri telif hakkını elinde tutar. Public domain hariç, lisansı ve koşulları değiştirebilen yalnızca yazardır. Kullanıcı, yazılım ve kodla çeşitli işler yapabilmek için bir lisans alır; sahiplik elde etmez.
  • “Para kazanmak için hukuki numaralarla etrafından dolaşmak” ifadesi enshittification kavramını akla getiriyor.
    Tamamen katılıyorum; Cory Doctorow'un argümanına bir örnek daha eklenmiş gibi geliyor.

• Şimdiye kadar bir fork’un çoktan başlamış olduğunu düşünüyorum. Bir şirketin kendi geliştirici topluluğuyla bağını kendi eliyle kopardığını görmek biraz üzücü
  Neden yaptıklarını anlıyorum ama bunun uzun vadede işe yarayacağını sanmıyorum
  Redis kullanıcılarının çoğu arkasındaki şirkete tek kuruş ödemedi; ben de ödemedim. Para kazanmak için bunu yapmalarını anlıyorum ama benim davranışım değişmeyecek. Sadece fork’u kullanacağım. Diğer Redis kullanıcılarının büyük çoğunluğu, dış katkıcılar ve Redis’i ticari olarak sunan tüm bulut sağlayıcıları da öyle yapacak; zamanla mevcut Redis çalışanlarının epey büyük bir kısmı da o tarafa geçebilir
  Ticari kullanıcı ve bulut sağlayıcı sayısı fazla olduğundan, bunların örgütlenmesi çok uzun sürmez gibi görünüyor. Zaten ödeme yapan kullanıcı çok olduğu için pratikte başka türlüsü pek mümkün değil
  Terraform, Elasticsearch, Red Hat gibi örneklerde de benzer emsaller var. Hedef kullanıcıların ve potansiyel müşterilerin kayda değer bir bölümünü açık kaynak fork’a bağımlı hâle getirmek, iş stratejisi olarak yanlış yön gibi görünüyor
  Oracle, Sun’ın mysql, hudson, openoffice gibi açık kaynak projelerini devraldığında da kontrolün büyük kısmını hızla kaybetti. Oracle’ın kapalı kaynak ürününü kullanmaya ikna etme girişimleri pek sonuç vermedi. Java bile sonunda bir ölçüde geri adım attı ve bugün merkezde openjdk var. Birkaç banka dışında Oracle JDK kullanan pek kimse yok. Buna gerek yok ve Oracle da uzun zaman önce bunun bir avantajı varmış gibi davranmayı bıraktı. Tüm geliştirme OpenJDK’da oluyor ve sertifikalı build sağlayan birden fazla şirket var
  Kişisel olarak Elasticsearch ve Opensearch danışmanlığı yapıyorum; son dönemde müşterilerin çoğu Opensearch’ü varsayılan olarak görüyor. Akış basitçe bu yönde. Herkes ücretsiz ve açık kaynak olan seçeneği seçiyor
  Sonuç tek: Mevcut Redis kullanıcılarının büyük çoğunluğunun kullanacağı bir Redis fork’u ortaya çıkacak

  • Microsoft 3 gün önce neredeyse drop-in replacement sayılabilecek bir alternatif yayımladı[1]. Redis istemcilerinin çoğuyla çalıştığını iddia ediyor. En azından Azure kullanıcıları için epey büyük bir değişim yaratacak gibi
    [1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
  • Uzun vadeli strateji, Broadcom tarzı bakış açısıyla bakılırsa işe yarayabilir. Çok sayıda kullanıcıyı elde tutmak yerine, sistemlerini ürünün etrafında kurmuş, çok pahalı az sayıda müşteriyi hedeflemek gibi
    Şirketler açısından, tamamen taşınmamak için ya da kısa vadede migrasyon sürecindeyken fiyat artışını sineye çekmek mümkün olabilir
    Kısa vadeli kopuşu önlemek için sağlayıcı “zaman satın alıp” fiyatı düşük tutabilir; proje fork’lardan yeterince farklılaşıp taşınma çok daha zor hâle geldiğinde de fiyatı artırabilir
    Her iki durumda da uzun vadede farklı ölçeklerde çok sayıda şirketi desteklemeyi sürdürmektense az sayıda şirketten büyük para kazanabilirler. Hoşuma gitmiyor ama çalışabilir gibi görünüyor
  • Zaten devam eden bir fork var: https://codeberg.org/redict/redict
  • Uzun vadede FOSS, sektörün bir dönemlik modası olarak görülüp bir daha tekrarlanmayabilir. Sektör, ücretsiz katmanlarda ya da kaynak kodunda tüm özellikleri sunmayan deneme ve demo sürümlerine geri dönme yönünde karar kılabilir
  • Alaycı bir açıdan bakarsak Oracle’ın zaten çok daha pahalı bir alternatifi olduğu için MySQL’i gelir odaklı hâle getirmesine gerek yoktu
    MySQL topluluğunu bölmek, kullanımı ve dış geliştirmeyi zayıflatmak, tüm projenin hızını düşürmek bile iyi bir yatırım getirisi sağlamış olabilir

• Bu projelerin büyük itici gücü hâlâ hosting geliri ve lisans değişiklikleri de bu yüzden oluyor
  Gidişata bakınca, projeyi sahibi olan şirkete uyan açık kaynak türü sanki yalnızca kütüphaneler gibi görünüyor. Bir program, örneğin veritabanı gibi sunucu yazılımıysa ya kaynak kodu açık ama lisansı kısıtlı olmalı ya da bir vakfın altında yer almalı. Zor bir konu ve cevabın ne olduğunu bilmiyorum
  Karmaşık programlara da izin verici açık kaynak lisanslarını geri getirecek bir model görmek isterdim ama henüz uygulanabilir bir yol görünmüyor. Belki marka hakkı uygulaması, açık kaynak kod ve yalnızca lisanslı build’ler sunma biçiminde olabilir
  Her hâlükârda popüler açık kaynak yazılımların yükselişini ve düşüşünü ya da lisans değişikliklerini görmeye devam edeceğiz. Geliştiriciler ve şirketler için başta açık kaynak olarak başlamanın avantajı çok büyük; sonradan değiştirme baskısı da çok büyük
  En azından Redis’in dünyaya verdiği değerin, aldığı değerden çok daha büyük olduğunu kabul etmek isterim. Aradaki fark gerçekten ezici
  Fork’un ne kadar hızlı çıkıp başarılı olacağı ve Redis adlı şirketin 5 yıl sonraki gelir büyüme eğrisinin nasıl görüneceği ilginç olacak

  • Sonuçta dev bulut sağlayıcılarının Redis gibi şirketlerin ekmeğini elinden aldığı bir yapı değil mi bu diye düşünüyorum
    Lisansları pek bilmiyorum ama temel teknolojiyi geliştiren küçük ve orta ölçekli şirketlerin oligopol niteliğindeki bulut devleri tarafından metalaştırılıp yüksek fiyatla yeniden satılması durumuna büyük ölçüde katılıyorum. Hatta bunun bu kadar uzun sürmüş olması şaşırtıcı
    Hem şirketlerin hem de açık kaynağın sağlıklı bir ekosistem istediğini varsayarsak, lisans değişikliği dışında hangi alternatifler olabilir merak ediyorum
  • Vakıfları bu sorunun sihirli çözümü olarak görmüyorum
    Tek bir şirketin vakfın dışına fiilen “fork” ederek çıkmaya karar verdiği çok sayıda örnek var ve topluluk sonuçta aynı akıbetle karşılaşıyor
  • “Karmaşık programlar için izin verici açık kaynak lisansı” derken AGPL3 gibi bir şey mi kastediliyor?
    https://spdx.org/licenses/AGPL-3.0-or-later.html
  • Geliştiricilerin de diğer mesleklerden farklı olmadığını kabul etmek faydalı olur. Kendi işi için ücret beklerken çalışma araçlarını yapan kişiye tek kuruş ödemek istemeyen tavır sürdürülebilir değil
    Çalışma araçlarını yapanların da faturalarını ödemesi gerekiyor
    Bir anlamda FOSS hayalinin başarısız olmasında geliştiricilerin kendilerinin de payı var
    Yavaş yavaş kamu malı ve shareware dönemine geri dönüyoruz
  • “Açık kaynak kod için yalnızca lisanslı build’ler sunmak” açık kaynak değildir

• İnsanlar açık kaynaktan para kazanma modelinin her zaman destek hizmetleri olduğunu söyledi. Örneğin bir şirket Postgres kullanıyorsa, şirket içi kurulumda bir uzmanın yardım etmesi ve arızaları gidermesi gibi.
  Ama “bulut” çağında şirketler yalnızca Amazon, Microsoft, Google vb. tarafından sunulan yönetilen hizmetleri kullanıyor ve projenin bakımcıları ile çevresindeki insanların finansal fırsatları fiilen ortadan kalkıyor. Kimse OSS için canını dişine takıp çalıştıktan sonra AWS’in hiçbir şey geri vermeden milyonlarca dolar kazandığını görmek istemez.

  • Açıklama: Amazon’da çalışıyorum ama Redis ile ilgili bulut hizmetlerinde doğrudan yer almıyorum. Açık kaynak program ofisine yakınım ve açık kaynak projelerinde işbirliği yapmak için gereken zor işi yapan insanlara çok değer veriyorum.
    Madelyn Olson, AWS’te çalışırken yıllar boyunca zorlu işler yaparak diğer Redis çekirdek geliştiricilerinin güvenini kazandı ve çekirdek bakımcısı oldu. O ve diğer AWS geliştiricileri Redis çekirdek motoruna çok katkıda bulundu. Onların da Redis topluluğu için çok çalıştığı söylenebilir.
    İlgili katkılar hakkında burada daha fazla okuyabilirsiniz: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...

• Daha fazla açık kaynak projesinin SSPL’yi benimsemesi ya da Llama 2 gibi ücretsiz kullanım için şirket ölçeğine sınır koyan yöntemleri denemesi gerekiyor. Örneğin açık kaynak olup, on milyarlarca dolarlık bulut devleri için geçerli olmaması gibi.
  Bireysel geliştiriciler katkı verirken AWS’in bedavacılığını mümkün kılmayı amaçlamıyordu.
  Projelerin daha kısıtlayıcı lisanslara yönelmesinin en büyük nedeni AWS. AWS’in yapması gereken doğru şey, asıl yazarın ya da şirketin emeğine saygı göstermek ve asıl geliştiricinin desteklediği ürünü güçlendirmekti. Bunun yerine AWS, bir OSS ürününün başarılı olduğunu gördüğünde rakip ürün çıkarıyor. Daha sıkı entegrasyon ve pazarlama gücü nedeniyle üçüncü taraf tedarikçilerin şansı olmuyor.
  Üstelik Amazon ve AWS, açık kaynağın büyük, belki de en büyük faydalanıcılarından biri olmasına rağmen neredeyse hiçbir şey geri vermiyor. Google, Microsoft, hatta Oracle bile açık kaynağa Amazon’dan daha fazla katkı sağlıyor.

  • SSPL ve AGPL sorun değil; ama haklarımı başkasına devretmemi sağlayan bir CLA yoksa.
    CLA’sı olan projelere hiç katkıda bulunmadım; işverenim para vermediği sürece bundan sonra da düşünmüyorum.
  • Geçmişte yapay zekanın kod yazmasını engelleyen bir FOSS lisansını savunmuştum. Kısıtlama getirdiği için FOSS olmadığı yönünde çok olumsuz tepki aldım. SSPL de aynı durumda.
    Ama FOSS’un uzun vadede yaşayabilirliği için, FOSS geliştiricilerini fiilen sömüren dev şirketlere karşı kendimizi korumak üzere kısıtlamalar gerekebilir.
  • AWS’in birçok OSS projesinin popüler hale gelmesinin önemli nedenlerinden biri olduğunu da unutmamak gerekir.
    Redis, Mongo, ES, HashiCorp ürün ailesi ve tüm büyük veri ekosistemi AWS’in sunması sayesinde daha geniş kitlelerce bilinir oldu. AWS ya da başka büyük bulut sağlayıcıları desteklemediği için hâlâ insanların bilmediği, yıllardır geliştirilen çok sayıda az bilinen veritabanı da var.
    Ayrıca serbest lisans sayesinde kullanım ve popülerlik arttıkça birçok proje hata raporu, PR, yama gibi katkılar aldı. SSPL, BSL türü lisanslara sahip olanlara pek katkıda bulunmak istemem. Çünkü daha sonra özgürce kullanamayacağım bir şeye zaman harcamak istemiyorum.
  • Redis’in tam olarak ücretsiz ve açık olduğu için büyüdüğünü unutuyorsunuz.
    Redis, Llama 2’ye benzer kısıtlamalarla çıksaydı en başından batardı. Ana tüketiciler şirketler ve Llama 2’nin popüler olmasının başlıca nedeni, bireylerin kişisel kullanım için kullanabileceği kaliteli bir LLM’i erken dönemde sunmasıydı.
    RESP ile uyumlu bir anahtar-değer deposu özellikle olağanüstü bir şey değil. Microsoft da az önce kendi uygulaması olan garnet’i MIT lisansıyla yayımladı. Redis’in değeri her zaman ücretsiz ve açık kaynak olması ile bunu ayakta tutan topluluktu. Şimdi Redis’i kullanmanın en büyük nedeni terk edilmiş oldu.
  • AWS bazı durumlarda asıl geliştirici tarafını da destekliyor. Yönetilen Grafana ve Prometheus’ta Grafana Labs ile işbirliği yapıyor.
    Ama bildiğim kadarıyla örnek fiilen bundan ibaret; MongoDB, Redis, Memcached, MySQL, PgSQL vb. neredeyse tüm diğer durumlarda böyle değil.

• Redis Inc., https://github.com/redis/redis/ projesini 3 maddeli BSD lisansından, OSI onayı almamış iki lisanslı ikili lisans modeline taşıyor.
  Daha önce “Redis core license 3-Clause-BSD ile lisanslanmıştır ve gelecekte de her zaman böyle kalacaktır” demişti. (https://redis.com/blog/redis-labs-modules-license-changes/)

  • Açık kaynak projesini geliştirmemiş, sadece benimsemiş şirketleri MBA’li CEO’ların ele geçirmesinin sonucu.

• Desteğin sona ermesi konusunda endişeliyseniz, Redis 7.4 yeni lisans altındaki ilk sürüm, 7.2 ise eski lisans altındaki son sürüm olacak.
  Redis belirli bir anda iki ek sürümü destekler: latest major.(minor-1), (major-1).(last-minor)
  Kabaca bu, 8.0 çıktığında 6.2 desteğinin sona ereceği; 7.6 veya 8.0 çıktığında da 7.2 desteğinin sona ereceği anlamına gelir.
  Geçmiş sürümlere bakılırsa 8.0’ın 2025 Mart-Mayıs civarında çıkması bekleniyor. Bu nedenle 3BSD lisansı altındaki Redis’e bağımlıysanız planınızı buna göre yapmalısınız.
  Ubuntu, redis’i universe deposunda paketlediği için güvenlik yükseltmeleri yalnızca Ubuntu Pro müşterilerine sunulur. Dolayısıyla Ubuntu 20.04’te, Ubuntu Pro’nun ESM kullanıcıları hariç, redis yükseltmeleri 2024 Nisan’da duracak.
  Debian 11/12, Redis 6.0/7.0’ı takip ettiği için 7.2 yamalarını backport etme sorumluluğu var. 7.2 güvenlik güncellemesi almaz ve bunlar yalnızca 7.4 dalında sağlanırsa bunun ne olacağı kesin değil.
  Doğrudan kullanım biçiminiz yeni lisansla uyumlu olsa bile dolaylı olarak etkilenebilirsiniz. Dağıtımların bir sonraki sürümde redis’i resmi depolardan çıkarma olasılığı yüksek olduğundan, bir sonraki dağıtım yükseltme döngüsünde bunu hesaba katmalısınız.
  (https://endoflife.date/redis sitesini sürdürüyorum; destek sonu ve desteğin nasıl etkileneceğini net bilen biri varsa PR’ını birleştirebilirim.)

• Yeni lisans SSPL, en azından kullanım alanı kısıtlaması nedeniyle büyük olasılıkla açık kaynak değildir: https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...

  • SSPL kesinlikle açık kaynak değildir ve 6. maddeyi ihlal eder.
    https://opensource.org/definition-annotated#6
    Açık kaynağın ve bir yönüyle özgür yazılımın özü tam da budur. Copyleft lisanslarda kısıtlamalar vardır, ancak bu kısıtlamalara uyarsanız o yazılımla istediğinizi yapabilirsiniz. SSPL, FSL, BUSL lisansları ise belirli ticari rekabet biçimlerini tamamen engeller.
    Çoğu iş modelinin copyleft’e uymak istememesi onu açık kaynak olmaktan çıkarmaz. Sadece o iş modeline uygun değildir.
  • “Muhtemelen” değil, düpedüz özgür olmayan bir lisans.
  • Bence bunlar için yeni bir terime ihtiyaç var.
    SSPL, BSL, FSL gibi yeni lisanslar giderek popülerleşiyor ve bunun anlaşılır nedenleri var. 20 yıl önce AWS’nin FOSS’u tüm dünyaya yeniden sattığı bir durum yoktu; koşullar bugünkünden çok farklıydı.
    Kısıtlamalar nedeniyle “açık kaynak” değiller, ama bir sonraki en yakın terim olan “kaynak kodu açık” da gerçeği iyi yansıtmıyor. Çünkü daha çok kaynak kodunun teknik olarak bir yerde mevcut olduğu anlamına geliyor.
    ElasticSearch, Sentry vb. hâlâ açık şekilde geliştiriliyor; projeyle ilgisi olmayan kişiler de PR gönderebiliyor ve projenin arkasındaki şirketle açıkça rekabet etmeye çalışmadığınız sürece herkes istediğini yapabiliyor.

• Aynı zamanda Microsoft, Garnet’i yayımladı: https://github.com/microsoft/garnet
  Zamanlama iyi.

  • Garnet ile ilgili HN tartışmasında biri MS ile asla işinin olmayacağını söylemişti.
    Mantığı, MS’in yem atıp gerektiğinde lisansı değiştireceği; bu yüzden her zaman açık kaynak lisansını koruyacak Redis’in daha iyi olduğu yönündeydi. Harika bir öngörüymüş.
  • Microsoft ve Azure bu değişiklikle tamamen hemfikir görünüyor: https://azure.microsoft.com/en-us/blog/redis-license-update-...
  • Bunun araştırma amaçlı bir ürün mü, yoksa üretim ortamı için mi olduğunu merak ediyorum.
  • Bu kadar kritik bir yazılımın neden C# veya Java gibi tüm runtime ve VM kurulumunu gerektiren dillerle yazıldığını anlamıyorum.

• Redis ve Hashicorp’un teknik kurucuları, şirketleri FOSS’tan uzaklaşıp büyük bir fırtınayla karşılaşmadan önce görevden ayrılmış sayılır. Zaman çizelgesi yanlış değilse durum bu.
  Bunu önceden bilip karşı mı çıktılar, yoksa biliyorlardı ama itibar darbesinden kaçınmak mı istediler merak ediyorum. Bu hamleye katılın ya da katılmayın, itibar kaybı var. Yoksa onlar ayrıldığı için mi değişiklik zorlanabildi?
  Tamamen spekülasyon, ama Hashi’de gördüğümüz şeyin Redis’te de tekrarlanıyor gibi görünmesi dikkat çekici.

  • Ayrılmadan önce bunu engelleyecek kadar etkileri olmuş olabilir.
    Hashi ile benzerlik benim de gözümden kaçmadı.
  • Daha olası olan, projeyi ya da şirketi epey uzun süre yürütmüş olmaları ve yeni, daha ilginç bir işe geçmek istemeleri olabilir. Ya da sadece nakde dönmek istemiş de olabilirler.