7 poin oleh xguru 2024-04-01 | 3 komentar | Bagikan ke WhatsApp

Mengapa SSPL buruk

  • SSPL(Server Side Public License) adalah lisensi yang mengerikan bagi semua pengguna, perusahaan, dan komunitas secara umum
  • Produk berlisensi SSPL bukan open source, bertujuan untuk membunuh pesaing di layanan cloud dan layanan terkelola, menaikkan harga hosting, dan membunuh open source
  • Tujuan SSPL mungkin lebih dekat pada mengembalikan uang kepada investor daripada melawan perusahaan-perusahaan besar

Apa itu SSPL

  • SSPL diperkenalkan pada 2008 oleh MongoDB, Inc sebagai lisensi untuk membatasi penggunaan MongoDB
  • Produk seperti Elasticsearch, Kibana, dan Graylog kini juga menggunakan lisensi SSPL
  • Menurut Pasal 13, jika Anda ingin menyediakan produk secara langsung kepada pelanggan, Anda harus menyediakan "kode sumber layanan" secara publik

Mengapa SSPL buruk bagi semua orang

  • SSPL dipresentasikan sebagai solusi yang baik untuk mencegah beberapa perusahaan cloud yang berniat buruk mengambil keuntungan tanpa berkontribusi kepada komunitas, tetapi pada kenyataannya ini adalah ancaman terhadap kebebasan dan lisensi yang membunuh pesaing
  • Lisensi ini tidak lebih dari mengurung produk yang dulunya open source ke dalam produk komersial sambil bersembunyi di balik semangat palsu "gratis". Mungkin sekarang kita harus menyebut perangkat lunak seperti ini sebagai perangkat lunak "Freemium"
  • MongoDB, Elasticsearch, Kibana, dan Graylog bukan lagi produk open source, dan perusahaan-perusahaan ini kini bisa sepenuhnya menentukan siapa yang boleh menawarkan produk mereka kepada pelanggan. Ini berarti membunuh pesaing
  • Mereka kini dapat menawarkan solusi hosting cloud mereka sendiri tanpa pesaing, tanpa membuka kode sumber, dan membunuh persaingan serta inovasi dengan biaya yang mereka tentukan sendiri
  • Bagi kita sebagai pelanggan, ini berarti kita tidak lagi punya kuasa untuk memilih penyedia cloud
  • Secara mekanis, harga hosting akan naik dan satu-satunya pilihan kita hanyalah memiliki tim khusus untuk mengelola bagian hosting di infrastruktur kita sendiri. Persis hal-hal yang selama beberapa tahun terakhir ingin kita hindari lewat solusi hosting cloud

Perusahaan yang menggunakan SSPL

  • Produk MongoDB telah menggunakan lisensi SSPL sejak 2018, dengan MongoDB, Inc berada di belakangnya
  • Produk Elasticsearch telah menggunakan lisensi SSPL sejak 2021, dengan Elastic NV berada di belakangnya
  • Produk Graylog telah menggunakan lisensi SSPL sejak 2020, dengan GrayLog, Inc. berada di belakangnya

Beberapa pertanyaan yang perlu kita ajukan kepada diri sendiri

  • Bagaimana perusahaan yang tidak lagi menggunakan open source bisa menuntut orang lain untuk "memberi kembali ke komunitas"?
  • Bagaimana perusahaan yang tidak membuka kode sumber layanan cloud mereka sendiri bisa menuntut orang lain untuk membuka kode sumber?
  • Bagaimana perusahaan bisa menyatakan bahwa open source adalah bagian dari DNA mereka sambil menggunakan lisensi non-open-source?
  • Dari lebih dari 3000 karyawan, berapa banyak yang membagikan pekerjaan dan kode sumber mereka kepada komunitas? (Spoiler: jauh lebih sedikit)
  • Apakah ini perusahaan teknologi yang ingin berbagi dengan komunitas, atau perusahaan penjualan yang ingin meningkatkan keuntungan investor?

Klaim yang keliru tentang SSPL

  • Klaim "Saya bukan penyedia cloud jadi ini tidak relevan" sebetulnya harus membuat semua orang sadar bahwa masalah ini relevan bagi semua pihak
  • Klaim "Perusahaan-perusahaan ini butuh uang untuk bertahan hidup" harus dipahami bahwa menghasilkan uang dari open source bukanlah hal yang buruk, tetapi SSPL bukan solusi yang tepat
  • Klaim "Pesaing masih ada. SSPL bisa dinegosiasikan" pada kenyataannya berarti perusahaan yang menguasai pasar dapat menentukan harga dan syarat bagi para pesaing
  • Klaim "SSPL adalah cara melawan pemain cloud besar, dan bagus untuk usaha kecil" harus menyadari bahwa SSPL pada kenyataannya bisa membuat pesaing kecil bangkrut dan menghilang

