GPL vs MIT vs Apache: Kewajiban Tiap Lisensi

GPL vs MIT vs Apache: kewajiban setiap lisensi

GPL, MIT, dan Apache 2.0 menjawab pertanyaan yang sama dengan cara berbeda: apa yang wajib Anda berikan kepada orang lain ketika mendistribusikan software? MIT hanya mewajibkan pencantuman pemberitahuan hak cipta. Apache 2.0 mewajibkan pemberitahuan tersebut serta kesepakatan paten antara semua pihak yang menyentuh kode. GPL mewajibkan Anda memublikasikan source code dari hasil pengembangan Anda berdasarkan lisensi yang sama dengan lisensi yang Anda terima.

Hal ini tampak seperti persoalan untuk pengacara sampai suatu hari project yang Anda jalankan mengubah lisensinya dan terpecah menjadi dua. Setelah itu, persoalannya menjadi bagian dari operasi. Anda harus memilih antara dua package repository, sementara client library tidak lagi dapat saling berkomunikasi. Panduan ini membahas lisensi dan mekanismenya, bukan gerakan yang melahirkannya. Karena itu, setiap bagian berakhir pada dampaknya bagi Anda: orang yang harus menjalankan upgrade.

Mengapa GPL ada: printer yang tidak boleh diperbaiki siapa pun

Sekitar 1980, MIT Artificial Intelligence Lab menerima printer laser Xerox 9700. Lab tersebut telah menambal perangkat lunak untuk printer sebelumnya agar printer itu memberi tahu ketika pekerjaan cetak macet. Untuk printer baru itu, tidak ada source code, dan permintaan untuk mendapatkannya ditolak karena adanya perjanjian nondisclosure. Richard Stallman, yang saat itu merupakan programmer di lab tersebut, menganggap penolakan itu sebagai kondisi umum, bukan sekadar masalah sementara, lalu mengumumkan proyek GNU pada 27 September 1983.

Copyleft dibangun berdasarkan hukum hak cipta, bukan menentangnya. Secara default, Anda sama sekali tidak berhak menyalin code milik orang lain. GPL memberikan hak tersebut dengan syarat: jika Anda memberikan program itu kepada orang lain, Anda harus memberikan source code kepada mereka dengan ketentuan yang sama, sehingga mereka dapat melakukan hal yang tidak dapat dilakukan lab tersebut. Syarat ini dapat ditegakkan karena tanpa lisensi, sejak awal Anda tidak memiliki izin untuk menyalinnya.

Stallman pertama-tama menulis lisensi untuk GNU Emacs, lalu menggeneralisasikannya menjadi GPL version 1 pada 25 February 1989. GPL version 2 menyusul pada June 1991, dan lisensi tersebut masih digunakan oleh sebagian besar system software yang Anda jalankan. Lesser GPL dibuat untuk library, sehingga library copyleft dapat ditautkan oleh program dengan lisensi apa pun tanpa membuat program tersebut tunduk pada GPL.

Satu hal menentukan cara GPL memengaruhi self-hoster. Kewajiban tersebut berlaku saat distribusi, bukan saat penggunaan. Anda dapat memodifikasi program GPL, menjalankannya pada server milik sendiri, dan menyediakan layanan kepada publik, tanpa berkewajiban memberikan apa pun kepada siapa pun, karena Anda tidak pernah menyerahkan salinan program. Celah inilah yang menjadi alasan AGPL ada.

Tradisi permisif: BSD, kemudian MIT

Berkeley mengambil jalur yang berbeda. Computer Systems Research Group merilis karya Unix-nya berdasarkan lisensi yang mewajibkan pemberitahuan hak cipta tetap dicantumkan dan meniadakan semua jaminan. Versi asli memiliki empat klausul. Klausul keempat, yaitu klausul iklan, mewajibkan pencantuman pengakuan kepada University dalam semua materi iklan yang menyebutkan fitur perangkat lunak tersebut. Ketentuan ini tidak dapat diskalakan. Stallman menghitung 75 pengakuan terpisah dalam versi NetBSD tahun 1997. UC Berkeley mencabut klausul tersebut pada 22 July 1999 melalui surat dari William Hoskins dari Office of Technology Licensing.

Yang tersisa adalah lisensi BSD 3-klausul, yang menambahkan larangan menggunakan nama kontributor untuk mendukung produk Anda, serta versi 2-klausul yang menghapus ketentuan tersebut. Teks lisensi MIT berasal dari MIT pada 1980-an. Saat itu, lisensi tersebut digunakan untuk X Window System. Dalam praktiknya, lisensi ini memiliki fungsi yang sama dengan BSD 2-klausul.

