GPL vs MIT vs Apache: różnice w licencjach oprogramowania

GPL a MIT a Apache: czego wymaga każda z licencji

GPL, MIT oraz Apache 2.0 odpowiadają na to samo pytanie w różny sposób: jakie zobowiązania powstają wobec innych osób w momencie przekazania oprogramowania dalej? Licencja MIT wymaga jedynie zachowania informacji o prawach autorskich. Apache 2.0 wymaga tej informacji oraz zawarcia porozumienia patentowego pomiędzy wszystkimi podmiotami modyfikującymi kod. GPL wymaga publikacji kodu źródłowego utworzonego rozwiązania na tej samej licencji, na której zostało ono otrzymane.

Zagadnienie to wydaje się domeną prawników, dopóki projekt, z którego korzystasz, nie zmieni licencji i nie podzieli się na dwie części. Wówczas staje się to problemem operacyjnym. Pojawia się konieczność wyboru między dwoma repozytoriami pakietów oraz problem bibliotek klienckich, które przestają ze sobą współpracować. Niniejszy przewodnik dotyczy licencji i ich mechanizmów, a nie ruchu, który je stworzył, dlatego każda sekcja kończy się w miejscu, w którym dotyczy ona bezpośrednio Ciebie: osoby odpowiedzialnej za przeprowadzenie aktualizacji.

Dlaczego istnieje GPL: drukarka, której nikomu nie wolno było naprawić

Około 1980 roku laboratorium sztucznej inteligencji MIT otrzymało drukarkę laserową Xerox 9700. Laboratorium zmodyfikowało oprogramowanie wcześniejszej drukarki, aby powiadamiała o zacięciu papieru. W przypadku nowego modelu kod źródłowy nie był dostępny, a prośba o jego udostępnienie została odrzucona ze względu na umowę o zachowaniu poufności. Richard Stallman, ówczesny programista w laboratorium, potraktował tę odmowę jako zjawisko powszechne, a nie incydent, i 27 września 1983 roku ogłosił projekt GNU.

Copyleft opiera się na prawie autorskim, a nie występuje przeciwko niemu. Domyślnie użytkownik nie posiada prawa do kopiowania cudzego kodu. Licencja GPL przyznaje to prawo pod pewnym warunkiem: jeśli przekazujesz program komuś innemu, musisz udostępnić mu kod źródłowy na tych samych zasadach, aby mógł on zrobić to, czego laboratorium nie mogło. Warunek ten jest egzekwowalny, ponieważ bez licencji użytkownik nie posiadałby żadnego zezwolenia na korzystanie z oprogramowania.

Stallman napisał licencję najpierw dla GNU Emacs, a następnie uogólnił ją do wersji GPL 1 w dniu 25 lutego 1989 roku. Wersja GPL 2 pojawiła się w czerwcu 1991 roku i nadal stanowi licencję dla większości oprogramowania systemowego. Licencja Lesser GPL powstała z myślą o bibliotekach, dzięki czemu biblioteka typu copyleft może być linkowana przez program na dowolnej licencji bez konieczności obejmowania tego programu licencją GPL.

Jeden szczegół decyduje o tym, jak GPL wpływa na użytkownika prowadzącego własny serwer (self-hoster). Obowiązek powstaje w momencie dystrybucji, a nie użytkowania. Można modyfikować program na licencji GPL, uruchamiać go na własnym serwerze i udostępniać publicznie, nie będąc nikomu nic winnym, ponieważ kopia programu nigdy nie została przekazana dalej. Ta luka jest powodem, dla którego istnieje licencja AGPL.

Tradycja permisywna: BSD, a następnie MIT

Berkeley obrało inną drogę. Grupa Computer Systems Research Group udostępniła swoje prace nad Unix na licencji, która wymagała zachowania informacji o prawach autorskich i wyłączała wszelką odpowiedzialność. Pierwotna wersja zawierała cztery klauzule, a czwarta z nich, dotycząca reklamy, wymagała wzmianki o Uniwersytecie w każdym materiale reklamowym wspominającym o funkcjach oprogramowania. Takie podejście nie jest skalowalne. Stallman doliczył się 75 oddzielnych podziękowań w wersji NetBSD z 1997 roku. UC Berkeley wycofało tę klauzulę 22 lipca 1999 roku w liście wystosowanym przez Williama Hoskinsa z Office of Technology Licensing.

