Perbezaan Lesen GPL, MIT dan Apache 2.0

GPL lwn MIT lwn Apache: apa yang diminta oleh setiap lesen daripada anda

GPL, MIT dan Apache 2.0 menjawab soalan yang sama dengan cara yang berbeza: apakah tanggungjawab anda kepada orang lain apabila anda mengedarkan perisian tersebut? MIT hanya meminta notis hak cipta dan tiada perkara lain. Apache 2.0 meminta notis tersebut berserta perjanjian paten antara semua pihak yang menyentuh kod tersebut. GPL meminta anda menerbitkan kod sumber bagi apa yang anda bina di atasnya, di bawah lesen yang sama seperti yang anda terima.

Perkara ini kelihatan seperti soalan untuk peguam sehingga tiba hari di mana projek yang anda jalankan menukar lesennya dan berpecah kepada dua. Pada ketika itu, ia menjadi soalan operasi. Anda mempunyai dua repositori pakej untuk dipilih, dan pustaka klien yang tidak lagi serasi antara satu sama lain. Panduan ini adalah mengenai lesen dan mekanismenya, bukan mengenai gerakan yang menghasilkannya, jadi setiap bahagian berakhir di tempat ia memberi kesan kepada anda: individu yang perlu menjalankan naik taraf.

Mengapa GPL wujud: pencetak yang tidak dibenarkan untuk dibaiki

Sekitar tahun 1980, Makmal Kepintaran Buatan MIT menerima pencetak laser Xerox 9700. Makmal tersebut telah mengubah suai perisian untuk pencetak terdahulu supaya ia memberitahu pengguna apabila kerja cetakan tersangkut. Bagi pencetak baharu ini, kod sumber tidak disediakan, dan permintaan untuk mendapatkannya ditolak kerana perjanjian kerahsiaan. Richard Stallman, yang ketika itu merupakan seorang pengatur cara di makmal tersebut, menganggap penolakan itu sebagai satu norma umum dan bukannya insiden terpencil, lalu mengumumkan projek GNU pada 27 September 1983.

Copyleft dibina berasaskan undang-undang hak cipta, bukan menentangnya. Secara lalai, anda langsung tidak mempunyai hak untuk menyalin kod orang lain. GPL memberikan hak tersebut dengan satu syarat: jika anda memberikan program itu kepada orang lain, anda mesti memberikan kod sumbernya di bawah syarat yang sama, supaya mereka boleh melakukan apa yang makmal tersebut tidak dapat lakukan. Syarat ini boleh dikuatkuasakan kerana tanpa lesen tersebut, anda tidak mempunyai kebenaran sejak awal lagi.

Stallman menulis lesen untuk GNU Emacs terlebih dahulu, kemudian menggeneralkannya menjadi GPL versi 1 pada 25 Februari 1989. GPL versi 2 menyusul pada Jun 1991, dan ia masih menjadi lesen bagi kebanyakan perisian sistem yang anda jalankan. Lesser GPL diperkenalkan untuk pustaka, supaya pustaka copyleft boleh dipautkan oleh program di bawah sebarang lesen tanpa mengheret program tersebut ke dalam GPL.

Satu perincian menentukan bagaimana GPL memberi kesan kepada pengguna self-host. Kewajipan tersebut tercetus apabila berlakunya pengedaran, bukan penggunaan. Anda boleh mengubah suai program GPL, menjalankannya pada pelayan sendiri, menyediakan perkhidmatan kepada orang awam dengannya, dan tidak berhutang apa-apa kepada sesiapa, kerana anda tidak pernah menyerahkan salinan program tersebut. Jurang itulah sebabnya AGPL wujud.

Tradisi permisif: BSD, kemudian MIT

