GPL vs MIT vs Apache: Ano ang Hinihingi Nila?

GPL vs MIT vs Apache: ano ang hinihingi ng bawat lisensya

Sinasagot ng GPL, MIT, at Apache 2.0 ang parehong tanong sa magkakaibang paraan: ano ang pananagutan mo sa ibang tao kapag ipinamahagi mo ang software? Ang MIT ay humihingi lamang ng copyright notice. Ang Apache 2.0 ay humihingi ng notice na iyon, pati ng patent bargain sa pagitan ng lahat ng gumagamit o nag-aambag sa code. Hinihiling ng GPL na ilabas mo ang source code ng ginawa mo batay rito, gamit ang parehong lisensyang natanggap mo.

Mukhang para ito sa mga abogado hanggang sa magbago ang lisensya ng isang proyektong pinapatakbo mo at mahati ito sa dalawa. Pagkatapos, nagiging usapin ito ng operations. Mayroon kang dalawang package repository na pagpipilian, at mga client library na hindi na makapagpalitan ng data. Tungkol ang guide na ito sa mga lisensya at mekanismo ng mga ito, hindi sa kilusang nagpasimula sa mga ito. Kaya nagtatapos ang bawat seksyon sa epekto nito sa iyo: sa taong kailangang magpatakbo ng upgrade.

Bakit umiiral ang GPL: isang printer na walang sinumang pinayagang mag-ayos

Noong bandang 1980, nakatanggap ang MIT Artificial Intelligence Lab ng Xerox 9700 laser printer. Na-patch na ng lab ang software para sa naunang printer upang ipaalam nito kapag na-stuck ang isang print job. Para sa bagong printer, walang source code, at tinanggihan ang hiling para rito dahil sa isang nondisclosure agreement. Si Richard Stallman, na programmer noon sa lab, ay itinuring ang pagtangging iyon bilang pangkalahatang problema sa halip na isang masamang pangyayari lamang, at inanunsyo niya ang GNU project noong 27 September 1983.

Binubuo ang Copyleft gamit ang copyright law, hindi laban dito. Bilang default, wala kang karapatang kumopya ng code ng ibang tao. Ibinibigay ng GPL ang karapatang iyon sa isang kondisyon: kung ibibigay mo ang program sa iba, dapat mo rin silang bigyan ng source sa ilalim ng parehong mga tuntunin, upang magawa nila ang hindi nagawa ng lab. Naipatutupad ang kondisyong ito dahil kung wala ang license, wala ka sanang pahintulot mula sa simula.

Unang nagsulat si Stallman ng license para sa GNU Emacs, pagkatapos ay ginawa niya itong pangkalahatang GPL version 1 noong 25 February 1989. Sumunod ang GPL version 2 noong June 1991, at ito pa rin ang license ng karamihan sa system software na ginagamit mo. Dumating ang Lesser GPL para sa mga library, upang ma-link ng program na gumagamit ng anumang license ang isang copyleft library nang hindi napapailalim sa GPL ang program na iyon.

May isang detalyeng nagpapasya kung paano naaapektuhan ng GPL ang isang self-hoster. Nati-trigger ang obligasyon kapag may distribution, hindi kapag ginagamit lamang ang software. Maaari mong baguhin ang isang GPL program, patakbuhin ito sa sarili mong server, at gamitin ito upang magbigay ng serbisyo sa publiko nang wala kang kailangang ibigay sa iba, dahil hindi ka naman namahagi ng kopya. Ang puwang na ito ang dahilan kung bakit umiiral ang AGPL.

Ang permissive na tradisyon: BSD, pagkatapos ay MIT

Iba ang naging direksiyon ng Berkeley. Inilabas ng Computer Systems Research Group ang Unix code nito sa ilalim ng lisensiyang humihiling na panatilihin ang copyright notice at nagdi-disclaim ng lahat ng warranty. May apat na clause ang orihinal na bersiyon. Ang ikaapat, ang advertising clause, ay nag-aatas ng acknowledgement sa University sa lahat ng advertising material na bumabanggit sa mga feature ng software. Hindi ito scalable. Nabilang ni Stallman ang 75 magkakahiwalay na acknowledgement sa bersiyon ng NetBSD noong 1997. Inalis ng UC Berkeley ang clause noong 22 July 1999, sa isang liham mula kay William Hoskins ng Office of Technology Licensing nito.

