GPL vs MIT vs Apache: Ano ang Hinihingi Nila?

GPL laban sa MIT laban sa Apache: ano ang hinihingi ng bawat lisensya

Iba-ibang paraan ang sagot ng GPL, MIT, at Apache 2.0 sa parehong tanong: ano ang obligasyon 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, kasama ang kasunduan tungkol sa patent sa lahat ng nag-aambag sa code. Hinihingi naman ng GPL na ilabas mo ang source code ng ginawa mo sa ibabaw nito, gamit ang parehong lisensyang natanggap mo.

Mukhang usapin ito para sa mga abogado hanggang sa araw na baguhin ng isang project na pinapatakbo mo ang lisensya nito at mahati sa dalawa. Pagkatapos, nagiging usapin ito ng operations. Dalawang package repository ang kailangan mong pagpilian, at may mga client library na hindi na magawang makipag-ugnayan sa isa't isa. Tungkol ang gabay 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: ang 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.

Permissive tradition: BSD, pagkatapos ay MIT

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

Ang natira ay ang 3-clause BSD licence, na nagpapanatili sa pagbabawal ng orihinal na bersiyon sa paggamit ng mga pangalan ng contributors upang i-endorse ang iyong produkto, at ang 2-clause na bersiyon, na inaalis maging ang probisyong iyon. Nagmula sa MIT ang teksto ng MIT licence noong 1980s, kung saan ginamit ito para sa X Window System. Sa praktika, pareho ang gamit nito sa 2-clause BSD.

Magkaiba ang mga dahilan. Nais ng isang unibersidad na pinopondohan ng public money na gamitin ang gawa nito kahit saan, kabilang ng mga kumpanya. Nais naman ng GNU project ng commons na hindi maaaring isara. Parehong lehitimo ang dalawang posisyon, at parehong may posibleng failure mode. Maaaring gawing private ang permissive code, at wala kang matatanggap pabalik. Tinatanggihan naman ng mga kumpanyang hindi tatanggap ng ganitong kondisyon ang copyleft code.

May ikalawang aral mula sa Berkeley, at ito ang puntong 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 pagbasehan ang BSD, kaya bumagal ang adoption nito habang lumalaki ang Linux. Mas mabilis na nakapipigil sa adoption ang legal uncertainty kaysa sa isang feature na wala.

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.

Ang panahon ng relicensing: SSPL, BUSL, at kung ano ang hindi mga ito

Komersiyal ang naging dahilan. Pagmamay-ari ng isang kumpanya ang copyright ng isang produkto, ibinebenta ito ng isang cloud provider bilang managed service sa malaking saklaw habang kakaunti ang ibinabalik na ambag, at binabago ng kumpanya ang licence upang pigilan ito. Ginawa ng Redis Labs ang unang kapansin-pansing hakbang noong Agosto 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 Oktubre 2018 nang lumipat ito mula AGPLv3 patungo sa Server Side Public License.

Ang SSPL ay AGPL na may isang seksyong muling isinulat. Kapag iniaalok mo ang program sa mga third party bilang isang service, kailangan mong i-publish ang source ng lahat ng ginagamit mo upang maibigay ito, kabilang ang management at orchestration software na nakapaligid dito. Walang malinaw na hangganan ang obligasyong ito, at wala pang korte na sumubok dito. Hindi kailanman inaprubahan ng OSI ang licence, at binawi ng MongoDB ang application nito noong Marso 2019. Nauna nang sinabi ng Debian noong Disyembre 2018 na hindi kabilang sa archive nito ang SSPL software, at ipinasiya ng Fedora noong Enero 2019 na hindi free ang licence. Dahil dito, inalis ng Red Hat ang MongoDB sa Fedora at sa Red Hat Enterprise Linux. Ito ang praktikal na resulta ng relicence: tumitigil ang distribution sa pag-package ng software, kaya ang iyong mga upgrade ay nagmumula na ngayon sa vendor repository ayon sa schedule ng vendor.

Ibang mekanismo ang Business Source License. Nagmula ito sa mga founder ng MariaDB, at 2017 ang petsa ng version 1.1. Hindi ito copyleft at hindi ito open source. Public ang source, at libre ang paggamit na hindi pang-production. Pinapayagan lamang ang production use hanggang sa saklaw na itinakda ng vendor's Additional Use Grant, at karaniwang ipinagbabawal ng grant na iyon ang pagpapatakbo ng competing hosted service. Awtomatikong nagko-convert ang bawat release sa isang tunay na open source licence sa isang change date na hindi lalampas sa apat na taon mula sa release na iyon. Ang licence na paglilipatan nito ay dapat GPL version 2.0 o mas bago, o isang licence na compatible sa isa sa mga iyon. Inilipat ng HashiCorp ang Terraform at iba pa nitong produkto sa BUSL 1.1 noong 10 Agosto 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, ngunit hindi ang pagbuo ng service batay rito.

Hindi hindi tapat ang alinman sa dalawang licence. Malinaw na sinasabi ng mga ito na source available ang mga ito. Hindi open source ang alinman sa mga ito ayon sa depinisyon ng OSI, at ikaw ang direktang naaapektuhan ng pagkakaibang iyon, hindi ang cloud provider na pinatutungkulan nito.

OpenSearch: magkano ang gastos ng operator sa isang licence fork

Inanunsyo ng Elastic noong 14 January 2021 na aalis ang Elasticsearch at Kibana sa Apache 2.0 at lilipat sa pagpipilian ng SSPL o Elastic License, simula sa release 7.11. Ang version 7.10.2 ang huling Apache 2.0 release. Makalipas ang humigit-kumulang isang linggo, sinabi ng AWS na gagawa at magme-maintain ito ng Apache 2.0 fork ng dalawa. Pinangalanang OpenSearch ang fork noong 12 April 2021, at pinalitan ng OpenSearch Dashboards ang pangalan ng Kibana. 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 gawing OpenSearch Dashboards. Nagbago rin ang mga plugin name. Pagkatapos, umabot ang paghihiwalay sa application code: mula version 7.13 ng official client libraries ng Elastic, sinusuri ng client kung saan ito nakakonekta at tumatangging magpatuloy kapag ang nakakonekta 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 direksiyon ng kuwento. Inanunsyo ng Elastic noong 29 August 2024 na idaragdag nito ang AGPLv3 bilang ikatlong licence option. Ayon naman sa licensing FAQ nito, noong September 2024 idinagdag ang option. Dahil dito, ang kasalukuyang Elasticsearch ay muli nang OSI-approved open source. 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 pagmamay-ari ng iisang kumpanya. Limang taon matapos ang paghihiwalay, open source ang dalawang proyekto, parehong may maintenance, at nasa 3.x series na ang OpenSearch noong October 2026.

Ito ang aral sa naging wakas. Bumalik ang licence, pero nanatili ang fork. Kapag may dalawang bersiyon na ng lahat ng bahagi ng 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 stable fork na maaari mo talagang i-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
  }
]

Binibilang ang bawat pagitan 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 gawing batayan. Umabot ng 153 araw ang OpenTofu. Umabot ng 27 araw ang Valkey, dahil nag-fork ito mula sa Redis 7.2.4 at pinanatiling pareho ang protocol at on-disk format. Ito ang mahalagang direksiyon: nakalilikha na ngayon ng 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.