Berkeley mengambil haluan yang berbeza. Computer Systems Research Group mengeluarkan hasil kerja Unix mereka di bawah lesen yang meminta notis hak cipta dikekalkan dan menafikan semua waranti. Versi asal mempunyai empat klausa, dan klausa keempat, iaitu klausa pengiklanan, mewajibkan pengiktirafan terhadap universiti dalam semua bahan pengiklanan yang menyebut ciri-ciri perisian tersebut. Perkara ini tidak berskala. Stallman mengira 75 pengiktirafan berasingan dalam versi NetBSD tahun 1997. UC Berkeley menarik balik klausa tersebut pada 22 Julai 1999, melalui surat daripada William Hoskins dari Office of Technology Licensing mereka.

Apa yang tinggal ialah lesen BSD 3-klausa, yang menambah larangan menggunakan nama penyumbang untuk menyokong produk anda, dan versi 2-klausa, yang menggugurkan syarat tersebut. Teks lesen MIT muncul dari MIT pada tahun 1980-an, di mana ia meliputi X Window System, dan secara praktikalnya ia melakukan tugas yang sama seperti BSD 2-klausa.

Motifnya berbeza. Sebuah universiti yang dibiayai dengan wang awam mahukan hasil kerjanya digunakan di mana-mana, termasuk oleh syarikat. Projek GNU mahukan sumber awam yang tidak boleh ditutup. Kedua-dua pendirian adalah jujur, dan kedua-duanya mempunyai mod kegagalan. Kod permisif boleh diambil untuk kegunaan peribadi, dan anda tidak mendapat apa-apa balasan. Kod copyleft ditolak oleh syarikat yang peguamnya tidak akan menerima syarat tersebut.

Terdapat pengajaran kedua daripada Berkeley, dan inilah perkara yang sering disentuh oleh catatan ini. AT&T Unix System Laboratories menyaman Berkeley Software Design pada tahun 1992 berhubung kod BSD, dan kes tersebut diselesaikan pada awal tahun 1994. Selama dua tahun, tiada siapa yang pasti sama ada BSD selamat untuk dibina, dan penggunaan terhenti sementara Linux berkembang. Ketidakpastian undang-undang menghentikan penggunaan dengan lebih pantas berbanding ciri yang tiada.

Mengapa Apache 2.0 menambah geran paten

Lesen pertama Apache Group ialah terbitan BSD 4-klausa yang mempunyai masalah pengiklanan yang sama. Versi 1.1, pada tahun 2000, membuang klausa tersebut. Versi 2.0, yang diterbitkan pada Januari 2004, merupakan penulisan semula dan bukannya tampalan.

Penambahan penting ialah paten. MIT dan BSD langsung tidak menyebut tentang paten. Penyumbang boleh memberikan kebenaran hak cipta yang jelas untuk kod mereka tetapi masih memegang paten yang berkaitan dengan fungsi kod tersebut, kemudian menyaman pihak yang menggunakannya. Apache 2.0 menutup kelompangan itu: setiap penyumbang memberikan lesen paten yang meliputi sumbangan mereka, dan sesiapa yang menyaman dengan mendakwa karya tersebut melanggar paten mereka akan kehilangan lesen paten mereka sendiri terhadap karya itu. Ancaman ini bersifat timbal balik, jadi secara praktikalnya tiada siapa yang memulakan tindakan undang-undang.

Selebihnya dalam versi 2.0 adalah bersifat pentadbiran, dan itulah sebabnya syarikat menyukainya. Terdapat fail NOTICE yang ditetapkan, jadi atribusi mempunyai satu lokasi khusus dan tidak bertaburan di seluruh pepohon direktori. Lesen boleh digunakan melalui rujukan dan bukannya ditampal ke dalam setiap fail sumber. Sumbangan dilindungi oleh terma yang jelas. Tanda dagangan dikecualikan. Semakan undang-undang terhadap dependensi Apache 2.0 mendapati setiap soalan yang ingin ditanya sudah dijawab dalam teks tersebut, jadi kelulusan menjadi rutin, yang merupakan maksud utama bagi "pilihan lalai korporat".