To, co pozostało, to 3-klauzulowa licencja BSD, która dodaje zakaz używania nazwisk współtwórców do promowania własnego produktu, oraz wersja 2-klauzulowa, która rezygnuje nawet z tego zapisu. Tekst licencji MIT powstał w MIT w latach 80. XX wieku, gdzie obejmował X Window System, i w praktyce pełni tę samą funkcję co 2-klauzulowe BSD.

Motywy były odmienne. Uniwersytet finansowany ze środków publicznych chciał, aby jego praca była wykorzystywana wszędzie, w tym przez firmy. Projekt GNU dążył do stworzenia zasobów wspólnych, których nie można zamknąć. Obie postawy są uczciwe i obie mają swój tryb awarii. Kod permisywny może zostać przejęty przez podmioty prywatne, przez co autorzy nie otrzymują nic w zamian. Kod typu copyleft jest odrzucany przez firmy, których prawnicy nie akceptują nałożonych warunków.

Z historii Berkeley płynie druga lekcja, do której ten wpis stale powraca. W 1992 roku Unix System Laboratories należące do AT&T pozwało Berkeley Software Design w związku z kodem BSD, a sprawa zakończyła się ugodą na początku 1994 roku. Przez dwa lata nikt nie miał pewności, czy budowanie rozwiązań w oparciu o BSD jest bezpieczne, co wstrzymało adopcję systemu, podczas gdy Linux zyskiwał na popularności. Niepewność prawna hamuje adopcję szybciej niż brakująca funkcjonalność.

Dlaczego Apache 2.0 wprowadziło licencję patentową

Pierwsza licencja The Apache Group była pochodną licencji BSD 4-clause i zawierała ten sam problematyczny zapis dotyczący reklamy. Wersja 1.1, wydana w 2000 roku, usunęła ten punkt. Wersja 2.0, opublikowana w styczniu 2004 roku, była całkowitym przepisaniem tekstu, a nie tylko poprawką.

Istotnym dodatkiem są kwestie patentowe. Licencje MIT oraz BSD w ogóle o nich nie wspominają. Współtwórca może udzielić jasnego zezwolenia na korzystanie z praw autorskich do swojego kodu, jednocześnie posiadając patent na rozwiązanie, które ten kod implementuje, a następnie pozwać użytkowników tego oprogramowania. Licencja Apache 2.0 zamyka tę lukę: każdy współtwórca udziela licencji patentowej obejmującej jego wkład, a każdy, kto wytoczy powództwo twierdząc, że praca narusza jego patenty, traci własną licencję na to oprogramowanie. Zagrożenie jest obustronne, więc w praktyce nikt nie podejmuje takich działań.

Pozostałe elementy wersji 2.0 mają charakter administracyjny i dlatego firmy preferują tę licencję. Zdefiniowano plik NOTICE, dzięki czemu atrybucje znajdują się w jednym miejscu, zamiast być rozproszone w całym drzewie plików. Licencję można stosować poprzez odniesienie, zamiast wklejać ją do każdego pliku źródłowego. Wkłady są objęte jasnymi warunkami. Znaki towarowe są wyłączone z licencji. Analiza prawna zależności na licencji Apache 2.0 pozwala uzyskać odpowiedzi na wszystkie pytania zawarte w tekście, dzięki czemu zatwierdzenie staje się rutyną, co w dużej mierze definiuje pojęcie „standardu korporacyjnego”.

Co zmieniła licencja GPLv3 i dlaczego Linux pozostał przy GPLv2

Firma TiVo wprowadziła do sprzedaży rejestrator wideo działający pod kontrolą systemu Linux i udostępniła kod źródłowy jądra, zgodnie z wymogami licencji GPLv2. Sprzęt weryfikował jednak podpis kryptograficzny podczas rozruchu i odmawiał uruchomienia jądra, którego nie rozpoznawał. Użytkownik mógł odczytać kod, zmodyfikować go i skompilować, ale nie mógł uruchomić go na urządzeniu, z którego pochodził. Litera licencji została zachowana, lecz jej cel został podważony; praktyka ta zyskała miano tivoizacji.

Wydana 29 czerwca 2007 roku licencja GPL w wersji 3 bezpośrednio odnosi się do tego problemu. W przypadku dostarczania plików binarnych wewnątrz urządzenia konsumenckiego, należy również dostarczyć „Informacje instalacyjne”: klucze lub instrukcje niezbędne do zainstalowania zmodyfikowanej wersji i jej uruchomienia. Wersja 3 wprowadziła także wyraźne postanowienia dotyczące patentów, opracowane w odpowiedzi na porozumienie patentowe między Microsoft a Novell z listopada 2006 roku, oraz jednostronną kompatybilność z licencją Apache 2.0.