Motifnya berbeda. Sebuah universitas yang didanai dengan uang publik ingin karyanya digunakan di mana-mana, termasuk oleh perusahaan. Proyek GNU menginginkan commons yang tidak dapat ditutup. Kedua posisi ini jujur, dan keduanya memiliki mode kegagalan. Kode permisif dapat diambil menjadi milik privat sehingga Anda tidak menerima apa pun sebagai imbalan. Kode copyleft ditolak oleh perusahaan yang pengacaranya tidak menerima ketentuan tersebut.

Ada pelajaran kedua dari Berkeley, dan inilah hal yang terus dibahas dalam tulisan ini. AT&T's Unix System Laboratories menggugat Berkeley Software Design pada 1992 terkait kode BSD, dan perkara tersebut diselesaikan pada awal 1994. Selama dua tahun, tidak ada yang dapat memastikan bahwa BSD aman untuk dijadikan fondasi. Adopsi pun terhenti sementara Linux berkembang. Ketidakpastian hukum menghentikan adopsi lebih cepat daripada ketiadaan suatu fitur.

Mengapa Apache 2.0 menambahkan pemberian lisensi paten

Lisensi pertama Apache Group merupakan turunan BSD 4-klausul yang memiliki masalah iklan yang sama. Versi 1.1, pada 2000, menghapus klausul tersebut. Versi 2.0, yang diterbitkan pada Januari 2004, merupakan penulisan ulang, bukan sekadar tambalan.

Penambahan yang penting adalah paten. MIT dan BSD sama sekali tidak mengatur paten. Kontributor dapat memberikan izin hak cipta yang jelas atas kodenya, tetapi tetap memiliki paten yang mencakup fungsi kode tersebut, lalu menggugat orang yang menggunakannya. Apache 2.0 menutup celah ini: setiap kontributor memberikan lisensi paten yang mencakup kontribusinya, dan siapa pun yang menggugat dengan alasan karya tersebut melanggar patennya akan kehilangan lisensi patennya sendiri atas karya tersebut. Ancaman ini berlaku timbal balik, sehingga dalam praktiknya tidak ada pihak yang mengajukan gugatan.

Bagian lain dari 2.0 bersifat administratif, dan itulah alasan perusahaan menyukainya. Terdapat file NOTICE yang ditentukan, sehingga atribusi memiliki satu tempat, bukan tersebar di seluruh pohon sumber. Lisensi dapat diterapkan melalui rujukan, bukan ditempelkan pada setiap file sumber. Kontribusi dicakup oleh ketentuan yang eksplisit. Merek dagang tidak termasuk. Dalam peninjauan hukum terhadap dependensi Apache 2.0, setiap pertanyaan yang perlu diajukan sudah dijawab dalam teks lisensi, sehingga persetujuan menjadi prosedur rutin. Itulah sebagian besar makna dari "default perusahaan".

Perubahan dalam GPLv3 dan alasan Linux tetap menggunakan GPLv2

TiVo merilis perekam video yang menjalankan Linux dan memublikasikan kode sumber kernel, tepat seperti yang diwajibkan GPLv2. Perangkat keras tersebut kemudian memeriksa tanda tangan kriptografis saat boot dan menolak menjalankan kernel yang tidak dikenalnya. Anda dapat membaca kode sumber, mengubahnya, dan mengompilasinya. Namun, Anda tidak dapat menjalankannya pada perangkat asalnya. Ketentuan lisensi secara harfiah dipenuhi, tetapi tujuannya digagalkan. Praktik ini kemudian dikenal sebagai tivoisation.

GPL versi 3, yang diterbitkan pada 29 June 2007, menjawab masalah ini secara langsung. Jika Anda mendistribusikan biner di dalam perangkat konsumen, Anda juga harus menyediakan "Installation Information": kunci atau petunjuk yang diperlukan untuk memasang versi yang telah dimodifikasi dan membuatnya berjalan. Versi 3 juga menambahkan pemberian paten secara eksplisit, ketentuan yang disusun sebagai tanggapan terhadap perjanjian paten Microsoft dan Novell pada November 2006, serta kompatibilitas satu arah dengan Apache 2.0.