Perubahan dalam GPLv3 dan sebab Linux kekal dengan GPLv2

TiVo mengeluarkan perakam video yang menjalankan Linux dan menerbitkan kod sumber kernel, tepat seperti yang disyaratkan oleh GPLv2. Perkakasan tersebut kemudian menyemak tandatangan kriptografi semasa but dan menolak untuk menjalankan kernel yang tidak dikenalinya. Anda boleh membaca kod sumber, mengubahnya, dan menyusunnya semula. Namun, anda tidak boleh menjalankannya pada peranti asal. Syarat lesen dipenuhi tetapi tujuannya digagalkan, dan amalan ini dikenali sebagai tivoisation.

GPL versi 3, yang diterbitkan pada 29 Jun 2007, menjawab perkara ini secara langsung. Apabila anda mengedarkan binari di dalam peranti pengguna, anda juga mesti membekalkan "Maklumat Pemasangan": kunci atau arahan yang diperlukan untuk memasang versi yang diubah suai dan membolehkannya berjalan. Versi 3 juga menambah pemberian paten secara eksplisit, syarat yang ditulis sebagai respons kepada perjanjian paten Microsoft dan Novell pada November 2006, serta keserasian sehala dengan Apache 2.0.

Linux tidak mengikut langkah tersebut. Kernel hanya menggunakan GPL versi 2, tanpa klausa "atau mana-mana versi kemudian", dan fail COPYING menyatakan perkara tersebut. Linus Torvalds membantah secara terbuka terhadap syarat anti-tivoisation untuk perkakasan yang ditandatangani. Halangan praktikalnya lebih besar daripada perbezaan pendapat tersebut: kernel mempunyai ribuan pemegang hak cipta, jadi tiada sesiapa yang boleh mengumpulkan kebenaran yang diperlukan untuk pelesenan semula walaupun semua orang menginginkannya. Fakta tunggal itu merupakan perlindungan terkuat yang boleh dimiliki oleh sesuatu projek, dan ia perlu diingat apabila anda melihat projek yang dimiliki oleh satu syarikat.

Lesen tahun 2007 yang satu lagi lebih penting bagi anda. GNU Affero GPL versi 3, yang diterbitkan pada bulan November tahun yang sama, melanjutkan kewajipan kod sumber kepada pihak yang berinteraksi dengan program melalui rangkaian. Jalankan servis AGPL yang diubah suai untuk orang awam dan anda wajib memberikan kod sumber kepada pengguna tersebut. Itulah sebabnya banyak perisian web yang dihoskan sendiri menggunakan AGPL. Nextcloud adalah salah satu contohnya, dan jika anda sedang membandingkan alternatif hos sendiri kepada Nextcloud, baris lesen dalam repositori setiap calon memberitahu anda lebih banyak tentang lima tahun akan datangnya berbanding senarai cirinya.

Lesen manakah yang sebenarnya boleh anda gabungkan?

Keserasian berfungsi sehala, daripada lesen permisif ke arah copyleft.

• Kod MIT dan BSD boleh dimasukkan ke dalam apa-apa sahaja, termasuk produk tertutup.
• Kod Apache 2.0 boleh dimasukkan ke dalam projek GPLv3, dan hasil gabungan tersebut menjadi GPLv3.
• Kod Apache 2.0 tidak boleh dimasukkan ke dalam projek yang hanya menggunakan GPLv2. Syarat penamatan paten dan ganti rugi dalam lesen tersebut merupakan syarat tambahan yang tidak dibenarkan oleh GPLv2. FSF dan ASF kedua-duanya menerbitkan kesimpulan ini.
• Kod GPL tidak boleh ditukar kepada lesen permisif oleh anda. Hanya pemegang hak cipta yang boleh berbuat demikian, yang membawa anda kembali kepada persoalan tentang siapa mereka sebenarnya.

Era pelesenan semula: SSPL, BUSL, dan perkara yang bukan daripadanya