Ang natira ay ang 3-clause BSD licence, na nagdaragdag ng pagbabawal sa paggamit ng mga pangalan ng contributors upang i-endorse ang produkto mo, at ang 2-clause na bersiyon, na inaalis pati ang pagbabawal na iyon. Ang teksto ng MIT licence ay nagmula sa MIT noong 1980s, kung kailan saklaw nito ang X Window System. Sa aktuwal na paggamit, pareho ang ginagawa nito sa 2-clause BSD.

Magkaiba ang mga motibo. Nais ng isang university na pinopondohan ng public money na magamit kahit saan ang gawa nito, pati ng mga kumpanya. Nais ng GNU project ng isang commons na hindi maaaring isara. Parehong tapat ang mga posisyong ito, at parehong may failure mode. Maaaring gawing private ang permissive code, at wala kang matatanggap na kapalit. Tinatanggihan naman ng mga kumpanyang hindi tinatanggap ng kanilang mga abogado ang kondisyon ang copyleft code.

May ikalawang aral mula sa Berkeley, at ito ang paulit-ulit na binabalikan ng post na ito. Kinasuhan ng AT&T's Unix System Laboratories ang Berkeley Software Design noong 1992 dahil sa BSD code, at na-settle ang kaso noong unang bahagi ng 1994. Sa loob ng dalawang taon, walang makatitiyak na ligtas pagbatayan ang BSD. Naantala ang adoption nito habang lumalaki ang Linux. Mas mabilis pahintuin ng legal uncertainty ang adoption kaysa sa isang nawawalang feature.

Bakit nagdagdag ang Apache 2.0 ng patent grant

Ang unang lisensya ng Apache Group ay derivative ng BSD 4-clause na may parehong problema sa advertising clause. Inalis ang clause na iyon sa Version 1.1 noong 2000. Ang Version 2.0, na inilabas noong January 2004, ay isang muling pagsulat sa halip na simpleng patch.

Ang mahalagang dagdag ay tungkol sa patents. Walang sinasabi ang MIT at BSD tungkol sa mga ito. Maaaring magbigay ang isang contributor ng malinaw na copyright permission para sa code nito, pero mayroon pa rin itong patent na sumasaklaw sa ginagawa ng code. Maaari nitong idemanda ang mga taong gumagamit ng code. Tinatanggal ng Apache 2.0 ang puwang na ito: nagbibigay ang bawat contributor ng patent licence para sa sakop ng contribution nito. Kapag may nagdemanda at nag-claim na lumalabag sa patents nito ang gawa, mawawala naman ang sarili nitong patent licence para rito. Mutual ang banta, kaya sa pagsasagawa ay walang gumagamit nito para umatake.

Administrative ang natitirang bahagi ng 2.0, at iyon ang dahilan kung bakit gusto ito ng mga kumpanya. May tinukoy na NOTICE file, kaya iisa ang lokasyon ng attribution sa halip na nakakalat ito sa buong tree. Maaaring ilapat ang lisensya sa pamamagitan ng reference sa halip na i-paste sa bawat source file. Sakop ng malinaw na terms ang mga contribution. Hindi kasama ang trademarks. Kapag nagsagawa ng legal review sa isang Apache 2.0 dependency, nasasagot na sa mismong text ang lahat ng tanong na nais nitong suriin. Dahil dito, nagiging routine ang approval, at ito ang malaking bahagi ng ibig sabihin ng “corporate default.”

Ano ang binago ng GPLv3, at bakit nanatili ang Linux sa GPLv2

Nag-release ang TiVo ng isang video recorder na nagpapatakbo ng Linux at nag-publish ng source code ng kernel, gaya mismo ng hinihingi ng GPLv2. Pagkatapos, nag-check ang hardware ng cryptographic signature habang nagbo-boot at tumangging magpatakbo ng kernel na hindi nito kinikilala. Maaari mong basahin ang source code, baguhin ito, at i-compile. Ngunit hindi mo ito maaaring patakbuhin sa device kung saan ito nagmula. Natupad ang literal na kondisyon ng license, pero nabigo ang layunin nito. Tinawag na tivoisation ang ganitong gawain.

Direktang tinutugunan ito ng GPL version 3, na na-publish noong 29 June 2007. Kapag ipinamahagi mo ang binary sa loob ng isang consumer device, kailangan mo ring ibigay ang "Installation Information": ang mga key o instruction na kailangan upang mag-install ng binagong version at mapatakbo ito. Nagdagdag din ang Version 3 ng tahasang patent grant, mga terminong isinulat bilang tugon sa patent agreement ng Microsoft at Novell noong November 2006, at one-way compatibility sa Apache 2.0.

