- Liquibase telah beralih dari lisensi open source sebelumnya ke Functional Source License (FSL)
- Meski FSL bukan lisensi open source resmi menurut kriteria Open Source Initiative (OSI), muncul persoalan karena proyek ini masih diperkenalkan sebagai proyek open source di README dan tempat lain
- Di komunitas muncul pandangan yang saling bertentangan: ada yang menilai FSL melanggar kriteria resmi open source, sementara yang lain berpendapat FSL memenuhi persyaratan open source
- Di dalam proyek, perbaikan penyebutan open source di README sedang dikerjakan
- Ada kritik bahwa FSL berbenturan dengan sebagian ketentuan OSI Open Source Definition karena memuat klausul yang membatasi penggunaan kompetitif
Ringkasan isu
- Lisensi proyek Liquibase baru-baru ini diubah menjadi Functional Source License (FSL)
- Namun, di README.md dan dokumen resmi lain, Liquibase masih diperkenalkan sebagai proyek open source, sehingga memicu kebingungan dan perbedaan pendapat di komunitas
Isi laporan dan kontroversi
- Pembuat isu menyoroti bahwa meskipun Liquibase telah beralih ke FSL, proyek ini masih menyatakan dirinya sebagai open source, dan itulah pokok masalahnya
- Liquibase sendiri juga pernah menyebut bahwa FSL bukan lisensi open source
- Diminta agar istilah open source tidak lagi digunakan dalam dokumentasi proyek, termasuk README dan dokumen lainnya
Pendapat komunitas dan tokoh terkait
- Sebagian peserta berpendapat bahwa FSL memenuhi kriteria lisensi open source yang disetujui OSI, dan jika FSL lolos tinjauan resmi lalu menjadi lisensi yang disetujui OSI, maka tidak akan ada masalah
- Sebaliknya, peserta lain menegaskan bahwa karena adanya klausul seperti “tujuan yang diizinkan” dalam FSL, lisensi ini melanggar beberapa butir Open Source Definition milik OSI (pasal 1, 3, 5, dan 6)
- Ada juga pendapat yang menekankan pembedaan antara “Fair Source” dan “open source sejati”, serta menyatakan bahwa FSL seharusnya diklasifikasikan sebagai Fair Source
Proses penyelesaian isu dan revisi dokumen
- Kontributor proyek menanggapi persoalan ini dengan memperbarui README.md dan secara bertahap menghapus penyebutan open source
- Namun, di berbagai bagian repositori masih ada beberapa istilah seperti ‘open source’ dan ‘oss’, sehingga peninjauan dan perapian tambahan masih akan dilakukan
Definisi open source dan persoalan FSL (Functional Source License)
- Tokoh kubu open source seperti Richard Fontana dengan jelas menyatakan bahwa FSL melanggar OSI Open Source Definition karena klausul seperti larangan penggunaan kompetitif
- Definisi open source memuat ketentuan seperti “tidak boleh mendiskriminasi bidang usaha, individu, atau organisasi”, sehingga larangan penggunaan untuk tujuan kompetitif bertentangan dengan prinsip tersebut
- FSL akan beralih menjadi MIT atau Apache License setelah 2 tahun sehingga nantinya menjadi benar-benar open source, tetapi hingga saat itu syarat yang membatasi masih tetap ada
Kesimpulan dan situasi saat ini
- Isu ini mendorong diskusi soal transparansi komunitas dan hakikat open source dalam proses perbaikan pelabelan open source oleh Liquibase
- Revisi dokumen resmi seperti README telah dimulai, dan batas pembeda antara Fair Source dan open source turut dibahas melalui kasus nyata ini
- Terlepas dari apakah lisensi ini disetujui OSI atau tidak, syarat-syarat nyata dalam lisensi tersebut memiliki makna penting di komunitas open source internasional
1 komentar
Opini Hacker News
Kami mulai mencari alternatif untuk berjaga-jaga jika versi 4.x tak lagi bisa digunakan.
Saya paham perpindahan dari lisensi OSS ke model berbayar sebagai upaya seseorang menghasilkan uang dari perangkat lunak yang berguna.
Namun, mengubah lisensi dari open source terasa seperti taktik bait-and-switch.
Keputusan seperti ini langsung merusak kepercayaan, dan juga menghilangkan basis pengguna yang saat ini sulit dimonetisasi tetapi punya potensi jangka panjang.
Saya kira kita sudah mendapat pelajaran penting dari kasus Elastic dan TerraForm.
Flyway juga bisa menempuh jalan serupa kapan saja, jadi rasanya tingkat kepercayaannya ikut turun.
Kalau tidak ada fork, kami bahkan mempertimbangkan membuat sendiri library migration yang sesuai dengan kebutuhan produksi kami.
Kami memakai Liquibase semata karena nyaman, bukan karena tak tergantikan
Saya juga menganggap EventstoreDB(sekarang KurrentDB) dan NATS patut dicurigai dari sisi keandalan layanan.
EventstoreDB sudah mengganti lisensi, dan NATS hanya membatalkan rencananya karena penolakan pengguna.
Sekarang langkah seperti ini terasa sudah menjadi semacam strategi bisnis.
Keunggulan terbesar open source adalah kita selalu bisa mem-fork versi lama kapan saja dan tetap memakainya.
Menurut saya ini pada dasarnya tak berbeda dari sekadar menaikkan harga produk.
Memang khusus untuk Postgres, tetapi ada juga proyek bernama pgroll yang membawa otomatisasi ke tingkat berikutnya.
Selain Flyway (lisensi Apache), masih banyak lisensi yang benar-benar open source seperti Atlas (Apache) dan Sqitch (MIT).
Saya penasaran apakah perubahan lisensi Elastic benar-benar gagal dari sudut pandang mereka.
Harga sahamnya sempat turun untuk beberapa waktu, tetapi perusahaannya sendiri masih baik-baik saja.
Semua developer yang saya kenal di bidang pencarian dan RAG masih memakai Elasticsearch dari Elastic NV saja (bukan fork open source atau alternatif lain).
Khususnya jika hanya melihat pelanggan utama yang paling penting bagi Elastic (pelanggan berbayar), tampaknya ini bukan penghancuran kepercayaan, malah menghasilkan efek sebaliknya.
Pendapatan aktualnya juga tumbuh dua kali lipat dibanding 2020.
Ada yang masih mengklaim ini open source, tetapi Liquibase sendiri menyatakan bahwa FSL bukan lisensi open source.
Lihat pengumuman blog resmi Liquibase
Disayangkan belakangan ini banyak proyek yang hanya membuka source code sambil membangun branding seolah-olah open source.
Jika Liquibase memilih Apache alih-alih copyleft kuat (misalnya GNU AGPL), mereka seharusnya sejak awal mengantisipasi bahwa perusahaan lain akan membuat turunan closed source.
Pada akhirnya ini adalah pilihan Liquibase sendiri, jadi menurut saya tanggung jawabnya juga ada pada Liquibase.
Strukturnya tampak seperti otomatis beralih ke Apache setelah jangka waktu tertentu.
Saya sendiri belum yakin apakah itu lebih baik atau tidak.
Perusahaan sebenarnya bisa mencapai tujuan mereka dengan lisensi seperti AGPL.
Redis juga sudah beralih dan respons komunitasnya positif.
Saya rasa pengguna tidak akan keberatan jika Liquibase memilih model dual license AGPL.
Rasanya ini harus disebut "open source tertunda 2 tahun" atau "open source setelah 2 tahun".
Dalam praktiknya, menurut saya ini berarti "baru open source saat sudah tidak berguna".
Kalau modelnya seperti ini, intinya hanya memberi citra seolah menghormati kebebasan sejati, padahal kenyataannya tidak.
Jarang juga versi lama menjadi tidak berguna secepat itu.
Saya tidak melihat ini sebagai kurangnya penghormatan terhadap kebebasan saya.
Tujuannya adalah memberi beberapa batasan pada perusahaan (bukan individu).
Di ranah enterprise, menurut saya inti open source bukanlah 'kebebasan' melainkan kepercayaan dan transparansi.
Dengan sekadar membuka source code, manfaat FOSS tetap bisa dinikmati tanpa masalah hukum atau monetisasi.
Di internet ada kecenderungan kepercayaan yang terlalu buta terhadap model open source.
Kebijakan campuran 2 tahun juga menurut saya cukup masuk akal, dan kalau tidak mau lisensi baru ya pakai versi lama saja.
Open source yang ditunda, seperti kata bahasa Inggris 'late', punya makna ganda.
#source-washing
Jika belum familier dengan lisensi baru ini, lihat tautan penjelasan detail FSL
Tambahan konteks soal FSL: ini dibuat oleh Sentry; alasan lisensi ini diperlukan dan masalah apa yang ingin dipecahkan bisa dilihat di blog Sentry
Secara pribadi, satu-satunya lisensi closed source yang masih bisa saya terima adalah BuSL "Business Source License".
Setelah masa berlaku 4 tahun, lisensi ini pasti menjadi open source, dan sebelum itu source code tetap dibuka.
Ini juga mencegah proliferasi lisensi yang tidak perlu.
Wiki Business Source License juga layak dijadikan referensi.
Saya bertanya-tanya apakah periode 2 tahun itu tidak terlalu singkat.
Dari sudut pandang perusahaan besar, software berumur 5 tahun pun masih sangat layak dipakai, dan saya sendiri masih menganggap Redis versi 2012 atau Postgres versi 2020 sudah cukup baik.
Saya pernah merangkum sejarah kasus-kasus seperti ini beserta daftar perusahaannya.
Sudah saya susun di posting blog terkait, jadi kalau ada tambahan lain tolong dibagikan.
Fitur pro terus-menerus merusak sintaks versi komunitas, jadi saya merasa sama sekali tidak ada transparansi.
Tentu saja pekerjaan yang dilakukan memang perlu mendapat kompensasi yang layak, tetapi pola "kami dulu open source lalu diam-diam tidak lagi" makin lama makin umum.
Perubahan seperti ini selalu dilakukan diam-diam, seolah berharap tak ada yang menyadarinya.
Saya penasaran apa sebenarnya kerugian nyata atau masalah utamanya.
Malah saya suka adanya pembedaan antara bidang yang kompetitif dan yang tidak kompetitif.
Suasana komentar di sini terasa agak aneh.
Kebanyakan hanya melihat kata "base" lalu merekomendasikan layanan yang sama sekali tidak relevan, atau menganggap asal source code dibuka berarti open source.
Saya tidak tahu kalau Liquibase sudah mengubah lisensinya.
Sebenarnya hampir semua framework web punya alternatif, dan juga ada alternatif yang independen dari framework seperti Alembic dan Flyway.
Pada titik ini rasanya agak aneh.
Isu kali ini bisa menimbulkan masalah juga bagi proyek OSS seperti Keycloak.
Menurut kebijakan CNCF, lisensi yang bukan open source tidak boleh digunakan, jadi Keycloak tidak bisa memakai Liquibase.
Karena Debian, Fedora, dan lainnya juga punya persyaratan lisensi OSS, saya penasaran apakah proyek yang bergantung pada Liquibase bisa dimasukkan ke distribusi seperti itu.
Detail isu Keycloak
Namun, tetap bisa dimasukkan ke repo terpisah atau repo kustom seperti rpm fusion non-free.