Pencetusnya adalah komersial. Sebuah syarikat memiliki hak cipta ke atas sesuatu produk, penyedia awan menjualnya sebagai perkhidmatan terurus secara besar-besaran namun memberikan sumbangan yang sedikit, lalu syarikat tersebut menukar lesen untuk menghalangnya. Redis Labs membuat langkah pertama yang ketara pada Ogos 2018 dengan menambah Commons Clause di atas Apache 2.0 untuk beberapa modulnya. MongoDB mengikut jejak langkah tersebut pada 16 Oktober 2018 dengan beralih daripada AGPLv3 kepada Server Side Public License.

SSPL ialah AGPL dengan satu bahagian ditulis semula. Jika anda menawarkan program tersebut kepada pihak ketiga sebagai perkhidmatan, anda mesti menerbitkan kod sumber bagi segala yang anda gunakan untuk menawarkannya, termasuk perisian pengurusan dan orkestrasi di sekelilingnya. Kewajipan itu tidak mempunyai sempadan yang jelas, dan tiada mahkamah yang telah mengujinya. OSI tidak pernah meluluskan lesen tersebut, dan MongoDB menarik balik permohonannya pada Mac 2019. Debian telah pun menyatakan pada Disember 2018 bahawa perisian SSPL tidak sepatutnya berada dalam arkibnya, dan Fedora memutuskan pada Januari 2019 bahawa lesen tersebut tidak bebas, yang menyebabkan Red Hat menggugurkan MongoDB daripada Fedora dan Red Hat Enterprise Linux. Itulah hasil mekanikal bagi pelesenan semula: pengedar berhenti membungkus perisian tersebut, jadi naik taraf anda kini datang daripada repositori vendor mengikut jadual vendor.

Business Source License ialah peranti yang berbeza. Ia datang daripada pengasas MariaDB, dan versi 1.1 bermula dari tahun 2017. Ia bukan copyleft dan ia bukan sumber terbuka. Kod sumbernya adalah awam, penggunaannya adalah percuma kecuali bagi penggunaan yang dikhaskan oleh vendor, yang biasanya adalah menjalankan perkhidmatan hos yang bersaing, dan setiap keluaran akan bertukar secara automatik kepada lesen sumber terbuka sebenar pada tarikh perubahan yang tidak melebihi empat tahun selepas keluaran tersebut. Lesen yang ditukarkan itu mestilah serasi dengan GPLv2. HashiCorp memindahkan Terraform dan produk-produknya yang lain kepada BUSL 1.1 pada 10 Ogos 2023. Outline juga menggunakannya, yang perlu diketahui jika anda sedang memilih daripada alternatif Notion yang dihoskan sendiri: menjalankannya untuk pasukan anda sendiri adalah dibenarkan, manakala membina perkhidmatan di atasnya adalah tidak dibenarkan.

Kedua-dua lesen tersebut tidak berniat jahat. Kedua-duanya menyatakan dengan jelas bahawa ia adalah sumber tersedia (source available). Tiada satu pun yang merupakan sumber terbuka mengikut definisi OSI, dan perbezaannya memberi kesan kepada anda dan bukannya kepada penyedia awan yang disasarkan.

OpenSearch: kos yang ditanggung pengendali akibat fork lesen

Elastic mengumumkan pada 14 Januari 2021 bahawa Elasticsearch dan Kibana akan meninggalkan lesen Apache 2.0 untuk beralih kepada pilihan lesen SSPL atau Elastic License, bermula dengan keluaran 7.11. Versi 7.10.2 merupakan keluaran Apache 2.0 yang terakhir. Kira-kira seminggu kemudian, AWS menyatakan bahawa mereka akan mencipta dan menyelenggara fork Apache 2.0 bagi kedua-dua perisian tersebut. Fork itu dinamakan OpenSearch pada 12 April 2021, dengan Kibana dinamakan semula sebagai OpenSearch Dashboards. OpenSearch 1.0 tersedia secara umum pada 12 Julai 2021, dibina daripada Elasticsearch 7.10.2 dan Kibana 7.10.2.