Hindi ito sinunod ng Linux. GPL version 2 lamang ang kernel. Wala itong escape clause na "or any later version", at malinaw itong sinasabi sa COPYING file nito. Publikong tinutulan ni Linus Torvalds ang mga anti-tivoisation term para sa signed hardware. Mas malaki ang praktikal na hadlang kaysa sa mismong hindi pagkakasundo: libo-libong copyright holder ang kernel, kaya walang makakakalap ng mga permission na kailangan para sa relicensing kahit gusto ito ng lahat. Ang katotohanang iyon ang pinakamalakas na proteksiyong maaaring magkaroon ang isang project. Mahalagang tandaan ito kapag tumitingin ka sa isang project na pagmamay-ari ng iisang kumpanya.

Mas mahalaga sa iyo ang isa pang license na inilabas noong 2007. Pinalalawak ng GNU Affero GPL version 3, na na-publish noong November ng parehong taon, ang source obligation para sa mga taong nakikipag-ugnayan sa program sa network. Kapag nagpatakbo ka ng binagong AGPL service para sa publiko, kailangan mong ibigay sa mga user na iyon ang source code. Iyan ang dahilan kung bakit AGPL ang license ng maraming self-hosted web software. Halimbawa ang Nextcloud. Kung ikinukumpara mo ang mga self-hosted alternative sa Nextcloud, mas marami pang sinasabi tungkol sa susunod nitong limang taon ang license line sa repository ng bawat candidate kaysa sa feature list nito.

Aling mga lisensya ang maaari mo talagang pagsamahin?

Isinasagawa ang compatibility sa isang direksiyon lamang, mula permissive patungo sa copyleft.

• Maaaring ilagay ang MIT at BSD code sa anumang proyekto, kasama ang closed product.
• Maaaring isama ang Apache 2.0 code sa isang GPLv3 project, at magiging GPLv3 ang pinagsamang work.
• Hindi maaaring isama ang Apache 2.0 code sa isang GPLv2-only project. Ang mga kondisyon nito tungkol sa patent termination at indemnity ay mga karagdagang kondisyon na hindi pinapayagan ng GPLv2. Parehong inilalathala ng FSF at ASF ang konklusyong ito.
• Hindi mo maaaring ilipat ang GPL code sa isang permissive licence. Mga copyright holder lamang ang maaaring gumawa nito, kaya babalik ka sa tanong kung sino sila.

Panahon ng relicensing: SSPL, BUSL, at kung ano ang hindi kasama sa mga ito

Komersyal ang nagpasimula nito. Pagmamay-ari ng isang kumpanya ang copyright ng isang produkto, ibinebenta ito ng isang cloud provider bilang managed service sa malaking scale at kakaunti ang ibinabalik na kontribusyon, kaya binabago ng kumpanya ang license upang mapigilan iyon. Ang Redis Labs ang unang gumawa ng kapansin-pansing hakbang noong August 2018 nang idagdag nito ang Commons Clause sa ibabaw ng Apache 2.0 para sa ilan sa mga module nito. Sumunod ang MongoDB noong 16 October 2018 nang lumipat ito mula AGPLv3 sa Server Side Public License.

Ang SSPL ay AGPL na may isang seksyong binago. Kapag iniaalok mo ang program sa mga third party bilang service, kailangan mong i-publish ang source ng lahat ng ginagamit mo upang maialok ito, pati ang management at orchestration software sa paligid nito. Walang malinaw na hangganan ang obligasyong ito, at wala pang korte na sumubok dito. Hindi kailanman inaprubahan ng OSI ang license, at binawi ng MongoDB ang application nito noong March 2019. Nauna nang sinabi ng Debian noong December 2018 na hindi kabilang sa archive nito ang SSPL software, at nagpasiya ang Fedora noong January 2019 na hindi free ang license. Pagkatapos nito, inalis ng Red Hat ang MongoDB sa Fedora at sa Red Hat Enterprise Linux. Ito ang praktikal na resulta ng relicensing: tumitigil ang distribution sa pag-package ng software, kaya ang mga upgrade mo ay manggagaling na sa vendor repository ayon sa schedule ng vendor.