Linux nie przeszedł na tę licencję. Jądro jest objęte wyłącznie licencją GPL w wersji 2, bez klauzuli „lub dowolnej późniejszej wersji”, co potwierdza plik COPYING. Linus Torvalds publicznie sprzeciwił się zapisom anty-tivoizacyjnym dotyczącym sprzętu z weryfikacją podpisów. Bariera praktyczna jest jednak większa niż sam spór: jądro posiada tysiące właścicieli praw autorskich, więc nikt nie byłby w stanie zebrać zgód wymaganych do zmiany licencji, nawet gdyby wszyscy tego chcieli. Ten pojedynczy fakt stanowi najsilniejszą ochronę, jaką może mieć projekt, i warto o tym pamiętać, analizując projekty należące do jednej firmy.

Druga licencja z 2007 roku ma dla użytkownika większe znaczenie. GNU Affero GPL w wersji 3, opublikowana w listopadzie tego samego roku, rozszerza obowiązek udostępniania kodu źródłowego na osoby wchodzące w interakcję z programem za pośrednictwem sieci. Uruchomienie zmodyfikowanej usługi na licencji AGPL dla publiczności wiąże się z obowiązkiem udostępnienia kodu źródłowego tym użytkownikom. Dlatego tak wiele oprogramowania webowego do samodzielnego hostowania jest objęte licencją AGPL. Przykładem jest Nextcloud, a jeśli porównujesz alternatywy dla Nextcloud do samodzielnego hostowania, zapis o licencji w repozytorium każdego z kandydatów mówi o jego przyszłości przez kolejne 5 lat więcej niż lista funkcji.

Które licencje można ze sobą łączyć?

Zgodność licencyjna działa w jednym kierunku: od licencji permisywnych w stronę licencji typu copyleft.

• Kod na licencjach MIT oraz BSD można wykorzystać w dowolnym projekcie, w tym w produktach o zamkniętym kodzie źródłowym.
• Kod na licencji Apache 2.0 może zostać włączony do projektu na licencji GPLv3, a praca zbiorcza podlega wówczas licencji GPLv3.
• Kod na licencji Apache 2.0 nie może zostać włączony do projektu objętego wyłącznie licencją GPLv2. Postanowienia dotyczące wygaśnięcia patentu oraz odszkodowań stanowią dodatkowe warunki, których licencja GPLv2 nie pozwala wprowadzać. Zarówno FSF, jak i ASF potwierdzają ten wniosek.
• Kod na licencji GPL nie może zostać przeniesiony na licencję permisywną przez użytkownika. Mogą to zrobić wyłącznie właściciele praw autorskich, co ponownie prowadzi do pytania o ich tożsamość.

Era zmiany licencji: SSPL, BUSL i czym one nie są

Impulsem były względy komercyjne. Firma posiada prawa autorskie do produktu, dostawca chmurowy sprzedaje go jako usługę zarządzaną na dużą skalę, nie wnosząc w zamian istotnego wkładu, więc firma zmienia licencję, aby temu zapobiec. Redis Labs wykonało pierwszy widoczny ruch w sierpniu 2018 roku, dodając Commons Clause do licencji Apache 2.0 dla kilku swoich modułów. MongoDB poszło w ślady tej decyzji 16 października 2018 roku, przechodząc z AGPLv3 na Server Side Public License.

SSPL to AGPL z jedną przeredagowaną sekcją. Jeśli oferujesz program osobom trzecim jako usługę, musisz opublikować kod źródłowy wszystkiego, czego używasz do świadczenia tej usługi, w tym oprogramowania do zarządzania i orkiestracji. To zobowiązanie nie ma wyraźnych granic i żaden sąd go nie przetestował. OSI nigdy nie zatwierdziło tej licencji, a MongoDB wycofało swój wniosek w marcu 2019 roku. Debian już w grudniu 2018 roku stwierdził, że oprogramowanie na licencji SSPL nie powinno znajdować się w jego archiwach, a Fedora w styczniu 2019 roku orzekła, że licencja ta nie jest wolna, po czym Red Hat usunął MongoDB z Fedory oraz z Red Hat Enterprise Linux. Jest to mechaniczny skutek zmiany licencji: dystrybucja przestaje pakować oprogramowanie, więc aktualizacje pochodzą teraz z repozytorium dostawcy i zgodnie z jego harmonogramem.

