2 poin oleh GN⁺ 2024-03-22 | 1 komentar | Bagikan ke WhatsApp
  • Mulai Redis 7.4, Redis menghentikan distribusi dengan BSD 3-Clause dan ke depannya menyediakan Redis di bawah RSALv2 atau SSPLv1, sehingga batasan lisensinya berubah secara signifikan
  • Kode sumber tetap tersedia gratis sebagai Redis Community Edition, tetapi lisensi baru ini bukan open source menurut definisi OSI
  • Redis berencana menggabungkan Core dan Stack, menyatukan pencarian, JSON, vektor, struktur data probabilistik, dan model data deret waktu dalam satu paket gratis
  • Penggunaan internal/pribadi, pustaka klien, mitra integrasi, dan pelanggan Redis Enterprise yang sudah ada tidak terdampak, tetapi layanan terkelola yang bersaing tidak dapat menggunakan kode sumber Redis baru secara gratis
  • Mulai Redis 8, fitur Redis Stack akan disertakan di dalam Redis itu sendiri, lalu Redis Stack build terpisah akan memasuki akhir masa pakai

Cakupan Perubahan Lisensi Redis

  • Semua versi Redis yang dirilis ke depannya akan didistribusikan dengan lisensi source-available
  • Mulai Redis 7.4, perangkat lunak Redis Core dapat digunakan dengan salah satu dari Redis Source Available License v2 atau Server Side Public License v1
  • Redis tidak lagi didistribusikan dengan lisensi BSD 3-Clause
  • Kode sumber Redis tetap tersedia gratis sebagai Redis Community Edition melalui repositori GitHub Redis
  • Baik RSALv2 maupun SSPLv1 bukan lisensi yang disetujui OSI, dan masing-masing memiliki pembatasan penggunaan

Integrasi Redis Stack dan Perubahan Susunan Produk

  • Rilis source-available mendatang akan mengintegrasikan Redis Core dan Redis Stack
  • Yang diintegrasikan mencakup pencarian, JSON, vektor, struktur data probabilistik, dan model data deret waktu
  • Semuanya akan tersedia sebagai satu paket unduhan gratis, dan Redis dapat digunakan untuk:
    • Penyimpanan key/value berkinerja tinggi
    • Penyimpanan dokumen
    • Mesin kueri
    • Basis data vektor berlatensi rendah untuk aplikasi AI generatif
  • Mulai Redis 8, tipe data dan mesin pemrosesan baru yang sebelumnya tersedia di Redis Stack dengan RSALv2 atau SSPLv1 direncanakan masuk ke fitur bawaan
  • Setelah Redis 8 tersedia, build Redis Stack terpisah tidak lagi diperlukan sehingga Redis Stack akan memasuki akhir masa pakai

Latar Belakang Perubahan dan Posisi Redis

  • Redis menyatakan bahwa modul Redis lanjutan dalam distribusi Redis Stack sudah menerapkan lisensi ganda, dan lebih dari 50% unduhan dari redis.io sejak Redis 6 berasal dari Redis Stack
  • Redis menilai struktur pemeliharaan beberapa distribusi sekaligus bertentangan dengan arah pengembangan Redis ke depan
    • Distribusi open source
    • Distribusi source-available
    • Perangkat lunak komersial yang dioptimalkan untuk platform on-premises dan cloud
  • Redis menilai penyedia layanan cloud besar mengkomersialisasi investasi Redis dan komunitas open source
  • Perubahan ini merupakan langkah untuk mengelola penggunaan komersial agar Redis dapat terus berinvestasi pada perangkat lunak gratis yang kaya fitur dan produk enterprise
  • Dengan perubahan ini, Redis tidak lagi open source menurut definisi OSI