Ibang mekanismo ang Business Source License. Nagmula ito sa mga founder ng MariaDB, at ang version 1.1 ay mula noong 2017. Hindi ito copyleft at hindi ito open source. Public ang source, at libre ang paggamit maliban sa paggamit na itinatakda ng vendor, na karaniwang pagpapatakbo ng competing hosted service. Awtomatikong nagko-convert ang bawat release sa isang tunay na open source license sa change date na hindi lalampas sa apat na taon mula sa release na iyon. Kailangang compatible sa GPLv2 ang license na pagko-convertan nito. Inilipat ng HashiCorp ang Terraform at iba pa nitong produkto sa BUSL 1.1 noong 10 August 2023. Ginagamit din ito ng Outline, na mahalagang malaman kung pumipili ka mula sa mga self-hosted na alternatibo sa Notion: pinapayagan ang pagpapatakbo nito para sa sarili mong team, pero hindi ang pagbuo ng service batay rito.

Hindi dishonest ang alinmang license. Malinaw na sinasabi ng dalawang ito na source available sila. Hindi open source ang alinman sa depinisyon ng OSI, at ang pagkakaibang ito ay ikaw ang direktang naaapektuhan, hindi ang cloud provider na target ng mga license na ito.

OpenSearch: magkano ang gastos sa operator ng isang licence fork

Noong 14 January 2021, inanunsyo ng Elastic na aalis ang Elasticsearch at Kibana sa Apache 2.0 at pipili sa SSPL o Elastic License, simula sa release 7.11. Ang version 7.10.2 ang huling release sa ilalim ng Apache 2.0. Makalipas ang humigit-kumulang isang linggo, sinabi ng AWS na gagawa at magme-maintain ito ng Apache 2.0 fork ng dalawa. Pinangalanan ang fork na OpenSearch noong 12 April 2021, at pinalitan ang pangalan ng Kibana ng OpenSearch Dashboards. Naging generally available ang OpenSearch 1.0 noong 12 July 2021, na binuo mula sa Elasticsearch 7.10.2 at Kibana 7.10.2.

Tingnan kung ano ang naging gastos nito para sa mga nagpapatakbo ng clusters. Nagbago ang package names at repositories. Ang bawat reference sa Kibana sa isang runbook ay kailangang palitan ng OpenSearch Dashboards. Nagbago rin ang plugin names. Pagkatapos, umabot ang split sa application code: simula sa version 7.13 ng official client libraries ng Elastic, sinusuri ng client kung ano ang kinonektahan nito at tumatangging magpatuloy kapag ang server ay hindi Elasticsearch. Nag-uulat ito na unknown product ang server. Ang desisyon sa licence ng isang kumpanyang hindi mo pinagtatrabahuhan ay nauwi sa isang failing call sa loob ng sarili mong application.

Dalawang beses pang nagbago ang sitwasyon. Nagdagdag ang Elastic ng AGPLv3 bilang ikatlong licence option noong 29 August 2024, kaya muli nang OSI-approved open source ang kasalukuyang Elasticsearch. Noong 16 September 2024, inilipat ng AWS ang OpenSearch sa OpenSearch Software Foundation, na hosted ng Linux Foundation. Nagkaroon ang fork ng governance home na hindi kontrolado ng iisang kumpanya. Limang taon matapos ang split, parehong open source at parehong mine-maintain ang dalawang project. Nasa 3.x series na ang OpenSearch noong August 2026.

Ito ang aral sa naging resulta. Bumalik ang licence, pero nanatili ang fork. Kapag nagkaroon na ng dalawang bersyon ng bawat bahagi sa isang ecosystem, hindi na sila muling pinagsasama ng pagbawi sa dating paperwork.

Ang bilang na tumutukoy kung gaano kasakit ang relicensing ay ang pagitan ng announcement at ng isang stable fork na aktuwal mong maide-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
  }
]

Ang bawat pagitan ay binibilang mula sa public announcement ng vendor hanggang sa unang stable release ng fork, gamit ang mga petsang nakalista sa ibaba. Umabot ng 179 araw ang OpenSearch 1.0, dahil kinailangang palitan ang pangalan ng fork at buuing muli ito nang walang naunang fork na maaaring kopyahan. Umabot ng 153 araw ang OpenTofu. Umabot ng 27 araw ang Valkey, dahil nag-fork ito mula sa Redis 7.2.4 at pinanatiling magkapareho ang protocol at on-disk format. Ang mahalagang punto ay ang direksiyon ng pagbabago: dumarating na ngayon ang isang credible fork sa loob ng ilang linggo, na may foundation at paid maintainers mula pa sa unang araw.