Business Source License to inne rozwiązanie. Wywodzi się od założycieli MariaDB, a wersja 1.1 pochodzi z 2017 roku. Nie jest to licencja typu copyleft ani open source. Kod źródłowy jest publiczny, korzystanie z niego jest darmowe, z wyjątkiem zastosowań wykluczonych przez dostawcę, co zazwyczaj oznacza uruchamianie konkurencyjnej usługi hostowanej. Każde wydanie automatycznie przekształca się w prawdziwą licencję open source w dniu zmiany, nie później niż cztery lata po publikacji danego wydania. Licencja, na którą następuje konwersja, musi być zgodna z GPLv2. HashiCorp przeniósł Terraform i swoje pozostałe produkty na BUSL 1.1 w dniu 10 sierpnia 2023 roku. Outline również z niej korzysta, o czym warto wiedzieć, jeśli wybierasz rozwiązanie spośród alternatyw dla Notion z możliwością hostowania we własnym zakresie: uruchamianie go dla własnego zespołu jest dozwolone, ale budowanie na jego podstawie usługi komercyjnej – nie.

Żadna z tych licencji nie jest nieuczciwa. Obie jasno określają, że są to licencje typu source available. Żadna z nich nie jest open source według definicji OSI, a skutki tej różnicy odczujesz raczej Ty, a nie dostawca chmurowy, w którego wymierzono te zmiany.

OpenSearch: koszty forków licencyjnych dla operatora

Firma Elastic ogłosiła 14 stycznia 2021 roku, że Elasticsearch oraz Kibana przechodzą z licencji Apache 2.0 na SSPL lub Elastic License, począwszy od wydania 7.11. Wersja 7.10.2 była ostatnim wydaniem na licencji Apache 2.0. Około tydzień później AWS zapowiedział stworzenie i utrzymywanie forka obu projektów na licencji Apache 2.0. 12 kwietnia 2021 roku fork otrzymał nazwę OpenSearch, a Kibana została przemianowana na OpenSearch Dashboards. OpenSearch 1.0 stał się ogólnie dostępny 12 lipca 2021 roku, bazując na kodzie Elasticsearch 7.10.2 oraz Kibana 7.10.2.

Warto przyjrzeć się kosztom, jakie ponieśli operatorzy klastrów. Zmieniły się nazwy pakietów i repozytoria. Każde odniesienie do Kibana w dokumentacji operacyjnej musiało zostać zastąpione przez OpenSearch Dashboards. Zmieniono nazwy wtyczek. Następnie podział dotknął kodu aplikacji: od wersji 7.13 oficjalnych bibliotek klienckich Elastic, klient sprawdza, z czym nawiązuje połączenie i odmawia współpracy z czymkolwiek, co nie jest Elasticsearch, zgłaszając, że serwer jest nieznanym produktem. Decyzja licencyjna podjęta w firmie, w której nie pracujesz, objawiła się jako błąd wywołania wewnątrz twojej własnej aplikacji.

Historia ta miała jeszcze dwa zwroty. 29 sierpnia 2024 roku Elastic dodał AGPLv3 jako trzecią opcję licencyjną, więc obecny Elasticsearch ponownie jest oprogramowaniem open source zatwierdzonym przez OSI. 16 września 2024 roku AWS przekazał OpenSearch do OpenSearch Software Foundation, hostowanej przez Linux Foundation, co zapewniło forkowi zarządzanie niezależne od jednej firmy. Pięć lat po podziale oba projekty są open source, oba są utrzymywane, a OpenSearch w sierpniu 2026 roku znajduje się w serii 3.x.

Zakończenie jest lekcją. Licencja wróciła, ale fork pozostał. Gdy w ekosystemie istnieją dwie wersje wszystkiego, cofnięcie zmian formalnych nie powoduje ich ponownego połączenia.

Liczbą decydującą o tym, jak dotkliwa jest zmiana licencji, jest czas między ogłoszeniem a stabilnym forkiem, który można wdrożyć.

[
  {
    "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
  }
]

Każdy odstęp liczony jest od publicznego ogłoszenia dostawcy do pierwszego stabilnego wydania forka, przy użyciu dat wymienionych poniżej. OpenSearch 1.0 potrzebował 179 dni, ponieważ fork musiał zostać przemianowany i przebudowany bez wcześniejszego wzorca do skopiowania. OpenTofu potrzebował 153 dni. Valkey potrzebował 27 dni, ponieważ forkował Redis 7.2.4, zachowując identyczny protokół i format zapisu na dysku. Kierunek jest istotny: wiarygodny fork powstaje obecnie w ciągu tygodni, mając od pierwszego dnia zapewnione wsparcie fundacji i opłacanych opiekunów.