Linux tidak mengikuti perubahan tersebut. Kernel hanya menggunakan GPL versi 2, tanpa klausul pengecualian "or any later version", dan berkas COPYING menyatakan hal itu. Linus Torvalds secara terbuka menentang ketentuan anti-tivoisation untuk perangkat keras bertanda tangan. Hambatan praktisnya lebih besar daripada perbedaan pendapat tersebut: kernel memiliki ribuan pemegang hak cipta, sehingga tidak ada pihak yang dapat mengumpulkan izin yang diperlukan untuk mengganti lisensi, bahkan jika semua pihak menginginkannya. Fakta tunggal ini merupakan perlindungan terkuat yang dapat dimiliki sebuah proyek. Hal ini perlu diingat ketika Anda menilai proyek yang dimiliki oleh satu perusahaan.

Lisensi lain dari tahun 2007 lebih penting bagi Anda. GNU Affero GPL versi 3, yang diterbitkan pada November pada tahun yang sama, memperluas kewajiban penyediaan kode sumber kepada orang yang berinteraksi dengan program melalui jaringan. Jika Anda menjalankan service AGPL yang telah dimodifikasi untuk publik, Anda wajib menyediakan kode sumbernya kepada pengguna tersebut. Inilah alasan begitu banyak software web self-hosted menggunakan AGPL. Nextcloud adalah salah satu contohnya. Jika Anda membandingkan alternatif self-hosted untuk Nextcloud, baris lisensi di repository setiap kandidat memberi tahu Anda lebih banyak tentang lima tahun berikutnya daripada daftar fiturnya.

Lisensi apa saja yang sebenarnya dapat Anda gabungkan?

Kompatibilitas berjalan satu arah, dari lisensi permisif menuju copyleft.

• Kode MIT dan BSD dapat dimasukkan ke produk apa pun, termasuk produk tertutup.
• Kode Apache 2.0 dapat disertakan dalam proyek GPLv3, dan karya gabungannya menggunakan GPLv3.
• Kode Apache 2.0 tidak dapat disertakan dalam proyek yang hanya menggunakan GPLv2. Ketentuan penghentian paten dan ganti ruginya merupakan persyaratan tambahan yang tidak mengizinkan GPLv2 untuk ditambahkan. FSF dan ASF sama-sama menerbitkan kesimpulan ini.
• Anda tidak dapat memindahkan kode GPL ke lisensi permisif. Hanya pemegang hak cipta yang dapat melakukannya. Hal ini membawa Anda kembali pada pertanyaan tentang siapa saja pemegang hak cipta tersebut.

Era relicensing: SSPL, BUSL, dan apa yang bukan termasuk di dalamnya

Pemicu utamanya adalah kepentingan komersial. Sebuah perusahaan memiliki hak cipta atas suatu produk, penyedia cloud menjualnya sebagai layanan terkelola dalam skala besar dan hanya memberikan sedikit kontribusi balik, lalu perusahaan tersebut mengubah lisensinya untuk menghentikan praktik itu. Redis Labs mengambil langkah yang paling terlihat pada Agustus 2018 dengan menambahkan Commons Clause di atas Apache 2.0 untuk beberapa modulnya. MongoDB menyusul pada 16 October 2018 dengan beralih dari AGPLv3 ke Server Side Public License.

SSPL adalah AGPL dengan satu bagian yang ditulis ulang. Jika Anda menawarkan program tersebut kepada pihak ketiga sebagai layanan, Anda harus memublikasikan source code dari semua yang Anda gunakan untuk menawarkan layanan itu, termasuk software pengelolaan dan orkestrasi di sekitarnya. Batas kewajiban tersebut tidak jelas, dan belum pernah diuji di pengadilan. OSI tidak pernah menyetujui lisensi ini, dan MongoDB menarik permohonannya pada Maret 2019. Debian telah menyatakan pada Desember 2018 bahwa software SSPL tidak termasuk dalam arsipnya, dan Fedora memutuskan pada Januari 2019 bahwa lisensi tersebut bukan lisensi bebas. Setelah itu, Red Hat menghapus MongoDB dari Fedora dan Red Hat Enterprise Linux. Itulah dampak mekanis dari relicensing: distribusi berhenti mengemas software tersebut, sehingga pembaruan Anda kini berasal dari repositori vendor sesuai jadwal vendor.