Valkey at OpenTofu: parehong pattern, mas mabilis

Inilipat ng Redis Ltd ang Redis mula sa 3-clause BSD licence tungo sa pagpili sa pagitan ng RSALv2 at SSPLv1 noong 20 March 2024. Pagkalipas ng walong araw, inanunsyo ng Linux Foundation ang Valkey, na nag-fork mula sa Redis 7.2.4 at nanatili sa BSD 3-clause. Dumating ang Valkey 7.2.5 noong 16 April 2024 na may parehong protocol at parehong data files. Kaya para sa karamihan ng operators, pagpapalit lang ng package name ang migration. Idinagdag naman ng Redis ang AGPLv3 bilang ikatlong option sa Redis 8 noong May 2025. Dahil dito, muli itong naging open source ayon sa depinisyon ng OSI. Samantala, nagpapatuloy ang Valkey sa sarili nitong governance. Malapit ang pattern nito sa Elasticsearch.

Sinundan ng Terraform ang parehong landas, pero may isang karagdagang kabanata. Nag-fork ang OpenTofu mula sa huling release na may Mozilla Public License 2.0, sumali sa Linux Foundation noong September 2023, at naglabas ng 1.6.0 noong 10 January 2024. Noong 3 April 2024, nagpadala ang mga abogado ng HashiCorp sa project ng cease and desist letter. Iginiit nila na may kinopyang code mula sa isang BUSL-licensed na Terraform release papunta sa fork. Naglabas ang OpenTofu ng detalyadong tugon noong 11 April 2024 at itinanggi ito. Sinundan din nito ang pinagtatalunang code hanggang sa MPL-licensed history na pinagsasaluhan ng dalawang project. Wala nang sumunod na pampublikong aksyon. Ang tunay na panganib sa pangyayaring ito ang dapat tandaan: maaaring ihinto ng isang akusasyon lamang ang adoption sa loob ng isang quarter. Pareho ito ng naging epekto ng Berkeley lawsuit tatlumpung taon na ang nakalipas.

Hindi lahat ng fork ay nagsisimula sa licence. Nag-fork ang Forgejo mula sa Gitea noong 2022 matapos mapunta sa isang kumpanya ang development ng Gitea. Isyu ito sa governance, hindi sa licensing. Nanatili sa MIT ang Forgejo hanggang sa version 8 series nito. Pagkatapos, nag-relicense ito sa GPLv3 o mas bago mula sa version 9.0 noong 2024. Dahil dito, hindi maaaring ibalik ang gawa nito sa isang product na kontrolado ng isang commercial entity. Kung sinusuri mo ang mga opsyon para sa self-hosted Git server, ang pares na ito ang pinakamalinaw na aktuwal na halimbawa ng isang codebase at dalawang magkaibang pilosopiya.

Ang pagsubok na dapat patakbuhin bago ka mag-adopt ng anuman

Apat na tanong bago ang unang installation, hindi pagkatapos.

1. Sino ang may hawak ng copyright? Kailangan ng pahintulot mula sa bawat copyright holder para sa relicensing, kaya hindi praktikal na i-relicense ang isang project na may daan-daang independent contributor at walang assignment. Ang project na pag-aari ng isang kumpanya ang lahat ay maaaring i-relicense sa isang board meeting.
2. May CLA ba, at ano ang ipinagkakaloob nito? Ang contributor licence agreement na nagpapahintulot sa kumpanya na i-relicense ang iyong contribution sa anumang terms na gusto nito ang eksaktong mekanismo sa likod ng lahat ng relicensing sa itaas. Ang DCO (developer certificate of origin), ang sign-off line na pinagtibay ng Linux kernel noong 2004, ay walang inililipat na rights. Mas ligtas ang CLA na hawak ng isang foundation kaysa sa hawak ng isang kumpanya, dahil maaaring ibenta ang kumpanya.
3. Sino ang may-ari ng trademark? Pinanatili ng Elastic ang pangalang Elasticsearch, kaya kinailangang palitan ng fork ang pangalan nito at muling isulat ang bawat runbook na bumabanggit sa Kibana.
4. Magkano ang magiging gastos sa iyo mismo ng relicensing? Isama sa bilang ang data format, client libraries, configuration na kailangan mong muling isulat, at kung mayroon nang compatible fork.