Dampak bagi Pengguna dan Mitra

  • Pengguna akhir yang memakai versi open source Redis yang sudah ada atau rilis baru berlisensi ganda untuk penggunaan internal/pribadi tidak terdampak
  • Tidak ada perubahan bagi mitra yang membuat pustaka klien atau integrasi lain yang terhubung dengan Redis
  • Semua pustaka klien Redis yang menjadi tanggung jawab Redis akan tetap memakai lisensi open source
  • Pelanggan Redis Enterprise yang sudah ada tidak terdampak karena mereka menerima teknologi berdasarkan ketentuan lisensi yang dinegosiasikan secara terpisah
  • Mitra integrasi dan layanan terkelola yang memanfaatkan Redis Community Edition atau Enterprise dalam bentuk yang tidak bersaing dapat terus membangun, mengoperasikan, dan menyediakan solusi melalui kemitraan dengan Redis
  • Partner Program ke depannya akan menyediakan akses eksklusif ke teknologi, fitur, dan rilis Redis

Pembatasan untuk Layanan Cloud dan Produk Pesaing

  • Di bawah lisensi baru, penyedia layanan cloud yang menawarkan layanan hosting Redis tidak dapat menggunakan kode sumber Redis secara gratis
  • Misalnya, penyedia layanan cloud hanya dapat menawarkan Redis 7.4 setelah menyepakati ketentuan lisensi dengan Redis, pemelihara kode Redis
  • “Penawaran yang bersaing” menurut Redis berarti produk yang diturunkan dari basis kode Redis, memiliki tumpang tindih fungsi yang signifikan dengan produk komersial Redis, dan dijual kepada pihak ketiga
    • Termasuk penjualan melalui kontrak dukungan berbayar
    • Contohnya adalah meng-host atau menyematkan Redis dalam solusi yang dijual secara bersaing dengan Redis Enterprise Software atau Redis Cloud
  • Solusi yang menggunakan Redis tetapi tidak secara spesifik bersaing dengan Redis sendiri tidak terdampak
  • Pertanyaan untuk kasus penggunaan tertentu diarahkan ke redis_licensing@redis.com

Ketentuan RSALv2 dan SSPLv1

  • RSALv2 adalah lisensi permisif non-copyleft yang mengizinkan hak untuk menggunakan, menyalin, mendistribusikan, menyediakan, dan menyiapkan karya turunan dari perangkat lunak
  • Ada dua pembatasan utama dalam RSALv2
    • Tidak boleh mengomersialisasikan perangkat lunak atau menyediakannya kepada orang lain sebagai layanan terkelola
    • Tidak boleh menghapus atau menyembunyikan lisensi, hak cipta, atau pemberitahuan lainnya
  • SSPLv1 berbasis AGPL, dan jika perangkat lunak disediakan sebagai layanan, kode sumber dari keseluruhan layanan harus dibuka dengan SSPL
    • Ini mencakup perangkat lunak manajemen, antarmuka pengguna, API, perangkat lunak otomasi, pemantauan, pencadangan, penyimpanan, dan perangkat lunak hosting
    • MongoDB adalah penerbit lisensi ini
  • Versi modifikasi dari perangkat lunak berlisensi SSPL tidak dapat didistribusikan ulang dengan lisensi lain
  • Dalam lisensi ganda, jika memilih RSALv2, modifikasi dan redistribusi dimungkinkan selama mematuhi batasan RSALv2, seperti tidak menyediakan fungsinya sebagai layanan kepada pihak ketiga

Versi BSD Lama dan Patch Keamanan

  • Perubahan lisensi tidak berlaku surut
  • Semua kode sumber dan rilis sebelum perubahan tetap berada di bawah lisensi BSD 3-Clause
  • Pengguna dapat terus menggunakan versi BSD lama tanpa batas waktu selama mematuhi ketentuan lisensinya
  • Redis berencana terus menyediakan pembaruan keamanan dan perbaikan cacat penting untuk rilis tersebut sesuai kebijakan keamanan saat ini hingga Redis Community Edition tersedia
  • Backport patch keamanan penting untuk versi BSD 3-Clause lama akan disediakan hingga sebelum Redis Community Edition 9.0 dirilis; setelah itu patch akan disediakan dengan lisensi ganda baru