Valkey i OpenTofu: ten sam schemat, szybsze tempo

Firma Redis Ltd zmieniła licencję Redis z 3-clause BSD na wybór między RSALv2 a SSPLv1 w dniu 20 marca 2024 roku. Osiem dni później Linux Foundation ogłosiła powstanie Valkey, forka Redis 7.2.4, który pozostał na licencji BSD 3-clause. Wersja Valkey 7.2.5 pojawiła się 16 kwietnia 2024 roku, zachowując ten sam protokół i format plików danych, więc dla większości operatorów migracja sprowadziła się do zmiany nazwy pakietu. W maju 2025 roku, wraz z wydaniem Redis 8, firma Redis dodała AGPLv3 jako trzecią opcję, co zgodnie z definicją OSI ponownie czyni oprogramowanie open source, podczas gdy Valkey kontynuuje rozwój w ramach własnego modelu zarządzania. Sytuacja ta ściśle przypomina przypadek Elasticsearch.

Terraform przeszedł tę samą drogę z jednym dodatkowym rozdziałem. OpenTofu powstało jako fork ostatniego wydania na licencji Mozilla Public License 2.0, dołączyło do Linux Foundation we wrześniu 2023 roku i wydało wersję 1.6.0 w dniu 10 stycznia 2024 roku. 3 kwietnia 2024 roku prawnicy HashiCorp wysłali do projektu wezwanie do zaprzestania naruszeń (cease and desist), twierdząc, że kod z wydania Terraform na licencji BUSL został skopiowany do forka. OpenTofu opublikowało 11 kwietnia 2024 roku szczegółową odpowiedź, w której zaprzeczyło tym zarzutom i wskazało, że sporny kod pochodzi z historii na licencji MPL, którą dzielą oba projekty. Publicznie nie podjęto dalszych kroków. Prawdziwym ryzykiem w tym epizodzie, o którym należy pamiętać, jest fakt, że samo oskarżenie może wstrzymać adopcję technologii na kwartał, co daje ten sam efekt, jaki trzydzieści lat wcześniej wywołał pozew sądowy przeciwko Berkeley.

Nie każdy fork zaczyna się od kwestii licencyjnych. Forgejo powstało jako fork Gitea w 2022 roku, po tym jak rozwój Gitea przeszedł pod kontrolę firmy, co było sporem o model zarządzania, a nie o licencję. Forgejo pozostało na licencji MIT aż do serii wersji 8, po czym od wersji 9.0 w 2024 roku zmieniło licencję na GPLv3 lub nowszą, aby uniemożliwić włączenie jego kodu z powrotem do komercyjnie kontrolowanego produktu. Jeśli rozważasz opcje samodzielnie hostowanego serwera Git, ta para stanowi najjaskrawszy przykład jednego kodu źródłowego i dwóch różnych filozofii.

Testy do wykonania przed wdrożeniem jakiegokolwiek rozwiązania

Cztery pytania, które należy zadać przed pierwszą instalacją, a nie po niej.

1. Kto posiada prawa autorskie? Zmiana licencji wymaga zgody każdego właściciela praw autorskich, więc projektu z setkami niezależnych współtwórców i brakiem przeniesienia praw nie da się w praktyce przelicencjonować. Projekt, w którym jedna firma posiada całość praw, może zostać przelicencjonowany na posiedzeniu zarządu.
2. Czy istnieje CLA i co ono gwarantuje? Umowa licencyjna współtwórcy (Contributor Licence Agreement), która pozwala firmie na zmianę licencji wkładu na dowolną inną, jest mechanizmem stojącym za każdą wspomnianą zmianą licencji. DCO (Developer Certificate of Origin), czyli linia podpisu przyjęta w jądrze Linux w 2004 roku, nie przenosi żadnych praw. CLA zarządzane przez fundację jest bezpieczniejsze niż to należące do firmy, ponieważ firmę można sprzedać.
3. Kto posiada znak towarowy? Firma Elastic zachowała nazwę Elasticsearch, więc fork musiał zmienić nazwę, a każdy podręcznik operacyjny wspominający o Kibana musiał zostać przepisany.
4. Ile kosztowałaby Cię osobiście zmiana licencji? Policz format danych, biblioteki klienckie, konfigurację, którą musiałbyś przepisać, oraz sprawdź, czy istnieje już kompatybilny fork.