Business Source License adalah mekanisme yang berbeda. Lisensi ini berasal dari pendiri MariaDB, dan versi 1.1 diterbitkan pada 2017. Lisensi ini bukan copyleft dan bukan open source. Source code tersedia untuk publik, dan penggunaannya gratis kecuali untuk penggunaan yang dikecualikan vendor. Biasanya, pengecualian tersebut adalah menjalankan layanan hosted yang bersaing. Setiap release otomatis beralih ke lisensi open source yang sebenarnya pada tanggal perubahan, paling lambat empat tahun setelah release tersebut. Lisensi tujuan perubahan itu harus kompatibel dengan GPLv2. HashiCorp memindahkan Terraform dan produk lainnya ke BUSL 1.1 pada 10 August 2023. Outline juga menggunakannya. Hal ini perlu diketahui jika Anda memilih dari alternatif Notion yang dapat di-self-host: menjalankannya untuk tim Anda sendiri diperbolehkan, tetapi membangun layanan di atasnya tidak diperbolehkan.

Tidak ada dari kedua lisensi tersebut yang tidak jujur. Keduanya menyatakan dengan jelas bahwa source code-nya tersedia. Namun, menurut definisi OSI, tidak satu pun merupakan open source. Perbedaan itu pada akhirnya berdampak kepada Anda, bukan kepada penyedia cloud yang menjadi sasaran lisensi tersebut.

OpenSearch: biaya fork lisensi bagi operator

Elastic mengumumkan pada 14 January 2021 bahwa Elasticsearch dan Kibana akan meninggalkan Apache 2.0 dan beralih ke salah satu dari SSPL atau Elastic License, mulai dari release 7.11. Version 7.10.2 adalah release terakhir berlisensi Apache 2.0. Sekitar satu minggu kemudian, AWS menyatakan akan membuat dan memelihara fork Apache 2.0 untuk keduanya. Fork tersebut diberi nama OpenSearch pada 12 April 2021, sedangkan Kibana berganti nama menjadi OpenSearch Dashboards. OpenSearch 1.0 tersedia secara umum pada 12 July 2021, dibangun dari Elasticsearch 7.10.2 dan Kibana 7.10.2.

Perhatikan dampaknya bagi operator cluster. Nama package dan repository berubah. Setiap referensi ke Kibana dalam runbook harus diubah menjadi OpenSearch Dashboards. Nama plugin berpindah. Kemudian perpecahan ini mencapai kode aplikasi: mulai version 7.13, library client resmi milik Elastic memeriksa produk yang terhubung dengannya dan menolak melanjutkan jika produk tersebut bukan Elasticsearch. Client melaporkan bahwa server itu adalah produk yang tidak dikenal. Keputusan lisensi di perusahaan tempat Anda tidak bekerja muncul sebagai panggilan yang gagal di dalam aplikasi Anda sendiri.

Perkembangan ini kemudian berubah dua kali lagi. Elastic menambahkan AGPLv3 sebagai opsi lisensi ketiga pada 29 August 2024. Karena itu, Elasticsearch saat ini kembali menjadi open source yang disetujui OSI. Pada 16 September 2024, AWS mengalihkan OpenSearch ke OpenSearch Software Foundation yang berada di bawah Linux Foundation. Langkah ini memberi fork tersebut tempat tata kelola yang tidak dikendalikan oleh satu perusahaan. Lima tahun setelah perpecahan itu, kedua project merupakan open source, keduanya dipelihara, dan OpenSearch berada pada series 3.x per August 2026.

Kesimpulannya adalah pelajarannya. Lisensi tersebut kembali, tetapi fork tetap ada. Setelah sebuah ecosystem memiliki dua versi untuk setiap komponen, pembatalan perubahan administratif tidak akan menggabungkannya kembali.

Angka yang menentukan seberapa besar dampak relicensing adalah jarak antara pengumuman dan fork stabil yang benar-benar dapat Anda deploy.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

Setiap jarak dihitung dari pengumuman publik vendor hingga release stabil pertama fork, menggunakan tanggal yang tercantum di bawah. OpenSearch 1.0 memerlukan 179 hari, karena fork tersebut harus diberi nama baru dan dibangun ulang tanpa fork sebelumnya yang dapat dijadikan acuan. OpenTofu memerlukan 153 hari. Valkey memerlukan 27 hari, karena fork tersebut dibuat dari Redis 7.2.4 dan mempertahankan protocol serta format on-disk yang identik. Arah perkembangannya adalah bagian yang penting: fork yang kredibel kini dapat tersedia dalam hitungan minggu, dengan foundation dan maintainer berbayar yang terlibat sejak hari pertama.