Saran untuk proyek open source

  • SSPL mungkin tampak seperti solusi yang baik pada awalnya, tetapi saya menyarankan agar tidak membuat kesalahan itu
  • Jika ada masalah dengan sebagian penyedia cloud, itu tidak bisa diabaikan dan kita semua harus melawannya bersama. Keluar dari dunia open source untuk bertarung bukanlah cara yang baik
  • Jika profitabilitas dibutuhkan, gunakan lisensi enterprise dan dukungan premium: "Jika Anda membutuhkan dukungan, kami memiliki tim terbaik untuk itu."
  • Gunakan lisensi copyleft agar perusahaan dapat memberi kembali kepada komunitas: "Jika Anda memodifikasi kode kami, bagikanlah kepada komunitas"
  • Jika Anda tetap memilih lisensi SSPL.. Anda akan:
    • kehilangan banyak kontributor independen dan kontributor dari karyawan perusahaan besar
    • mengkhianati para kontributor yang telah berusaha meningkatkan perangkat lunak open source
    • meninggalkan dunia open source dan mengembangkan perangkat lunak Freemium
    • mengaitkan produk Anda dengan citra yang sangat buruk
    • kehilangan manfaat dari banyak pemain berbeda yang membantu mempromosikan produk di seluruh dunia, sehingga kebutuhan akan dukungan premium meningkat

3 komentar

 
aer0700 2024-04-04

Karena ini open source, kita bisa memilihnya, tetapi karena ini juga open source, kadang ada juga yang justru mengeluarkannya dari daftar pilihan.
Lisensi ini mungkin muncul karena AWS mengambil MongoDB lalu membuat DynamoDB, jadi dari sudut pandang orang yang menyukai open source, wajar kalau terasa agak meragukan.

 
coremaker 2024-04-01

Akan menarik jika dibandingkan juga dengan AGPL.
https://sktelecom.github.io/guide/use/obligation/agpl-3.0/

 
xguru 2024-04-01

Sesuai domain dan nama situs SSPL is BAD, ini adalah situs web yang dibuat dengan tujuan tertentu.
Ada juga cukup banyak lompatan logika. Silakan lihat bersama pendapat di Hacker News berikut.

Pendapat Hacker News

  • Ada keberatan prinsipil terhadap SSPL, tetapi juga ada pemahaman terhadap latar belakangnya. Ada pula kritik bahwa penggambaran Pasal 13 lebih berniat sensasional daripada analisis objektif.

    • MongoDB dan Elastic tidak memperkirakan bahwa AWS akan mengemas ulang produk mereka sebagai layanan dan menjadi pesaing. Lisensi Apache yang digunakan Elasticsearch memang mengizinkan hal itu, tetapi ada pendapat bahwa secara etis hal tersebut seharusnya dicegah.
    • AWS sebenarnya bisa membentuk hubungan 'win-win' melalui kontrak OEM atau kemitraan, tetapi tidak melakukannya sehingga memicu bentuk pembatasan tidak menyenangkan seperti SSPL.
    • Ada keluhan bahwa SSPL dibuat untuk menyenangkan investor, tetapi meskipun perangkat lunak itu open source, perusahaan tersebut juga bukan bertujuan nirlaba, sehingga ada pendapat yang tidak memahami mengapa Elastic atau MongoDB disalahkan sementara AWS tidak.
  • SSPL dianggap buruk bagi pengguna, dengan klaim bahwa SSPL mendorong monopoli dan mengurangi partisipasi komunitas, yang pada akhirnya berdampak pada semua pengguna.

  • Wajar jika orang ingin menghasilkan uang, dan orang juga bisa memilih untuk tidak menggunakan proyek SSPL. Ada pandangan bahwa perangkat lunak yang dirilis dengan lisensi SSPL tetap lebih baik daripada tidak ada sama sekali.

  • Ekosistem saat ini sangat berbeda dibanding 10 tahun lalu, dan ada pendapat bahwa perusahaan kecil membutuhkan jalan untuk bertahan dalam persaingan dan bertumbuh. Lisensi seperti BSL (Business Source License) mungkin tidak sempurna, tetapi bisa dilihat sebagai upaya mencari jalan tengah yang sehat.

  • Ada pendapat bahwa aneh mengkritik SSPL tanpa menyebut AGPL. Ada pula sorotan terhadap orang-orang yang ingin menggunakan perangkat lunak bebas tetapi tidak ingin berkontribusi.

  • Ada pendapat bahwa kita tidak boleh condong ke satu sisi, melainkan harus melihat tiap kasus secara berbeda. SSPL bisa baik bagi sebagian perusahaan yang ingin bertahan melawan raksasa cloud, tetapi bisa buruk bagi sebagian perusahaan yang ingin memanfaatkan para kontributor.

  • Produk MongoDB, Elasticsearch, dan Graylog dilarang untuk ditawarkan langsung kepada pelanggan. Kata 'langsung' dalam SSPL membuka ruang perdebatan hukum, dan inilah salah satu hal yang dikhawatirkan orang.

  • FSL (Functional Source License) adalah lisensi alternatif yang baik karena otomatis berubah menjadi Apache 2.0 atau MIT setelah 2 tahun. Lisensi ini sederhana, membuka source, dan memberi cara yang masuk akal agar perusahaan SaaS tetap dapat beroperasi.

  • Ada koreksi terhadap informasi yang salah bahwa SSPL diperkenalkan pada 2008. Faktanya, lisensi ini diperkenalkan pada 2018.

  • Ada kritik terhadap pandangan yang terlalu satu dimensi tentang masa depan hak cipta.