Dalawang command ang makakasagot sa bahagi nito sa loob ng ilang segundo.

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

May file ang bawat Debian at Ubuntu package sa /usr/share/doc/<package>/copyright, at itinatala nito ang licence ng bersyong na-install mo, hindi ang licence na ginagamit ng project ngayon. Para sa bash sa Ubuntu 24.04, nakasaad sa file na iyon ang GNU General Public License version 3. Patakbuhin ang ikalawang command sa loob ng source checkout para makita ang history mismo ng licence file. Sulit basahin ang commit doon mula sa nakalipas na dalawang taon bago ka bumuo ng anuman batay sa project. Kung walang inilalabas ang command, iba ang pangalan ng licence file sa repository, kaya ilista ang root directory at hanapin ito.

Walang licence na magpoprotekta sa iyo mula sa bawat posibleng resulta, at ang pagpili batay sa ideolohiya ang dahilan kung bakit nagugulat ang mga tao. Mas piliin ang mga project na kalat sa maraming tao ang copyright o hawak ito ng isang foundation, at panatilihin ang data sa format na maaari mong i-export. Pagkatapos, alamin kung saang fork ka lilipat, at isulat ang pangalan nito bago mo ito kailanganin. Ang pagsasagawa ng check na ito sa bawat candidate ay wala pang isang oras, at ito ang naghihiwalay sa upgrade sa migration kapag nagpapasya ka kung ano ang ilo-host sa sarili mong server sa 2026.

FAQ

Kapareho ba ng MIT licence ang BSD licence?

Sa praktikal na epekto, katumbas ng MIT ang 2-clause BSD licence: panatilihin ang copyright notice at warranty disclaimer, saka gamitin ito ayon sa nais mo, kabilang ang pagbuo ng closed product. May isang dagdag ang 3-clause BSD licence: ipinagbabawal nitong gamitin ang pangalan ng mga contributor para i-endorse ang iyong product nang walang pahintulot. Sa mas lumang 4-clause na bersyon, kailangan din ang acknowledgement sa advertising material. Inalis ng UC Berkeley ang clause na iyon noong 22 July 1999, kaya halos wala nang kasalukuyang software na gumagamit nito.

Maaari ko bang ilagay ang Apache 2.0 code sa isang GPLv2 project?

Hindi. May mga condition ang Apache 2.0 na hindi pinapayagang idagdag ng GPLv2, lalo na ang patent termination clause. Dahil dito, hindi maaaring sumunod ang isang combined work sa dalawang licence nang sabay. Parehong inilalathala ng FSF at ASF ang konklusyong ito. Gumagana ang kabaligtarang direksiyon: maaaring isama ang Apache 2.0 code sa isang GPLv3 project, at magiging GPLv3 ang resulta. Ito rin ang dahilan kung bakit hindi maaaring i-merge ang Apache 2.0 code sa Linux kernel, na GPL version 2 lamang.

Open source licence ba ang SSPL?

Hindi, at may praktikal itong mga epekto. Hindi ito inaprubahan ng OSI, at binawi ng MongoDB ang application nito noong March 2019. Sinabi ng Debian noong December 2018 na hindi dapat mapabilang ang SSPL software sa archive nito. Nagpasya naman ang Fedora noong January 2019 na hindi free ang licence. Pagkatapos nito, inalis ng Red Hat ang MongoDB sa Fedora at Red Hat Enterprise Linux. Para sa iyo, nangangahulugan ito na ang package na dating mina-maintain ng iyong distribution ay nagmumula na ngayon sa vendor repository, ayon sa support timetable ng vendor. Ang Business Source License ay source available din sa halip na open source, bagama't nagko-convert ang bawat release sa isang open source licence sa loob ng apat na taon.

Nalalapat ba ang pagbabago ng licence sa bersyong pinapatakbo ko na?

Hindi. Hindi maaaring bawiin ang licence na ibinigay kasama ng isang release mula sa mga copy na nailathala na, at ito mismo ang dahilan kung bakit posible ang mga fork. Binuo ang OpenSearch mula sa Elasticsearch 7.10.2, ang huling release na inilathala ng Elastic sa ilalim ng Apache 2.0. Ang mawawala sa iyo ay ang hinaharap, dahil darating ang susunod na security fix sa ilalim ng mga bagong term. Makapagbibigay sa iyo ng ilang buwan ang pag-pin sa huling permissively licensed version, pero hindi ito isang pangmatagalang plano.