Nama, Kontribusi, dan Ketentuan Pencampuran Kode

  • Redis 7.2 dan rilis sebelumnya tetap disebut Redis OSS
  • Mulai Redis 7.4, versi yang tersedia secara publik dan gratis disebut Redis Community Edition
  • Nama produk tidak lagi boleh memakai “Redis” atau “for Redis”, tetapi deskripsi produk boleh menyatakan kompatibel dengan Redis atau berbasis legacy-Redis
  • Kontribusi komunitas tetap dapat diterima, tetapi persetujuan Contributor License Agreement diperlukan untuk peninjauan kontribusi
  • Kode RSALv2 atau SSPLv1 dapat digunakan bersama kode berlisensi lain selama setiap komponen mempertahankan lisensinya sendiri dan tidak dicampur dengan kode copyleft kuat seperti GPL
  • Meng-host Redis sebagai layanan di dalam organisasi diperbolehkan, dan organisasi mencakup afiliasi serta anak perusahaan

1 komentar

 
GN⁺ 2024-03-22
Pendapat di Hacker News
  • Ini kemungkinan besar akan merusak Redis Labs, seperti Hashicorp yang terdesak lalu mencari pembeli, dan sepertinya juga tidak akan mencegah pihak yang ingin meniru Redis Labs
    Yang benar-benar dirugikan adalah startup kecil yang ingin memakai cache Redis tanpa pusing urusan hukum. AWS bisa mem-fork Redis, dan kalau mereka malah merilis fork itu dengan lisensi permisif, Redis Labs bisa menjadi pilihan yang lebih buruk dari sisi lisensi
    Ini memang pilihan yang sulit, tetapi menurut saya lebih baik mempertahankan kode sebagai proprietary, atau tetap berpegang pada Apache atau MIT. Mengubah lisensi di tengah jalan itu benar-benar buruk dan tampak ditakdirkan menjadi bumerang
    Open source adalah soal memungkinkan pengguna memiliki software. Jika mencoba mengakalinya dengan trik hukum demi menghasilkan uang, yang terluka bukan tim perusahaan besar, melainkan para pengguna. Redis selalu menjadi proyek open source yang permisif, dan justru karena itulah ia berhasil. Jika syarat itu diubah, perhitungan ke depannya juga berubah, dan itu menandakan hasil buruk bagi semua pihak yang terkait

    • Peristiwa ini tampaknya hampir mengakhiri gagasan bahwa, dalam jangka panjang, perusahaan bisa menjadi pengelola yang baik bagi kebutuhan pengguna open source
      Kita perlu melihat lebih jelas perbedaan antara software yang dimiliki yayasan, seperti PostgreSQL, dan open source yang dimiliki perusahaan. Jika fokusnya adalah “memaksimalkan nilai pemegang saham”, tujuan menjaga kebebasan pengguna pada akhirnya pasti tersisih
      Dari sudut pandang komunitas Redis, akan jauh lebih baik jika Antirez memisahkan hubungan kerja dari kepemilikan proyek dan menyerahkannya ke pihak nirlaba. Bentuk seperti Apache Redis akan lebih baik bagi komunitas, dan Redis Labs juga bisa membangun ekstensi proprietary serta bisnis cloud di sekitarnya
    • Seiring waktu saya jadi setuju dengan sudut pandang ini, dan merumuskannya begini: jika tujuannya adalah laba, jangan merilis produk inti sebagai open source
      Kita terus melihat ketika sebuah perusahaan merilis software intinya dengan lisensi permisif, pesaing yang lebih besar datang lalu menjual solusi yang mendistribusikan ulang software itu
      Jika tujuan utama perusahaan adalah laba, ini merupakan ancaman eksistensial. Sebaliknya, jika tujuan perusahaan adalah menjadi pengelola nirlaba agar software itu terus ada, maka ini adalah keberhasilan besar
      Logika ini tidak berlaku untuk software pendukung yang bukan produk inti, misalnya alat berguna yang dibuat selama pengembangan tetapi bukan sesuatu yang dijual langsung untuk menghasilkan uang
    • Di open source ada masalah “kalian yang mengimplementasikan, kami yang menjualnya, terima kasih”
      Perubahan lisensi ini persis ditujukan untuk masalah itu, yaitu agar raksasa cloud tidak bisa menumpang gratis
      Bagi saya ini terdengar seperti AGPL yang lebih baik. Saya tidak peduli pada nuansa filosofis atau daftar persetujuan OSI; pada akhirnya ini jauh lebih tidak membatasi dibanding AGPL. Ada source code-nya, bisa dijalankan secara lokal, dan bisa dipakai dengan cara yang sama untuk proyek saya, proyek komersial, di tempat kerja, bare metal, VM, Docker, k8s, dan Azure
      Fakta bahwa Microsoft harus berbagi sebagian premi yang sudah mereka terima tidak ada hubungannya dengan saya. Justru mereka layak diapresiasi karena menemukan model bisnis yang berkelanjutan
    • Pernyataan “open source adalah kepemilikan pengguna atas software” itu keliru
      Pengembang OSS memegang hak cipta. Kecuali public domain, hanya penulislah yang bisa mengubah lisensi dan ketentuannya. Pengguna mendapatkan lisensi untuk melakukan berbagai hal dengan software dan kodenya, bukan mendapatkan kepemilikan
    • Ungkapan “mengakalinya dengan trik hukum demi menghasilkan uang” mengingatkan saya pada enshittification
      Saya sepenuhnya setuju, dan rasanya ini menambahkan satu lagi contoh pada argumen Cory Doctorow
  • Sepertinya saat ini fork sudah berlangsung. Agak menyedihkan melihat sebuah perusahaan memutus hubungan dengan komunitas developernya sendiri
    Saya mengerti alasannya, tetapi saya tidak melihat ini akan berhasil dalam jangka panjang
    Sebagian besar pengguna Redis tidak pernah membayar sepeser pun kepada perusahaan di baliknya, begitu juga saya. Saya paham mereka melakukan ini untuk menghasilkan uang, tetapi perilaku saya tidak akan berubah. Saya akan memakai fork saja. Begitu pula mayoritas pengguna Redis lainnya, kontributor eksternal, dan semua penyedia cloud yang selama ini menawarkan Redis secara komersial; seiring waktu, cukup banyak karyawan Redis saat ini juga bisa berpindah ke sana
    Karena ada banyak pengguna komersial dan penyedia cloud, sepertinya tidak akan butuh waktu lama bagi mereka untuk terorganisasi. Karena sudah ada banyak pengguna yang membayar, pada dasarnya memang harus begitu
    Sudah ada preseden serupa di Terraform, Elasticsearch, Red Hat, dan lainnya. Membuat banyak pengguna sasaran dan calon pelanggan bergantung pada fork open source tampak seperti arah yang keliru sebagai strategi bisnis
    Ketika Oracle mengambil proyek-proyek open source Sun, misalnya mysql, hudson, openoffice, dan sebagainya, mereka juga dengan cepat kehilangan sebagian besar kendali. Upaya meyakinkan orang untuk memakai produk tertutup Oracle tidak banyak membuahkan hasil. Bahkan Java pada akhirnya mundur sampai batas tertentu, dan pusatnya sekarang adalah openjdk. Selain beberapa bank, hampir tidak ada yang memakai Oracle JDK. Tidak perlu, dan Oracle pun sudah lama berhenti berpura-pura bahwa itu punya keunggulan. Semua pengembangan terjadi di OpenJDK, dan ada beberapa perusahaan yang menyediakan build tersertifikasi
    Secara pribadi saya melakukan konsultasi Elasticsearch dan Opensearch, dan belakangan sebagian besar klien menjadikan Opensearch sebagai default. Begitulah arusnya. Semua orang memilih opsi yang gratis sekaligus open source
    Kesimpulannya hanya satu. Akan dibuat fork Redis yang akan dipakai oleh mayoritas pengguna Redis saat ini

    • Microsoft tiga hari lalu merilis hampir sebuah pengganti drop-in[1]. Mereka mengklaim itu bekerja dengan sebagian besar klien Redis. Setidaknya bagi pengguna Azure, ini tampaknya akan membawa perubahan cukup besar
      [1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
    • Strategi jangka panjangnya mungkin bisa berhasil jika dilihat dari sudut pandang ala Broadcom. Bukan mengejar banyak pengguna, melainkan menargetkan segelintir pelanggan sangat mahal yang telah membangun sistem mereka di sekitar produk tersebut
      Dari sudut pandang perusahaan, mereka bisa menerima kenaikan harga agar tidak perlu migrasi sepenuhnya, atau selama masa migrasi dalam jangka pendek
      Untuk mencegah churn jangka pendek, penyedia bisa “membeli waktu” dengan menjaga harga tetap rendah, lalu menaikkannya setelah proyek cukup berbeda dari fork sehingga migrasi menjadi jauh lebih sulit
      Apa pun caranya, dalam jangka panjang mereka bisa menghasilkan banyak uang dari sedikit perusahaan ketimbang terus mendukung banyak perusahaan dengan berbagai ukuran. Saya tidak menyukainya, tetapi tampaknya bisa berjalan
    • Sudah ada fork yang sedang berjalan: https://codeberg.org/redict/redict
    • Dalam jangka panjang, FOSS bisa saja dianggap sebagai tren sesaat di industri dan tidak pernah terulang lagi. Industri mungkin akan menetap pada arah kembali ke versi trial dan demo yang tidak menyediakan seluruh fitur pada tier gratis atau dalam source code
    • Secara sinis, Oracle tidak perlu membuat MySQL berorientasi pendapatan karena mereka sudah punya alternatif yang jauh lebih mahal
      Dengan memecah komunitas MySQL, melemahkan penggunaan dan pengembangan eksternal, serta memperlambat keseluruhan proyek, mereka mungkin sudah mendapatkan return on investment yang bagus
  • Pendorong besar proyek-proyek seperti ini tetap pendapatan hosting, dan karena itulah perubahan lisensi terjadi
    Melihat arusnya, tampaknya open source yang cocok untuk perusahaan pemilik proyek hanyalah library. Jika berupa program, misalnya perangkat lunak server seperti database, maka ia harus menjadi source-available atau berada di bawah yayasan. Ini sulit dan saya tidak tahu apa jawabannya
    Saya ingin melihat model yang membuat lisensi open source permisif bisa kembali untuk program yang kompleks, tetapi belum terlihat cara yang layak dijalankan. Mungkin penegakan merek dagang, kode open source, dan hanya menyediakan build berlisensi
    Bagaimanapun, kita akan terus melihat naik-turun atau perubahan lisensi pada perangkat lunak open source populer. Manfaat bagi developer dan perusahaan untuk memulai sebagai open source terlalu besar, dan tekanan untuk mengubahnya kemudian juga terlalu besar
    Setidaknya saya ingin mengakui bahwa nilai yang diberikan Redis kepada dunia jauh lebih besar daripada nilai yang diambilnya. Selisihnya benar-benar sangat besar
    Akan menarik melihat seberapa cepat fork muncul dan berhasil, serta seperti apa kurva pertumbuhan pendapatan perusahaan Redis lima tahun dari sekarang

    • Pada akhirnya, bukankah strukturnya memang para penyedia cloud raksasa mengambil jatah makan siang perusahaan seperti Redis?
      Saya tidak begitu tahu soal lisensi, tetapi saya sangat bersimpati pada situasi ketika perusahaan kecil-menengah yang membuat teknologi dasar dikomoditisasi oleh raksasa cloud oligopolistis dan dijual kembali dengan harga tinggi. Justru mengejutkan bahwa ini butuh waktu selama ini
      Jika kita menginginkan ekosistem yang sehat bagi perusahaan maupun open source, saya penasaran alternatif apa selain perubahan lisensi
    • Saya tidak melihat yayasan sebagai solusi ajaib untuk masalah ini
      Ada banyak kasus ketika satu perusahaan secara efektif melakukan “fork” keluar dari yayasan, dan komunitas pada akhirnya menghadapi hasil yang sama
    • Yang dimaksud “lisensi open source permisif untuk program kompleks” apakah seperti AGPL3?
      https://spdx.org/licenses/AGPL-3.0-or-later.html
    • Akan membantu jika developer juga mengakui bahwa mereka tidak berbeda dari profesi lain. Sikap mengharapkan bayaran untuk pekerjaan sendiri tetapi tidak mau membayar sepeser pun kepada orang yang membuat alat kerja tidak bisa berkelanjutan
      Orang yang membuat alat kerja juga harus membayar tagihan
      Dalam satu arti, developer sendiri juga ikut bertanggung jawab atas gagalnya mimpi FOSS
      Kita perlahan kembali ke masa domain publik dan shareware
    • “Menyediakan hanya build berlisensi untuk kode open source” bukanlah open source
  • Orang-orang selalu mengatakan bahwa model menghasilkan uang dari open source adalah layanan dukungan. Misalnya, ketika sebuah perusahaan memakai Postgres, pakar membantu konfigurasi on-premises dan menangani gangguan
    Namun di era “cloud”, perusahaan cukup memakai layanan terkelola yang disediakan Amazon, Microsoft, Google, dan lainnya, sehingga peluang finansial bagi pemelihara proyek dan orang-orang di sekitarnya praktis menghilang. Tidak ada yang ingin melihat seseorang bekerja mati-matian di OSS lalu AWS meraup jutaan dolar tanpa memberikan apa pun kembali

    • Pengungkapan: Saya bekerja di Amazon, tetapi tidak terlibat langsung dengan layanan cloud terkait Redis. Saya dekat dengan kantor program open source, dan sangat menghargai orang-orang yang melakukan pekerjaan berat yang diperlukan untuk berkolaborasi dalam proyek open source
      Madelyn Olson, saat dipekerjakan AWS, selama bertahun-tahun melakukan pekerjaan berat hingga mendapatkan kepercayaan para developer inti Redis lainnya dan menjadi pemelihara inti. Ia dan developer AWS lainnya banyak berkontribusi pada engine inti Redis. Mereka juga bisa dikatakan telah bekerja keras untuk komunitas Redis
      Kontribusi terkait bisa dibaca lebih lanjut di sini: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...
  • Lebih banyak proyek open source perlu mengadopsi SSPL, atau bereksperimen dengan cara seperti Llama 2 yang membatasi ukuran perusahaan yang boleh menggunakannya secara gratis. Misalnya, tetap open source tetapi tidak berlaku untuk hyperscaler cloud bernilai puluhan miliar dolar
    Ketika developer individu berkontribusi, mereka tidak bermaksud memungkinkan AWS menumpang gratis
    Alasan terbesar proyek-proyek terdorong ke lisensi yang lebih restriktif adalah AWS. Hal benar yang seharusnya dilakukan AWS adalah menghormati karya penulis atau perusahaan asal, dan memperkuat produk yang didukung developer asal. Sebaliknya, ketika AWS melihat produk OSS sukses, mereka membuat produk pesaing. Karena integrasi yang lebih rapat dan kekuatan pemasaran, vendor pihak ketiga tidak punya peluang menang
    Selain itu, Amazon dan AWS adalah penerima manfaat besar—mungkin yang terbesar—dari open source, tetapi hampir tidak memberi kembali. Google, Microsoft, bahkan Oracle lebih banyak berkontribusi pada open source dibanding Amazon

    • SSPL dan AGPL tidak masalah, tetapi dengan syarat tidak ada CLA yang memaksa saya menyerahkan hak saya kepada orang lain
      Saya belum pernah berkontribusi ke proyek yang memiliki CLA, dan tidak berniat melakukannya kecuali pemberi kerja saya membayar saya untuk itu
    • Dulu saya pernah mengusulkan lisensi FOSS yang mencegah AI menulis kode. Banyak yang bereaksi negatif dengan mengatakan itu bukan FOSS karena memberlakukan pembatasan. SSPL juga sama
      Namun demi kelangsungan jangka panjang FOSS, kita mungkin perlu pembatasan untuk melindungi diri dari perusahaan raksasa yang pada dasarnya mengeksploitasi developer FOSS
    • Jangan lupa juga bahwa AWS adalah salah satu alasan besar banyak proyek OSS menjadi populer
      Redis, Mongo, ES, lini produk HashiCorp, dan seluruh ekosistem big data menjadi lebih dikenal luas melalui penawaran AWS. Ada juga banyak database kurang dikenal yang sudah dikembangkan bertahun-tahun tetapi masih tidak diketahui orang karena tidak didorong oleh AWS atau penyedia cloud besar lainnya
      Selain itu, berkat lisensi yang bebas, seiring meningkatnya penggunaan dan popularitas, banyak proyek menerima kontribusi seperti laporan bug, PR, dan patch. Saya tidak terlalu ingin berkontribusi pada sesuatu yang memakai lisensi keluarga SSPL atau BSL, karena saya tidak ingin membuang waktu untuk sesuatu yang nantinya tidak bisa digunakan secara bebas
    • Mereka lupa bahwa Redis tumbuh justru karena gratis dan terbuka
      Jika Redis sejak awal hadir dengan pembatasan mirip Llama 2, proyek itu akan gagal sejak start. Konsumen utamanya adalah perusahaan, dan alasan utama Llama 2 populer adalah karena sejak awal menyediakan LLM berkualitas tinggi yang bisa dipakai individu untuk keperluan pribadi
      Penyimpanan key-value yang kompatibel dengan RESP bukan sesuatu yang sangat istimewa. Microsoft juga baru saja merilis implementasinya sendiri, garnet, dengan lisensi MIT. Nilai Redis selalu ada pada fakta bahwa ia gratis dan open source, serta komunitas yang menopangnya. Sekarang mereka pada dasarnya membuang alasan terbesar untuk memakai Redis
    • Dalam beberapa kasus, AWS memang mendukung pihak developer asli. Managed Grafana dan Prometheus bekerja sama dengan Grafana Labs
      Namun sejauh yang saya tahu, praktis hanya itu contohnya; hampir semua kasus lain seperti MongoDB, Redis, Memcached, MySQL, PgSQL, dan sebagainya tidak begitu
  • Redis Inc. sedang memindahkan proyek https://github.com/redis/redis/ dari lisensi BSD 3-Clause ke lisensi ganda dengan dua lisensi yang tidak disetujui OSI
    Sebelumnya mereka pernah mengatakan bahwa “Redis core license dilisensikan di bawah 3-Clause-BSD dan akan selalu begitu.” (https://redis.com/blog/redis-labs-modules-license-changes/)

    • Ini akibat perusahaan yang bukan mengembangkan proyek open source, melainkan mengadopsinya, dikuasai oleh CEO bergelar MBA
  • Jika khawatir tentang berakhirnya dukungan, Redis 7.4 akan menjadi rilis pertama di bawah lisensi baru, dan 7.2 menjadi rilis terakhir dengan lisensi lama.
    Redis mendukung 2 rilis tambahan pada titik waktu tertentu: latest major.(minor-1), (major-1).(last-minor)
    Secara kasar, ini berarti dukungan 6.2 akan berakhir saat 8.0 keluar, dan dukungan 7.2 akan berakhir saat 7.6 atau 8.0 keluar.
    Melihat rilis sebelumnya, 8.0 diperkirakan akan keluar sekitar Maret–Mei 2025. Jadi jika Anda bergantung pada Redis di bawah lisensi 3BSD, Anda perlu membuat rencana sesuai dengan itu.
    Ubuntu mengemas redis di repositori universe, sehingga upgrade keamanan hanya disediakan untuk pelanggan Ubuntu Pro. Jadi, di Ubuntu 20.04, upgrade redis akan berhenti pada April 2024 kecuali untuk pengguna ESM Ubuntu Pro.
    Debian 11/12 mengikuti Redis 6.0/7.0, sehingga bertanggung jawab untuk melakukan backport patch dari 7.2. Jika 7.2 tidak menerima pembaruan keamanan dan pembaruan hanya tersedia di branch 7.4, belum jelas bagaimana hasilnya nanti.
    Walaupun cara penggunaan langsung Anda sesuai dengan lisensi baru, Anda bisa terdampak secara tidak langsung. Karena besar kemungkinan distro akan mengecualikan redis dari repositori resmi pada rilis berikutnya, hal ini perlu dipertimbangkan dalam siklus upgrade distro berikutnya.
    (Saya memelihara https://endoflife.date/redis, jadi jika ada yang tahu dengan jelas dampaknya terhadap akhir dukungan dan dukungan, saya bisa merge PR)

  • Lisensi baru, SSPL, kemungkinan besar bukan open source setidaknya karena pembatasan bidang penggunaan: https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...

    • SSPL jelas bukan open source, dan melanggar klausul 6.
      https://opensource.org/definition-annotated#6
      Di sinilah inti dari open source, dan dalam beberapa hal juga perangkat lunak bebas. Lisensi copyleft memang punya batasan, tetapi selama Anda mematuhi batasan itu, Anda bisa membuat apa pun yang Anda inginkan dengan perangkat lunak tersebut. Lisensi SSPL, FSL, dan BUSL sepenuhnya mencegah persaingan dalam cara komersial tertentu.
      Fakta bahwa sebagian besar model bisnis tidak ingin mengikuti copyleft bukan berarti copyleft bukan open source. Itu hanya berarti tidak cocok untuk model bisnis tersebut.
    • Bukan “mungkin”, melainkan jelas lisensi tidak bebas.
    • Saya rasa kita butuh istilah baru untuk hal-hal seperti ini.
      Lisensi baru seperti SSPL, BSL, dan FSL makin populer, dan ada alasan yang cukup masuk akal. 20 tahun lalu belum ada situasi AWS menjual kembali FOSS ke seluruh dunia, jadi kondisinya sangat berbeda dengan sekarang.
      Karena pembatasannya, ini bukan “open source”, tetapi istilah terdekat berikutnya, “source-available”, juga tidak benar-benar mencerminkan kenyataan. Istilah itu lebih terasa berarti kode sumber secara teknis ada di suatu tempat saja.
      ElasticSearch, Sentry, dan lainnya masih dikembangkan secara terbuka, orang yang tidak terkait dengan proyek pun bisa mengirim PR, dan siapa pun bisa melakukan apa yang mereka inginkan selama tidak mencoba bersaing secara terbuka dengan perusahaan di balik proyek tersebut.
  • Pada saat yang sama Microsoft merilis Garnet: https://github.com/microsoft/garnet
    Timing-nya bagus.

    • Dalam diskusi HN tentang Garnet, ada seseorang yang mengatakan tidak akan pernah mau berurusan dengan MS.
      Logikanya adalah MS akan memberi umpan lalu mengubah lisensi saat dibutuhkan, sehingga Redis, yang akan selalu mempertahankan lisensi open source, lebih baik. Prediksi yang luar biasa.
    • Microsoft dan Azure tampaknya sepenuhnya setuju dengan perubahan ini: https://azure.microsoft.com/en-us/blog/redis-license-update-...
    • Saya penasaran apakah ini produk untuk riset atau untuk lingkungan produksi.
    • Saya tidak mengerti mengapa perangkat lunak sepenting ini ditulis dalam bahasa seperti C# atau Java yang memerlukan instalasi seluruh runtime dan VM.
  • Para founder teknis Redis dan Hashicorp masing-masing mundur sebelum perusahaan mereka menjauh dari FOSS dan menghadapi badai besar. Dengan catatan, kalau jadwalnya tidak keliru.
    Saya penasaran apakah mereka sudah tahu hal ini sebelumnya dan menentangnya, atau sudah tahu tetapi ingin menghindari pukulan reputasi. Setuju atau tidak dengan langkah ini, tetap ada kerusakan reputasi. Atau justru karena mereka pergi, perubahan ini bisa dipaksakan?
    Ini sepenuhnya spekulasi, tetapi terasa mencolok karena apa yang saya lihat di Hashi sepertinya terulang di Redis.

    • Bisa jadi sebelum mereka pergi, mereka punya pengaruh yang cukup untuk menghentikannya.
      Kemiripan dengan Hashi juga tidak luput dari perhatian saya.
    • Yang lebih masuk akal mungkin mereka memang sudah cukup lama menjalankan proyek atau perusahaan, lalu ingin pindah ke hal baru yang lebih menarik. Atau mungkin mereka hanya ingin mencairkan kepemilikan mereka.