Dwa polecenia odpowiadają na część tych pytań w kilka sekund.

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

Każdy pakiet w systemach Debian i Ubuntu zawiera plik w /usr/share/doc/<package>/copyright, który rejestruje licencję zainstalowanej wersji, a nie licencję, której projekt używa obecnie. Dla bash w systemie Ubuntu 24.04 plik ten wskazuje na GNU General Public License version 3. Wykonaj drugie polecenie wewnątrz pobranego kodu źródłowego, aby uzyskać historię samego pliku licencji. Warto przeczytać każdy commit z ostatnich dwóch lat, zanim zbudujesz cokolwiek w oparciu o ten projekt. Jeśli polecenie nic nie wyświetla, repozytorium używa innej nazwy pliku licencji, więc wyświetl zawartość katalogu głównego i sprawdź.

Żadna licencja nie chroni przed każdym scenariuszem, a wybieranie rozwiązań w oparciu o ideologię prowadzi do rozczarowań. Preferuj projekty, których prawa autorskie są rozproszone między wielu właścicieli lub należą do fundacji, a dane przechowuj w formacie, który można wyeksportować. Następnie ustal, do którego forka mógłbyś przejść, i zapisz jego nazwę, zanim będzie potrzebna. Zastosowanie tej weryfikacji do każdego kandydata zajmuje mniej niż godzinę i to właśnie ona odróżnia aktualizację od migracji, gdy decydujesz co hostować samodzielnie w 2026.

FAQ

Czy licencja MIT jest taka sama jak licencja BSD?

W praktyce MIT odpowiada 2-klauzulowej licencji BSD: należy zachować informację o prawach autorskich oraz wyłączenie odpowiedzialności, a następnie można postępować z kodem dowolnie, w tym tworzyć produkty zamknięte. 3-klauzulowa licencja BSD dodaje jeden warunek: zakaz używania nazwisk współtwórców do promowania produktu bez ich zgody. Starsza, 4-klauzulowa wersja wymagała również zamieszczenia wzmianki w materiałach reklamowych, jednak UC Berkeley wycofał ten zapis 22 lipca 1999 roku, więc niemal żaden współczesny projekt go nie zawiera.

Czy mogę umieścić kod na licencji Apache 2.0 w projekcie GPLv2?

Nie. Apache 2.0 dodaje warunki, których GPLv2 nie dopuszcza, przede wszystkim klauzulę wygaśnięcia patentu, dlatego praca łącząca oba te kody nie może jednocześnie spełniać wymagań obu licencji. Zarówno FSF, jak i ASF publikują to stanowisko. W drugą stronę to działa: kod Apache 2.0 można włączyć do projektu GPLv3, a wynikowy produkt jest objęty licencją GPLv3. Jest to również powód, dla którego kod Apache 2.0 nie może zostać scalony z jądrem Linux, które jest dostępne wyłącznie na licencji GPL w wersji 2.

Czy SSPL jest licencją open source?

Nie, a odpowiedź ta niesie ze sobą praktyczne konsekwencje. OSI nigdy jej nie zatwierdziło, a MongoDB wycofało swój wniosek w marcu 2019 roku. Debian stwierdził w grudniu 2018 roku, że oprogramowanie na licencji SSPL nie powinno znajdować się w jego archiwach, a Fedora w styczniu 2019 roku uznała, że licencja ta nie jest wolna, po czym Red Hat usunął MongoDB z Fedory oraz Red Hat Enterprise Linux. Dla użytkownika oznacza to, że pakiet, który wcześniej był utrzymywany przez dystrybucję, pochodzi teraz z repozytorium dostawcy i podlega jego harmonogramowi wsparcia. Business Source License również jest licencją typu source available, a nie open source, chociaż każde wydanie po czterech latach zmienia licencję na open source.

Czy zmiana licencji dotyczy wersji, którą już uruchamiam?

Nie. Licencja udzielona wraz z wydaniem nie może zostać cofnięta dla kopii już opublikowanych, co jest powodem, dla którego możliwe są forki. OpenSearch został zbudowany na bazie Elasticsearch 7.10.2, czyli ostatniego wydania, które Elastic opublikował na licencji Apache 2.0. Użytkownik traci przyszłe aktualizacje, ponieważ kolejne poprawki bezpieczeństwa są udostępniane na nowych warunkach. Zablokowanie wersji na ostatniej liberalnej licencji pozwala zyskać kilka miesięcy, ale nie jest to rozwiązanie długofalowe.