Valkey dan OpenTofu: pola yang sama, lebih cepat

Redis Ltd mengubah lisensi Redis dari BSD 3-clause menjadi pilihan RSALv2 atau SSPLv1 pada 20 March 2024. Delapan hari kemudian, Linux Foundation mengumumkan Valkey, yang di-fork dari Redis 7.2.4 dan tetap menggunakan BSD 3-clause. Valkey 7.2.5 dirilis pada 16 April 2024 dengan protokol dan file data yang sama. Karena itu, bagi sebagian besar operator, migrasinya hanya memerlukan perubahan nama paket. Redis kemudian menambahkan AGPLv3 sebagai pilihan ketiga dalam Redis 8 pada May 2025. Dengan demikian, Redis kembali menjadi open source menurut definisi OSI, sedangkan Valkey tetap berada di bawah tata kelolanya sendiri. Polanya sangat mirip dengan Elasticsearch.

Terraform mengalami pola yang sama dengan satu bab tambahan. OpenTofu di-fork dari rilis terakhir berlisensi Mozilla Public License 2.0, bergabung dengan Linux Foundation pada September 2023, lalu merilis 1.6.0 pada 10 January 2024. Pada 3 April 2024, pengacara HashiCorp mengirimkan surat cease and desist kepada proyek tersebut. Mereka menuduh bahwa kode dari rilis Terraform berlisensi BUSL telah disalin ke dalam fork tersebut. OpenTofu menerbitkan tanggapan terperinci pada 11 April 2024 dan menyangkal tuduhan itu. OpenTofu juga menelusuri kode yang dipersoalkan ke riwayat berlisensi MPL yang digunakan bersama oleh kedua proyek. Setelah itu, tidak ada perkembangan lebih lanjut yang dipublikasikan. Risiko utama dari kejadian tersebut adalah hal yang perlu diingat: tuduhan saja dapat menghentikan adopsi selama satu kuartal. Dampaknya sama seperti gugatan Berkeley tiga puluh tahun sebelumnya.

Tidak semua fork berawal dari persoalan lisensi. Forgejo di-fork dari Gitea pada 2022 setelah pengembangan Gitea dipindahkan ke bawah sebuah perusahaan. Perselisihan tersebut berkaitan dengan tata kelola, bukan lisensi. Forgejo tetap menggunakan lisensi MIT hingga seri versinya 8. Kemudian, mulai versi 9.0 pada 2024, Forgejo mengubah lisensinya menjadi GPLv3 atau versi yang lebih baru. Dengan demikian, kodenya tidak dapat ditarik kembali ke produk yang dikendalikan secara komersial. Jika Anda sedang mempertimbangkan opsi server Git yang di-host sendiri, pasangan ini merupakan contoh nyata yang paling jelas tentang satu basis kode dengan dua filosofi.

Uji yang harus dijalankan sebelum mengadopsi apa pun

Ajukan empat pertanyaan sebelum instalasi pertama, bukan setelahnya.

1. Siapa yang memegang hak cipta? Relisensi memerlukan izin dari setiap pemegang hak cipta. Karena itu, proyek dengan ratusan kontributor independen tanpa pengalihan hak tidak dapat direlisensikan secara realistis. Proyek yang seluruh kepemilikannya berada pada satu perusahaan dapat direlisensikan melalui rapat dewan.
2. Apakah terdapat CLA, dan apa saja yang diberikan oleh perjanjian tersebut? Contributor licence agreement yang mengizinkan perusahaan merelisensikan kontribusi Anda dengan persyaratan apa pun merupakan mekanisme yang digunakan dalam setiap relisensi di atas. DCO (developer certificate of origin), yaitu baris sign-off yang diadopsi Linux kernel pada 2004, sama sekali tidak mengalihkan hak. CLA yang dipegang oleh yayasan lebih aman daripada CLA yang dipegang perusahaan karena perusahaan dapat dijual.
3. Siapa yang memiliki merek dagang? Elastic mempertahankan nama Elasticsearch. Karena itu, fork tersebut harus mengganti namanya, dan setiap runbook yang menyebut Kibana harus ditulis ulang.
4. Berapa biaya relisensi bagi Anda secara khusus? Hitung biaya untuk format data, pustaka klien, konfigurasi yang harus Anda tulis ulang, serta kemungkinan sudah adanya fork yang kompatibel.