Lihat kos yang ditanggung oleh mereka yang mengendalikan kluster. Nama pakej dan repositori berubah. Setiap rujukan kepada Kibana dalam buku panduan (runbook) menjadi OpenSearch Dashboards. Nama plugin berpindah. Kemudian, perpecahan itu sampai ke kod aplikasi: bermula dari versi 7.13 pustaka klien rasmi Elastic, klien tersebut menyemak destinasi sambungannya dan enggan meneruskan operasi jika ia bukan Elasticsearch, dengan melaporkan bahawa pelayan tersebut adalah produk yang tidak dikenali. Keputusan lesen di syarikat yang anda tidak bekerja dengannya tiba sebagai panggilan yang gagal di dalam aplikasi anda sendiri.

Kisah ini kemudian berubah dua kali lagi. Elastic menambah AGPLv3 sebagai pilihan lesen ketiga pada 29 Ogos 2024, jadi Elasticsearch semasa kini merupakan sumber terbuka yang diluluskan oleh OSI semula. Pada 16 September 2024, AWS memindahkan OpenSearch kepada OpenSearch Software Foundation, yang dihoskan oleh Linux Foundation, memberikan fork tersebut tempat tadbir urus yang bukan milik satu syarikat tunggal. Lima tahun selepas perpecahan itu, kedua-dua projek adalah sumber terbuka, kedua-duanya diselenggara, dan OpenSearch berada pada siri 3.x setakat Ogos 2026.

Pengakhirannya adalah pengajarannya. Lesen tersebut kembali kepada asal tetapi fork tetap wujud. Apabila sesuatu ekosistem mempunyai dua versi bagi segala-galanya, membatalkan urusan kertas kerja tidak akan menggabungkan mereka semula.

Angka yang menentukan betapa buruknya kesan penukaran lesen ialah jurang masa antara pengumuman dan fork stabil yang boleh anda gunakan.

[
  {
    "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 jurang dikira dari pengumuman awam vendor sehingga keluaran stabil pertama fork tersebut, menggunakan tarikh yang disenaraikan di bawah. OpenSearch 1.0 mengambil 179 hari, kerana fork tersebut perlu dinamakan semula dan dibina semula tanpa fork terdahulu untuk disalin. OpenTofu mengambil 153 hari. Valkey mengambil 27 hari, kerana ia melakukan fork daripada Redis 7.2.4 dan mengekalkan protokol serta format cakera yang sama. Arah aliran ini adalah bahagian yang berguna: fork yang kredibel kini tiba dalam masa beberapa minggu, dengan yayasan dan penyelenggara berbayar yang terlibat sejak hari pertama.

Valkey dan OpenTofu: corak yang sama, lebih pantas

Redis Ltd menukar lesen Redis daripada BSD 3-clause kepada pilihan RSALv2 atau SSPLv1 pada 20 Mac 2024. Lapan hari kemudian, Linux Foundation mengumumkan Valkey, yang di-fork daripada Redis 7.2.4 dan kekal di bawah lesen BSD 3-clause. Valkey 7.2.5 dikeluarkan pada 16 April 2024 dengan protokol dan fail data yang sama, jadi bagi kebanyakan pengendali, migrasi hanyalah melibatkan penukaran nama pakej. Redis kemudian menambah AGPLv3 sebagai pilihan ketiga dalam Redis 8 pada Mei 2025, yang menjadikannya perisian sumber terbuka semula mengikut definisi OSI, manakala Valkey terus beroperasi di bawah tadbir urus sendiri. Situasi ini hampir sama dengan Elasticsearch.

Terraform melalui laluan yang sama dengan satu bab tambahan. OpenTofu di-fork daripada keluaran terakhir Mozilla Public License 2.0, menyertai Linux Foundation pada September 2023 dan mengeluarkan versi 1.6.0 pada 10 Januari 2024. Pada 3 April 2024, peguam HashiCorp menghantar surat tuntutan henti dan larang (cease and desist) kepada projek tersebut dengan mendakwa bahawa kod daripada keluaran Terraform berlesen BUSL telah disalin ke dalam fork tersebut. OpenTofu menerbitkan respons terperinci pada 11 April 2024 yang menafikan dakwaan itu, dan menjejaki kod yang dipertikaikan tersebut kepada sejarah berlesen MPL yang dikongsi oleh kedua-dua projek. Tiada tindakan lanjut susulan di khalayak umum. Risiko sebenar dalam episod itu adalah perkara yang perlu diingati: tuduhan semata-mata boleh membekukan penggunaan selama satu suku tahun, kesan yang sama seperti tuntutan mahkamah Berkeley tiga puluh tahun sebelumnya.

Tidak semua fork bermula dengan isu lesen. Forgejo di-fork daripada Gitea pada tahun 2022 selepas pembangunan Gitea diletakkan di bawah sebuah syarikat, yang merupakan pertikaian tadbir urus dan bukannya pelesenan. Forgejo kekal dengan lesen MIT sehingga siri versi 8, kemudian menukar lesen kepada GPLv3 atau lebih baharu bermula versi 9.0 pada tahun 2024, supaya hasil kerjanya tidak boleh ditarik balik ke dalam produk yang dikawal secara komersial. Jika anda sedang menimbangkan pilihan pelayan Git yang dihoskan sendiri, pasangan tersebut merupakan contoh paling jelas bagi satu kod asas dengan dua falsafah berbeza.

Ujian yang perlu dijalankan sebelum anda menggunakan apa-apa

Empat soalan, sebelum pemasangan pertama dan bukannya selepas.

1. Siapa yang memegang hak cipta? Penukaran lesen memerlukan kebenaran daripada setiap pemegang hak cipta, jadi projek dengan ratusan penyumbang bebas dan tiada penyerahan hak tidak boleh ditukar lesennya secara realistik. Projek di mana satu syarikat memiliki segala-galanya boleh menukar lesen dalam mesyuarat lembaga pengarah.
2. Adakah terdapat CLA, dan apakah yang ia berikan? Perjanjian lesen penyumbang (CLA) yang membenarkan syarikat menukar lesen sumbangan anda di bawah sebarang terma yang disukainya adalah mekanisme sebenar di sebalik setiap penukaran lesen di atas. DCO (developer certificate of origin), iaitu baris pengesahan yang diterima pakai oleh kernel Linux pada tahun 2004, tidak memindahkan sebarang hak langsung. CLA yang dipegang oleh yayasan adalah lebih selamat daripada yang dipegang oleh syarikat, kerana syarikat boleh dijual.
3. Siapa yang memiliki tanda dagangan? Elastic mengekalkan nama Elasticsearch, jadi fork tersebut terpaksa menukar namanya sendiri dan setiap runbook yang menyebut Kibana terpaksa ditulis semula.
4. Berapakah kos penukaran lesen kepada anda secara khusus? Kira format data, pustaka klien, konfigurasi yang anda perlu tulis semula, dan sama ada fork yang serasi sudah wujud.

Dua arahan menjawab sebahagian daripada perkara ini dalam beberapa saat.

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

Setiap pakej Debian dan Ubuntu menghantar fail di /usr/share/doc/<package>/copyright, dan ia merekodkan lesen versi yang anda pasang, bukan lesen yang digunakan oleh projek tersebut hari ini. Untuk bash pada Ubuntu 24.04, fail tersebut menamakan GNU General Public License version 3. Jalankan arahan kedua di dalam semakan sumber (source checkout) dan anda akan mendapat sejarah fail lesen itu sendiri. Komit di sana dalam tempoh dua tahun lepas perlu dibaca sebelum anda membina apa-apa di atas projek tersebut. Jika arahan tidak mencetak apa-apa, repositori menamakan fail lesennya dengan nama lain, jadi senaraikan direktori akar dan cari.

Tiada lesen yang melindungi anda daripada setiap hasil, dan memilih berdasarkan ideologi adalah punca orang berasa terkejut. Utamakan projek yang hak ciptanya tersebar dalam kalangan ramai pihak atau dipegang oleh yayasan, dan simpan data anda dalam format yang boleh anda eksport. Kemudian, ketahui fork mana yang akan anda pindahkan, dan tulis namanya sebelum anda memerlukannya. Melaksanakan pemeriksaan tersebut kepada setiap calon memakan masa kurang daripada satu jam, dan itulah yang membezakan antara naik taraf (upgrade) dengan migrasi apabila anda sedang memutuskan apa yang perlu di-self host pada tahun 2026.

FAQ

Adakah lesen MIT sama dengan lesen BSD?

Secara praktikalnya, MIT sepadan dengan lesen BSD 2-klausa: kekalkan notis hak cipta dan penafian waranti, kemudian anda bebas melakukan apa sahaja, termasuk membina produk tertutup. Lesen BSD 3-klausa menambah satu perkara, iaitu larangan menggunakan nama penyumbang untuk mengesyorkan produk anda tanpa kebenaran. Versi 4-klausa yang lebih lama juga menuntut pengiktirafan dalam bahan pengiklanan, dan UC Berkeley telah menarik balik klausa tersebut pada 22 Julai 1999, jadi hampir tiada perisian semasa yang masih menggunakannya.

Bolehkah saya memasukkan kod Apache 2.0 ke dalam projek GPLv2?

Tidak. Apache 2.0 menambah syarat yang tidak dibenarkan oleh GPLv2, terutamanya klausa penamatan paten, jadi karya gabungan tidak dapat memenuhi kedua-dua lesen tersebut serentak. FSF dan ASF kedua-duanya menerbitkan kesimpulan ini. Arah sebaliknya boleh dilakukan: kod Apache 2.0 boleh disertakan dalam projek GPLv3, dan hasilnya adalah GPLv3. Inilah sebabnya kod Apache 2.0 tidak boleh digabungkan ke dalam kernel Linux, yang hanya menggunakan GPL versi 2.

Adakah SSPL merupakan lesen sumber terbuka?

Tidak, dan jawapan ini mempunyai kesan praktikal. OSI tidak pernah meluluskannya, dan MongoDB menarik balik permohonannya pada Mac 2019. Debian menyatakan pada Disember 2018 bahawa perisian SSPL tidak sepatutnya berada dalam arkibnya, dan Fedora memutuskan pada Januari 2019 bahawa lesen tersebut tidak bebas, yang menyebabkan Red Hat menggugurkan MongoDB daripada Fedora dan Red Hat Enterprise Linux. Bagi anda, ini bermakna pakej yang dahulunya diselenggara oleh pengedaran anda kini datang daripada repositori vendor, mengikut jadual sokongan vendor tersebut. Business Source License juga merupakan lesen "source available" dan bukannya sumber terbuka, walaupun setiap keluaran akan bertukar kepada lesen sumber terbuka dalam tempoh empat tahun.

Adakah perubahan lesen terpakai pada versi yang sedang saya jalankan?

Tidak. Lesen yang diberikan bersama sesuatu keluaran tidak boleh ditarik balik daripada salinan yang telah diterbitkan, itulah sebabnya fork boleh dilakukan. OpenSearch dibina daripada Elasticsearch 7.10.2, keluaran terakhir yang diterbitkan oleh Elastic di bawah Apache 2.0. Apa yang anda hilang adalah masa depan, kerana tampalan keselamatan seterusnya akan tiba di bawah terma baharu. Mengekalkan versi berlesen permisif yang terakhir hanya memberi anda masa beberapa bulan, dan itu bukanlah satu pelan jangka panjang.