Dua perintah dapat menjawab sebagian pertanyaan ini dalam hitungan detik.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

Setiap paket Debian dan Ubuntu menyertakan file di /usr/share/doc/<package>/copyright. File tersebut mencatat lisensi versi yang Anda instal, bukan lisensi yang digunakan proyek saat ini. Untuk bash pada Ubuntu 24.04, file tersebut mencantumkan GNU General Public License version 3. Jalankan perintah kedua di dalam source checkout untuk mendapatkan riwayat file lisensi itu sendiri. Commit dalam dua tahun terakhir pada file tersebut perlu dibaca sebelum Anda membangun apa pun berdasarkan proyek itu. Jika perintah tidak menghasilkan output, repository menggunakan nama lain untuk file lisensinya. Karena itu, tampilkan isi direktori root dan cari file tersebut.

Tidak ada lisensi yang melindungi Anda dari semua kemungkinan, dan memilih berdasarkan ideologi dapat menimbulkan kejutan. Utamakan proyek yang hak ciptanya tersebar di banyak pihak atau dimiliki yayasan, dan simpan data dalam format yang dapat Anda ekspor. Selanjutnya, cari tahu fork yang akan Anda gunakan untuk berpindah, lalu catat namanya sebelum Anda membutuhkannya. Menerapkan pemeriksaan ini pada setiap kandidat memerlukan waktu kurang dari satu jam. Pemeriksaan inilah yang membedakan upgrade dari migrasi saat Anda menentukan hal yang akan di-self-host pada 2026.

FAQ

Apakah lisensi MIT sama dengan lisensi BSD?

Pada praktiknya, MIT setara dengan lisensi BSD 2-klausul: pertahankan pemberitahuan hak cipta dan penafian garansi, lalu gunakan kode tersebut sesuai kebutuhan, termasuk untuk membuat produk tertutup. Lisensi BSD 3-klausul menambahkan satu hal, yaitu larangan menggunakan nama kontributor untuk mendukung produk Anda tanpa izin. Versi 4-klausul yang lebih lama juga mewajibkan pencantuman pengakuan dalam materi iklan. UC Berkeley menghapus klausul tersebut pada 22 July 1999, sehingga hampir tidak ada lisensi yang masih menggunakannya saat ini.

Dapatkah saya memasukkan kode Apache 2.0 ke dalam proyek GPLv2?

Tidak. Apache 2.0 menambahkan ketentuan yang tidak diizinkan oleh GPLv2, terutama klausul penghentian hak paten. Karena itu, karya gabungan tidak dapat memenuhi kedua lisensi tersebut sekaligus. FSF dan ASF sama-sama menerbitkan kesimpulan ini. Arah sebaliknya dapat dilakukan: kode Apache 2.0 dapat disertakan dalam proyek GPLv3, dan hasilnya berlisensi GPLv3. Hal ini juga menjelaskan mengapa kode Apache 2.0 tidak dapat digabungkan ke dalam Linux kernel, yang hanya menggunakan GPL version 2.

Apakah SSPL merupakan lisensi open source?

Tidak, dan jawabannya memiliki konsekuensi praktis. OSI tidak pernah menyetujuinya, dan MongoDB menarik permohonannya pada March 2019. Debian menyatakan pada December 2018 bahwa software SSPL tidak termasuk dalam arsipnya. Fedora memutuskan pada January 2019 bahwa lisensi tersebut bukan lisensi bebas. Setelah itu, Red Hat menghapus MongoDB dari Fedora dan Red Hat Enterprise Linux. Bagi Anda, hal ini berarti package yang sebelumnya dipelihara oleh distribution kini berasal dari repository vendor, dengan jadwal dukungan yang ditentukan vendor. Business Source License juga menyediakan source code, bukan open source, meskipun setiap release berubah menjadi lisensi open source dalam waktu four years.

Apakah perubahan lisensi berlaku untuk version yang sudah saya jalankan?

Tidak. Lisensi yang diberikan bersama sebuah release tidak dapat ditarik dari salinan yang sudah diterbitkan. Inilah alasan fork dapat dibuat. OpenSearch dibangun dari Elasticsearch 7.10.2, yaitu release terakhir yang diterbitkan Elastic di bawah Apache 2.0. Yang hilang adalah akses ke masa depan, karena security fix berikutnya diterbitkan berdasarkan ketentuan baru. Mengunci version terakhir yang berlisensi permisif hanya memberi waktu beberapa bulan, dan itu bukan rencana.